 TechNet Magazine February 2008

TechNet Magazine February 2008

SharePoint: Un approccio intelligente alla raccolta di dati nelle aziende

Le informazioni sono tra i beni più preziosi di un'azienda. Può tuttavia risultare difficile gestire la montagna di dati che si raccolgono tramite posta elettronica, moduli basati sul Web, sondaggi e altri meccanismi. Microsoft Office System aiuta a integrare i sistemi e a rendere i dati più accessibili.

Keith Deshaies SharePoint: Creazione di una potente infrastruttura di sondaggio

La raccolta e l'analisi dei dati è una parte essenziale dei processi aziendali, ma sono necessari strumenti che consentano a team indipendenti di raccogliere i dati necessari quando ne hanno bisogno. È possibile utilizzare WSS 3.0, MOSS 2007 e InfoPath 2007 per creare una soluzione di sondaggio flessibile e completa da impiegare in tutta l'organizzazione.

Jim Bradley SharePoint: Standardizzazione della gestione dei dati con tipi di contenuto personalizzati

L'elevato numero di documenti differenti e di altri elementi di contenuto archiviati all'interno di un'organizzazione di grandi dimensioni può rendere piuttosto difficoltosa la gestione centralizzata dei documenti, dei metadati associati e delle relative caratteristiche. In questo articolo viene illustrato come utilizzare i tipi di contenuto in SharePoint 2007 per semplificare la gestione del contenuto all'interno dell'organizzazione.

Pav Cherny Office Communications Server: Ottimizzazione della potenza di OCS 2007 tramite la presenza

Office Communications Server 2007 utilizza le informazioni sulla disponibilità degli utenti per eseguire il routing delle comunicazioni alle posizioni più appropriate, indipendentemente dal tipo di comunicazione, una chiamata vocale, una conferenza video, un messaggio di posta elettronica o un messaggio immediato. Scopri come il sistema OCS 2007 utilizza la presenza per connettere gli endpoint.

Rajesh Ramanathan Office Communications Server: Pianificazione della distribuzione di Enterprise Voice per OCS 2007

L'integrazione di Office Communications Server 2007 con un sistema PBX esistente può rivelarsi un'attività piuttosto complessa. È necessario selezionare uno scenario di integrazione, comprendere il routing delle chiamate, saper configurare le impostazioni utente, gestire piani di numerazione e molto altro. Nessun problema: in questa panoramica verrà illustrato tutto ciò che serve sapere.

Jochen Kunert and Rui Maximo Soluzioni HPC (High Performance Computing): Un'introduzione a Windows Compute Cluster Server

Per i sistemi di calcolo ad altre prestazioni, piuttosto che basarsi su grandi sistemi specializzati, si utilizzano cluster di sistemi standard più piccoli. La distribuzione del carico di lavoro costituisce una soluzione economica per la rapida soluzione di problemi complessi. Nell'articolo si esplorano le funzionalità dei cluster di calcolo e il supporto offerto da Windows Compute Cluster Server 2003.

John Kelbley and Doug Lindsey Ulteriori informazioni in linea: Distribuzione di Office System 2007 con Servizi terminal

Microsoft Office System 2007 include modifiche di progettazione che è necessario prendere in considerazione prima della distribuzione di tale sistema nella server farm in cui viene eseguito Servizi terminal. In questo articolo viene fornita una panoramica delle modifiche.

James D. Silliman Dal redattore: Gestione del sovraccarico di informazioni

Joshua Hoffman Lettere: La parola ai lettori

Casella degli strumenti: Nuovi prodotti per professionisti IT

Greg Steen Domande e risposte su SQL: Indici non raggruppati e conservazione delle autorizzazioni

Saleem Hakani and Dan Carollo Utilità in primo piano: ADMX Migrator

In Windows Vista il formato per i modelli di Criteri di gruppo è diventato una struttura basata su XML. L'utilità ADMX Migrator consente di convertire i file ADM legacy nel nuovo formato ADMX e facilita la creazione di file ADMX personalizzati.

Lance Whitney The Cable Guy: Autenticazione per reti cablate IEEE 802.1X

L'autenticazione IEEE 802.1X è una barriera di protezione aggiuntiva per l'accesso a Intranet. Ecco in che modo Windows Vista e Windows Server 2008 semplificano l'implementazione dell'autenticazione IEEE 802.1X per le reti cablate.

Joseph Davies Windows PowerShell: Autorizzazioni della shell

Le autorizzazioni in Windows sono, purtroppo, per propria natura molto complesse. Tuttavia, Windows PowerShell può rivelarsi da questo punto di vista particolarmente utile. Di seguito è riportata una breve panoramica del funzionamento delle autorizzazioni in Windows e vengono fornite informazioni su come semplificarne l'utilizzo.

Don Jones Hey, Scripting Guy!: Le Olimpiadi sono alle porte (oltre a un po' di XML)

Gli Scripting Guy di Microsoft si stanno preparando senza posa alle Olimpiadi dello scripting del 2008 e spiegano anche come creare, aggiungere e modificare i documenti XML. Comunque, hai mai sentito parlare delle Olimpiadi dello scripting del 2008?

The Microsoft Scripting Guys Controllo della protezione: Island hopping: limitazione delle dipendenze non desiderate

Le dipendenze di protezione non desiderate possono esporre l'intera rete ad attacchi. Scopri la dinamica di funzionamento delle dipendenze di protezione in modo da poter analizzarle nell'ambiente in uso e risolvere potenziali problemi.

Jesper M. Johansson File desktop: Avvio doppio con Windows XP e Windows PE 2.0

L'avvio di Windows PE 2.0 dalla stessa partizione di Windows comporta diversi vantaggi. Nell'articolo si spiega come ottenere un avvio doppio di Windows XP e Windows PE 2.0 dalla stessa partizione e vengono illustrati i problemi che si risolvono con questa soluzione.

Wes Miller Taccuino: La donazione di dispositivi informatici

Quando si regala e riutilizza un vecchio computer, si evita che l'hardware finisca in discarica e si aiuta a salvaguardare l'ambiente. Questi utili suggerimenti insegnano a eliminare in modo definitivo i dati personali da un vecchio computer, preparandolo a un successivo riutilizzo.

Jim Lynch Windows Confidential: Eliminazione delle funzionalità obsolete

Ecco la storia di come siano state eliminate un paio di funzionalità non tanto apprezzate.

Raymond Chen


 SharePoint: Un approccio intelligente alla raccolta di dati nelle aziende
SharePoint Keith Deshaies

Un approccio intelligente alla raccolta di dati nelle aziende
Panoramica:
  • Raccolta ed elaborazione dei dati
  • Separazione della logica di presentazione dalla logica di gestione delle informazioni
  • Utilizzo delle tecnologie di Microsoft Office 2007 per la creazione di una soluzione di raccolta dei dati
Scarica il codice per questo articolo: DataGathering2008_02.exe (567KB)

Nelle aziende si raccolgono grandi quantità di informazioni utilizzando metodi diversi. I dati arrivano tramite posta elettronica, sondaggi, moduli Web e altri meccanismi di raccolta dei dati. La disponibilità di dati, di solito, è una buona
cosa. Tuttavia, la gestione di una pletora di strumenti di raccolta dei dati e di tutte le informazioni più disparate è un compito complesso. L'integrazione affidabile e la condivisione protetta dei dati sono delle sfide costanti per le organizzazioni IT. Le architetture standard e orientate ai servizi si evolvono e consentono ai professionisti IT di rendere i dati più accessibili, in modo più protetto. Ma se da un lato sono disponibili tutti gli strumenti e le tecnologie necessarie per creare un'architettura aziendale efficiente, è fin troppo facile restare imprigionati in una selva di interfacce proprietarie, con la conseguente produzione di soluzioni isolate.
Le tecnologie disponibili in Microsoft® Office System sono un valido esempio. È possibile creare rapidamente un sondaggio in un reparto basato su Windows® SharePoint® Services 3.0, ma se questo poi diventa una soluzione standard dipende solo dall'organizzazione. Se l'azienda utilizza ASP.NET e SharePoint come piattaforma per l'integrazione di collaborazione basata sul Web e dati, il sondaggio costituisce una soluzione standard. Se invece l'ambiente somiglia a quello in cui lavoro io, SharePoint è solo una delle tante piattaforme.
SharePoint è dotato di molte opzioni per l'integrazione con sistemi quali IBM, HP, Siebel e così via. Questa è un'ottima notizia per gli utenti avanzati che vogliono creare soluzioni ad hoc e ricevono ancora flussi di dati in una varietà di sistemi back-end. Tuttavia, per gli architetti di soluzioni esiste una soluzione ancora migliore: InfoPath ® 2007.
Con InfoPath 2007, che è parte di Office System 2007, è possibile separare la logica di presentazione delle soluzioni dalla logica di gestione delle informazioni ospitata sui server. Con la tecnologia di InfoPath basata su XML, si possono creare soluzioni di raccolta dei dati su misura per l'azienda. In genere, inoltre, chi si occupa di progettare i moduli di InfoPath non deve necessariamente conoscere a fondo il linguaggio XML, i servizi Web, le architetture delle soluzioni, ASP.NET o il modello a oggetti di SharePoint.
In questo articolo si illustrerà la creazione di soluzioni di raccolta dei dati flessibili con InfoPath 2007, Office SharePoint Server 2007 e Forms Services. Si dimostrerà inoltre come XML consenta di separare la logica di presentazione dalla logica aziendale in un'architettura aziendale multilivello.
Quando si parla di "raccolta dei dati", si fa riferimento al processo di raccolta delle informazioni da fonti umane. Esistono, ovviamente, altri metodi per raccogliere i dati, come eseguire ricerche nelle origini dati, ma i metodi automatici non sono tra gli argomenti dell'articolo.

Acquisizione e gestione dei dati
I requisiti di acquisizione dei dati possono essere complessi, ma i processi hanno alcune cose in comune. Se si sfruttano le somiglianze con moduli centralizzati gestendo i requisiti univoci in componenti decentralizzati, è possibile limitare il lavoro ridondante, una manutenzione eccessiva e il costo totale di proprietà.
La conformità alle normative, ad esempio, per le aziende pubbliche producono dei requisiti aziendali che si traducono a propria volta in criteri di gestione delle informazioni nell'intera azienda. I criteri influiscono sulle soluzioni di raccolta dei dati nei diversi reparti e conducono spesso a una duplicazione del lavoro all'interno dei singoli reparti. Ne sono un esempio le normative per la raccolta di informazioni personalmente identificabili da parte di un ufficio del personale (con la gestione delle informazioni sui dipendenti) e di un reparto di assistenza ai clienti (con la gestione delle informazioni sui clienti). Anche i processi aziendali tra i singoli reparti che sono simili, ma non correlati, rappresentano un'opportunità per unificare le soluzioni di gestione delle informazioni.
Nella Figura 1 viene illustrato un esempio di processo aziendale tipico. Un dipendente che intende scambiare un incarico con un collega deve ottenere prima un consenso dal collega, quindi l'approvazione da un responsabile o coordinatore della pianificazione dell'incarico e, infine, dal supervisore. Lo scambio potrebbe comportare, ad esempio, un cambiamento nei turni di lavoro. Anche se questi scambi si verificano in reparti diversi e potrebbero prevedere l'impiego di moduli diversi, la logica dei flussi di lavoro e della gestione delle informazioni può essere condivisa fra le varie soluzioni dei reparti.
Figura 1 Processo di esempio di raccolta dei dati che può essere condiviso fra i reparti
Figura 1 Processo di esempio di raccolta dei dati che può essere condiviso fra i reparti
Il consolidamento dei componenti ridondanti è, naturalmente, un'attività molto impegnativa. Apportare delle modifiche di carattere organizzativo nell'intera azienda non è facile, ma con le tecnologie di Office System è possibile gettare delle fondamenta solide per le modifiche. InfoPath 2007 consenti ai singoli reparti di creare applicazioni a moduli che si integrano con i sistemi di gestione delle informazioni centralizzati e standardizzati,. SharePoint 2007, nel frattempo, consente ai reparti IT di delegare il controllo amministrativo su raccolte di siti, siti e raccolte documenti ai singoli reparti e team. Di conseguenza, i team possono creare e distribuire le proprie soluzioni con un coinvolgimento minimo del reparto IT, a cui resta la responsabilità del controllo di tutti i servizi e componenti condivisi, come i flussi di lavoro, i criteri di gestione delle informazioni e le procedure di backup.

Centralizzazione del lavoro di raccolta dei dati
Le aziende spesso affidano ai team dei server applicazioni dipartimentali per soddisfare le esigenze particolari di gestione delle informazioni. Al reparto IT viene semplicemente attribuita la responsabilità del corretto funzionamento di hardware e sistema operativo, mentre i singoli reparti si occupano di tutti gli altri aspetti delle soluzioni personalizzate. La coordinazione tra i reparti è scarsa e la condivisione delle informazioni è difficile.
Le sfide tecniche per la centralizzazione del lavoro di raccolta dei dati riguardano principalmente la protezione, le prestazioni, la manutenzione e il supporto dei componenti personalizzati ospitati in un ambiente condiviso. Gli effetti di un componente che non funziona, ad esempio, restano isolati quando le singole soluzioni sono ospitate sui server applicazioni dipartimentali. In un ambiente condiviso, tuttavia, un componente che non funziona può coinvolgere i processi aziendali su una scala molto più ampia. Ne consegue che il reparto IT deve stabilire dei criteri rigorosi sulla distribuzione e manutenzione dei componenti personalizzati nei sistemi centralizzati.
Per ospitare le soluzioni SharePoint dipartimentali in una server farm centralizzata, è necessario distribuire e gestire tutti i componenti personalizzati delle soluzioni dipartimentali sui server applicazioni centralizzati. Una possibile soluzione si basa sui tipi di campo personalizzati, per estendere l'interfaccia utente della soluzione con elenchi a discesa precompilati dai servizi Web back-end. Un'altra possibile soluzione si basa, allo stesso scopo, sulle Web part mentre un'altra ancora prevede l'utilizzo dei flussi di lavoro personalizzati. Tutte le soluzioni sono comunque scritte in codice gestito e distribuite come assembly di Microsoft .NET Framework.
Lo spostamento anche di un numero relativamente ridotto di soluzioni SharePoint a una server farm applicazioni centralizzata può implicare difficoltà di configurazione e problemi di supporto. Se gli assembly devono essere distribuiti nella Cache di assembly globale (GAC), la protezione diventa un problema perché gli assembly vengono eseguiti con attendibilità totale. I componenti programmati in modo non ottimale potrebbero esporre il sistema ad attacchi intrusivi nel codice SQL, attacchi con script da altri siti o attacchi Denial of Service. È necessario verificare che i componenti possano sostenere il carico di lavoro tipico, oltre ai picchi di richieste e alle operazioni a esecuzione prolungata. È inoltre necessario verificare che i componenti non blocchino altri processi, gestendo gli eventi in modo sincrono, e che i componenti eseguano convalide degli input affidabili. In tal modo si impedirà agli utenti di inserire istruzioni SQL o script nelle colonne utilizzate per aggiornare un database o un sistema Web remoto.
In breve, lo scopo è enfatizzare una configurazione protetta e scalabile dei server basata su funzionalità di prodotto standard. L'adozione di soluzioni riutilizzabili e testate a fondo consente di evitare la trappola rappresentata dalla creazione di troppi componenti personalizzati. È utile decentrare il front-end e centralizzare il back-end. La chiave è l'integrazione dei componenti in associazioni non rigide, in modo da promuovere il riutilizzo delle soluzioni esistenti

Divisione della logica aziendale
Come è quindi possibile creare soluzioni di raccolta dei dati flessibili, che possano essere configurate sui server? La strategia migliore consiste nel separare l'architettura della soluzione in singoli livelli come illustrato nella Figura 2: archiviazione dei dati, logica aziendale e presentazione o interfaccia utente. Oggi l'interfaccia utente è in genere basata sul browser, mentre la logica aziendale risiede sui server delle applicazioni Web. I server, a propria volta, accedono a database e archivi di dati non relazionali.
Figura 2 Una soluzione aziendale tipica creata su un'architettura a tre livelli
Figura 2 Una soluzione aziendale tipica creata su un'architettura a tre livelli
La logica aziendale comprende spesso la logica di transazione, per garantire che le transazioni vengano applicate automaticamente ai sistemi di gestione dei database. La logica aziendale può comprendere anche più servizi di livello intermedio tramite HTTP, code dei messaggi, RPC e così via. L'architettura complessiva della soluzione, tuttavia, resta sostanzialmente un modello a tre livelli.
Ciò che nella Figura 2 non viene illustrato, è la complessità della logica aziendale nell'ambiente di una grande azienda. Sembra che il server applicazioni in questa figura si limiti a eseguire il rendering di un modulo basato su browser e a gestire i dati inviati; ma la rappresentazione non tiene conto dei requisiti di flussi di lavoro, conformità o gestione delle informazioni. Per rispondere a questi requisiti, è necessario dividere la logica aziendale in due: logica di presentazione e logica di gestione delle informazioni. La divisione consente di combinare e associare i componenti di livello intermedio in base alle esigenze, senza ricreare i componenti da capo per ciascuna soluzione.
Nella Figura 3 è illustrata questa architettura. In definitiva il contenuto, nel corso del suo ciclo di vita, viene governato dai dati, racchiusi nella logica di gestione delle informazioni. La logica di presentazione si interfaccia alla logica di gestione delle informazioni per garantire l'accesso ai dati tramite l'interfaccia utente.
Figura 3 Separazione della logica di presentazione dalla logica di gestione delle informazioni
Figura 3 Separazione della logica di presentazione dalla logica di gestione delle informazioni

Raccolta ed elaborazione di XML
Negli ambienti delle applicazioni orientate ai servizi (SOA), XML è lo standard dominante utilizzato per la definizione e condivisione di dati e strutture di dati tra i componenti. XML, quindi, rappresenta un'ottima interfaccia tra i componenti di presentazione e di gestione delle informazioni.
La comunicazione deve muoversi in due direzioni: è necessario tradurre il codice XML in un documento leggibile dai browser, oltre che in un documento XML generato dal modulo. Fino a qualche tempo fa, per la creazione di applicazioni a moduli basate su XML erano necessarie competenze approfondite nel campo della programmazione. Questo era particolarmente vero quando i dati XML risultanti dovevano aderire a uno schema di settore per facilitare lo scambio di informazioni tra le organizzazioni.
InfoPath 2007 semplifica di molto lo sviluppo di moduli basati su XML. Certo una buona conoscenza dei dettagli dell'XML resta utile, ma progettisti e utenti esperti non devono essere maghi dell'XML per creare delle applicazioni con moduli basati su XML. Chi progetta il modulo deve semplicemente importare uno documento XML o uno schema XML in InfoPath e associare i singoli nodi di attributi ed elementi dell'origine dei dati e dei campi del modello. Il progettista inoltre può assumere come punto di partenza un servizio Web o un database di SQL Server® oppure un modello vuoto e creare un modulo da zero mentre InfoPath crea automaticamente lo schema sottostante e le associazioni di dati in background.
La standardizzazione dei moduli con gli schemi InfoPath e XML offre molti vantaggi. Quando è già disponibile uno schema XML ben definito, chi progetta i moduli e sviluppa flussi di lavoro e componenti di gestione delle informazioni ha la possibilità di creare delle soluzioni a fronte delle stesse strutture di dati. Se un progettista di moduli inizia da zero, gli sviluppatori devono restare in attesa del modulo definitivo prima di poter valutare in che modo questo influisca sulle strutture di dati sottostanti. Una volta definite le strutture di dati, inoltre, per le soluzioni future, come i nuovi modelli di moduli, si potranno riutilizzare i flussi di lavoro e i componenti di gestione delle informazioni esistenti che poggiano sulle medesime strutture di dati. I flussi di lavoro e i componenti di gestione delle informazioni futuri si integreranno ai moduli e ai dati esistenti. Se si creano le soluzioni di raccolta dei dati in base a schemi standard del settore, i risultati diventano ancora più flessibili. Infatti, le soluzioni saranno compatibili con le soluzioni create da altre aziende che utilizzano gli stessi schemi.
Ho creato un semplice schema DirectReports, che associa i dipendenti ai responsabili. Questi ultimi possono utilizzare il modulo che ne risulta per valutare i report diretti. Lo schema, il modulo e il file readme.htm con le istruzioni per ricreare il modulo nella cartella Direct Reports sono disponibili nel download che accompagna l'articolo, all'indirizzo technetmagazine.com/code08.aspx. Il modulo è molto semplice, ma illustra il concetto generale.
Un punto molto importante è il seguente: Non ho creato alcuna logica di convalida in InfoPath, anche se InfoPath richiede che ID utente e indirizzi di posta elettronica vengano immessi in un formato specifico (dominio\account e destinatario@dominio.tld). In caso contrario, il documento di XML che ne risulta non è valido. Ciò accade perché lo schema XML definisce questi formati. È possibile salvare il modulo con dei dati non validi, ma non è possibile inviarlo, come illustrato nella Figura 4. Al modulo è stata aggiunta una regola di invio fittizia, in modo che si possa verificare questo comportamento senza inviare effettivamente i dati ad altre posizioni. La convalida di InfoPath 2007 garantisce automaticamente che il modulo venga compilato in modo completo, senza errori di sorta.
Figura 4a Un modulo con errori di convalida non può essere inviato
Figura 4a Un modulo con errori di convalida non può essere inviato
Figura 4b Il messaggio di errore generato
Figura 4b Il messaggio di errore generato
Lo schema XML ha la funzione di contratto di associazione tra la logica di presentazione e la logica di gestione delle informazioni. InfoPath blocca lo schema, in modo che il progettista di moduli non possa modificare le strutture di dati. Si tratta di una funzionalità importante, perché la modifica di uno schema XML prestabilito può provocare problemi alle soluzioni aziendali esistenti, come i moduli del flusso di lavoro che si intende utilizzare in combinazione con il nuovo modello di modulo.
InfoPath è dotato di molte funzionalità utili per l'implementazione di una logica di presentazione avanzata nelle applicazioni con moduli. È possibile utilizzare dati da file XML, servizi Web, raccolte ed elenchi SharePoint, database e così via per incorporare i valori predefiniti significativi. È possibile modificare i valori dei campi in base alle selezioni degli utenti utilizzando delle regole, implementare una logica di convalida, aggiungere codice gestito per i requisiti di personalizzazione più avanzati e utilizzare Forms Service per rendere il modello di modulo accessibile sul Web. In ogni caso i dati del modulo raggiungono alla fine la logica di gestione delle informazioni come documento XML conforme a una definizione dello schema.

Utilizzo di XML o metadati
È lecito a questo punto chiedersi se è preferibile applicare la logica di gestione delle informazioni direttamente al documento XML inviato oppure utilizzare un parser che estrae le informazioni richieste nei metadati. SharePoint supporta entrambi gli approcci. Gli sviluppatori sono abituati a lavorare direttamente sui documenti XML, ma i metadati offrono una maggiore flessibilità.
A fini dimostrativi, è stato creato un semplice servizio Web che analizza un documento XML passato dal modulo Direct Reports illustrato nella Figura 4a (il codice sorgente, i file di installazione ed un file readme.htm con le istruzioni dettagliate sono disponibili nella cartella XMLParsingWebService del download). Il servizio Web si limita a leggere l'ID utente del responsabile dal documento XML, dividere l'ID utente nelle parti di dominio e nome utente, creare un messaggio basato su tali parti e generare un'eccezione generica per restituire e visualizzare le informazioni elaborate nel modulo di uno pseudomessaggio di errore nel modulo InfoPath. Questo è un semplice modo per far apparire una finestra di dialogo in InfoPath dopo l'invio dei dati. Il servizio Web funziona bene, ma se si modifica l'origine dati sottostante (ad esempio, rinominando l'elemento OrgPerson come Manager in DirectReports.xsd e aggiornando il modulo InfoPath con il nuovo schema come delineato nel file readme.htm) si verifica un errore. Questo non deve sorprendere. Il documento XML ora è diverso e l'espressione XPath precedente per l'accesso all'elemento dell'ID utente non è valido. Gli schemi OrgPerson e Manager sono quasi identici, i moduli InfoPath sono identici e i risultati di elaborazione desiderati sono gli stessi ma, sebbene le differenze siano minime, resta necessario distribuire e gestire servizi Web duplicati.
Non è un buon approccio se si desidera minimizzare l'impatto in termini di codice personalizzato sui server applicazioni. Al contrario, se si associano i nodi XML ai campi di metadati e si esegue l'elaborazione in base ai metadati, è possibile utilizzare gli stessi flussi di lavoro e logica di gestione delle informazioni per strutture di dati simili, anche se gli schemi XML differiscono. Per riutilizzare il codice esistente, è sufficiente verificare che l'elemento figlio venga associato al campo di metadati corretto e che il formato dei dati soddisfi i requisiti di elaborazione.
L'associazione dei nodi XML ai campi di metadati è un'operazione simile all'associazione dei nodi XML ai controlli dell'interfaccia utente in un formato InfoPath, come illustrato nella Figura 5. In SharePoint i campi di metadati corrispondono a colonne definite a livello di sito o elenco e a cui si fa riferimento nelle definizioni di tipo di contenuto. I tipi di contenuto definiscono le caratteristiche degli elementi di contenuto, come i campi di metadati, i flussi di lavoro e i moduli. Per tenere sincronizzati i campi di metadati di un tipo di contenuto con i nodi corrispondenti nel documento XML associato, SharePoint utilizza un parser XML incorporato che esegue la promozione e il declassamento delle proprietà. Durante la promozione delle proprietà, il parser XML estrae i valori del nodo da un documento XML nelle colonne corrispondenti della raccolta documenti. Il declassamento delle proprietà si riferisce al processo inverso, con i valori delle colonne che vengono prelevati dalla raccolta documenti e scritti nel documento. Il punto più importante è la capacità del parser XML di tenere sincronizzati i campi di metadati e i nodi XML associati.
Figura 5 Associazioni dello schema di XML tra InfoPath e SharePoint
Figura 5 Associazioni dello schema di XML tra InfoPath e SharePoint
Quando si utilizza il modello a oggetti SharePoint, le web part, i flussi di lavoro e la logica di gestione delle informazioni corrispondente possono essere utilizzati sia con i campi di metadati che con i documenti XML sottostanti. La modifica del valore di un campo di metadati associato comporta la modifica del valore del nodo nel documento XML e viceversa. Quando si lavora direttamente con il documento XML, si correla in modo stretto la logica aziendale allo schema XML. I campi di metadati associati, d'altra parte, fanno aumentare il tasso di riutilizzabilità del codice. È quindi necessario individuare l'approccio più adatto al proprio ambiente, ma in generale le soluzioni SharePoint basate sui campi di metadati garantiscono maggiore flessibilità e maggiori opportunità di riutilizzo del codice.
Per illustrare il meccanismo di associazione dei nodi XML ai campi di metadati in SharePoint, nel materiale di esempio è stato inclusa una funzionalità SharePoint per fornire dati a una raccolta documenti personalizzata (vedere il file OrgPersonContentType.xml che si trova nella cartella OrgPersonLib del download). Il tipo di contenuto OrgPerson fa riferimento a quattro campi: UserID, FullName, EMail e Direct_x0020_Reports. FullName ed EMail sono campi incorporati. UserID and Direct_x0020_Reports sono campi personalizzati definiti in OrgPersonSiteColumns.xml.
Le definizioni dei campi sono relativamente semplici. È possibile associare i campi ai nodi XML direttamente nelle definizioni dei campi, come è d'altra parte possibile sovrascrivere queste informazioni nei tipi di contenuto. Si è deciso di utilizzare quest'ultima tecnica perché in tal modo è possibile utilizzare i campi personalizzati in tipi di contenuto non correlati a documenti XML, oltre che in tipi di contenuto basati su strutture XML diverse. Il tipo di contenuto OrgPerson associa i campi di metadati ai nodi XML che corrispondono, come disposizione, allo schema OrgPerson illustrato in precedenza. Esiste anche un file AdditionalContentTypes.xml che definisce altri tipi di contenuto che associano gli stessi campi di metadati a nodi XML diversi. È possibile notare le differenze esaminando le espressioni XPath negli attributi Node.
Nelle raccolte documenti del tipo OrgPersonLib è possibile archiviare tipi diversi di documenti XML, mentre i valori del nodo vengono esposti tramite le stesse colonne delle raccolte. Questa semplice tecnica di associazione consente inoltre di riutilizzare i flussi di lavoro e la logica di gestione delle informazioni, poiché i quattro tipi di contenuto (OrgPerson, Manager, Supervisor e User) fanno riferimento a una serie comune di campi di metadati.
Nella Figura 6 viene illustrato l'elemento FieldRef dal tipo di contenuto OrgPerson per Direct_x0020_Reports, che associa il campo ai nodi dell'ID utente dei report diretti in base all'espressione XPath, /OrgPerson/direct-report/user-id. Poiché il documento XML può contenere più voci di report diretti, è importante specificare un attributo Aggregation, che definisce la modalità di gestione dell'insieme di valori da parte del parser XML. Se si omette l'attributo, il parser XML estrae solo il primo valore del nodo. I valori di aggregazione supportati sono somma, conteggi, media, minimo, massimo, testo normale, primo e ultimo.
Figura 6 Campo di metadati associato a un'espressione XPath
Figura 6 Campo di metadati associato a un'espressione XPath
Tutti i tipi di contenuto dell'esempio utilizzano la pagina upload.aspx standard come DocumentTemplate, in modo che si possano caricare i file XML nella raccolta documenti con un clic sul pulsante Nuovo nell'interfaccia utente di SharePoint. Fino a che si caricano file con un'estensione .xml, SharePoint chiama automaticamente il parser XML incorporato (un'eccezione è rappresentata dai file WordProcessingML, per cui SharePoint chiama un parser WordProcessingML). Il parser XML esamina il file .xml caricato per determinare il tipo di contenuto associato. L'operazione è congegnata in modo che vengano estratti i valori del nodo dalle posizioni specificate nelle definizioni del campo ed eseguita la promozione delle proprietà. È possibile verificare il processo quando si carica il file OrgPerson.xml contenuto nella cartella OrgPersonLib\XMLFiles. La struttura di questo documento XML corrisponde alle espressioni XPath specificate nella definizione di tipo di contenuto OrgPerson. Di conseguenza, SharePoint estrae i dati dal file .xml, scrive i dati nelle colonne della raccolta corrispondenti e riporta i dati nella pagina EditForm.aspx, in modo che si possano verificare e aggiornare le proprietà del documento non contrassegnate come di sola lettura. Nella Figura 7 viene illustrato il modulo EditForm.aspx con i dati estratti da OrgPerson.xml.
Figura 7 Modulo EditForm.aspx con i dati estratti
Figura 7 Modulo EditForm.aspx con i dati estratti
Se in EditForm.aspx si modificano i valori di User ID, Full Name o E-Mail, SharePoint esegue il declassamento delle proprietà per modificare i valori del nodo nel documento XML sottostante. Tuttavia, SharePoint non applica le restrizioni dello schema XML, a meno che nel modulo non si implementi la logica necessaria.
SharePoint inoltre non esegue la logica di presentazione di un'applicazione a moduli. Quando, ad esempio, si modifica il valore di User ID, SharePoint non verifica se il nuovo valore è conforme alle convenzioni NetBIOS e non aggiorna automaticamente i campi Full Name ed E-Mail in modo che corrispondano alla nuova selezione. Quando la modifica di un singolo campo può causare l'introduzione di incoerenze, è quindi necessario contrassegnare come di sola lettura la colonna corrispondente nella definizione di tipo di contenuto. In tal modo si obbliga l'utente a utilizzare l'applicazione a moduli, come InfoPath, per aggiornare i dati. Il parser XML, inoltre, promuoverà le eventuali modifiche dal documento XML ai campi di metadati corrispondenti in SharePoint.
Nell'esempio OrgPersonLib è possibile caricare uno qualsiasi dei file .xml dalla cartella OrgPersonLib\XMLFiles. I file .xml utilizzano strutture di dati molto diverse, ma SharePoint riconosce i tipi di contenuto e promuove i valori del nodo corretti nelle colonne del sito. Questo accade perché nei file XML è stata utilizzata un'istruzione di elaborazione per associare i documenti XML con i tipi di contenuto corrispondenti. Il file OrgPerson.xml, tuttavia, non contiene queste informazioni, ma ciò non costituisce un problema. Se non può associare un documento XML a un tipo di contenuto tramite un'istruzione di elaborazione o il modello del documento, SharePoint utilizza il tipo di contenuto predefinito. Nel caso di OrgPersonLib, questo corrisponde al tipo di contenuto OrgPerson e, quindi, il documento XML viene analizzato in modo corretto.
Nella Figura 8 si illustra come sia possibile associare esplicitamente un documento XML a un tipo di contenuto. L'istruzione di elaborazione MicrosoftWindowsSharePointServices definisce il ContentTypeID come 0x010100668E393E4F0EFF4294DBD202D5D8321D. Questo è l'ID del tipo di contenuto User, come definito in AdditionalContentTypes.xml.
Figura 8 Istruzioni di elaborazione e dati XML del file di esempio user.xml
Figura 8 Istruzioni di elaborazione e dati XML del file di esempio user.xml
Il parser XML elabora l'istruzione MicrosoftWindowsSharePointServices e scrive il valore di ContentTypeID nel campo di metadati ContentType. Tutto i tipi di contenuto SharePoint condividono questo campo di metadati, perché è definito a livello di radice nel tipo di contenuto System. Se si apre il file fieldswss.xml su un server SharePoint (nella cartella %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields) e si cerca MicrosoftWindowsSharePointServices, si noterà come SharePoint associ l'istruzione di elaborazione al campo ContentType. L'attributo PITarget punta verso MicrosoftWindowsSharePointServices (questa è l'istruzione di elaborazione) e i punti PIAttribute verso ContentTypeID (che contiene l'ID del tipo di contenuto User).

Associazioni del tipo di contenuto in InfoPath
Molti progettisti di moduli trovano molto complessi i dettagli tecnici dell'analisi XML e dell'associazione dei tipi di contenuto, ma InfoPath 2007 si occupa direttamente di tutta la parte essenzialmente tecnica. Il file readme.htm fornito con l'esempio OrgPersonLib contiene le istruzioni per la pubblicazione del modello di modulo Direct Reports in SharePoint e la creazione di un tipo di contenuto che venga associato di nuovo agli stessi campi di metadati (UserID, FullName, EMail e Direct_x0020_Reports). È possibile aggiungere facilmente il nuovo tipo di contenuto alla raccolta documenti di OrgPersonLib nell'interfaccia utente di SharePoint. Ma il nuovo tipo di contenuto punta anche verso il modello di modulo InfoPath come modello di documento, per chiamare l'applicazione a moduli quando si aggiornano i documenti XML esistenti. Nella Figura 9 viene illustrato come Pubblicazione guidata di InfoPath semplifichi l'associazione delle proprietà tra i valori del nodo XML e le colonne del sito SharePoint. Anche in questo caso, se si associano i valori del nodo con le colonne del sito esistenti, sarà possibile riutilizzare i componenti SharePoint esistenti.
Figura 9 Associazione delle proprietà in InfoPath 2007
Figura 9 Associazione delle proprietà in InfoPath 2007

Conclusioni
Risorse aggiuntive in linea
  • Il blog del team di InfoPath 2007
  • Specifiche W3C e sviluppo degli schemi XML
  • Introduzione agli schemi XML
  • Flussi di lavoro in Office SharePoint Server 2007
  • InfoPath 2007 Forms Services

Con le tecnologie disponibili in Office, gli architetti aziendali possono creare soluzioni di raccolta dei dati che promuovano il riutilizzo del codice e lo scambio di informazioni. InfoPath 2007 consente ai singoli reparti di creare soluzioni in grado di estrarre dati da varie fonti e di inviare quindi i dati a diversi sistemi, come SharePoint. SharePoint inoltre fornisce agli sviluppatori una serie completa di servizi e interfacce Web per la creazione di flussi di lavoro e componenti di gestione delle informazioni. Se ospitano questi componenti su server SharePoint centralizzati, i reparti ottengono l'infrastruttura necessaria per creare le applicazioni personalizzate.
Inoltre i singoli reparti possono creare in modo più rapido soluzioni di raccolta dei dati personalizzate. È infine possibile soddisfare le esigenze di conformità alle normative e di altri requisiti aziendali a livello interdipartimentale, con un significativo incremento della gestibilità e affidabilità dell'ambiente IT grazie all'uso di meno componenti personalizzati sui server applicazioni.

Keith Deshaiesè un technical writer professionista e un analista informatico per una grande azienda di telecomunicazioni. Si è specializzato nelle tecnologie di Microsoft Office e SharePoint ed è membro della Society for Technical Communications.
© 2007 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.


 SharePoint: Creazione di una potente infrastruttura di sondaggio
SharePoint Jim Bradley

Creazione di una potente infrastruttura di sondaggio
Panoramica:
  • Pianificazione e implementazione di una soluzione di sondaggio
  • Raccolta ed elaborazione dei risultati del sondaggio nelle raccolte di SharePoint
  • Gestione dei problemi di protezione e di prestazioni

Non si possono prendere decisioni ponderate senza le informazioni. Le intuizioni non bastano, almeno non quando le decisioni prese avranno un impatto significativo sull'azienda. Questo vale sia nel caso in cui si stia prendendo una decisione in merito al luogo in cui ospitare un party del team
sia che si stia valutando la riallocazione del 50% delle risorse aziendali per il lancio di un nuovo prodotto. Ma come ottenere queste informazioni?
I sondaggi forniscono un metodo efficace ed economico per raccogliere commenti e suggerimenti su qualsiasi argomento, dalla verifica del livello di soddisfazione dei clienti per le proprie offerte di prodotti alla determinazione del livello di gradimento da parte dei dipendenti per i sandwich preparati nel corso dell'ultima riunione del team. I sondaggi producono risultati fondamentali necessari per il ciclo di sviluppo oltre che per i futuri miglioramenti di prodotti, sistemi o processi. La domanda fondamentale è la seguente: in che modo un professionista IT può implementare un sistema di sondaggi in grado di raccogliere e archiviare i dati in modo da consentirne un utilizzo significativo?
È probabile che già si disponga di uno o più strumenti necessari per raccogliere, strutturare e analizzare questo tipo di dati. Microsoft® Office System 2007 fornisce questi strumenti e ne semplifica l'utilizzo. In effetti, esistono numerosi metodi per eseguire un sondaggio. Il punto chiave è fare in modo che l'approccio adottato sia in grado di soddisfare le specifiche esigenze. Ad esempio, i sondaggi basati sulla posta elettronica rappresentano un ottimo metodo per la raccolta improvvisata e in tempo reale dei dati quando si ha a che fare con un piccolo numero di intervistati e dati non critici. Per ulteriori informazioni, vedere l'intestazione laterale riportata di seguito "Utilizzo della posta elettronica per sondaggi rapidi". I sondaggi basati su database, invece, rappresentano una soluzione ideale per iniziative più complesse che includono un elevato numero di intervistati e sono relative a dati di importanza critica per le strategie aziendali. Per ulteriori informazioni su questo argomento, vedere l'intestazione laterale riportata di seguito "Creazione di una soluzione di sondaggio basata su database".
Questo articolo è incentrato su una soluzione più completa e flessibile: i sondaggi in linea basati su SharePoint®. Questo approccio risulta appropriato sia per sondaggi di importanza critica per le strategie aziendali che per sondaggi non critici e di qualsiasi livello di complessità. Poiché sono basati sul Web, i sondaggi SharePoint possono essere completati da chiunque abbia accesso a un browser Web e sono supportati anche i dispositivi portatili. Con un sondaggio SharePoint, le risposte possono essere firmate o anonime, sono disponibili risultati in tempo reale ed è possibile avere accesso a strumenti di analisi.
questo tipo di sondaggio viene implementato mediante Windows® SharePoint Services 3.0 (WSS) con Forms Server e InfoPath® o Microsoft Office SharePoint Server 2007 (MOSS) con Forms Services e InfoPath® (vedere la Figura 1 per una descrizione di ciascuna di queste tecnologie). Poiché entrambi gli scenari offrono essenzialmente la stessa funzionalità, questa discussione verrà incentrata sulla seconda combinazione. Per un confronto completo dei prodotti di SharePoint e delle relative funzionalità, vedere Download del confronto tra i prodotti di Microsoft Office SharePoint Server 2007 all'indirizzo office.microsoft.com/en-us/sharepointserver/HA101978031033.aspx.
Figure 1 Tecnologie Microsoft che supportano i sondaggi SharePoint (Close Figure 1)

Tecnologia | Descrizione
Microsoft Office InfoPath 2007 | Microsoft Office InfoPath 2007 è uno strumento per la creazione di moduli e la raccolta di informazioni. Per ulteriori informazioni, visitare il sito all'indirizzo office.microsoft.com/infopath.
Windows SharePoint Services 3.0 | In precedenza SharePoint Team Services, Windows SharePoint Services 3.0 funge da base per la creazione di applicazioni SharePoint estese. Per ulteriori informazioni, visitare il sito all'indirizzo microsoft.com/technet/windowsserver/sharepoint/techinfo/overview.mspx.
Microsoft Office SharePoint Server 2007 | Microsoft Office SharePoint Server 2007 (in precedenza SharePoint Portal Server 2003) fornisce un'infrastruttura sul lato server che trasforma i client Office 2007 in generatori e consumatori di contenuti per le applicazioni SharePoint. Per ulteriori informazioni, visitare il sito all'indirizzo microsoft.com/sharepoint.
InfoPath Forms Services, Microsoft Office Forms Server 2007 | InfoPath Forms Services consente agli utenti di completare i moduli InfoPath in un browser Web senza dover installare InfoPath, creando sondaggi compatibili con più piattaforme e più browser. Forms Services richiede Windows SharePoint Services 3.0, anche se le stesse funzionalità sono disponibili come prodotto autonomo denominato Microsoft Office Forms Server 2007. Per ulteriori informazioni su Forms Services, visitare il sito all'indirizzo microsoft.com/ms540731. Per ulteriori informazioni su Forms Server, visitare il sito all'indirizzo office.microsoft.com/en-us/formsserver/FX100490391033.aspx.

Pianificazione e implementazione
Durante la progettazione di un sondaggio, è necessario considerare in anticipo una serie di fattori. Poiché questo comporta un'analisi preliminare, è opportuno sviluppare un piano di sondaggio elaborato con cura. Nella fase di pianificazione iniziale, è consigliabile definire l'area dei problemi e il tipo di dati che si intende ottenere, determinare le tecnologie da utilizzare e stabilire i requisiti di budget e di amministrazione. A questo punto, è possibile passare alla fase di implementazione. Il flusso di lavoro generale prevede la progettazione di un modulo di sondaggio, la pubblicazione del modulo, la raccolta e la convalida delle risposte, l'aggregazione e l'analisi dei dati e la creazione di report dei risultati.
Un flusso di lavoro per l'implementazione del sondaggio include in genere almeno un progettista, degli intervistati e un analista (come illustrato nella Figura 2). Ovviamente, i flussi di lavoro per i sondaggi possono variare significativamente in termini di complessità. È probabile, ad esempio, che un sondaggio aziendale venga sottoposto a diverse sessioni di modifica di progettazione e di approvazione e che utilizzi dei promemoria automatici per gli intervistati, offra diverse forme di supporto e risoluzione dei problemi, fornisca visualizzazioni in tempo reale dei risultati per i manager e disponga di un processo chiaro per la determinazione e la consegna dell'analisi finale. Un flusso di lavoro complesso come questo richiede un sistema basato sul Web che supporti funzionalità di flusso di lavoro e di report.
Figura 2 Flusso di lavoro di un sondaggio dalla progettazione dei moduli all'analisi dei dati
Figura 2 Flusso di lavoro di un sondaggio dalla progettazione dei moduli all'analisi dei dati

Requisiti di una soluzione completa
L'elenco dei requisiti chiave che una soluzione di sondaggio completa deve soddisfare è piuttosto lungo. La soluzione deve consentire ai singoli team o alle singole unità aziendali di creare, diffondere e raccogliere i risultati del sondaggio con il minimo coinvolgimento del reparto IT e non deve richiedere alcuna abilità di programmazione. Lo strumento di creazione dei moduli deve offrire un'interfaccia WYSIWYG di facile utilizzo e un insieme avanzato di funzionalità che semplificano l'invio, il salto condizionato e la logica condizionale. Inoltre, lo strumento di creazione dei moduli di sondaggio deve, ovviamente, contenere tutti i sondaggi, indipendentemente dalle dimensioni e dalla complessità.
È necessario che il sondaggio venga eseguito su un server Web e garantisca l'integrazione con un database SQL Server® centralmente gestito, eliminando la necessità per i singoli reparti di gestire database SQL dedicati. Qualsiasi intervistato con accesso a Internet deve essere in grado di completare il sondaggio da qualsiasi browser conforme agli standard.
Il processo di sondaggio deve essere facilmente collegato ai flussi di lavoro e soddisfare le esigenze aziendali senza compromettere la protezione. Inoltre, per molte organizzazioni, la soluzione di sondaggio deve fornire il supporto multilingue.
Quando utilizzati insieme, MOSS 2007, WSS 3.0 e InfoPath 2007 creano una soluzione integrata in grado di soddisfare tutti questi requisiti. Nella Figura 3 viene illustrata la correlazione tra i vari componenti nello stack di SharePoint. Tuttavia, prima di illustrare la soluzione di sondaggio completa, è opportuno esaminare brevemente i risultati che è possibile raggiungere utilizzando solo WSS. Successivamente, verranno illustrati i vantaggi aggiuntivi che è possibile ottenere quando WSS viene utilizzato in combinazione con MOSS e InfoPath.
Figura 3 Componenti dello stack di SharePoint
Figura 3 Componenti dello stack di SharePoint

Utilizzo di WSS
È possibile utilizzare WSS senza gli altri componenti per creare e implementare un sondaggio. In effetti, WSS include un modello di sondaggio incorporato che consente di semplificare il processo. Per creare un sondaggio, fare clic su Start | Tutti i programmi, | Strumenti di amministrazione e selezionare Amministrazione centrale SharePoint 3.0. Dall'elenco a discesa scegliere Azioni sito e fare clic su Crea. Verrà visualizzata la pagina di creazione in cui vengono mostrati i titoli per le raccolte, le comunicazioni, la gestione, gli elenchi personalizzati e le pagine Web. Sotto ogni titolo sono presenti le opzioni del modello. In Gestione, fare clic su Sondaggio.
A questo punto, in WSS verranno illustrate le varie fasi del processo di creazione dei sondaggi. È possibile creare domande aperte o chiuse e specificare se una domanda può essere lasciata senza risposta. È possibile persino creare sondaggi con logica di salto condizionato, che conducono gli intervistati verso sequenze di domande differenti, a seconda delle relative risposte. I sondaggi possono essere anonimi o, se necessario, identificare l'intervistato. È inoltre possibile assegnare un flusso di lavoro al sondaggio.
Il sondaggio è basato su browser e pertanto non è necessario alcun software speciale per creare o rispondere al sondaggio. Per completare il sondaggio, gli intervistati accedono semplicemente al sito SharePoint e compilano il modulo. Le autorizzazioni di accesso vengono ereditate dal sito padre ma possono essere modificate direttamente dal menu Azioni di SharePoint. Le risposte al sondaggio vengono salvate nel sito dei sondaggi di SharePoint e i risultati possono essere visualizzati nel modulo elenco o come riepiloghi grafici oppure esportati in Excel®.
Riepilogando, questa soluzione (con il processo illustrato nella Figura 4) può essere ottenuta solo con WSS senza utilizzare software aggiuntivo. Supponendo che si sia già implementato un sito SharePoint ben progettato, un singolo reparto deve essere in grado di creare e implementare un sondaggio senza alcun coinvolgimento o con un intervento minimo da parte del reparto IT.
Figura 4 Sondaggio basato su Windows SharePoint Services
Figura 4 Sondaggio basato su Windows SharePoint Services
Una limitazione del processo per la creazione di sondaggi basati solo su WSS diventa evidente nel caso in cui si renda necessario personalizzare un sondaggio. WSS prevede la creazione di elenchi di sondaggi mediante l'uso di diverse pagine ASPX predefinite (AllItems.aspx, DispForm.aspx, EditForm.aspx, NewForm.aspx, overview.aspx e summary.aspx). Sebbene siano possibili personalizzazioni delle pagine aggiuntive rispetto ai parametri specifici di WSS, la maggior parte delle funzionalità deriva da web part che non sono immediatamente personalizzabili. Inoltre, la soluzione basata solo su WSS risulta maggiormente appropriata per i sondaggi che non richiedono l'integrazione con origini dati esterne, come il sistema ERP aziendale.
Quando è necessario espandere la soluzione di sondaggio per includere un'interfaccia utente personalizzata o l'integrazione con origini dati esterne, è consigliabile considerare seriamente la soluzione che prevede l'utilizzo congiunto di MOSS, WSS e InfoPath.

Soluzione di sondaggio completa
MOSS include molte funzionalità che estendono WSS, ma per ora l'attenzione verrà focalizzata su un singolo componente: InfoPath Forms Services. Con InfoPath Forms Services, solo il progettista del sondaggio deve installare InfoPath nel computer in uso. Gli altri possono accedere al sondaggio tramite un browser Web.
In InfoPath, il progettista seleziona l'opzione che consente di compilare il modulo mediante un browser. In InfoPath viene quindi creato automaticamente un modulo che può essere visualizzato in qualsiasi browser Web conforme agli standard. questo modulo basato sul Web ha le stesse funzioni di un modulo InfoPath, ad eccezione di alcune funzionalità InfoPath avanzate, come ruoli utente, testo verticale, azioni di finestre di dialogo e controlli avanzati. Il modulo viene quindi pubblicato in una raccolta o un elenco SharePoint. Un'altra funzionalità InfoPath, denominata Controllo grafico, assicura che il modulo di sondaggio sia compatibile con InfoPath Forms Services.
Non esiste alcuna differenza tra una raccolta di moduli InfoPath e una raccolta di moduli abilitati per i browser. In ciascun caso, un modello di modulo è un file .xsn. InfoPath Forms Services consente di visualizzare il modulo in un browser o il file viene scaricato sul client e visualizzato direttamente in InfoPath. Se un progettista di sondaggi dispone almeno delle autorizzazioni di Collaboratore per un sito SharePoint, potrà utilizzare le raccolte documenti di SharePoint per pubblicare i modelli di modulo.
Un intervistato con un browser conforme agli standard può completare il sondaggio di InfoPath Forms Services e le relative risposte vengono restituite al server SharePoint. In SharePoint, i dati possono essere archiviati, condivisi e analizzati in modo protetto (utilizzando Excel, SQL o altri strumenti disponibili in rete). È possibile eseguire tutte queste operazioni con un coinvolgimento minimo dell'amministrazione IT.

Postback e problemi di prestazioni
È possibile, tuttavia, che si verifichino problemi di prestazioni. I moduli abilitati per i browser vengono eseguiti, ad esempio, nel contesto di un account di sistema sul server SharePoint, il che implica che se un modulo include codice o connessioni dati, come illustrato nella Figura 5, il codice o le connessioni dati verranno eseguite sul server, non sul client. È possibile che alcune forme complesse necessitino di eseguire di frequente il postback dei dati al server, il che aumenta il carico di lavoro sul server.
Figura 5 Soluzione di sondaggio basata su InfoPath Forms Services con connessioni dati aggiuntive
Figura 5 Soluzione di sondaggio basata su InfoPath Forms Services con connessioni dati aggiuntive
Maggiore è il numero di postback utilizzati da un sondaggio, più elevato sarà il carico sui server Web front-end. Tuttavia, in alcuni contesti il postback diventa inevitabile, ad esempio durante l'implementazione della logica di salto condizionato per le risposte. Per ridurre al minimo i potenziali effetti negativi sul sistema, i progettisti dei sondaggi devono essere consapevoli dei problemi correlati al postback e determinare come implementare al meglio i sondaggi quando il postback non può essere evitato. È opportuno, ad esempio, che i progettisti utilizzino sondaggi simili a procedure guidate che eseguono il postback dei dati al server quando l'utente fa clic sul pulsante Avanti. Questo consente di ridurre il numero di postback.
InfoPath Forms Services deve gestire lo stato di ciascun modulo correntemente attivo sul server. Il timeout di sessione predefinito è 60 minuti, il che implica che se il completamento di un sondaggio complesso richiede più di 60 minuti e durante tale periodo non vengono eseguiti postback, la sessione verrà chiusa sul server. I dati immessi ma non inviati andranno persi e l'intervistato deve iniziare daccapo.
Tali problemi diventano ancora più evidenti quando un numero elevato di intervistati utilizza contemporaneamente lo stesso modulo di sondaggio e quando i sondaggi contengono origini dati di grandi dimensioni o includono allegati di file. Per ulteriori informazioni, vedere "Miglioramento delle prestazioni di InfoPath 2007 Forms" all'indirizzo msdn2.microsoft.com/bb380251.

Considerazioni sulla protezione
Sebbene una discussione approfondita sulla protezione esuli dall'ambito del presente articolo, è importante evidenziare alcune considerazioni relative alla protezione. Per iniziare, SharePoint e InfoPath 2007 aderiscono all'iniziativa Trustworthy Computing Initiative adottata da Microsoft agli inizi del 2002. In InfoPath sono disponibili tre livelli di protezione per i moduli: Con restrizioni, Dominio e Attendibilità completa. Per impostazione predefinita, InfoPath determina e applica automaticamente il livello di protezione consigliato al modulo.
La funzionalità di firma digitale consente di confermare l'identità dell'utente che ha creato o compilato il modulo e di assicurarsi che il contenuto del modulo non venga alterato. La funzionalità Information Rights Management (IRM) può limitare l'accesso ai modelli e ai moduli completati. Per impedire agli utenti malintenzionati di caricare moduli che contengono codice dannoso o di utilizzare la piattaforma SharePoint per sferrare attacchi contro altri sistemi tramite le connessioni dati, in InfoPath si opera una distinzione tra i moduli distribuiti dall'utente e i moduli distribuiti dall'amministratore. Gli utenti possono caricare i moduli purché non contengano codice dannoso e utilizzino solo il livello di protezione Dominio, che limita connessioni dati tra domini. Questi parametri sono sufficienti per la maggior parte delle soluzioni di sondaggio.
Quando un progetto di sondaggio richiede il livello di protezione Attendibilità completa per consentire accesso illimitato alle risorse, per la pubblicazione dei moduli è necessaria l'approvazione dell'amministrazione IT. Per impostazione predefinita, l'approvazione dell'amministrazione IT è necessaria quando un modulo contiene codice gestito, quando le connessioni dati tra domini sono definite nel modello di modulo, quando il modulo utilizza connessioni dati definite nella raccolta connessioni dati gestita in modo centralizzato e quando viene attivata l'opzione per il supporto del rendering sui dispositivi portatili.
Per il livello di protezione Attendibilità completa, il progettista del sondaggio crea un modulo InfoPath e salva il modello di modulo. Il modello o il file .xsn viene inviato all'amministratore SharePoint come allegato a un messaggio di posta elettronica o trasmesso tramite una condivisione di rete. L'amministratore IT controlla quindi le funzionalità di sondaggio e qualsiasi codice in esso contenuto prima di rendere disponibile il sondaggio sul sistema di produzione. L'amministratore IT completa la distribuzione caricando il modello di sondaggio in una raccolta siti e attivando il modello di sondaggio. Entrambe le procedure vengono completate nella pagina Gestione applicazioni della console Amministrazione centrale WSS. Il risultato finale è che un amministratore IT può delegare la pubblicazione dei moduli a singoli reparti e continuare a occuparsi della supervisione del processo di pubblicazione nel caso in cui i moduli prevedano attività che vanno oltre le attività di raccolta dei dati di base.
La supervisione dell'amministratore IT è necessaria in alcuni scenari comuni: quando i moduli devono essere compilati con i dati predefiniti e quando i risultati del sondaggio vengono inviati a più origini dati. Per impostazione predefinita, i modelli di modulo con relazione di trust tra domini non possono stabilire connessioni dati tra domini, ma per aggirare questa limitazione, è possibile intraprendere alcune azioni, tra cui:
  • Concessione delle autorizzazioni Attendibilità completa per il modulo.
  • Creazione della relazione di trust tra domini utilizzando connessioni dati dalla raccolta connessioni dati.
  • Utilizzo della relazione di trust tra domini con la raccolta connessioni gestita in modo centralizzato.
Le opzioni Attendibilità completa e raccolta connessioni dati gestita in modo centralizzato richiedono l'approvazione dell'amministratore durante la pubblicazione dei moduli. Tuttavia, la raccolta connessioni dati (DCL) consente ai moduli pubblicati dall'utente di superare i limiti dei domini utilizzando la raccolta connessioni dati gestita a livello di raccolta siti. Questa raccolta connessioni dati può essere sotto il controllo del singolo reparto. È importante capire, tuttavia, che consentire ai singoli reparti di definire le relative connessioni dati basate sul server può costituire un problema di protezione.
L'opzione che garantisce il massimo livello di protezione prevede la definizione delle connessioni dati nella raccolta connessioni dati gestita in modo centralizzato e la distribuzione da parte di un amministratore IT di moduli di sondaggio avanzati che utilizzano queste connessioni dati. La raccolta connessioni dati gestita in modo centralizzato è utile in quanto è disponibile in tutte le raccolte siti e nell'intera server farm. Questo consente all'amministratore di definire le impostazioni di autenticazione centrali per l'accesso alle origini dati che non risiedono sul server SharePoint locale. Per le ulteriori informazioni, leggere l'articolo "Informazioni sulle connessioni dati, sull'autenticazione e sul mapping di accesso alternativo" all'indirizzo msdn2.microsoft.com/ms771995.

Conclusioni
I sondaggi forniscono un metodo valido per raccogliere sia informazioni di importanza critica per le strategie aziendali che dati non critici per ogni tipo di azienda e a qualsiasi livello. La creazione di un sondaggio efficace, tuttavia, richiede gli strumenti appropriati, un piano valido e una combinazione equilibrata di arte e scienza. Una accurata pianificazione preliminare consentirà di creare una soluzione che consente a ciascun reparto all'interno di un'organizzazione di creare, inviare, ricevere, archiviare e analizzare i dati del sondaggio.
I sondaggi più efficaci sono quelli che producono informazioni rilevanti e tempestive. Per raccogliere le informazioni quando necessario, la soluzione deve semplificare la creazione e la gestione dei sondaggi a livello di reparto, senza compromettere la protezione. InfoPath consente agli Information Worker di creare sondaggi di elevata qualità fornendo un'interfaccia intuitiva il cui utilizzo richiede una formazione minima. InfoPath consente di raccogliere dati di sondaggi di elevata qualità richiedendo un intervento minimo da parte dell'amministrazione IT.
InfoPath 2007 funziona in modo completamente integrato con WSS e MOSS per semplificare soluzioni di sondaggio avanzate e complesse che sono compatibili con più piattaforme e più browser. Questo consente a ogni azienda di sfruttare una delle risorse più preziose: le informazioni.
Utilizzo della posta elettronica per sondaggi rapidi
I sondaggi improvvisati sono uno strumento essenziale per raccogliere rapidamente dati da un piccolo gruppo di intervistati. I sondaggi basati sulla posta elettronica sono ideali per questo tipo di ricerca in tempo reale: possono essere creati rapidamente e non richiedono server dedicati o assistenza IT. Uno degli approcci più semplici, pulsanti di voto incorporati in un messaggio di Microsoft® Outlook®, consente di inviare, ricevere e catalogare un sondaggio unidimensionale.
Dopo aver avviato un sondaggio con pulsanti di voto, i destinatari ricevono un messaggio di posta elettronica che contiene una fascia di voti in cui viene visualizzato un elenco a discesa di opzioni. Il destinatario risponde facendo clic su una delle opzioni. In una finestra popup viene quindi visualizzato il messaggio "Risposta selezionata: <opzione scelta>" e consente di scegliere di inviare o modificare la risposta.
Il progettista del sondaggio o un delegato assegnato riceve le singole risposte nel messaggio di posta elettronica e cataloga manualmente i risultati. Se il sondaggio include un elevato numero di destinatari, è consigliabile creare una regola in Outlook (utilizzando la Creazione guidata Regole) che instradi automaticamente le risposte a una cartella dedicata, come illustrato nella Figura A.
Figura A Risposte al sondaggio instradate automaticamente a una cartella dedicata
Figura A Risposte al sondaggio instradate automaticamente a una cartella dedicata
I pulsanti di voto, tuttavia, sono piuttosto limitati. I moduli di sondaggio inseriti nei messaggi di posta elettronica possono raccogliere molti più dati, ma il recupero e la catalogazione manuali di questi dati possono rivelarsi ingestibili. Il lato più complesso dei sondaggi basati sulla posta elettronica è rappresentato dall'utilizzo di VBScript per personalizzare i sondaggi di Outlook. I moduli personalizzati possono semplificare la raccolta e l'analisi di maggiori quantità di dati più complessi. Per accedere alle funzionalità destinate agli sviluppatori in Outlook 2007, è necessario prima visualizzare la scheda Sviluppo, illustrata nella Figura B.
Figura B Scheda Sviluppo in Outlook 2007
Figura B Scheda Sviluppo in Outlook 2007
La creazione di moduli Outlook personalizzati non rientra nelle conoscenze dell'utente Outlook tipico. Tuttavia, InfoPath® 2007 fornisce nuove funzionalità che semplificano l'implementazione di moduli personalizzati. Senza alcuna competenza particolare, i progettisti di sondaggi possono creare i moduli e i modelli InfoPath in tre modi:
  • Importando i documenti di Microsoft Word o i fogli di calcolo di Excel® esistenti.
  • Eseguendo il download dei modelli InfoPath predefiniti e modificandoli in base alle specifiche esigenze.
  • Progettando i modelli da zero utilizzando la funzionalità di progettazione moduli di InfoPath.
In tutti i tre casi, i modelli possono essere pubblicati in Outlook e distribuiti tramite posta elettronica. Con InfoPath 2007 e Outlook 2007, in poche ore e con un intervento minimo dell'assistenza IT un Information Worker può creare un sondaggio di venti domande, inviarlo tramite posta elettronica a un gruppo, ricevere i risultati in Outlook e analizzare i dati in un foglio di calcolo di Excel.
L'unico requisito effettivo in questo scenario prevede l'installazione di InfoPath e Outlook nei computer di tutti i partecipanti. Poiché InfoPath 2007 estende le funzionalità di Outlook 2007, i destinatari possono rispondere al sondaggio direttamente dall'interno dell'interfaccia di Outlook.
Tuttavia, InfoPath supporta altre funzionalità che vanno oltre i sondaggi basati sulla posta elettronica. È possibile creare modelli che prevedono l'esecuzione di query e l'invio di dati ai servizi Web e ai database SQL Server® o è possibile utilizzare un documento XML o uno schema XML esistente come origine dati. In altre parole, con una formazione minima e con una quantità limitata di codice aggiuntivo un utente può usufruire della potenza e della flessibilità del formato XML.
La posta elettronica come soluzione di sondaggio presenta alcuni significativi svantaggi. Ad esempio, i sondaggi non sono anonimi, in quanto l'indirizzo di posta elettronica degli intervistati è disponibile. Questo può ridurre la sincerità delle risposte e alterare i risultati. Occorre inoltre considerare i rischi per la protezione, come gli attacchi di phishing; pertanto, vi è un limite al tipo e alla ricchezza di informazioni che è possibile raccogliere mediante i sondaggi basati sulla posta elettronica.

Creazione di una soluzione di sondaggio basata su database
I sondaggi basati sulla posta elettronica non sono adatti a studi più complessi che coinvolgono un numero elevato di intervistati: l'utilizzo di una cartella in Outlook® non è sufficiente per gestire e analizzare tutti i dati. Una soluzione più robusta consiste nell'indirizzare le risposte al sondaggio a un database. Le funzionalità avanzate di archiviazione, indicizzazione, elaborazione e report offerte da un database possono rivelarsi molto utili. Microsoft® SQL Server® 2005, ad esempio, include SQL Server Reporting Services, che può essere utilizzato per elaborare automaticamente i risultati del sondaggio.
Per creare un modello InfoPath con cui inviare le risposte a un database, è necessario prima creare un database Access® o SQL Server all'interno della rete. In InfoPath®, sarà quindi possibile avviare il processo di creazione dei modelli mediante la procedura guidata Progetta modello di modulo. Verrà quindi visualizzata la Connessione guidata dati in cui viene illustrato il processo di collegamento del modulo al database. In InfoPath le informazioni all'interno del database vengono utilizzate per creare campi di dati e query delle origini dati.
La maggior parte dei lavoratori disporrà di conoscenze sufficienti per completare e inviare il sondaggio avvalendosi di una formazione e un supporto minimi. Tuttavia, in questo scenario (in cui i dati vengono passati direttamente al database), è necessario che gli intervistati abbiano installato InfoPath e Outlook e che siano protetti dal firewall aziendale o che dispongano dell'accesso VPN alla rete aziendale.
La Connessione guidata dati di InfoPath si interfaccia solo con Microsoft SQL Server 2000 o versioni successive e i database Access che utilizzano ADOXML in modalità nativa. L'invio diretto dei dati al database non è supportato per altri database. Le altre limitazioni riguardano il fatto che InfoPath non consente l'associazione di controlli testo RTF ai campi di database e non fornisce il supporto per tipi di dati binari di grandi dimensioni.
Con l'aumento della dimensione e della complessità della topologia di rete diventa sempre più vantaggioso inviare i dati a un servizio Web intermedio e passare tali dati a un database. La separazione del modulo di sondaggio front-end dal database back-end, tramite un servizio Web, semplifica inoltre l'implementazione della logica aziendale sul server Web. Poiché il servizio Web viene eseguito su connessioni HTTP o HTTPS, i partecipanti possono inviare i dati attraverso i firewall, come illustrato nella Figura C. Notare, tuttavia, che è necessario che gli intervistati abbiano installato InfoPath 2003 o 2007.
Lo svantaggio di questo scenario è che l'implementazione richiede l'intervento dell'amministrazione IT. Una descrizione dettagliata di questo processo non rientra nell'ambito di questo articolo, ma tenere presente che la creazione di una soluzione basata su database da zero è un'impresa molto ardua. Richiede una pianificazione preliminare, una progettazione efficace del sondaggio, la programmazione del servizio Web e la progettazione del database back-end. InfoPath 2007 semplifica la fase del processo relativa alla progettazione dei moduli, ma la soluzione end-to-end richiede solide competenze di programmazione e di progettazione dei database. Inoltre, l'aggiunta di funzionalità avanzate, come il supporto multilingue o per il flusso di lavoro, determina un rapido aumento dei costi di implementazione.
Figura C Flusso di dati InfoPath attraverso un servizio Web
Figura C Flusso di dati InfoPath attraverso un servizio Web

Jim Bradley è il proprietario di CoyoteTech LLC, una società operante nel settore delle comunicazioni tecniche specializzata nella documentazione per gli utenti relativa ai prodotti server Microsoft. I progetti della documentazione includono "Protezione della messaggistica e Trasporto Edge di Microsoft Exchange Server 2007", "Passaggio alla piattaforma a 64 bit con Microsoft Exchange Server 2007" e "Guida di riferimento tecnico di Microsoft Exchange Server 2003".


 SharePoint: Standardizzazione della gestione dei dati con tipi di contenuto personalizzati
SharePoint Pav Cherny

Standardizzazione della gestione dei dati con tipi di contenuto personalizzati
Panoramica:
  • Gestione del ciclo di vita del contenuto con SharePoint
  • Creazione di riquadri informazioni documento
  • Modifica dei documenti di Office e SharePoint tramite InfoPath
Scarica il codice per questo articolo: ContentTypes2008_02.exe (779KB)

L'elevata quantità di documenti e altri elementi di contenuti disponibili in genere all'interno di un ambiente aziendale crea diverse problematiche di carattere tecnico per la gestione centralizzata e riutilizzabile dei documenti,
dei metadati associati e delle relative caratteristiche. Microsoft® Office SharePoint® Server 2007 promuove la collaborazione aziendale consentendo ai diversi team all'interno di un'organizzazione di condividere aree di lavoro in siti Web, raccolte documenti ed elenchi.
SharePoint 2007 consente di standardizzare molti aspetti delle caratteristiche del contenuto e del ciclo di vita tramite i tipi di contenuto. I tipi di contenuto del sito sono definizioni di metadati che è possibile stabilire indipendentemente da raccolte siti, siti, elenchi o raccolte documenti specifiche. Questo consente di stabilire in modo coerente le proprietà, i flussi di lavoro, i criteri di gestione delle informazioni e altri elementi all'interno dell'azienda e offre ai singoli reparti o ai proprietari del sito la possibilità di personalizzare i tipi di contenuto per scopi specifici.
In questo articolo verrà illustrato come utilizzare il nuovo modello di contenuto SharePoint introdotto con Windows® SharePoint Services (WSS) 3.0 e Microsoft Office SharePoint Server (MOSS) 2007 per creare gerarchie per il contenuto aziendale in base a caratteristiche generali. Queste gerarchie di contenuti consentono un'applicazione uniforme dei metadati, dei flussi di lavoro e dei criteri di gestione delle informazioni a livello globale, garantendo nel contempo la flessibilità necessaria per soddisfare specifiche esigenze di gestione dei contenuti a livello di raccolta siti, sito, raccolta documenti ed elenco.
Per illustrare alcuni degli aspetti basilari dei tipi di contenuto di SharePoint, nel materiale allegato al presente articolo sono stati inclusi una serie di strumenti personalizzati e il codice sorgente nel caso in cui si desideri estendere questi strumenti in base alle specifiche esigenze. Tenere presente che questi strumenti non sono stati sottoposti a test completi e non devono essere utilizzati in un sistema di produzione. È possibile scaricare il codice dal sito Web di TechNet Magazine all'indirizzo technetmagazine.com/code08.aspx.

Ciclo di vita del contenuto e definizioni dei tipi di contenuto
Risorse di SharePoint
  • Blog del team InfoPath
  • Flussi di lavoro in Office SharePoint Server 2007
  • TechNet Webcast: Installazione e configurazione del servizio di ricerca in SharePoint Server 2007
  • InfoPath Forms Services

Occorre prendere in considerazione molti dettagli durante la gestione di documenti e altri contenuti in un'organizzazione. In particolare, è necessario definire la persona o il processo che deve eseguire una specifica azione durante la creazione, la pubblicazione, l'archiviazione e l'eliminazione del contenuto. Inoltre, si rende spesso necessario per un'organizzazione sviluppare specifici modelli per la creazione del contenuto, definire ruoli per assegnare responsabilità e privilegi di accesso agli utenti, fornire il controllo delle versioni, monitorare la conformità, archiviare dati, definire i metadati e così via.
Per quanto complesso possa essere uno specifico ciclo di vita del contenuto, il modello di contenuto SharePoint stabilisce che esistono alcune caratteristiche generali e fasi tipiche che determinano la modalità di gestione dei singoli elementi di contenuto. È possibile, ad esempio, strutturare sia la creazione del contenuto attraverso modelli e moduli di input che la visualizzazione e le ricerche del contenuto attraverso i metadati. È inoltre possibile utilizzare i requisiti di modifica, approvazione o altri requisiti del flusso del lavoro, i requisiti di archiviazione, le date di scadenza e i criteri di gestione delle informazioni applicabili per operare una distinzione tra i singoli elementi di contenuto. Alcuni contenuti potrebbero non richiedere modelli speciali o potrebbero non essere mai archiviati, ma anche queste sono caratteristiche del ciclo di vita che consentono di distinguere tali elementi da altri tipi di elementi.
Il modello di contenuto SharePoint consente di definire singoli tipi di contenuto e di stabilire relazioni gerarchiche. In una relazione gerarchica, gli elementi figlio ereditano caratteristiche generali dai tipi di contenuto padre, aggiungendo caratteristiche specifiche.
Il metodo migliore per illustrare questo concetto consiste nell'esaminare i tipi di contenuto incorporati di SharePoint. WSS 3.0 e MOSS 2007 includono una serie di tipi di contenuto predefiniti per elementi tipici che possono essere archiviati in una raccolta documenti o un elenco, compresi documenti e attività. È possibile trovare le definizioni di questi tipi di contenuto standard su un server SharePoint nella cartella %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes. In tale cartella è disponibile un file manifesto denominato feature.xml. Se si esamina questo file, si potrà osservare che SharePoint implementa le definizioni dei tipi di contenuto standard come caratteristiche nascoste (Hidden="TRUE") con un ambito di raccolta siti (Scope="Site") e che il file manifesto dell'elemento, che contiene gli elementi dei tipi di contenuto effettivi, è ctypeswss.xml (<ElementManifest Location="ctypeswss.xml" />).
Per ulteriori informazioni sulle funzionalità di SharePoint, è consigliabile leggere l'articolo della serie Spazio Office di Ted Pattison in MSDN® Magazine intitolato "Funzionalità per SharePoint," disponibile all'indirizzo msdnmagazine.com/issues/07/05/OfficeSpace.
A questo punto, aprire il file ctypeswss.xml nel Blocco note per esaminare i tipi di contenuto standard, indipendentemente dalla relativa visibilità nell'interfaccia utente di SharePoint. È consigliabile non modificare ctypeswss.xml. Se si intende modificare ctypeswss.xml per aggiungere nuovi campi ai tipi di contenuto standard o rendere visibili i tipi di contenuto nascosti in modo che possa essere utilizzati dagli utenti di SharePoint per derivare nuovi tipi di contenuto, tenere presente che questa operazione non è in genere necessaria. Inoltre, un'operazione di questo tipo conduce a configurazioni non supportate ed è possibile che l'installazione in un momento successivo dei Service Pack sovrascriva le personalizzazioni effettuate e comprometta il funzionamento delle soluzioni di gestione dei contenuti.
Un approccio molto più efficace consiste nel copiare i dati necessari in un nuovo file manifesto dell'elemento, nell'aggiungere le personalizzazioni necessarie e nel distribuire i tipi di contenuto personalizzati come nuova caratteristica con un ambito di raccolta siti in modo che siano disponibili a tutti i siti all'interno della raccolta siti.
La definizione basata su CAML (Collaborative Application Markup Language) del tipo di contenuto System specificato in ctypeswss.xml è riportata di seguito:
<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>
Gli attributi Group e Sealed mostrano che il tipo di contenuto System viene nascosto e sottoposto a sealing in modo che non possa essere modificato nell'interfaccia utente di SharePoint. Il tipo di contenuto System dispone di un solo elemento FieldRef che fa riferimento a una colonna del sito incorporata denominata ContentType. Questo è il livello più elevato di astrazione. Tutti gli altri tipi di contenuto di SharePoint ereditano questa proprietà dal tipo di contenuto System. In tal modo, SharePoint assicura che tutti gli elementi di contenuto archiviati in qualsiasi raccolta documenti o elenco abbiano questa proprietà in comune.
Nella Figura 1 viene riportata una web part ContentTypeHierarchy, inclusa nel materiale che accompagna questo articolo, che illustra le gerarchie in modo più intuitivo. Il tipo di contenuto System è alla base di tutti gli altri tipi di contenuto, seguiti dal tipo di contenuto Item e così via. Il tipo di contenuto Item, ad esempio, stabilisce il livello di dettaglio successivo. Se si controlla il file ctypeswss.xml, è possibile osservare che Item definisce un singolo campo di metadati che fa riferimento a una colonna del siti denominata Title. In tal modo, tutti i tipi di contenuto incorporati ai livelli inferiori includono una proprietà Title.
Figura 1 Gerarchia dei tipi di contenuto incorporati di WSS 3.0
Figura 1 Gerarchia dei tipi di contenuto incorporati di WSS 3.0
È inoltre possibile rimuovere un campo ereditato, come dimostrato dalla definizione del tipo di contenuto Document nel file ctypeswss.xml. Il tipo di contenuto Document include diversi elementi RemoveFieldRef corrispondenti, ma potrebbe essere opportuno non rimuovere il campo Title nei tipi di contenuto personalizzati, in quanto la colonna Title fornisce l'accesso al menu a discesa ECB (Edit Control Box) nelle visualizzazioni raccolta documenti ed elenco di SharePoint.
Un esempio efficace in cui viene illustrato come rinominare i campi ereditati è rappresentato dal tipo di contenuto Far East Contact in ctypeswss.xml. Cercare 0x0116, ovvero l'ID del tipo di contenuto corrispondente, e selezionare l'elemento FieldRef con l'attributo Name="Title" per vedere come utilizzare l'attributo DisplayName per rinominare un campo nell'interfaccia utente. In questo specifico esempio, l'attributo DisplayName modifica il nome del campo Title nell'interfaccia utente in un valore di dati localizzato a cui fa riferimento "$Resources:core,Last_Name;".
Se si esamina in modo più approfondito la Figura 1, è possibile osservare che l'attributo ID dell'elemento ContentType identifica in modo univoco il tipo di contenuto e stabilisce la relazione gerarchica. Tutti gli ID iniziano con l'ID del tipo di contenuto padre ma con l'aggiunta di altri valori esadecimali. Ai tipi di contenuto standard in genere vengono aggiungi due valori esadecimali per creare un nuovo ID univoco per il tipo di contenuto figlio. Un'altra tecnica prevede l'aggiunta di "00" e di un GUID esadecimale. Questa tecnica viene utilizzata, ad esempio, per derivare i tipi di contenuto Office Data Connection File e Universal Data Connection File dal tipo di contenuto Document.
Un punto importante da tenere presente è che l'attributo ID dell'elemento ContentType non può essere composto da più di 1.024 caratteri. Questo può costituire un problema in una relazione gerarchica di grandi dimensioni quando tutti i tipi di contenuto utilizzano la tecnica del GUID esadecimale Tuttavia, non è consigliabile iniziare con la tecnica più breve in quanto questi ID potrebbero non essere univoci.
Per assicurare l'univocità, utilizzare la tecnica GUID in modo da stabilire uno spazio dei nomi globale per i tipi di contenuto aziendali e passare alla tecnica più breve all'interno dello spazio dei nomi in questione. Per informazioni dettagliate sull'attributo ID e su altri elementi delle definizioni dei tipi di contenuto, vedere l'argomento relativo allo schema delle definizioni dei tipi di contenuto nell'SDK di WSS 3.0.

Dipendenze dei tipi di contenuto
A questo punto, è opportuno affrontare la questione relativa all'utilizzo dei tipi di contenuto SharePoint per strutturare la gestione degli elementi di contenuto. È necessario prendere in considerazione diverse dipendenze, come le interdipendenze tra le raccolte documenti e gli elenchi, i tipi di contenuto, le colonne del sito e i tipi di campi. Le raccolte e gli elenchi fanno riferimento ai tipi di contenuto, che fanno riferimento alle colonne del sito, che a loro volta fanno riferimento ai tipi di campo (come i tipi di campi standard di WSS testo, nota, scelta, numero, valuta e così via), che a loro volta risiedono negli assembly Microsoft .NET Framework, come l'assembly di base di WSS Microsoft.SharePoint.dll.
A scopo esemplificativo, si esamini di nuovo il tipo di contenuto System illustrato in precedenza nella definizione CAML della voce del file manifesto dei tipi di contenuto System. Come descritto in precedenza, questo tipo di contenuto contiene un elemento FieldRef che fa riferimento a una colonna del sito denominata ContentType. Notare che la definizione del tipo di contenuto non definisce la colonna del sito ContentType effettiva. ContentType è un campo di testo, definito nel manifesto per gli elementi fieldswss.xml, situato nella cartella %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields. Il tipo di campo di testo viene definito in fldtypes.xml, disponibile nella cartella %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML. Un punto importante relativo a questa struttura di dipendenze è che è necessario assicurarsi che tutte le risorse siano disponibili sui server SharePoint.
I tipi di contenuto che si desidera utilizzare devono essere creati a livello di sito delle raccolte documenti e degli elenchi o a un livello più elevato nella gerarchia dei siti. Analogamente, i campi di metadati dei tipi di contenuto devono fare riferimento alle colonne del sito esistenti. È possibile aggiungere ai tipi di contenuti colonne del sito standard o personalizzate in base ai tipi di campi standard o personalizzati, ma occorre assicurarsi che le colonne del sito siano disponibili nel sito locale. Inoltre, se si desidera utilizzare i tipi di campo personalizzati, è necessario assicurarsi che gli assembly .NET sottostanti vengano distribuiti sui server SharePoint.
Dipendenze simili esistono per i tipi di contenuto che fanno riferimento a modelli di documento, riceventi di eventi personalizzati, flussi di lavoro e altri componenti. La definizione del tipo di contenuto, ad esempio, può contenere un elemento DocumentTemplate che fa riferimento al modello di documento associato al tipo di contenuto. La definizione del tipo di contenuto può contenere anche un elemento XmlDocuments con uno o più elementi XmlDocument figlio che definiscono caratteristiche aggiuntive del tipo di contenuto, come definizioni di spazi dei nomi, definizioni dei riquadri informazioni documento o qualsiasi informazione personalizzata.

Determinazione dei tipi di contenuto globali
Gli utenti che dispongono di autorizzazioni di creazione possono creare nuovi tipi di contenuto e nuove colonne del sito direttamente nell'interfaccia utente di SharePoint, ma, in tal caso, i tipi di contenuto sono disponibili solo nel sito locale e ai velli inferiori della gerarchia dei siti. Le colonne del sito personalizzate sono disponibili solo nel sito locale. Questo rappresenta un problema se si desidera stabilire tipi di contenuto globali. È necessario assicurare che i tipi di contenuto globali siano disponibili in tutte le raccolte siti nell'ambiente in uso. È in tale contesto che le caratteristiche di SharePoint possono risultare utili. È piuttosto semplice installare e attivare le caratteristiche di SharePoint in più raccolte siti per applicare in modo coerente le definizioni delle colonne del sito e dei tipi di contenuto corrispondenti in tutte le posizioni.
Il materiale accluso a questo articolo include una caratteristica di esempio denominata AdventureWorks che dimostra come stabilire un tipo di contenuto globale. La caratteristica definisce un tipo di contenuto generale denominato Customer Documentation che può essere utilizzato per creare qualsiasi tipo di materiale per clienti, come proposte e lettere di vendita. È ragionevole presupporre che tutti i tipi di documenti debbano essere associati alle informazioni relative ai clienti, come nome della società, dettagli di contatto e indirizzo. A tal proposito, è stato creato un campo personalizzato denominato Customer Name per il tipo di contenuto e sono stati aggiunti alcuni campi incorporati, come Department e Primary Phone. È possibile modificare il tipo di contenuto e i campi modificando il file ContentTypes.xml e i riferimenti di campo modificando il file SiteColumns.xml disponibile nell'esempio accluso.
Se si distribuisce la caratteristica descritta nel file readme.htm, è possibile attivarla in modo coerente in più raccolte siti. Il tipo di contenuto Customer Documentation viene quindi reso disponibile a livello globale. In tal modo, i singoli reparti possono creare una documentazione specifica per i clienti tramite tipi di contenuto derivati associati ai modelli di documento di destinazione. Il materiale di accompagnamento include modelli di documento di esempio che possono essere utilizzati nelle attività di vendita e di consulenza. Nella Figura 2 vengono illustrati i tipi di contenuto risultanti.
Figura 2 Tipi di contenuto padre e figlio per la documentazione dei clienti
Figura 2 Tipi di contenuto padre e figlio per la documentazione dei clienti
Sono disponibili diverse opzioni per la creazione delle caratteristiche per le colonne del sito e i tipi di contenuto personalizzati in WSS 3.0 e MOSS 2007. È possibile consultare l'SDK di WSS 3.0 e scrivere i file XML da zero. È inoltre possibile scegliere di utilizzare SharePoint Designer per esportare un elenco in un pacchetto Web personale, rinominare il file .fwp risultante in file .cab, estrarre il file manifest.xml dal file .cab e cercare le definizioni ContentType nel file manifest.xml. Sfortunatamente, entrambi gli approcci sono poco pratici e suscettibili di errore.
È molto più semplice invece creare tipi di contenuto e colonne del sito personalizzati nell'interfaccia utente di SharePoint. Tuttavia, l'interfaccia non fornisce un'opzione per modificare i file XML di una caratteristica. Le caratteristiche sono un metodo efficiente per eseguire il provisioning delle risorse SharePoint ma, una volta effettuato il provisioning, le risorse sono disponibili solo nel database del contenuto. Probabilmente una versione futura di WSS includerà la capacità di esportare colonne del sito e tipi di contenuto in file XML tramite l'interfaccia utente di SharePoint, simile all'esportazione di web part. Per ora, è necessario utilizzare le opzioni disponibili.
Il materiale di accompagnamento contiene una web part denominata ContentTypeSchema che può essere utilizzata come punto di partenza. Questa web part utilizza un modello a oggetti SharePoint per estrarre la proprietà SchemaXML dal tipo di contenuto selezionato. Tramite le trasformazioni basate su XSLT (eXtensible Stylesheet Language Transformation), la web part deriva le definizioni Field o le definizioni ContentType in base all'opzione selezionata nell'interfaccia utente prima di fare clic sul pulsante Display.
Nella Figura 3 viene illustrata la web part in azione. Nella figura viene visualizzato il tipo di contenuto Active Directory® Documentation, che è basato sul tipo di contenuto Customer Documentation. Il tipo di contenuto Active Directory Documentation è associato a un modello di Microsoft Word personalizzato (Active Directory Template.dot). Notare che questo tipo di contenuto non presenta campi aggiuntivi. Tutti i campi vengono ereditati dal tipo di contenuto padre.
Se si prevede di utilizzare la web part ContentTypeSchema nell'ambiente in uso, tenere presente che questa web part non è stata sottoposta a test completi. La web part illustrata in questo articolo utilizza trasformazioni XSL relativamente complesse per creare un delta tra la proprietà SchemaXML del tipo di contenuto correntemente selezionato e il tipo di contenuto padre corrispondente. Tuttavia, XSLT 1.0 non è progettato per conversioni di documenti XML avanzate. Non è disponibile alcuna funzionalità incorporata per il confronto dei nodi XML. Inoltre, gli spazi dei nomi XML e le sezioni CDATA pongono le difficoltà che XSLT 1.0 non è in grado di gestire in modo efficace.
SharePoint prevede l'archiviazione delle definizioni delle colonne del sito e dei tipi di contenuto del sito creati utilizzando l'interfaccia utente o il modello a oggetti di SharePoint nel database del contenuto in una tabella denominata ContentTypes. Nella Figura 3 viene illustrato l'ID del tipo di contenuto personalizzato. Di conseguenza, l'istruzione T-SQL riportata di seguito fornirà risultati esatti: SELECT Definition FROM ContentTypes WHERE ContentTypeId = <content type ID>.
Figura 3 Definizione del tipo di contenuto personalizzato in ContentTypeSchema Web part
Figura 3 Definizione del tipo di contenuto personalizzato in ContentTypeSchema Web part
Indipendentemente dall'approccio che si decide di utilizzare, la creazione di caratteristiche per i tipi di contenuto aziendali è molto semplice una volta ottenute le definizioni dei tipi di contenuto e delle colonne del sito. È consigliabile utilizzare una singola caratteristica per tutte le colonne e i tipi di contenuto del sito globali del proprio reparto o azienda. In tal modo, sarà chiaro dove aggiungere nuove definizioni dei tipi di contenuto e delle colonne del sito.

Ricerche a livello di organizzazione in metadati personalizzati
Un vantaggio immediato delle gerarchie dei tipi di contenuto è che tutti i tipi di contenuto figlio ereditano i campi di metadati del tipo di contenuto padre. Poiché tutti i tipi di contenuto hanno campi di metadati in comune, è piuttosto semplice per gli utenti creare visualizzazioni personalizzate e filtri nelle raccolte documenti.
Questo viene dimostrato in modo piuttosto intuitivo dalla caratteristica di esempio AdventureWorks. Indipendentemente dal tipo di contenuto creato da un consulente o un responsabile commerciale, il salvataggio del documento di Word 2007 risultante nella raccolta documenti richiede l'impostazione di un Customer Name, in quanto il tipo di contenuto padre Customer Documentation definisce questo campo di metadati in base alle esigenze. Raggruppando o filtrando gli elementi in una visualizzazione raccolta documenti in base al Customer Name, i consulenti e i membri del team di vendita possono individuare tutta la documentazione esistente per un cliente in modo rapido e semplice, come illustrato nella Figura 4.
Figura 4 Raggruppamento di vari documenti in una raccolta in base a metadati comuni
Figura 4 Raggruppamento di vari documenti in una raccolta in base a metadati comuni
Anche i metadati comuni semplificano l'individuazione del contenuto in più raccolte documenti e siti utilizzando le funzionalità di ricerca di WSS 3.0 e MOSS 2007. WSS supporta le ricerche in raccolte, elenchi e siti all'interno di una singola raccolta siti. MOSS 2007 va oltre queste funzionalità di base consentendo di implementare un Centro ricerche a livello aziendale e di gestire metadati personalizzati nell'interfaccia utente Amministrazione centrale di SharePoint 3.0. Per questo motivo, le spiegazioni riportate di seguito sono incentrate su MOSS 2007.
Quando si configura un provider di servizi condivisi (SPP) in MOSS 2007 e si esegue una ricerca per indicizzazione nei siti SharePoint, MOSS 2007 è in grado di individuare automaticamente i campi di metadati personalizzati utilizzati nelle origini di contenuto. Di conseguenza, è possibile trovare i campi di metadati personalizzati nell'elenco delle proprietà sottoposte a ricerca per indicizzazione.
I campi di metadati definiti nelle caratteristiche di SharePoint rientrano in genere nella categoria SharePoint. Per trovare la relativa posizione in Amministrazione centrale SharePoint nel menu Avvio veloce in Amministrazione servizi condivisi, fare clic sul collegamento a SSP, quindi su Impostazioni di ricerca e su Mapping di proprietà dei metadati, infine scegliere Proprietà sottoposte a ricerca per indicizzazione dal menu Avvio veloce e aprire la categoria SharePoint.
Di seguito viene illustrato un esempio pratico di questa procedura. Il campo di metadati Customer Name diventa una proprietà sottoposta a ricerca per indicizzazione denominata ows_Customer_x0020_Name. In SharePoint le proprietà sottoposte a ricerca per indicizzazione includono il prefisso "ows_", mentre "_x0020_" rappresenta la versione codificata di un singolo spazio. Se si visualizzano i dettagli di questa proprietà sottoposta a ricerca per indicizzazione, è possibile rilevare che tale proprietà viene inclusa nell'indice di ricerca per impostazione predefinita in modo che gli utenti possano impiegare i valori della proprietà sottoposta a ricerca per indicizzazione per eseguire ricerche di contenuto. Tuttavia, per ottenere una maggiore precisione della ricerca, è opportuno eseguire il mapping della proprietà sottoposta a ricerca per indicizzazione a una proprietà gestita in modo da consentire agli tenti di cercare esplicitamente il contenuto in base al nome del cliente.
Quando si esegue il mapping delle proprietà sottoposte a ricerca per indicizzazione alle proprietà gestite sono disponibili due opzioni. È possibile generare automaticamente una nuova proprietà gestita per ciascuna proprietà sottoposta a ricerca per indicizzazione o è possibile eseguire manualmente il mapping delle proprietà sottoposte a ricerca per indicizzazione alle proprietà gestite. La prima opzione è disponibile quando si visualizzano le impostazioni della categoria delle proprietà sottoposte a ricerca per indicizzazione desiderata (durante la visualizzazione delle proprietà sottoposte a ricerca per indicizzazione in una categoria, come la categoria SharePoint, fare clic sull'opzione Modifica categoria nel collegamento Avvio veloce). In Impostazioni generali proprietà sottoposte a ricerca per indicizzazione è necessario selezionare la casella di controllo "Genera automaticamente una nuova proprietà gestita per ogni proprietà sottoposta a ricerca per indicizzazione individuata in questa categoria". Tuttavia, in SharePoint le proprietà gestite vengono automaticamente precedute dal prefisso "ows" mentre gli spazi escape vengono preceduti dal prefisso "x0020". La proprietà gestita per la proprietà sottoposta a ricerca per indicizzazione ows_Customer_x0020_Name sarà owsCustomerx0020Name. Questo, tuttavia, non è un nome di proprietà particolarmente intuitivo per l'utente.
Probabilmente, una strategia più efficace consiste nell'eseguire manualmente il mapping delle proprietà sottoposte a ricerca per indicizzazione alle proprietà gestite dopo aver distribuito i tipi di contenuto aziendali. È possibile eseguire il mapping di una proprietà sottoposta a ricerca per indicizzazione a una o più proprietà gestite. Per creare nuove proprietà gestite, in Amministrazione centrale SharePoint nel menu Avvio veloce in Amministrazione servizi condivisi, fare clic sul collegamento a SSP, quindi su Impostazioni di ricerca, su Mapping di proprietà dei metadati e infine su Nuova proprietà gestita per specificare le informazioni necessarie e associare la nuova proprietà gestita alla proprietà sottoposta a ricerca per indicizzazione desiderata.
Gli utenti possono individuare gli elementi di contenuto rilevanti utilizzando le proprietà gestite nella sintassi proprietà: o utilizzando la ricerca avanzata. Se, ad esempio, si esegue il mapping della proprietà sottoposta a ricerca per indicizzazione ows_Customer_x0020_Name a una proprietà gestita denominata Customer, gli utenti possono cercare tutti i documenti di un cliente specificando semplicemente Customer: <Customer Name> nella casella di ricerca standard, come Customer: Contoso.
È consigliabile inoltre includere le proprietà gestite per i campi di metadati più importanti dei tipi di contenuto nell'elenco delle proprietà nella pagina Ricerca avanzata. A tal fine, visualizzare la pagina Ricerca avanzata, fare clic su Azioni sito e scegliere il comando Modifica pagina. Fare clic su Modifica in Casella di ricerca avanzata per selezionare l'opzione Modifica web part condivisa. Quando si espande la categoria Proprietà e si posiziona il cursore nel campo di testo corrispondente, è possibile fare clic sul pulsante per modificare il documento XML delle proprietà. È necessario aggiungere una definizione di proprietà all'elemento <PropertyDefs>, come <PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/>, nonché aggiungere un riferimento a questa definizione di proprietà in un elemento ResultType, ad esempio l'elemento <ResultType DisplayName="All Results" Name="default">, come <PropertyRef Name="Customer" />.Nella Figura 5a viene visualizzata l'interfaccia utente di Ricerca avanzata risultante. Nella Figura 5b vengono visualizzati i risultati della ricerca.
Figura 5a Ricerca nella documentazione dell'infrastruttura IT in base al nome del cliente
Figura 5a Ricerca nella documentazione dell'infrastruttura IT in base al nome del cliente
Figura 5b Risultati della ricerca in base al nome del cliente
Figura 5b Risultati della ricerca in base al nome del cliente

Garanzia della coerenza delle informazioni
A questo punto, i tipi di contenuto e i campi di metadati più importanti sono stati standardizzati e le funzionalità di ricerca nelle raccolte siti sono state estese nell'ambiente aziendale in base all'applicazione MOSS 2007. Ora è importante assicurare che gli utenti immettano informazioni accurate nei campi di metadati.
Sono disponibili due metodi per eseguire questa operazione. Primo, è possibile sostituire il riquadro informazioni documento standard nei modelli di documento con un modulo InfoPath® personalizzato che fornisce agli utenti una selezione predefinita di opzioni di input, come quelle disponibili in una casella di riepilogo. Secondo, è possibile associare un ricevente dell'evento al tipo di contenuto e controllare l'accuratezza dei metadati e di altre informazioni ogniqualvolta gli utenti creano, modificano o eliminano gli elementi di contenuto corrispondenti.
Entrambe le opzioni si completano a vicenda. Un modulo InfoPath fornisce principalmente un metodo conveniente per modificare le proprietà di un tipo di contenuto SharePoint, mentre un ricevente dell'evento può assicurare la validità dei metadati anche se gli utenti modificano le proprietà del tipo di contenuto all'esterno del modulo InfoPath. È possibile associare i gestori eventi a uno specifico tipo di contenuto, che consente di specificare gli eventi e le relative risposte per tutti i documenti associati a un singolo tipo di contenuto in tutte le raccolte siti, indipendentemente dalla raccolta documenti. Ulteriori informazioni su come sviluppare e distribuire i gestori eventi sono disponibili all'indirizzo msdn2.microsoft.com/ms453149.
Probabilmente un metodo più semplice per associare un tipo di contenuto a un riquadro informazioni documento personalizzato consiste nel visualizzare le impostazioni del riquadro informazioni documento del tipo di contenuto nell'interfaccia utente di SharePoint su un computer con InfoPath 2007 installato. È possibile fare clic sul collegamento Creare un nuovo modello personalizzato in Modello del riquadro informazioni documento per avviare InfoPath 2007 in modalità di progettazione. Tuttavia, se il tipo di contenuto del sito include colonne del sito senza un attributo SourceID esplicito, è possibile che si verifichi una situazione in cui InfoPath non è in grado di creare uno schema XSD valido per il modulo Riquadro informazioni documento. Ad esempio, il tipo di contenuto Customer Documentation introdotto in precedenza include diverse colonne specifiche dei contatti, come Department, Office ed e-mail, che possono causare questo problema, come illustrato nella Figura 6.
Figura 6 Incompatibilità tra gli schemi XSD in InfoPath 2007
Figura 6 Incompatibilità tra gli schemi XSD in InfoPath 2007
A questo punto, nel caso in cui si verifichi questo problema, si hanno a disposizione due opzioni. È possibile rimuovere i riferimenti alle colonne del sito senza un attributo SourceID esplicito dalla definizione del tipo di contenuto o è possibile sostituire le colonne del sito incorporate che causano il problema con le colonne del sito personalizzare compatibili con InfoPath 2007. Tenere presente che non è possibile modificare i riferimenti di campo di un tipo di contenuto basato su CAML dopo che ne è stato eseguito il provisioning nel database del contenuto, in particolare se si sono già creati tipi di contenuto figlio. Non è più possibile aggiornare semplicemente il file della definizione del tipo di contenuto basato su CAML né è possibile applicare le modifiche ai tipi di contenuto figlio, in quanto in Windows SharePoint Services non vengono rilevate le modifiche apportate alla definizione del tipo di contenuto padre.
Per applicare le modifiche, è necessario modificare il tipo di contenuto padre tramite il modello a oggetti o l'interfaccia utente di SharePoint o è necessario definire un nuovo tipo di contenuto derivato da quello esistente. La seconda tecnica consente di rimuovere i campi critici e aggiungere nuove colonne. Gli utenti possono quindi derivare i tipi di contenuto futuri dal nuovo tipo di contenuto. Per impedire agli utenti di scegliere il tipo di contenuto errato, aggiungere il tipo di contenuto precedente al gruppo dei tipi di contenuto _Hidden.
Come affermato in precedenza, non è possibile aggiornare i tipi di contenuto basati su CAML dopo averli distribuiti e attivati. Pertanto, è molto importante testare i tipi di contenuto globali prima della distribuzione. Per ulteriori informazioni, vedere l'articolo MSDN "Aggiornamento dei tipi di contenuto" all'indirizzo msdn2.microsoft.com/aa543504.
Una volta creato un tipo di contenuto con i riferimenti di campo appropriati, è possibile creare un riquadro informazioni documento personalizzato in InfoPath 2007. La strategia migliore è consentire ai proprietari del sito di creare riquadri informazioni documento personalizzati per i relativi tipi di contenuto figlio. InfoPath 2007 consente di pubblicare il riquadro informazioni documento personalizzato direttamente sul tipo di contenuto selezionato, semplificando lo scenario di distribuzione. È inoltre possibile pubblicare il modulo InfoPath in una posizione centrale, come una raccolta documenti, e includere un riferimento al riquadro informazioni documento nel tipo di contenuto. Questa rappresenta l'opzione ideale se si intende fornire un riquadro informazioni documento personalizzato insieme ai tipi di contenuto CAML. Nella Figura 7 viene illustrata l'architettura di implementazione.
Figura 7 Implementazione dei file XSN in una posizione centrale in MOSS 2007
Figura 7 Implementazione dei file XSN in una posizione centrale in MOSS 2007
Il download per questo articolo include una funzione denominata AdventureWorks_Update che consente di estendere la funzione AdventureWorks precedente aggiungendo ulteriori colonne del sito compatibili con InfoPath 2007. La funzione AdventureWorks_Update consente di contrassegnare il tipo di contenuto Customer Documentation originale come nascosto e di derivare un nuovo tipo di contenuto denominato Customer Docs, che sostituisce i campi incorporati ereditati con le nuove colonne del sito e associa il nuovo tipo di contenuto a un riquadro informazioni documento personalizzato.
La nuova definizione del tipo di contenuto Customer Docs include un elemento XmlDocument che fornisce informazioni sul riquadro informazioni documento. In particolare, l'elemento xsnLocation fa riferimento al modulo InfoPath http://companyresources/DIPs/customerDIP.xsn, che implementa il riquadro informazioni documento. Per istruzioni dettagliate su come applicare la caratteristica AdventureWorks_Update, vedere il file readme.htm nella cartella AdventureWorks_Update.

Conclusione
È possibile utilizzare i tipi di contenuto di SharePoint per creare criteri di metadati e utilizzarli in modo coerente nell'ambiente aziendale per la gestione dei contenuti. La gerarchia dei tipi di contenuto consente di standardizzare le caratteristiche rilevanti per l'intero ambiente aziendale e applicarle uniformemente a tutti i siti tramite l'ereditarietà.
È possibile ad esempio estendere le funzionalità di ricerca incorporate di MOSS 2007 in modo che gli utenti possano individuare contenuti specifici in modo più rapido e semplice. È inoltre possibile garantire la coerenza delle informazioni correlate ai metadati e stabilire criteri di gestione delle informazioni centralizzati. La strategia migliore consiste nella standardizzazione dei tipi di contenuto globali in base alle caratteristiche dei metadati più astratte per ridurre al minimo la necessità di modifiche successive. Basati su un modello di contenuto attentamente progettato, i tipi di contenuto di SharePoint sono in grado di fornire nuove funzionalità per standardizzare la gestione del ciclo di vita del contenuto nell'ambiente aziendale.

Pav Cherny è presidente di Biblioso Corporation, un esperto IT e un autore specializzato nelle tecnologie Microsoft per la collaborazione e la comunicazione unificata. I libri che ha pubblicato sono incentrati sulle operazioni IT e sull'amministrazione dei sistemi.


 Office Communications Server: Ottimizzazione della potenza di OCS 2007 tramite la presenza
Office Communications Server Rajesh Ramanathan

Ottimizzazione della potenza di OCS 2007 tramite la presenza
Panoramica:
  • Autorizzazione e servizi di directory
  • Opzioni di messaggistica in OCS 2007
  • Routing delle comunicazioni con la presenza

Microsoft Office Communication Server (OCS) 2007 si basa sui punti di forza di Live Communication Server (LCS) 2005. LCS 2005 forniva funzionalità di presenza e di messaggistica immediata di livello
aziendale. Ha introdotto inoltre l'integrazione della telefonia con le installazioni dei sistemi PBX esistenti tramite il controllo delle chiamate remote (RCC, Remote Call Control).
OCS 2007 migliora ulteriormente le funzionalità di presenza e di messaggistica immediata di LCS 2005 e aggiunge funzionalità avanzate per telefoni e supporti con Office Communicator 2007, il che lo rende un vero e proprio "softphone". Microsoft ha sviluppato inoltre i server per conferenze e i server Edge per i supporti che consentono di soddisfare tutte le esigenze di comunicazione dell'organizzazione con un PBX esistente o in modo indipendente come una soluzione completa autonoma.
Office Communicator 2007 fornisce funzionalità di "softphone" che consentono agli utenti di scegliere i dispositivi USB desiderati e fornisce agli utenti finali un'esperienza avanzata in modo da semplificare il rilevamento e l'utilizzo delle comuni funzionalità di controllo delle chiamate, come la messa in attesa o il trasferimento della chiamata. Gli utenti non devono più ricordare i numeri di telefono o utilizzare un tastierino, ma possono effettuare una chiamata con un semplice clic del mouse da un'applicazione desktop o creare una conferenza telefonica trascinando utenti o liste di distribuzione in una conversazione.
Chi necessita di veri e propri telefoni da tavolo, può utilizzare Office Communicator Phone Edition (o telefono Tanjay) come ulteriore endpoint per l'utente, con menu di scelta rapida touch screen e la familiare funzionalità di presenza di Office Communicator.
Queste funzionalità del sistema OCS sono basate sul concetto di presenza utente. OCS 2007 utilizza la disponibilità degli utenti, gli endpoint di comunicazione e le relazioni tra gli utenti per connettere gli utenti mediante il supporto più appropriato in qualsiasi momento. Poiché collega voce, posta elettronica, messaggistica immediata e altri percorsi di comunicazione, OCS consente di eseguire il routing dei messaggi nel modo più produttivo possibile.
In questo articolo verrà fornita una panoramica della soluzione OCS 2007 e verrà descritto come le diverse parti vengono combinate. Verrà inoltre illustrato come la presenza costituisca un importante elemento della comunicazione unificata e come utilizzarla per un routing più efficace delle chiamate vocali.

Autorizzazione e servizi di directory
Un sistema vocale aziendale deve essere in grado di verificare le identità degli utenti autorizzati a eseguire le chiamate, nonché di applicare restrizioni o criteri specifici in base alle singole chiamate. In un sistema Voice over IP (VoIP) è necessario che per avviare le chiamate i client vengano autenticati dal server. Si tratta di un sistema simile a un sistema PBX tradizionale in cui l'accesso alla linea fisica era sufficiente per verificare l'identità.
Il sistema OCS 2007, illustrato nella Figura 1, utilizza Active Directory® per l'autenticazione e l'archiviazione dei criteri di accesso e OCS autorizza le chiamate convalidandole in base ai criteri relativi a un utente in Active Directory. Poiché OCS utilizza le stesse informazioni di Active Directory utilizzate da altre applicazioni Microsoft, come Exchange Server o Microsoft® Outlook®, è possibile aggiungere semplicemente le funzionalità vocali agli utenti esistenti in Active Directory estendendo le proprietà e i criteri di un utente (tramite le estensioni dello schema di Active Directory) e fornendo una directory unificata che è possibile utilizzare per applicazioni in tempo reale, come chiamate vocali o messaggistica immediata.
Figura 1 Componenti di messaggistica unificata in OCS
Figura 1 Componenti di messaggistica unificata in OCS
In Active Directory, la proprietà più importante correlata alla comunicazione unificata è l'indirizzo SIP (Session Initiation Protocol) (noto anche come URI SIP), che è molto simile all'indirizzo di posta elettronica dell'utente. Ad esempio, a un utente in Active Directory con l'indirizzo di posta elettronica someone@contoso.com viene assegnato un indirizzo SIP sip:someone@contoso.com. Poiché l'indirizzo SIP è associato all'oggetto utente, è possibile fornire una singola identità in cui le stesse credenziali utilizzate dall'utente per l'accesso al relativo computer desktop o a Exchange Server possono essere impiegate per accedere al rispettivo server OCS.
Un'altra proprietà importante è rappresentata dal numero di telefono dell'utente. Il server OCS reindirizza internamente le chiamate inviate ai numeri di telefono all'URI SIP di un utente per consentire il routing della chiamata.
OCS 2007 fornisce l'interfaccia del servizio Rubrica (ABS) che è disponibile per la ricerca nelle directory all'interno di un'organizzazione. In quanto versione non in linea della rubrica, tale servizio consente agli endpoint client di evitare di utilizzare Active Directory ogni volta che viene eseguita un'operazione di ricerca sul lato client.
Oltre al servizio Rubrica, OCS 2007 rende le liste di distribuzione più utili fornendo un servizio espansione liste distribuzione (DLX, Distribution List Expansion) che consente agli utenti di visualizzare in Office Communicator la stessa lista di distribuzione visualizzata in Outlook e di espandere la lista di distribuzione in Communicator. Gli utenti possono configurare le conferenze telefoniche con i membri di queste liste di distribuzione direttamente da Office Communicator o avviare una chat di messaggistica immediata di gruppo.

Comunicazioni vocali e servizi di messaggistica
Risorse OCS aggiuntive
Per ulteriori informazioni, consultare le risorse riportate di seguito:
  • Webcast ed eventi per le comunicazioni unificate
  • Office Communications Server TechCenter
  • Laboratorio virtuale TechNet: Attivazione degli utenti e installazione di Office Communicator 2007

Una soluzione vocale aziendale deve fornire le funzionalità di controllo delle chiamate con cui gli utenti hanno maggiore familiarità. OCS 2007 quindi fornisce funzionalità molto diffuse, come la messa in attesa della chiamata, il trasferimento di chiamata e il trasferimento con consultazione del destinatario, l'inoltro e lo squillo simultaneo, nonché modalità non vocali, come la messaggistica immediata.
OCS 2007 è alla base del routing delle chiamate vocali, fornendo funzioni di routing di chiamate in ingresso e in uscita. Il routing delle chiamate in uscita implica la conversione dei numeri, l'applicazione di criteri (come le restrizioni per le chiamate internazionali) correlati a un utente e il routing della chiamata agli endpoint appropriati o alla rete telefonica pubblica commutata (PSTN). Le funzioni di routing delle chiamate in ingresso prevedono l'inoltro delle chiamate selezionate di un utente o le preferenze per la presenza o l'ora del giorno e consentono di eseguire il routing della chiamata in ingresso in modo appropriato.
OCS non termina le chiamate in ingresso. In ambiente SIP, OCS funge da registratore SIP e da proxy SIP. I segnali e i supporti vengono forniti interamente point-to-point dagli endpoint client del sistema. Gli endpoint nel sistema, come Office Communicator 2007, forniscono un codec audio a banda larga, denominato RTAudio, che garantisce caratteristiche di adattabilità e flessibilità alle condizioni di rete.
OCS 2007 fornisce conferenze Web in sede utilizzando i ruoli Server per conferenze per tutte le modalità di comunicazione: audio/video, messaggistica immediata e dati. I server per conferenze basati su OCS consentono agli endpoint client di fornire una transizione trasparente dalla comunicazione peer-to-peer alla comunicazione multimodale con più partecipanti tramite funzionalità come disattivazione audio, esclusione partecipante e blocco. Sono in grado di garantire una scalabilità che consente di supportare centinaia di partecipanti a conferenze pianificate e un massimo di cento partecipanti per discussioni ad hoc. È possibile pianificare le conferenze tramite i componenti aggiuntivi di Outlook o effettuare l'escalation nel corso della chiamata a una conferenza. Il servizio conferenze fornisce inoltre strumenti quali la condivisione file, le lavagne e la registrazione.
Ovviamente, è necessario essere in grado di fornire la connettività ai numeri di telefono e alle reti PSTN esterni nonché alle aziende federate o alle installazioni dei sistemi PBX esistenti all'interno dell'organizzazione. OCS 2007 si integra con i gateway SIP-to-PSTN offerti dai comuni provider di gateway che consentono la connessione alla rete PSTN o a un PBX esistente. Per la conversione dei codec e dei segnali, è possibile configurare un server Mediation Server. I server Mediation Server sono facoltativi e vengono configurati per i gateway che non supportano i codec Microsoft.
La messaggistica unificata di Exchange Server 2007 rappresenta la soluzione di segreteria telefonica per OCS 2007. La messaggistica unificata di Exchange fornisce la funzionalità di risposta alle chiamate fax e vocali in ingresso e consente di posizionare i messaggi ricevuti nella cassetta postale di Exchange dell'utente. Inoltre, la messaggistica unificata di Exchange fornisce servizi di operatore automatico a livello aziendale per i chiamanti esterni che cercano una specifica persona o reparto.
OCS fornisce messaggistica immediata in tempo reale come alternativa all'utilizzo dei servizi vocali e consente agli utenti di avviare conversazioni multimodali che coinvolgono contemporaneamente comunicazioni vocali, video e messaggistica immediata. Inoltre, Office Communicator 2007 supporta la formattazione e il testo RTF nella messaggistica immediata. È possibile aggiungere audio e video in qualsiasi momento alla sessione di messaggistica immediata, effettuando con facilità l'escalation dalla conversazione immediata a una conversazione audio.
L'accounting, la registrazione e la risoluzione dei problemi sono componenti aggiuntivi. L'accounting viene fornito mediante la funzionalità server di registrazione dettagli chiamate di OCS 2007. Per ogni chiamata eseguita nel sistema, viene creato un record con l'ora in cui è stata ricevuta la chiamata, la destinazione che ha risposto alla chiamata e diversi altri parametri, come i parametri che specificano ad esempio se la chiamata è stata trasferita. OCS fornisce inoltre server di archiviazione che prevedono la registrazione delle conversazioni immediate in base ai requisiti di conformità. QoE (Quality of Experience) Monitoring Server archivia le informazioni sulla qualità delle chiamate effettuate e può essere utilizzato per la risoluzione dei problemi relativi alla qualità delle comunicazioni vocali nella rete.

Registrazione e inizializzazione
Ogni endpoint client nel sistema OCS deve eseguire la registrazione in OCS, il che rappresenta il primo passo per l'inizializzazione del client. La registrazione è il processo di connessione al server OCS, un passaggio che segnala l'esistenza del client. Il processo di registrazione implica l'autenticazione dell'identità dell'utente da parte del server; questo determina la creazione di un'associazione di protezione tra l'istanza client e il server. Questa associazione di protezione viene utilizzata per le chiamate successive eseguite dal client tramite il server e viene aggiornata periodicamente dal client mediante una nuova registrazione. La durata della nuova registrazione varia in base alla topologia del server. Ad esempio, gli endpoint registrati dall'esterno dell'azienda tramite un server Edge Microsoft AccessTM aggiornano la relativa registrazione con maggiore frequenza rispetto ai client all'interno del firewall aziendale.
Tenere presente che solo gli endpoint client che necessitano di un canale autenticato persistente con OCS per ricevere le notifiche in ingresso, come le chiamate vocali o le notifiche relative alla modifica della presenza, devono eseguire la registrazione. Live Meeting è un endpoint client che richiede una connessione a OCS solo per partecipare a una riunione e, pertanto, non è necessario che esegue la registrazione con OCS.
Per comprendere meglio i dettagli dell'interazione client all'interno di OCS 2007, è opportuno esaminare in modo più approfondito Office Communicator nel ruolo di endpoint client. Molti dei flussi di segnali correlati a Office Communicator sono identici a quelli utilizzati per altri endpoint client come Office Communicator Phone Edition o Office Communicator Mobile. Una volta completata la registrazione, Office Communicator recupera le informazioni di configurazione che rivestono un'importanza critica per il funzionamento dell'endpoint client. Queste informazioni includono:
  • Informazioni personali, come biglietto da visita, indirizzo di posta elettronica, URI SIP, nome visualizzato e numero di telefono
  • Funzionalità attivate sul client e criteri
  • Indirizzi dei server come indirizzo SIP del server Edge AV e indirizzo del server della segreteria telefonica
  • Elenco degli amici archiviati nel server
  • Regole di formattazione dei numeri per la posizione del client
Questo meccanismo per il recupero di tutte le informazioni di provisioning utilizzando il canale SIP esistente al server è denominato provisioning inband. Questo consente agli endpoint client di eseguire la configurazione automatica e di aggiornare la relativa configurazione a ogni accesso dei client oltre che dall'esterno della rete o del firewall.
La sequenza di registrazione procede dalla registrazione con il server all'inizializzazione, all'impostazione della presenza e infine all'attivazione di uno stato di pronto (vedere la Figura 2). Tenere presente che OCS consente la registrazione di più endpoint client per lo stesso utente o URI SIP. Durante la registrazione, il server restituisce un indirizzo SIP univoco al client in modo che qualsiasi segnale in ingresso possa essere indirizzato allo specifico client. Questo indirizzo è noto anche come Globally Routable User URI (GRUU). A ciascun endpoint client che si registra con OCS viene assegnato un indirizzo GRUU separato dal server OCS, che identifica in modo univoco l'endpoint client.
Figura 2 Procedura di registrazione
Figura 2 Procedura di registrazione
Per tenere la registrazione sotto controllo, il server consente per qualsiasi utente un limite di otto registrazioni attive. Quando vengono registrati più client per lo stesso utente, la configurazione è nota come punti di presenza multipli (MPOP, multiple points of presence). Quando viene registrato un sinologo client, questa configurazione è nota come singolo punto di presenza (SPOP, single point of presence).
Il concetto di MPOP è alla base del sistema OCS. MPOP consente all'utente di ricevere le chiamate in ingresso o le notifiche di messaggistica immediata da qualsiasi endpoint, permettendo sostanzialmente all'utente di disporre di più endpoint per il telefono e la messaggistica immediata. Introduce dinamiche interessanti per la risposta alla messaggistica immediata o anche per illustrare in modo accurato la presenza per un utente.
Ad esempio, un utente remoto potrebbe essere collegato a un telefono IP Communicator Phone Edition (un endpoint SPOP) che non è in grado di ricevere la messaggistica immediata. Questa funzionalità dell'endpoint viene pubblicata dal telefono IP insieme alle informazioni di presenza. Lo stato di presenza dell'utente sul telefono è impostato su In linea. Un altro utente può visualizzare lo stato di presenza in linea e il tentativo di inviare un messaggio immediato mediante Communicator. Tuttavia, poiché la presenza ha già pubblicato la funzionalità dei dispositivi, viene visualizzata una notifica che informa che l'utente remoto non sta utilizzando un dispositivo che supporta la messaggistica immediata e pertanto non può ricevere il messaggio.
Un altro esempio è relativo all'accettazione automatica del messaggio immediato. Quando viene avviata una conversazione immediata, il messaggio viene accettato automaticamente se l'utente remoto si trova in una singola istanza di Communicator (un endpoint SPOP). Tuttavia, se l'utente remoto accede a due istanze di Communicator, ad esempio un portatile e un desktop, viene fornito un ritardo di 10 secondi per consentire all'utente di accettare il messaggio immediato da un dispositivo. Se non viene fornita alcuna risposta, il messaggio immediato verrà accettato automaticamente nell'istanza di Communicator più attiva.

Presenza
La presenza svolge un ruolo importante nelle comunicazioni unificate. Consente a un utente di ottenere anticipatamente informazioni sulla disponibilità dell'utente remoto per comunicare tramite una modalità specifica. Pertanto, gli stati di OCS, come Non disponibile o Chiamata in corso, vengono associati allo stato di non disponibilità di un utente anziché a un dispositivo o una linea non disponibile. Inoltre, OCS 2007 fornisce un'infrastruttura di presenza avanzata che consente all'utente di condividere informazioni come posizione, ore di lavoro e orari delle riunioni.
OCS consente all'utente di specificare le autorizzazioni in modo che diversi gruppi di persone possono avere accesso a diversi set di informazioni di presenza in base al relativo livello di accesso. OCS utilizza inoltre uno stato di presenza dell'utente, come "Non disturbare," gli orari di lavoro del calendario e il livello di autorizzazione fornito al chiamante per prendere decisioni di routing, specificando ad esempio se la chiamata deve essere inoltrata all'utente o inviata alla segreteria telefonica.
I numeri di telefono visualizzati in Fai clic per chiamare in Office Communicator sono originati da tre posizioni: due sono basate su directory (Elenco indirizzi globale/server della Rubrica e contatti di Outlook), mentre la terza è correlata alla presenza. Grazie alla presenza, gli utenti hanno la possibilità di pubblicare i numeri di telefono che desiderano vengano visualizzati ad altri utenti.
La presenza svolge un ruolo chiave anche in numerosi scenari di routing di comunicazioni vocali. Se, ad esempio, la presenza per un utente remoto è impostata sullo stato Non disponibile ed è contrassegnata dalla dicitura "In riunione", la probabilità che l'utente risponda a una chiamata vocale è piuttosto bassa. In tal caso, è possibile che il chiamante preferisca utilizzare la messaggistica immediata o la posta elettronica. Allo stesso modo, quando lo stato della presenza per un utente remoto è impostato su Non disturbare, questo indica che l'utente preferisce utilizzare metodi di comunicazione alternativi.
La presenza include inoltre informazioni sul titolo della riunione corrente di un utente e sulla posizione del calendario e tali dettagli vengono pubblicati agli utenti nel contenitore Team. La presenza contiene informazioni sull'endpoint preferito per una determinata funzionalità e tali informazioni vengono utilizzate per scegliere l'endpoint che intraprenderà un'azione predefinita. Ad esempio, la pubblicazione dei dati del calendario (che è essenzialmente identica in tutti gli endpoint) verrà eseguita solo dall'endpoint preferito per la funzionalità calendario. OCS è basato su una logica che prevede la scelta dell'endpoint preferito.
Nella Figura 3 vengono evidenziate le diverse funzionalità introdotte dalla presenza nel sistema OCS. La presenza, come affermato in precedenza, è una combinazione di disponibilità e volontà di comunicare. Lo stato In linea rappresenta lo stato in cui l'utente è maggiormente disponibile per la comunicazione, mentre Non disturbare è lo stato della presenza che indica una minore disponibilità dell'utente a comunicare. A eccezione dello stato Non disturbare, che deve essere impostato manualmente, tutti gli altri stati vengono automaticamente acquisiti da Communicator in base a diverse condizioni, ad esempio se l'utente è in riunione (non disponibile) o è lontano dal computer (inattivo), come illustrato nella Figura 4.
Figure 3 Modalità di impostazione delle informazioni di presenza (Close Figure 3)

Funzionalità | Origine
Disponibilità e volontà (In linea, Non in linea, Non al computer, Non disponibile, Non disturbare) | Automatica. Basata sullo stato della riunione, sullo stato del telefono e così via. Può anche essere impostata manualmente.
Stato del calendario (In riunione, posizione della riunione) | Automatica. Basata sulla preferenza dell'utente.
Funzionalità del dispositivo (messaggistica immediata consentita) | Automatica. Basata sul dispositivo MPOP.
Numeri di telefono | Automatica. Basata sulla preferenza dell'utente.
Endpoint più attivo | Automatica. Basata sull'attività dell'utente.
Nota | Manuale. Sostituita dalla nota Fuori sede.
Nota Fuori sede | Automatica. Basata sul calendario.
Ore lavorative | Automatica. Basata sui dati disponibili/non disponibili.
Percorso | Manuale. Basata sulla selezione dell'utente.
Figura 4 Presenza come combinazione di disponibilità e volontà
Figura 4 Presenza come combinazione di disponibilità e volontà
Notare che la disponibilità può essere gestita da diversi dispositivi a cui l'utente è correntemente collegato. Poiché sono presenti diversi dispositivi per lo stesso utente e ogni dispositivo pubblica le informazioni di presenza e i dati degli utenti, è necessaria una logica di aggregazione che consenta di presentare una sola visualizzazione agli spettatori. OCS include questa logica di aggregazione che consente di calcolare la presenza in base a vari parametri, dispositivi e input che vengono ricevuti dal sistema di presenza.
Prima di analizzare l'aggregazione, è opportuno esaminare la modalità con cui le informazioni aggregate vengono pubblicate agli utenti. OCS 2007 ha introdotto il concetto di contenitori, che sono simili ai livelli di accesso associati ai cerchi sociali. Ogni contenitore fornisce una diversa quantità di informazioni e le persone che vengono aggiunte a uno specifico contenitore hanno accesso solo alle informazioni rese disponibili a tale contenitore. Ciascun contatto nell'elenco degli amici dell'utente deve essere presente in uno dei contenitori disponibili. Office Communicator consente di assegnare utenti ai contenitori o di spostarli in contenitori differenti in base al livello della relazione. Office Communicator prevede l'utilizzo di un'euristica intelligente per selezionare automaticamente il contenitore predefinito (elencato nella Figura 5).
Figure 5 Contenitori di presenza (Close Figure 5)

Contenitore | Scopo
Bloccato | Blocca le informazioni di presenza. Le chiamate da parte degli utenti bloccati non sono consentite. Tuttavia, gli utenti bloccati possono visualizzare le informazioni sul nome e sull'indirizzo di posta elettronica.
Pubblico | Fornisce nome, titolo, azienda, indirizzo di posta elettronica e disponibilità limitata.
Società | Fornisce le informazioni sui contatti di lavoro, la pianificazione di base e la disponibilità.
Team | Fornisce il numero di telefono cellulare e dell'ufficio, la pianificazione, la disponibilità ed è in grado di interrompere l'utente quando nello stato Non disturbare.
Personale | Consente di visualizzare tutte le informazioni di contatto pubblicate, compresi i numeri di telefono cellulare e di casa.
L'aggregazione della presenza in OCS determina la corretta presenza per l'utente in base ai diversi stati di presenza che i dispositivi riportano al server. Nella Figura 6 viene illustrato come la presenza viene aggregata da un'ampia gamma di origini. Tenere presente che alcune informazioni, come lo stato della presenza e l'attività dell'utente, vengono inviate tramite il meccanismo di aggregazione della presenza di OCS prima che le informazioni vengano rese disponibili nei contenitori e prima che altre informazioni, come i dettagli di contatto, vengano aggiunte dall'endpoint client ai rispettivi contenitori. Il contenitore bloccato risulta mancante in quanto in tale contenitore non viene pubblicata alcuna informazione diversa dalle informazioni di appartenenza.
Figura 6 Aggregazione della presenza e pubblicazione
Figura 6 Aggregazione della presenza e pubblicazione
Nel sistema OCS, una relazione di presenza viene stabilita quando un utente aggiunge un altro utente all'elenco di contatti (elenco di amici). Tuttavia, il sistema OCS consente anche di verificare la presenza di altri utenti nella directory aziendale senza dover aggiungere questi utenti singolarmente ai contatti.
Il metodo più semplice per ottenere la presenza per un utente è cercare qualcuno in Office Communicator. Questo genera una singola query sul server e non determina la sottoscrizione delle notifiche del server relative alle modifiche dello stato della presenza degli utenti remoti. Tuttavia, quando un utente aggiunge un altro utente al proprio elenco di amici, sottoscrive le notifiche sulle modifiche dello stato della presenza in modo che OCS invii automaticamente degli avvisi quando viene apportata una modifica.

Messaggistica immediata e audio
La messaggistica immediata si avvale sia della registrazione che della presenza. Nel sistema OCS, i messaggi vengono trasmessi in modalità peer-to-peer e il server OCS funge da proxy che trasmette i messaggi tra i client di Office Communicator.
Il primo messaggio che un utente invia a un altro utente è molto importante, in quanto, nel gergo del protocollo SIP, stabilisce la sessione. Per poter stabilire la sessione, è necessario individuare il client MPOP appropriato tra i client registrati ed è in tale contesto che il sistema OCS svolge un ruolo importante come proxy. Quando l'utente accetta la sessione di messaggistica immediata in ingresso o se uno degli endpoint MPOP dell'utente accetta automaticamente la sessione, i messaggi successivi vengono trasmessi senza problemi e senza richiedere il rilevamento di un client appropriato da parte di OCS.
Gli utenti possono lasciare aperte sui desktop le relative finestre di conversazione immediata e, se non viene eseguita alcuna attività entro un intervallo di 10 minuti, Office Communicator 2007 terminerà la sessione SIP (anche se la finestra di messaggistica immediata resterà aperta). La sessione di messaggistica immediata può essere terminata su entrambi i lati. Quando la sessione di messaggistica immediata viene terminata, Office Communicator 2007 crea automaticamente un elemento della cronologia per la conversazione che consente di registrare l'intera conversazione nella cartella Cronologia conversazioni di Outlook. Questa è una cartella speciale che viene creata in Outlook da Office Communicator. Questa funzionalità di registrazione sul lato client è facoltativa ed è disattivata per impostazione predefinita. La cartella Cronologia conversazioni viene utilizzata da Office Communicator per riavviare una conversazione con lo stesso utente; pertanto, gli utenti che attivano questa funzionalità potranno continuare la conversazione immediata dopo la chiusura della finestra di messaggistica immediata.
La struttura di messaggistica immediata presentata in questo articolo per la duplicazione e MPOP è applicabile anche allo scenario delle comunicazioni vocali. Invece dell'invito contenente una descrizione della sessione di messaggistica immediata, conterrebbe una descrizione della sessione vocale che indica funzionalità audio. In OCS la duplicazione della chiamata vocale verrebbe applicata a tutti gli endpoint, analogamente a quanto accade con la messaggistica immediata.
La segnalazione vocale fa uso di molti concetti alla base della messaggistica immediata, ma introduce la necessità di gestire i supporti. Questo argomento verrà trattato in maggiore dettaglio in un articolo futuro.

Rajesh Ramanathan ha lavorato nel settore delle comunicazioni per 14 anni e attualmente lavora come Lead Program Manager nel team di Office Communicator. È possibile contattarlo all'indirizzo rajeshra@microsoft.com.


 Office Communications Server: Pianificazione della distribuzione di Enterprise Voice per OCS 2007
Office Communications Server Jochen Kunert and Rui Maximo

Pianificazione della distribuzione di Enterprise Voice per OCS 2007
Panoramica:
  • Scenari di integrazione della telefonia
  • Configurazione di Office Communications Server
  • Utenti, piani di numerazione e route

Microsoft Office Communications Server (OCS) 2007 è un prodotto rivolto alle aziende che integra supporti di comunicazione in tempo reale con il rilevamento della presenza degli utenti, comprese conferenze Web
(condivisione di dati, audio e video), messaggistica immediata e conversazioni audio/video. L'integrazione di OCS 2007 con un sistema PBX esistente può rivelarsi un'attività impegnativa. Office Communications Server 2007 non è progettato per essere impiegato come sistema PBX, poiché gli Information Worker oggi utilizzano nel flusso di lavoro quotidiano un'ampia gamma di supporti di comunicazione, e-mail, messaggistica immediata, telefono e segreteria telefonica, mentre i sistemi PBX consentono di effettuare solo chiamate telefoniche.
Per garantire la flessibilità necessaria agli amministratori per creare la strategia di integrazione della telefonia aziendale o privata ottimale, Office Communications Server 2007 fornisce tre scenari di configurazione per l'integrazione con gli ambienti di telefonia esistenti. Gli scenari sono i seguenti: controllo delle chiamate remote, Enterprise Voice ed Enterprise Voice con integrazione PBX.
In questo articolo vengono illustrate alcune considerazioni per la pianificazione di una distribuzione di telefonia di OCS 2007, che potrebbe richiedere l'integrazione con un sistema di telefonia esistente. Queste informazioni saranno di particolare interesse per gli architetti di sistema e gli amministratori IT e dei sistemi di telefonia. Nell'articolo verrà inoltre fornita una panoramica sugli altri scenari, ma l'attenzione verrà focalizzata sul componente Enterprise Voice di Office Communications Server 2007.

Controllo delle chiamate remote
Risorse OCS aggiuntive
  • Pro LCS: Live Communications Server Administration
  • Integrazione della telefonia con Office Communications Server 2007
  • Guida alla pianificazione e alla distribuzione di Enterprise Voice

In uno scenario per il controllo delle chiamate remote (RCC, Remote Call Control) gli utenti dispongono già di un telefono PBX, IP-PBX o TDM (Time-Division Multiplexing). Dal client Office Communicator 2007 gli utenti possono effettuare e ricevere chiamate con il telefono sulla scrivania senza digitare alcun numero sul tastierino o alzare la cornetta. Gli utenti possono controllare il telefono con Office Communicator 2007, mentre l'audio viene gestito dal sistema PBX e non verrà convertito in una chiamata Voice-over-IP (VoIP). Anche se il telefono della scrivania viene controllato da Office Communicator 2007, è comunque possibile effettuare e ricevere chiamate dal telefono PBX, indipendentemente dal fatto che Office Communicator 2007 sia o meno in esecuzione.
Per abilitare la funzionalità di controllo delle chiamate remote con Office Communicator 2007 e OCS 2007, è necessario distribuire un gateway SIP/CSTA (Session Initiation Protocol/Computer Supported Telephony Application), oltre ad attivare l'ambiente Office Communications Server 2007 per il controllo delle chiamate remote. Il gateway SIP/CSTA deve interoperare con il tipo di sistema PBX utilizzato e deve essere compatibile con OCS 2007, poiché stabilisce un collegamento tra i due sistemi. Per controllare il telefono PBX, in Office Communicator 2007 si utilizza il protocollo CSTA. Il protocollo definisce uno schema XML per interfacciarsi con le commutazioni telefoniche (PBX), come descritto nello standard ECMA (European Computer Manufacturers Association) 269, disponibile all'indirizzo www.ecma-international.org/publications/standards/Ecma-269.htm.
Office Communicator 2007 invia i comandi CSTA per il controllo del telefono PBX come payload SIP, che vengono instradati da Office Communications Server 2007 al gateway SIP/CSTA. Non è necessario che Office Communications Server 2007 riconosca il protocollo CSTA; occorre solo che sappia come eseguirne il routing. Il gateway SIP/CSTA converte quindi i comandi nel protocollo nativo utilizzato dal sistema PBX. Questo scenario è illustrato nella Figura 1.
Figura 1 Scenario di integrazione RCC
Figura 1 Scenario di integrazione RCC
L'attivazione del controllo delle chiamate remote richiede l'esecuzione di cinque operazioni. La prima consiste nel configurare il gateway SIP/CSTA per la comunicazione con il sistema PBX. Occorre quindi configurare OCS 2007 per il routing delle richieste CSTA al gateway SIP/CSTA. La terza operazione è la configurazione degli utenti per il controllo delle chiamate remote. La quarta consiste nel configurare Office Communicator 2007. Infine è necessario definire le regole di normalizzazione OCS 2007, che vengono anche utilizzate per la normalizzazione dei numeri di telefono della Rubrica e sono diverse dalle regole di normalizzazione dei numeri di telefono utilizzate in combinazione con Enterprise Voice.

Enterprise Voice
Quando un utente viene abilitato per Enterprise Voice, Office Communicator 2007 o Office Communicator Phone Edition diventa il telefono principale, non il sistema PBX. A Office Communicator 2007 viene assegnato un numero di telefono univoco. A scopo di test, è possibile inoltrare il telefono PBX esistente a un nuovo interno assegnato a Office Communicator 2007. Office Communicator 2007, in combinazione con un dispositivo audio USB consigliato, gestirà sia il controllo delle chiamate (o segnalazione) che i supporti (audio e video).
In questo scenario Office Communications Server 2007 esegue il routing delle chiamate tra gli endpoint Office Communicator 2007 sulla rete IP (chiamate IP-IP) ed esegue il routing delle chiamate alla rete telefonica pubblica commutata (PSTN)/PBX (chiamate IP-PSTN). OCS 2007 impone restrizioni di composizione alle chiamate instradate alla PSTN.
Per connettere l'ambiente Office Communications Server 2007 a un sistema PBX o una rete PSTN, è necessario distribuire un gateway multimediale, definito anche gateway SIP/PSTN o IP/PSTN. Per connettersi all'ambiente Office Communications Server 2007, è necessario che il gateway multimediale venga utilizzato con il server Mediation Server (un ruolo del server di OCS 2007), come illustrato nella Figura 2. È consigliabile installare Mediation Server e il gateway multimediale associato nella stessa posizione fisica.
Figura 2 Scenario di integrazione Enterprise Voice con PSTN o un PBX esistente
Figura 2 Scenario di integrazione Enterprise Voice con PSTN o un PBX esistente
Il server Mediation Server consente di connettere i gateway multimediali che supportano implementazioni SIP standard, anche non protette, con Office Communications Server 2007, poiché OCS 2007 consente solo comunicazioni autenticate e crittografate. Un'altra attività di Mediation Server consiste nel gestire le conversioni tra i codec standard (G.711, G.723 e così via) e il codec audio in tempo reale di Microsoft. Per un elenco dei gateway multimediali supportati da Office Communications Server 2007, vedere Partner hardware strategici all'indirizzo technet.microsoft.com/bb735838.
È possibile connettere i gateway multimediali direttamente alla rete PSTN o a una connessione PRI (Primary Rate Interface) di un sistema PBX esistente. Nella Figura 2 vengono illustrati i possibili scenari di integrazione per lo scenario Enterprise Voice con la rete PSTN e un sistema PBX esistente. Per una distribuzione di Enterprise Voice non è necessario un director (in genere un server Office Communications Server Standard Edition), anche se è consigliabile utilizzarlo.
Per l'attivazione di Enterprise Voice sono necessarie quattro operazioni. La prima consiste nel distribuire e configurare i gateway multimediali. Poiché si tratta di un prodotto di un partner Microsoft, è opportuno consultare la documentazione del fornitore, dal momento che ciascun gateway multimediale prevede una diversa procedura di distribuzione.
Quindi è necessario distribuire un server Mediation Server per ogni gateway multimediale. Durante questa operazione, si deve configurare una scheda di rete di Mediation server per l'invio e la ricezione del traffico proveniente dal gateway multimediale e configurare l'altra scheda di rete di Mediation Server per l'invio e la ricezione del traffico proveniente da un client Office Communications Server 2007 (in genere un director in una distribuzione Enterprise Edition). Per interoperare con l'infrastruttura Enterprise Voice per OCS 2007 il gateway multimediale in uso, a meno che non sia un gateway avanzato, necessiterà dell'assistenza di un ruolo Mediation Server OCS 2007.
La terza operazione prevede la definizione di un piano di numerazione, con la conseguente definizione dei criteri vocali, delle route telefoniche e dei profili località.
In seguito occorre configurare gli utenti per Enterprise Voice. Inoltre, è necessario abilitare gli utenti per Enterprise Voice in modo che siano in grado di effettuare e ricevere chiamate dal PBX o da PSTN. Questo richiede l'assegnazione di numeri di telefono univoci a ciascun utente.

Enterprise Voice con integrazione PBX
Questa configurazione è un'estensione della configurazione di Enterprise Voice. La differenza è che il telefono PBX dell'utente è sincronizzato con il client Office Communicator dell'utente. La configurazione è simile allo scenario Enterprise Voice per la connessione alla rete PSTN tramite un PBX, come illustrato nella Figura 2. Tuttavia, in questo caso, anziché sostituire il telefono PBX dell'utente con un client Office Communicator 2007, Office Communicator 2007 e il telefono PBX esistente utilizzeranno lo stesso numero di telefono.
Se un chiamante compone l'interno dell'utente da un altro telefono PBX o da un telefono PSTN, il sistema PBX devierà la chiamata sul telefono PBX dell'utente e sul client Office Communicator 2007 dell'utente tramite Office Communications Server 2007. Il client Office Communicator 2007 e il telefono PBX dell'utente squilleranno contemporaneamente in caso di chiamata in ingresso. Al contrario, Office Communications Server devierà le chiamate avviate da OCS 2007 sul telefono PBX tramite il gateway multimediale. Uno scenario di questo tipo non è possibile quando si utilizza Office Communicator Phone Edition. Questa configurazione richiede che la segreteria telefonica venga gestita dal sistema di segreteria telefonica del PBX. Per utenti di questo tipo non è possibile utilizzare la messaggistica unificata di Exchange Server 2007 come soluzione di segreteria telefonica.
L'attivazione dello scenario Enterprise Voice con integrazione PBX prevede gli stessi passaggi necessari per la distribuzione di Enterprise Voice ma con tre operazioni aggiuntive. Nel primo passaggio aggiuntivo, il gateway multimediale deve essere connesso direttamente al PBX. È quindi necessario configurare il sistema PBX per il supporto di questo scenario. Questo potrebbe richiedere un aggiornamento software del PBX, a seconda del fornitore. Infine, è necessario abilitare gli utenti per l'integrazione PBX.
Microsoft è attualmente impegnata nel fornire il supporto per la connessione diretta di Mediation Server al sistema IP PBX senza l'intermediazione di un gateway multimediale. Per informazioni aggiornate relative a questo argomento, visitare il sito technet.microsoft.com/bb735838.

Configurazione di Office Communications Server
La funzionalità Enterprise Voice viene gestita dai servizi eseguiti in Office Communications Server 2007 Enterprise Edition e Office Communications Server 2007 Standard Edition. Nella Figura 3 vengono descritti i servizi che forniscono la funzionalità Enterprise Voice per il routing delle chiamate in ingresso e in uscita.
Figure 3 Servizi di Enterprise Voice (Close Figure 3)

Servizio | Descrizione
Servizio di conversione | Applica le regole di normalizzazione in base al profilo località o al contesto del telefono.
Servizi utente | Esegue la ricerca inversa dei numeri sul numero di telefono di destinazione.
Componente di routing in ingresso | Applica le preferenze di chiamata dell'utente di destinazione.
Messaggistica unificata di Exchange | Inoltra la richiesta alla segreteria telefonica in base alle esigenze.
Componente di routing in uscita | Determina la route ottimale in base all'URI e al criterio utente.
Nella Figura 4 viene illustrato come ciascuno di questi componenti opera sulle chiamate in ingresso mentre vengono instradate da OCS 2007 per una chiamata da PC a PC. Le chiamate in ingresso possono provenire da un endpoint connesso, come Office Communicator 2007 o Office Communicator Phone Edition, o da un server Mediation Server proveniente da PSTN/PBX (chiamata PSTN-SIP). Le chiamate in uscita che hanno origine da uno degli endpoint del client Office Communications Server 2007 del chiamante, come Office Communicator 2007, vengono inviate al pool Standard Edition Server o Enterprise in cui risiede l'utente. Questo pool viene anche definito pool principale dell'utente.
Figura 4 Interazione dei servizi correlati a Enterprise Voice sui server front-end OCS
Figura 4 Interazione dei servizi correlati a Enterprise Voice sui server front-end OCS
A questo punto, Office Communications Server 2007 elabora la chiamata per determinare dove instradarla. L'hop successivo può essere rappresentato dal pool principale della parte chiamata, da un server Mediation Server o dalla messaggistica unificata di Microsoft® Exchange Server 2007 (vedere la Figura 5). Se la chiamata viene instradata a un altro pool principale, OCS 2007 invia la chiamata a tutti gli endpoint attivi della parte chiamata.. Il telefono Office Communicator 2007 o Office Communicator Phone Edition della parte chiamata squillerà e sul dispositivo viene visualizzata una finestra popup di notifica.
Figura 5 Routing della chiamata
Figura 5 Routing della chiamata
Se la chiamata viene instradata a un server Mediation Server, il server verrà configurato per il routing a uno specifico gateway multimediale. Se il gateway multimediale viene connesso direttamente a un PBX, la chiamata verrà instradata dal PBX a un telefono da tavolo o al telefono PSTN. Tuttavia, se il gateway multimediale viene connesso direttamente al telefono PSTN, la chiamata verrà inoltrata a PSTN.
Se l'hop successivo è rappresentato dalla messaggistica unificata di Exchange Server 2007, il chiamante può lasciare un messaggio. La segreteria telefonica è disponibile indipendentemente da se la parte chiamata sia connessa a Office Communications Server 2007.
Quando la parte chiamata risponde, l'audio viene inviato direttamente dal client Office Communicator 2007 o Office Communicator Phone Edition della parte chiamante al client Office Communicator 2007 o Office Communicator Phone Edition della parte chiamata in una chiamata IP-to-IP. Se la parte chiamante utilizza un telefono PBX o PSTN, Mediation Server invierà il traffico audio direttamente al client Office Communicator 2007 o Office Communicator Phone Edition della parte chiamata in una chiamata IP-to-PSTN. OCS 2007 gestisce solo la segnalazione delle chiamate e, per questo motivo, l'audio e il video vengono trasmessi direttamente tra gli endpoint e non vengono instradati da OCS 2007.

Configurazione degli utenti
È necessario assegnare agli utenti abilitati per Enterprise Voice numeri di telefono univoci all'interno dell'organizzazione. Questa configurazione viene eseguita in Active Directory®. Si tratta di una configurazione diversa da quella della maggior parte dei sistemi di telefonia in cui il numero di telefono è assegnato al telefono. Il vantaggio è rappresentato dalla possibilità per gli utenti di trasformare il computer su cui è in esecuzione Office Communicator 2007 nel telefono dell'ufficio accedendo a OCS 2007 dal client. Questa funzionalità di portabilità può risultare di particolare interesse per i telelavoratori o i lavoratori sul campo.
Il numero di telefono dell'utente viene specificato in formato E.164 in Active Directory. Questo formato definisce il piano di numerazione delle telecomunicazioni internazionali pubbliche, uno schema di numerazione per rappresentare in modo univoco e senza ambiguità i numeri di telefono. Il formato E.164 specifica il numero di telefono nel seguente formato:
+<country code><area code><phone number>
Un utente abilitato per Enterprise Voice dispone di due rappresentazioni univoche: un URI SIP e un numero di telefono E.164. Quando si compone un numero di telefono, Office Communications Server risolve la rappresentazione E.164 del numero di telefono (+14255551212) nell'URI SIP dell'utente (joe@contoso.com). Office Communications Server 2007 quindi esegue il routing della chiamata in base all'URI SIP della parte chiamata. Se il numero di telefono non può essere risolto in un URI SIP, OCS 2007 esegue il routing della chiamata a PBX/PSTN tramite un server Mediation Server.
Durante la pianificazione di una distribuzione di Enterprise Voice in cui a ogni utente di Office Communications Server deve essere assegnato un numero di telefono univoco, è necessario prendere in considerazione il sistema di telefonia esistente. Se si esegue una connessione diretta al sistema PSTN tramite un gateway multimediale, è probabile che si disporrà di un intero blocco di numeri di interni composti da 2 o 3 cifre, numeri DID (Direct-Inward-Dialing) che è possibile distribuire agli utenti di OCS 2007. Se si esegue una connessione al sistema PSTN tramite un PBX, è probabile che si disporrà di un blocco di numeri DID forniti dal PBX da assegnare agli utenti di OCS 2007.

Piani di numerazione
Anche se i numeri di telefono in formato E.164 forniscono una rappresentazione univoca, questo non rappresenta un metodo conveniente per la composizione dei numeri. Non è possibile inoltre comporre un numero in questo formato in Office Communicator Phone Edition o nei telefoni PBX/PSTN standard. Come è possibile specificare un carattere + utilizzando il tastierino del telefono composto da 10 cifre? Gli utenti si sono abituati a comporre interni più brevi, che possono essere univoci in uno specifico reparto ma non nell'intera azienda. Pertanto, è necessario specificare determinate regole per la conversione di tali numeri in formato E.164.
Per eseguire queste conversioni di numeri, l'amministratore deve definire i profili località che specificano le regole di normalizzazione. Dopo che il numero di telefono è stato esteso dal client (Office Communicator 2007 o Communicator Phone Edition) o dal servizio di conversione di Office Communications Server 2007 in un formato E.164, Servizi utente può eseguire una ricerca inversa dei numeri e associare il numero in formato E.164 a un URI SIP corrispondente. Se viene trovata una corrispondenza, le regole di normalizzazione definite in un profilo località utilizzano le espressioni regolari per eseguire la conversione. Se, ad esempio, viene composto il numero 1234, utilizzando una regola di normalizzazione che prevede un modello a quattro cifre per la conversione in +1425555{4-digit}, il numero 1234 verrebbe convertito in +1425551234. I profili località, pertanto, consentono agli utenti di mantenere le stesse abitudini di composizione.
Gli amministratori possono assegnare i profili località agli utenti in tre modi:
  • Definire il profilo località per gli utenti utilizzando Office Communicator 2007 tramite Criteri di gruppo.
  • Consentire agli utenti di selezionare un profilo località da Office Communicator Phone Edition.
  • Assegnare un profilo località al pool principale. Il profilo verrà assegnato automaticamente agli utenti residenti nel pool in questione.
La definizione di un piano di numerazione prevede la creazione di criteri vocali, route telefoniche e profili località tramite le regole di normalizzazione. I criteri vocali definiscono il tipo di accesso alle chiamate consentito agli utenti. Office Communications Server 2007 determina la modalità di routing delle chiamate a PBX/PSTN tramite le route telefoniche. Poiché i numeri di telefono possono essere composti in molteplici modi, le regole di normalizzazione di un profilo località definiscono come convertire il numero di telefono composto in formato E.164, che può essere quindi instradato.
Ogni utente abilitato per Enterprise Voice viene associato dall'amministratore a un criterio vocale. Un criterio vocale definisce i privilegi di chiamata assegnati a un utente. I privilegi di chiamata determinano le route che l'utente è autorizzato a utilizzare e pertanto i numeri che gli è consentito comporre. Ogni utente deve essere associato a un singolo criterio vocale. Il numero di criteri disponibili viene creato dall'amministratore.
Ogni criterio vocale contiene un'impostazione per consentire o non consentire agli utenti di eseguire le chiamate simultaneamente e un elenco ordinato di utilizzi telefono. Il criterio vocale, analogamente al criterio riunione, è un contenitore logico di impostazioni definite come documento XML archiviato in Active Directory. Il valore di questa configurazione è rappresentato dal fatto che può essere estesa nelle versioni future di OCS 2007 in modo da fornire il supporto per impostazioni di criteri aggiuntive, senza richiedere l'estensione dello schema di Active Directory. Se, ad esempio, un criterio vocale non viene associato ad alcun utilizzo telefono, il risultato è che agli utenti assegnati a tale criterio verrà impedito di effettuare chiamate in uscita al sistema PBX/PSTN. Tali utenti potranno solo effettuare chiamate IP-IP.

Utilizzo telefono e route telefoniche
Un utilizzo telefono definisce i privilegi di routing del telefono consentiti agli utenti. Un utilizzo telefono è un insieme di route telefoniche. Si tratta di una stringa che deve essere una parola chiave univoca, ovvero nessun altro utilizzo telefono può avere lo stesso nome. Gli amministratori possono creare il numero desiderato di utilizzi telefono.
Sebbene un criterio vocale possa essere associato direttamente a una route o un set di route, anziché agli utilizzi telefono, la parola chiave dell'utilizzo telefono è un'astrazione per mantenere l'associazione tra i criteri e le route. Se i criteri venissero associati direttamente alle route, rimuovendo effettivamente il concetto di utilizzi telefono, e l'amministratore modificasse il nome di una route, sarebbe necessario aggiornare ogni criterio associato a tale route. L'utilizzo telefono, che è un attributo di un criterio e una route per creare l'associazione tra criteri e route, consente di mantenere la relazione tra il criterio e la route anche se il nome della route viene modificato.
Una route contiene un formato di numeri di telefono e un elenco di server Mediation Server connessi ai gateway multimediali. Una route deve essere assegnata ad almeno un utilizzo telefono. Questa associazione tra il formato e i gateway specifica come eseguire il routing dei numeri di telefono che corrispondono al formato in questione.
Il formato specifica un intervallo di numeri di telefono tra cui è in grado di trovare una corrispondenza.. Viene definito come espressione regolare che può includere ed escludere i numeri di telefono. Lo strumento Route Helper di Enterprise Voice viene fornito per semplificare la creazione di queste espressioni regolari. Di conseguenza, se il numero di telefono che viene composto corrisponde al formato dell'espressione regolare della route, la chiamata verrà instradata a uno dei gateway definiti nella route.
In una singola route è possibile elencare più server Mediation Server (e pertanto più gateway multimediali). Office Communications Server 2007 esegue il routing della chiamata ai server Mediation Server utilizzando un approccio di tipo "round robin" in modo da bilanciare il traffico attraverso i gateway. Se un gateway genera un errore o viene interrotto per la manutenzione, il server Mediation Server corrispondente invierà una risposta a Office Communications Server 2007, che tenterà immediatamente di instradare la chiamata a un altro server Mediation Server (e pertanto a un altro gateway multimediale) nell'elenco della route.
Dopo 10 tentativi di routing delle chiamate a un gateway multimediale in stato di errore, Office Communications Server 2007 riduce il traffico verso il gateway multimediale in questione fino a quando non diventa di nuovo attivo. Se il gateway multimediale continua a non rispondere dopo altri 10 tentativi, Office Communications Server 2007 interromperà il routing delle chiamate al gateway multimediale in questione fino a quando non diventa attivo.
L'elenco dei gateway multimediali definiti nella route telefonica viene descritto dal nome di dominio completo e dal numero di porta del gateway. Se il numero di telefono non corrisponde al formato dell'espressione regolare, verrà eseguita una verifica della route successiva associata all'utilizzo telefono assegnato all'utente fino a quando non viene trovata una corrispondenza. Se non viene trovata alcuna corrispondenza, la chiamata non potrà essere instradata e non riuscirà a raggiungere la relativa destinazione. L'utente riceve una notifica che informa che la chiamata non può essere completata.

Passaggi successivi
Office Communications Server 2007 fornisce tre livelli di integrazione della telefonia. Durante la pianificazione della distribuzione della telefonia, è necessario determinare il livello che meglio corrisponde alle esigenze aziendali correnti e future in tema di telefonia. Una volta determinate tali esigenze, sarà possibile procedere con la pianificazione della distribuzione. Un aspetto importante della pianificazione è la definizione di un piano di numerazione per la distribuzione di Enterprise Voice per Office Communications Server. È opportuno prestare particolare attenzione a questo aspetto.
Per ulteriori informazioni su Enterprise Voice per Office Communications Server 2007 e sulle tecnologie correlate, vedere l'intestazione laterale "Risorse OCS 2007 aggiuntive".

Jochen Kunert vanta 10 anni di esperienza nel settore delle telecomunicazioni e attualmente lavora come Senior Program Manager nel gruppo Office Communications presso Microsoft. È coautore del libro di prossima pubblicazione Microsoft Office Communications Server 2007 Resource Kit. È possibile contattare Jochen all'indirizzo jkunert@microsoft.com.
Rui Maximo lavora da 14 anni nel settore IT ed è coautore di due libri: Pro LCS: Live Communications Server Administration e Microsoft Office Communications Server 2007 Resource Kit. È possibile contattare Rui all'indirizzo ruim@ruimaximo.com.


 Soluzioni HPC (High Performance Computing): Un'introduzione a Windows Compute Cluster Server
Soluzioni HPC (High Performance Computing) John Kelbley and Doug Lindsey

Un'introduzione a Windows Compute Cluster Server
Panoramica:
  • Utilizzo dei cluster per risolvere problemi complessi
  • Requisiti generali per i cluster di calcolo
  • Impostazione di un cluster di calcolo basato su Windows
  • Esecuzione di comandi in modalità remota

Per HPC (High Performance Computing) si intende una branca particolare dell'informatica applicata che si occupa, per la maggior parte, della risoluzione di problemi che prevedono notevoli carichi di lavoro per l'elaborazione. Alcuni anni fa, l'HPC (all'epoca definito più in generale "supercomputing") era dominato da
grandi sistemi specializzati (e costosi) utilizzati soprattutto nei centri di ricerca. Con l'aumento della potenza di calcolo dei sistemi più piccoli, tuttavia, il rapporto costo/prestazioni è cambiato e i carichi di lavoro di elaborazione si sono spostati verso i sistemi di classe PC.
Molti problemi che prevedono grandi carichi di lavoro possono essere risolti eseguendo i calcoli in parallelo; vale a dire, un determinato calcolo o processo potrebbe non dipendere dall'output di un altro. In casi come questo, per la risoluzione di problemi complessi si possono sfruttare più sistemi di piccole dimensioni (nodi) raggruppati in cluster di calcolo. Ecco alcuni esempi dei tipi di applicazione che si avvantaggiano dell'impiego di cluster di calcolo:
  • Modelli finanziari: un algoritmo o una formula viene eseguita per migliaia di volte, con input diversi a ogni esecuzione.
  • Ingegneria: simulazione degli effetti nelle singole parti, applicando delle texture ai modelli.
  • Animazione computerizzata: vengono applicati texture di materiali e illuminazioni a ogni fotogramma di un film.
I cluster di calcolo rappresentano un modo economico per risolvere problemi complessi in tempi ridotti. Come verrà illustrato dall'articolo, Microsoft fornisce le funzionalità chiave per i cluster di calcolo e il supporto completo con Windows® Cluster Server 2003.
È importante comprendere che un cluster di calcolo è diverso da un cluster di disponibilità (o di failover). I cluster di disponibilità sono già molto noti e diffusi in ambiti quali Exchange, SQL Server® o altre applicazioni in Windows Server® 2003. In genere sfruttano l'archiviazione condivisa per massimizzare i tempi di attività delle applicazioni. Lo scopo dei cluster di calcolo non è eseguire il lavoro di un altro sistema in caso di guasti, ma consentire a tutti i nodi di operare in modo coordinato.

Requisiti generali per i cluster di calcolo
Risorse per l'HPC
  • Community su Windows HPC
  • Applicazioni di calcolo ad alte prestazioni con WCCS 2003
  • Panoramica sull'elaborazione a 64 bit Microsoft
  • Home page delle applicazioni server Microsoft
  • Techcenter di Compute Cluster Server
  • Guida dettagliata all'installazione, configurazione e ottimizzazione di una distribuzione di cluster HPC

I sistemi HPC moderni condividono alcuni elementi chiave che facilitano l'elaborazione dei carichi di lavoro. Prima di tutto, è necessario più di un sistema. È inoltre necessaria un'utilità di pianificazione per coordinare le attività tra i nodi. L'utilità di pianificazione viene eseguita sul nodo principale e individua le risorse disponibili, assegnando e distribuendo le attività e registrando lo stato globale delle attività. È il coordinatore delle risorse all'interno del cluster di sistemi, oltre che il punto in cui utenti e amministratori inseriscono le attività da eseguire.
I cluster utilizzano un mezzo di comunicazione fra i nodi. In base al tipo di attività, ai nodi possono essere necessarie interconnessioni ad alta velocità e bassa latenza per il passaggio dei messaggi tra un nodo e l'altro e il coordinamento dell'elaborazione. Come minimo, ciascun nodo di calcolo e il nodo principale devono essere connessi a una rete comune.
Naturalmente, quando si utilizza un grande numero di sistemi interconnessi che collaborano alla risoluzione di problemi complessi, è necessario prestare molta attenzione e utilizzare strumenti specifici. Per ottenere un ambiente uniforme e stabile, è necessario utilizzare processi e strumenti per il provisioning, il controllo, la gestione e la manutenzione di centinaia o migliaia di sistemi.
Infine, devono essere disponibili applicazioni in grado di sfruttare le funzionalità di elaborazione parallela di un cluster di calcolo. Senza applicazioni in grado di suddividere le attività in modo che possano essere elaborate su più computer o strumenti di sviluppo che prevedano il supporto del "debug parallelo", un cluster non può fare molto più che riscaldare il centro di calcolo.

Clustering basato su Windows Server
Nel 2006 Microsoft ha presentato Windows Server 2003 Compute Cluster Edition (CCE) e Windows Compute Cluster Server 2003 (WCCS) per soddisfare le esigenze di una vasta gamma di applicazioni HPC. CCE e WCCS sono entrambi basati sul ben noto e diffuso Windows Server 2003. CCE è una versione di Windows Server 2003 concesso in licenza con le applicazioni HPC. WCCS è identico a CCE, con l'aggiunta del Microsoft® Compute Cluster Pack (CCP). Ne consegue che è possibile distribuire, gestire e monitorare un cluster basato su Windows Server utilizzando gli stessi strumenti che si utilizzano per gestire i sistemi Windows Server 2003 esistenti.
Un punto importante è che CCE e WCCS sono esclusivamente x64 e non esistono versioni a 32 bit (x86) di questi prodotti. I requisiti hardware per CCE con WCCS sono identici a quelli per Windows Server 2003 Standard x64 Edition. Oltre al supporto per l'hardware ad alte prestazioni (architettura a 64 bit), i prodotti prevedono il supporto per Remote Direct Memory Access (RDMA) per le connessioni ad alte prestazioni (Gigabit Ethernet, InfiniBand, Myrinet e altre).

Compute Cluster Pack
Come suggerito in precedenza, i cluster di calcolo devono soddisfare dei requisiti di base, obiettivo raggiungibile con l'installazione del Compute Cluster Pack. CCP è un pacchetto di installazione autonomo che contiene:
  • Utilità di pianificazione integrata
  • Supporto di MPI (Messaging Passing Interface) per lo standard MPICH2 del settore
  • Strumenti di gestione delle risorse del cluster e degli utenti
CCP è ciò che differenzia CCE da WCCS. È lecito chiedersi perché, se sono necessari per i cluster di calcolo, questi componenti sono disponibili solo in WCCS e non in CCE. La risposta è che alcune soluzioni HPC utilizzano utilità di pianificazione diverse o MPI specializzati (oppure non richiedono il supporto di MPI) ed è sufficiente una grande piattaforma su cui eseguirle, in particolare Windows Server 2003. Poiché è un pacchetto autonomo, è possibile installare CCP su altre versioni x64 di Windows Server 2003 (CCE, Standard, Standard R2, Enterprise ed Enterprise R2).

Aspetti pratici
WCCS sfrutta i principi di base di Windows per semplificare la gestione e il funzionamento dei cluster basati su Windows, compresi Active Directory® e Servizi di installazione remota (RIS). Compute Cluster Server utilizza Active Directory per gestire la protezione in modo trasparente. Con Active Directory, un utente può inviare al nodo principale un'attività da eseguire su centinaia di nodi server utilizzando un'unica serie di credenziali. Quando vengono eseguite su uno o più nodi, le attività vengono eseguite nel contesto delle credenziali utente fornite al momento della presentazione dell'attività e, quindi, memorizzate in modo protetto nella cache. In WCCS si utilizza Active Directory per fornire questa funzionalità di "punto di accesso unico". Un ulteriore vantaggio della presenza di Active Directory nell'ambiente consiste nella possibilità di amministrare criteri di server e configurazione in modo centralizzato, mediante i Criteri di gruppo.
Se nell'organizzazione IT Active Directory è già stato distribuito, sarà possibile risparmiare quantità significative di tempo e lavoro di amministrazione durante la creazione del cluster nel dominio esistente. Questo è lo scenario consigliato.
Quando è necessario distribuire un cluster di calcolo in un ambiente in cui Active Directory non esiste, è invece consigliabile distribuire uno o più controller di dominio dedicati che ospitino Active Directory per il cluster. Non è insolito impostare come nodo principale un controller di dominio Active Directory, poiché tutti i nodi dispongono già della connettività di rete al sistema, indipendentemente dalla topologia della rete. Tuttavia, adottare come nodo principale un controller di dominio non è una procedura consigliata per i cluster di maggiori dimensioni, a causa del maggior carico sul nodo principale. In questi casi è opportuno seguire le procedure comuni per la distribuzione e la gestione di Active Directory (installazione di controller di dominio ridondanti, backup adeguati, procedure consigliate per la protezione e così via).

Servizi di installazione remota
WCCS offre un front-end integrato per la piattaforma di distribuzione delle immagini Servizi di installazione remota (RIS). RIS viene utilizzato per distribuire le immagini del sistema operativo dal nodo principale a ciascuno dei nodi di calcolo. È quindi possibile utilizzare il RIS per installare rapidamente i nuovi nodi cluster. Non è necessario eseguire le installazioni in questo modo, poiché RIS è stato integrato in WCCS come servizio aggiuntivo. Si possono utilizzare anche altre tecnologie di distribuzione comuni di Windows Server, come Automated Deployment Services (ADS) di Windows Server 2003 o un'installazione manuale di Windows Server 2003.
Se si preferisce utilizzare RIS, prima di installare CCP sul nodo principale, accertarsi che siano stati definiti almeno due dischi logici. Per la memorizzazione delle immagini server in RIS è necessario un disco che sia separato dal sistema operativo. La quantità di spazio libero su disco per la partizione RIS deve essere sufficiente a contenere una o più copie complete di un'immagine di Windows Server.
L'hardware per server più recente, in particolare i dispositivi di connessione in rete e archiviazione, potrebbero richiedere driver Plug and Play non presenti nelle immagini predefinite di Windows Server 2003. In questo caso sarà necessario aggiungere i driver all'immagine manualmente. La procedura per questa operazione è documentata in linea all'indirizzo support.microsoft.com/kb/254078.

Installazione del cluster
Il primo passaggio consiste nel configurare il cervello del cluster, ovvero il nodo principale. Iniziare installando una delle versioni x64 di Windows Server 2003 citate in precedenza. Durante l'installazione del sistema operativo, decidere se aggiungere o meno il server a un dominio esistente (scelta consigliata) oppure installare Active Directory sul server (non consigliato per i cluster di grandi dimensioni).
Al termine dell'installazione del sistema operativo, scaricare e installare anche tutti gli aggiornamenti disponibili su Microsoft Update. Se si intende utilizzare RIS per le immagini dei nodi di calcolo, è necessario utilizzare lo strumento di amministrazione Gestione computer | Gestione disco per verificare che siano stati definiti almeno due dischi logici. Per motivi di spazio, nell'articolo non viene illustrata l'installazione basata su RIS.
Dopo l'accesso e l'aggiornamento del server, eseguire il programma di installazione di CCP. Durante l'installazione di CCP si esegue il download e l'installazione dei file e degli aggiornamenti seguenti:
  • Aggiornamento rapido di RIS (vedere go.microsoft.com/fwlink/?linkid=55167)
  • Microsoft Management Console (MMC) 3.0 (vedere go.microsoft.com/fwlink/?linkid=62400)
  • SQL Server Desktop Edition, installato come parte del processo di installazione del nodo principale Compute Cluster Server 2003
  • Microsoft .NET Framework 2.0
Il programma di installazione di CCP esegue tutte le operazioni di valutazione dello stato di preparazione del sistema per l'installazione. Consente di individuare i componenti necessari e installati come parte del processo e di procedere all'installazione, come illustrato nella Figura 1.
Figura 1 Componenti necessari per l'installazione di CCP
Figura 1 Componenti necessari per l'installazione di CCP

Elenco delle attività
Al termine dell'installazione di CCP, viene avviata la console di amministrazione con l'elenco delle attività visualizzato. Come illustrato nella Figura 2, nell'elenco delle attività sono disponibili alcuni riquadri, ciascuno relativo a un'area diversa e con le attività principali necessarie per completare la configurazione del cluster.
Figura 2 Elenco delle attività necessarie per la configurazione del cluster
Figura 2 Elenco delle attività necessarie per la configurazione del cluster
L'elenco consente di implementare facilmente l'architettura del cluster progettata, comprese la scelta e la configurazione della topologia di rete, del processo di installazione dei nodi e il modello di gestione degli utenti. Le attività di ciascuno dei riquadri sono elencate sulla destra e per ogni attività viene avviata una procedura guidata. Eseguire tutte le attività in sequenza per ottenere un nodo principale completamente configurato, pronto per la distribuzione di immagini RIS a una serie definita di nodi di calcolo che un numero specificato di utenti possono utilizzare e amministrare.
Topologia della rete WCCS supporta le cinque topologie di rete più comuni utilizzate per l'HPC. Come minimo, tutti i nodi di calcolo e il nodo principale devono condividere una rete comune. Le topologie prevedono il supporto per più tipi di interconnessioni tra i nodi e presentano vantaggi e svantaggi diversi.
La topologia di rete dipenderà da prestazioni, protezione e requisiti di distribuzione per il cluster. È possibile, ad esempio, che l'applicazione richieda una connessione ad alta velocità per passare i messaggi che non si desidera esporre alla rete aziendale. Oppure si intende approfittare delle funzionalità di distribuzione integrate e automatiche basate su RIS. O ancora, l'hardware scelto consente di ospitare un solo NIC o, magari, si desidera eseguire sul nodo principale Condivisione connessione Internet (ICS) per gestire la risoluzione dei nomi e i nodi di calcolo. Durante la procedura guidata "Configure Cluster Network Topology" richiamabile dall'elenco delle attività vengono presentate le cinque topologie supportate in genere dalle implementazioni HPC più comuni, oltre a consigli sulla configurazione delle connessioni di rete, compreso le configurazioni di Windows Firewall sul nodo principale e sui nodi di calcolo. Nella Figura 3 viene illustrata una delle topologie di rete supportate.
Figura 3 Una delle topologie di rete supportate da WCCS
Figura 3 Una delle topologie di rete supportate da WCCS
Servizi di installazione remota Come affermato in precedenza, RIS consente di distribuire in modo automatico i nodi cluster.
Gestione dei nodi È possibile specificare i nomi dei computer dei server che assumeranno la funzione di nodi di calcolo nel cluster. Quando si esegue CCP su un nodo, si specifica il nodo principale del cluster a cui deve essere associato il nodo.
Gestione degli utenti Si possono specificare gli account utente o i gruppi di Active Directory designati come amministratori del sistema e come utenti del cluster.

Installazione del nodo
La distribuzione dei nodi di calcolo può essere completata automaticamente tramite l'utilità di amministrazione RIS o con altri metodi di distribuzione supportati. Come accade con il nodo principale, CCP deve essere installato su tutti i nodi di calcolo. Come illustrato dalla Figura 4, le opzioni di configurazione di CCP sono molto più semplici per un nodo di calcolo e sono le seguenti:
Figura 4 Compute Cluster Pack
Figura 4 Compute Cluster Pack
  • Definizione del server come un nodo di calcolo (e non un nodo principale).
  • Indicazione del nome del nodo principale del cluster a cui deve essere associato il server.
  • Scelta se installare o meno gli strumenti di amministrazione dei nodi e degli utenti sul nodo di calcolo.

Console di amministrazione
Quando i nodi sono in comunicazione col il nodo principale, diventa possibile eseguire la maggior parte delle attività di gestione e amministrazione per tutti i sistemi mediante la console di amministrazione, illustrata nella Figura 5. La console costituisce un punto di vista centralizzato sull'intero cluster, con un elenco di tutti i nodi associati, l'accesso alle operazioni di amministrazione principali e altre informazioni. Nel riquadro più a sinistra è possibile spostarsi tra le sezioni principali della console, tra cui "Cluster Administrator" che, quando evidenziato, fornisce una schermata di riepilogo con lo stato del cluster e le statistiche sulle attività. È possibile accedere a tutte le sessioni di desktop remoto e di monitoraggio del sistema anche da qui, ma la maggior parte del lavoro di amministrazione del cluster verrà eseguito in "Node Management".
Figura 5 La console di amministrazione è un punto di vista centralizzato sull'intero cluster
Figura 5 La console di amministrazione è un punto di vista centralizzato sull'intero cluster
È utile esplorare la console di amministrazione di propria iniziativa, poiché consente di accedere agli strumenti e alle funzioni principali necessarie per amministrare in modo centralizzato Windows e i nodi del cluster. Se si fa clic su un nodo del cluster nel riquadro in alto al centro, si visualizzano dei dati in altre finestre e si possono esplorare le funzioni specifiche del nodo.
Le funzioni supportate dai menu di scelta rapida consentono di amministrare con facilità i nodi di calcolo direttamente da Node Management. È possibile utilizzare Node Management per le seguenti attività: sospensione e ripristino dei nodi; approvazione o rimozione dei nodi dal cluster; avvio dei desktop remoti, del monitoraggio del sistema o del visualizzatore eventi; espulsione del vassoio dell'unità CD (funzione particolarmente utile quando si deve identificare fisicamente un singolo computer in un grande cluster).

La funzionalità ClusRun
La funzionalità più utile in questo elenco è "Run Command", che consente di eseguire in modalità remota qualsiasi comando arbitrario, esattamente come se si utilizzasse un prompt dei comandi sul computer di destinazione. In WCCS è disponibile una versione a riga di comando della funzionalità Run Command denominata Clusrun.exe e si utilizza "ClusRun" per descrivere sia la versione della GUI che della riga di comando.
Non è necessario enfatizzare i vantaggi offerti da ClusRun, specialmente su un cluster di grandi dimensioni. Consente di risparmiare molto tempo nell'esecuzione di attività da riga di comando ripetitive e, spesso, di eliminare la necessità di scrivere script di amministrazione più complessi.
Per utilizzare questa funzionalità, evidenziare un elenco dei computer su cui si desidera eseguire un comando, quindi fare clic con il pulsante destro del mouse e scegliere Run Command. La finestra di dialogo è illustrata nella Figura 6. A questo punto è sufficiente digitare il comando desiderato, scegliere Run e attendere che l'output venga visualizzato nella finestra Result. In occasione del primo utilizzo di ClusRun vengono richieste le credenziali, ma è possibile scegliere di memorizzare le credenziali nella cache per gli utilizzi successivi.
Figura 6 È possibile eseguire un comando sui più nodi
Figura 6 È possibile eseguire un comando sui più nodi
Un modo molto comune per applicare delle patch ai cluster o installare dei programmi che prevedano routine di installazione automatiche consiste nel collocarli in una condivisione file e utilizzare, quindi, ClusRun per forzare tutti i nodi di calcolo a richiamare il comando. Il riavvio di tutti i nodi di calcolo del cluster si può ottenere con un unico comando:
CLUSRUN SHUTDOWN –R –F –T 0

Strumenti di Compute Cluster Pack
Nel maggio 2007 il team di HPC ha rilasciato il Compute Cluster Pack Tool Pack (disponibile all'indirizzo windowshpc.net/resources/Pages/default.aspx). Tra gli strumenti sono compresi il supporto per Windows PowerShellTM, uno strumento MPIPingPong per la diagnosi dell'integrità delle connessioni e un monitor grafico del cluster semplice ma molto utile.
Come illustrato nella Figura 7, in Simple Cluster Monitor è possibile visualizzare in una schermata ciascuno dei nodi del cluster, i core presenti in ciascun nodo, l'utilizzo di ciascuna CPU (verde chiaro), l'utilizzo della memoria (giallo), la percentuale di tempo disco (rosso) e l'utilizzo della larghezza di banda (arancio). È un ottimo strumento che gli amministratori possono eseguire per conoscere con un colpo d'occhio lo stato del cluster.
Figura 7 Monitoraggio di alcuni nodi con Simple Cluster Monitor
Figura 7 Monitoraggio di alcuni nodi con Simple Cluster Monitor
Nel monitor dei cluster è disponibile anche una funzionalità di "remotizzazione". È necessario eseguire la prima istanza del monitor dei cluster sul nodo principale. Quando si esegue un'istanza del monitor dei cluster in una sessione della console sul nodo principale, diventa possibile avviare le istanze del monitor dei cluster da una workstation, impostarle in modo che puntino al nodo principale e ottenere la medesima visualizzazione.

Non resta che provare.
A questo punto si sono acquisite le informazioni di base su HPC e Windows Server 2003 Compute Cluster Server. Si è appreso come installare CCP, come utilizzare l'ottima console polifunzionale ed eseguire i nuovi comandi e gli strumenti grafici con cui sorprendere colleghi e utenti. Le risorse per ottenere ulteriori informazioni sulle applicazioni di calcolo ad alte prestazioni sono disponibile nell'intestazione laterale "Risorse per l'HPC".

John Kelbley è un Technical Product Manager in Microsoft per il Global Solutions Technology Team con base nel nordest degli Stati Uniti. È possibile contattare John scrivendo all'indirizzo Johnkel@microsoft.com
Doug Lindsey è un Program Manager del team di Microsoft HPC. È anche un amministratore di cluster di calcolo di produzione (compreso il n. 116 nell'elenco di novembre 2007 sul sito www.top500.org). È possibile contattare Doug scrivendo all'indirizzo Dougli@microsoft.com.


 Ulteriori informazioni in linea: Distribuzione di Office System 2007 con Servizi terminal
Ulteriori informazioni in linea James D. Silliman

Distribuzione di Office System 2007 con Servizi terminal
Panoramica:
  • Distribuzione per Office System 2007
  • Gestione delle impostazioni utente
  • Nuova barra di accesso rapido
  • Strumento di personalizzazione per Office System 2007

Con il rilascio di Microsoft Office System 2007 sono state introdotte importanti modifiche di progettazione che è consigliabile prendere in considerazione prima di distribuire o eseguire l'aggiornamento dalle versioni precedenti nella server farm di Servizi Terminal. È necessario acquisire familiarità con concetti, quali modello generale, barra di accesso rapido,
snap-in del file .adm per Criteri di gruppo e Strumento di personalizzazione di Office. Se si acquisisce dimestichezza con tutti questi strumenti prima di avviare la distribuzione, tale processo sarà notevolmente agevolato. L'articolo inizia con un'analisi delle modifiche più importanti introdotte in Microsoft® Word.

Distribuzione di Word 2007
In Microsoft Word è sempre stato utilizzato un file di modello generale e in Office System 2007 questo file è denominato normal.dotm. In un ambiente Servizi terminal è possibile adottare tre approcci differenti per la distribuzione di Word e del file normal.dotm. È possibile lasciare invariato il file su tutti i server Servizi terminal in cui è installato Office in modo che gli utenti ricevano la visualizzazione predefinita standard di Word. È possibile aprire il file su ciascun Terminal Server e modificarlo manualmente, aggiungendo personalizzazioni in modo che gli utenti non ricevano la visualizzazione predefinita di Word. In alternativa, è possibile rinominare il file in modo che gli utenti dispongano di un proprio file specifico (modificato quando si modifica un'impostazione in Word e si fa clic su Predefinito).
Qualunque sia l'approccio scelto, è preferibile che tale decisione venga presa prima di avviare il processo di distribuzione. Se non si apporta alcuna modifica, gli utenti non potranno salvare le relative modifiche al modello generale in quanto il file del modello generale che risiede sui server di Servizi terminal sovrascriverà il file degli utenti nei singoli profili. Se non si apre il file del modello e lo si modifica, in Word 2007 verranno visualizzate agli utenti solo le impostazioni predefinite.
È possibile, tuttavia, modificare il file su ciascun server nella farm di Servizi Terminal, se si desidera. Per adottare questo approccio e mantenere le stesse impostazioni di Word per ogni utente (come layout, spaziatura tra paragrafi e tipi di carattere e dimensioni predefiniti) è necessario non rimuovere il file del modello generale dal percorso predefinito. Per modificare qualsiasi impostazione che si desidera distribuire globalmente agli utenti, aprire semplicemente il file in questione su ogni computer di Servizi Terminal, apportare le modifiche desiderate al layout di Word 2007 (fare clic su Predefinito) e salvarle, scrivendo le modifiche nel file predefinito normal.dotm.
Assicurarsi di eseguire il backup del file predefinito prima di apportare eventuali modifiche; in caso contrario, è possibile che si renda necessario reinstallare Word 2007 per recuperare il file originale. Tenere presente che se si apportano modifiche alla barra di accesso rapido durante la modifica del file normal.dotm, queste modifiche non verranno archiviate nel file del modello. La barra di accesso rapido e il relativo comportamento verranno descritti più avanti in questo articolo.
Nel caso in cui si desideri che gli utenti siano in grado di gestire le relative impostazioni globali in Word, sarà necessario rinominare il file normal.dotm, ad esempio in normal.dotm.old, su tutti i server della farm. Probabilmente questa è la scelta più appropriata, in quanto gli utenti possono ricevere messaggi di errore del modello alla chiusura di Word nel caso in cui altre applicazioni vi accedano.
Se si rinomina questo file, Word 2007 riconoscerà che si desidera consentire agli utenti di gestire le preferenze personalizzate anziché utilizzare le preferenze globali e, di conseguenza, consentirà agli utenti di modificare e salvare le impostazioni effettuate. In Word 2007 il file normal.dotm personalizzato viene posizionato nel percorso del profilo di ciascun utente. Se si utilizzano profili comuni (a seconda della modalità di impostazione dei percorsi), il file del modello verrà archiviato nel seguente percorso di cartella per ciascun utente: \\domain\sharename\%username%\Application Data\Microsoft\Templates.
Un'impostazione di una preferenza di un utente non archiviata nel file normal.dotm è rappresentata da qualsiasi modifica apportata alla barra di accesso rapido. La barra di accesso rapido è una nuova funzionalità di Office System 2007, differente dalla barra multifunzione principale (anche questa una nuova funzionalità). La barra di accesso rapido è la piccola barra situata per impostazione predefinita nell'angolo superiore sinistro dello schermo in Office System 2007. Questa barra viene utilizzata dalle applicazioni all'interno di Office System 2007, come illustrato nella Figura 1. Per ulteriori informazioni , visitare il sito support.microsoft.com/kb/926805.
Figure 1 File della barra di accesso rapido (Close Figure 1)

Applicazione di Office | Area di funzionalità | Nome file
Access 2007 | Tutte | Access.qat
Excel 2007 | Tutte | Excel.qat
Outlook 2007 | Contatti, calendario, lista di distribuzione, voce diario, posta, inserimento nella cartella, attività | Olkaddritem.qat Olkapptitem.qat Olkdistitem.qat Olklogitem.qat Olkmailitem.qat Olkpostitem.qat Olktaskitem.qat
PowerPoint 2007 | Tutte | PowerPoint.qat
Word 2007 | Tutte | Word.qat
Come illustrato nella Figura 1, la barra di accesso rapido utilizza i file con estensione .qat per archiviare le impostazioni personalizzate. I file vengono mantenuti nel seguente percorso predefinito su ciascun server di Servizi terminal all'interno della farm e non vengono spostati: C:\Documents and Settings\<nomeutente>\Impostazioni locali\Dati applicazioni\Microsoft\Office (o C:\Utenti\<nomeutente>\AppData\Local\Microsoft\Office su un computer su cui viene eseguito Windows Vista®).
Se si esamina questo percorso, si noterà che i file .qat sono nella sottocartella Impostazioni locali del profilo memorizzato nella cache locale dell'utente di Servizi terminal. Questa sottocartella non viene sincronizzata con un profilo comune di un utente in fase di disconnessione in quanto Impostazioni locali non esiste nella struttura del percorso dei profili comuni standard. Purtroppo, se si eliminano i profili memorizzati nella cache locale sui server di Servizi terminal attivando questa impostazione per gli oggetti Criteri di gruppo, i file.qat personalizzati dell'utente andranno persi (per ulteriori informazioni, vedere l'articolo della Knowledge Base all'indirizzo support.microsoft.com/kb/274152).
È noto che l'eliminazione dei profili memorizzati nella cache è un'attività ampiamente eseguita dagli amministratori di Servizi terminal per garantire la pulizia dei profili locali alla disconnessione di un utente; pertanto, questa modifica in Office System 2007 è significativa in quanto è correlata ai profili memorizzati nella cache e alla barra di accesso rapido. Una soluzione ovvia consiste nell'assicurarsi che l'impostazione per gli oggetti Criteri di gruppo illustrata nell'articolo della Knowledge Base sopra menzionato non venga configurata. Se non si consente l'eliminazione dei profili memorizzati nella cache in fase di disconnessione e si dispone di numerosi utenti, la conseguenza sarà l'utilizzo intensivo di spazio prezioso sull'unità %systemroot% locale di ciascun server di Servizi terminal e sarà necessario impostare un altro processo per tenere sotto controllo lo spazio disponibile in quanto lo spazio sul disco rigido del server in uso potrebbe esaurirsi. Non è insolito che si verifichi una situazione di questo tipo in quanto i profili locali possono raggiungere dimensioni piuttosto elevate.
Qualunque sia l'approccio adottato, è consigliabile aggiungere almeno una routine allo script di accesso che esegua un backup dei file .qat dell'utente periodicamente in modo che possano essere ripristinati nel caso in cui vengano eliminati accidentalmente. Conservando un backup di questi file personalizzati sarà possibile evitare chiamate frenetiche al supporto tecnico per richiederne il ripristino.
Il numero di amministratori che eseguono il backup di questi file memorizzati nella cache locale è piuttosto ridotto; gli amministratori generalmente eseguono invece il backup dei profili comuni di rete che, come già affermato, non contengono copie dei file .qat. Un'altra alternativa consiste nel considerare un prodotto di terze parti che consenta di distribuire un profilo obbligatorio per ciascun utente e di eseguire il mapping delle modifiche della cartella Impostazioni locali di ciascun utente in una cartella differente sulla rete.

Snap-in di Criteri di gruppo
Già da qualche tempo ormai per Office 2003 sono disponibili i file .adm di Criteri di gruppo, che consentono un maggiore controllo amministrativo dei criteri di Office e dell'esperienza utente. Allo stesso modo, in Office System 2007 sono presenti nuovi file .adm che è possibile utilizzare per effettuare numerose personalizzazioni, tra cui la disattivazione della finestra di dialogo relativa alla prima esecuzione e la modifica delle impostazioni di salvataggio automatico e di altre preferenze.
Se si sono già distribuiti i criteri di gruppo di Office 2003 e si è deciso di passare a Office System 2007, sarà necessario rimuovere i file .adm di Office 2003 esistenti dagli oggetti Criteri di gruppo prima di aggiungere i file. adm di Office System 2007. Ricordare di eseguire il backup degli oggetti Criteri di gruppo mediante l'interfaccia della Console Gestione Criteri di gruppo (GPMC) in modo da poter ripristinare il sistema in caso di errore dopo l'aggiunta dei nuovi snap-in. Sono certo che ad almeno un amministratori di Servizi terminal è capitato di imbattersi in voci di criteri fantasma create rimuovendo gli snap-in di Office 2003 e aggiungendo i file .adm di Office System 2007 nei relativi oggetti Criteri di gruppo.
Nel mio articolo di maggio 2007 "Guida alla distribuzione dei Servizi terminal" (technetmagazine.com/issues/2007/05/TerminalServices) ho affermato che agli utenti di Servizi terminal non dovrebbe essere chiesto di eseguire alcune azioni, come l'archiviazione automatica di Outlook® o l'accettazione delle finestre di dialogo relative alla prima esecuzione. Tenere presente che, per impostazione predefinita, al primo avvio di Outlook 2007 agli utenti vengono visualizzate due schermate relative alla prima esecuzione: una per le opzioni di privacy e l'altra per la ricerca desktop. La prima schermata, visualizzata nella Figura 2, può essere disattivata in diversi modi: modificando le impostazioni degli oggetti Criteri di gruppo (utilizzando i nuovi file .adm di Outlook 2007), utilizzando lo Strumento di personalizzazione di Office o modificando il Registro di sistema.
Figura 2 Finestra di dialogo Opzioni privacy in Office System 2007
Figura 2 Finestra di dialogo Opzioni privacy in Office System 2007
La schermata illustrata nella Figura 3 viene visualizzata subito dopo la finestra di dialogo Opzioni privacy (se non disattivata) e in tutte le altre applicazioni di Office System 2007.
Figura 3 Finestra di dialogo della funzionalità Ricerca immediata in Office System 2007
Figura 3 Finestra di dialogo della funzionalità Ricerca immediata in Office System 2007
Per disattivare la richiesta di ricerca di Windows® per le applicazioni di Office, scaricare i modelli ADM di Office System 2007 dal sito go.microsoft.com/fwlink/?LinkId=78161 e caricarli sull'unità disco nel proprio controller di dominio. In Criteri di gruppo, è necessario caricare il modello di Office Outlook 2007 (Outlk12.adm) in Configurazione computer o Configurazione utente, Aggiungi snap-in. Successivamente, accedere a Configurazione utente\Modelli amministrativi\Microsoft Office Outlook 2007\Strumenti | Opzioni\Preferenze\Opzioni di ricerca e attivare l'impostazione "Disattiva avvisi relativi all'installazione in assenza del componente Windows Desktop Search".
In Office System 2007 sono disponibili molte impostazioni di Criteri di gruppo che consentono di controllare l'esperienza utente, ma è necessario aggiungere per ciascuna di esse i rispettivi file .adm, come Word (Word12.adm) ed Excel® (Excel12.adm), agli oggetti Criteri di gruppo. Nella Figura 4 viene illustrato un esempio dell'aspetto del modello ADM di Outlook 2007 (Outlook12.adm) una volta aggiunto a Criteri di gruppo.
Figura 4 Modello ADM di Outlook 2007 in Criteri di gruppo
Figura 4 Modello ADM di Outlook 2007 in Criteri di gruppo

Modifiche aggiuntive
Tenere presente che in Office 2003 è inoltre possibile scaricare e utilizzare l'installazione guidata personalizzata per creare trasformazioni personalizzate. Il nuovo Strumento di personalizzazione di Office in Office System 2007 non richiede un download separato. Viene avviato utilizzando "Setup /admin" nel comando Esegui, indirizzato all'origine di installazione o supporto di Office System 2007. L'esecuzione di questo comando dai file dell'origine di installazione e la modifica di singole impostazioni in base alle esigenze consente di creare un file .msp (contrapposto al file .mst in Office 2003) e non è necessario specificare alcuna opzione della riga di comando per includerlo nel processo di distribuzione successivo. Se viene semplicemente posizionato nella cartella relativa agli aggiornamenti nella directory radice della cartella di installazione dalla rete, il file .msp personalizzato verrà automaticamente distribuito con le impostazioni preferite.
Outlook 2007 presenta un altro vantaggio rispetto alle versioni precedenti; è in grado di individuare automaticamente i server di Exchange 2007, inviando una query del punto di connessione del servizio (SCP) direttamente ad Active Directory®, se avviato nella rete LAN. Questa query semplifica la connessione a un'infrastruttura distribuita di Exchange 2007. Per ulteriori informazioni, visitare il sito Web all'indirizzo go.microsoft.com/fwlink/?linkid=76177.
Microsoft ha introdotto alcune importanti modifiche di progettazione nel comportamento di Office System 2007 in un ambiente Servizi terminal semplificando i relativi strumenti di distribuzione, aggiungendo nuovi snap-in per i file .adm e ottimizzando l'interfaccia. Se si comprendono alcuni dei concetti fondamentali illustrati in questo articolo prima di distribuire o aggiornare le applicazioni di Office, si avrà una conoscenza molto più approfondita del processo di aggiornamento, consentendo di prendere in anticipo importanti decisioni di progettazione. Se non si prevede di eseguire l'aggiornamento in questa fase, è consigliabile valutare l'opportunità di caricare semplicemente il pacchetto di compatibilità per Office System 2007 in modo da consentire agli utenti di aprire gli allegati inviati da utenti che hanno già effettuato l'aggiornamento. Il pacchetto di compatibilità è disponibile all'indirizzo go.microsoft.com/fwlink?LinkID=77512.
Con queste informazioni a disposizione, si avrà la preparazione necessaria per una corretta distribuzione di Office System 2007. Ricordare di eseguire il backup dei criteri e di testare tutte le impostazioni consigliate in un ambiente di laboratorio prima di distribuirle alla community di utenti.

James D. Silliman, MCSE, è un tecnologo Microsoft specializzato nella distribuzione di Servizi terminal. Attualmente lavora per un ASP, dove progetta soluzioni IT per le imprese di piccole dimensioni. È possibile contattarlo all'indirizzo jsilliman@gmail.com.


 Dal redattore: Gestione del sovraccarico di informazioni
Dal redattore
Gestione del sovraccarico di informazioni
Joshua Hoffman

Quando penso ai due argomenti principali del numero di questo mese (SharePoint e Office Communications Server), non mi sorprende che vi siano spesso difficoltà connessione tra tutti noi. Mentre scrivo questa nota (circa un mese prima che venga pubblicata per i lettori), New York City è in pieno clima vacanziero. Il quartier generale di TechNet Magazine si trova proprio all'epicentro delle vacanze di New York: al Rockefeller Center. È davvero una bellissima zona della città, per molti aspetti, ma per un mese all'anno diventa... diciamo una sfida. La popolazione aumenta a dismisura con il contributo dei turisti che giungono dall'intero paese e da tutto il mondo per fare spese o vedere uno spettacolo oppure pattinare sul ghiaccio con lo sfondo di grattacieli maestosi. Molti dei residenti di New York, invece, battono in ritirata.
Alcuni sostengono che questo accade in reazione a una sorta di fastidio verso i turisti che si fermano al centro del marciapiede per fare una foto, obbligando chi segue a bloccarsi improvvisamente per non prenderli in pieno. Ma non è tutto qui (davvero, siamo contenti di averli tutti qui i fotografi della domenica). Penso invece che sia colpa del sovraccarico. In una città già affollata e complessa, in questi giorni si raggiunge l'apice ed è sinceramente troppo.
Se applico lo stesso parametro di giudizio al settore che ci interessa, vedo la stessa tendenza. Le organizzazioni continuano a crescere (che tutto sommato è ciò che speriamo) e, di conseguenza, generano sempre più informazioni ogni giorno. Le condivisioni dei file sono piene. I database sono pieni. Senza parlare della posta elettronica. Solo poco tempo fa un gigabyte sembrava un'enorme capacità di archiviazione. Oggi, i terabyte sono comuni, anche nei computer di uso domestico. Molti datacenter ora vengono progettati sulla base dei petabyte. Penso che si possa convenire su un punto; in giro ci sono tante, tantissime informazioni. Ma sono tutte utili o soltanto ingestibili? Sono strutturate? Facili da analizzare? Facili da condividere?
Dunque, con questa enorme quantità di informazioni, non mi sorprende che le connessioni siano sempre più difficili. Ma tutto può essere semplificato: questo è l'argomento del mese. Ecco perché è necessario apprendere a padroneggiare la potenza di Sharepoint per facilitare la raccolta dei dati e strutturare meglio le organizzazioni. Imparare a creare rapidamente dei sondaggi per raccogliere i dati dagli utenti (o clienti). Acquisire le conoscenze necessarie a definire tipi di contenuto personalizzati, in modo che le informazioni raccolte risultino molto più significative. Infine, imparare a utilizzare Office Communications Server per rendere possibili tutte queste connessioni fondamentali. Tutto sommato, a che serve avere tanti dati senza qualcuno con cui condividerli? Joshua Hoffman

Si ringraziano i seguenti esperti tecnici di Microsoft: Ed Banti, Susan Bradley, Byron Hynes, Michael Murgolo, Ken Oien, Jim Truher e Kay Unkroth.


 Lettere: La parola ai lettori
Lettere
La parola ai lettori

Disponibilità del servizio ActiveX Installer
Ho appena letto l'articolo sul numero di luglio 2007 "Il servizio ActiveX Installer in Windows Vista" (all'indirizzo technetmagazine.com/issues/2007/07/AxIS). Il servizio ora è disponibile?
-Eugene Y.

Sì, il servizio Activex® Installer è disponibile. È possibile attivarlo facilmente con l'opzione "Attivazione o disattivazione delle funzionalità Windows" nel pannello di controllo Programmi e funzionalità di Windows Vista®.
Il servizio ActiveX Installer è un componente opzionale delle sole versioni Ultimate, Enterprise e Business di Windows Vista. L'elenco dei siti che consentono l'installazione Activex con il servizio Activex Installer si controlla tramite Criteri di gruppo. L'elenco è memorizzato in Configurazione computer | Modelli amministrativi | Componenti di Windows | sezione Servizio Activex Installer di Editor oggetti Criteri di gruppo.

Strumenti di Active Directory
Grazie per l'utile articolo "11 strumenti essenziali per la gestione di Active Directory" (numero di settembre 2007). Ho tentato di eliminare gli utenti da Active Directory® con l'utilità dsrm descritta nell'articolo, utilizzando la seguente riga di comando:
          dsquery user -samid <samid> | dsrm
Ottengo un messaggio di errore relativo a un input di "dsrm" in formato errato. Tuttavia, riesco a eseguire il comando separatamente senza problemi. Quale può essere il motivo?
-Keith E.

Abbiano girato la domanda all'autore dell'articolo, Laura Hunter. Laura evidenzia che quando viene eseguito il piping dei risultati di dsquery in dsrm, questo richiede l'opzione -noprompt. Ne consegue che è necessario utilizzare la riga di comando seguente:
dsquery user -samid <samid> | dsrm -noprompt
Ci scusiamo per l'omissione di queste informazioni nell'articolo originale e pubblicheremo una correzione nella versione online.

Soluzioni alternative per l'enigma
Immagino sappiate già, o vi è già stato fatto notare da altri utenti, che il rompicapo di script del Dottor Scripto (numero di novembre 2007) ha in verità due diverse soluzioni, entrambe valide. L'enigma si risolve correttamente anche se la variabile di 4 caratteri visualizzata nella prima e seconda riga è nnde e se la variabile di 5 caratteri visualizzata nella terza e quinta riga è iamex. Mi rendo anche conto che la differenza è poco significativa e che i nomi nella soluzione rendono lo script molto più leggibile.
Grazie per il momento di evasione offerto dall'enigma, che mi è piaciuto molto.
-Stan A.

Grazie per aver condiviso con noi la soluzione alternativa, Stan. Ci fa piacere sentire che ti è piaciuto il nuovo enigma degli Scripting Guy e siamo particolarmente soddisfatti di questa nuova rubrica fissa di TechNet Magazine.

Convinti a passare a Windows Vista
L'articolo "Modifiche ai file non in linea in Windows Vista" del numero di novembre 2007 di TechNet Magazine (all'indirizzo technetmagazine.com/issues/2007/11/Offline) illustra i vantaggi di Windows Vista nell'area dei file non in linea molto bene. L'articolo ci ha spinto a passare a Windows Vista, perché abbiamo avuto molti problemi con i file non in linea con Windows® XP Professional.
-Daniel Z.

Grazie, Daniel. Siamo molto contenti di sentire che hai trovato l'articolo utile per la tua organizzazione.

Pagine mancanti
La rivista è piacevole e piena di informazioni utili. Tuttavia, alla mia copia del numero di dicembre 2007 mancavano le pagine da 49 a 64. Ero interessato all'articolo sulle indagini forensi ("Una guida introduttiva alle indagini forensi sui computer") di Tom Cloward e Frank Simorjay a pagina 60. Forse il vostro team di detective forensi riuscirà a ritrovare le pagine mancanti. Se l'articolo è disponibile online, vorrei conoscere l'URL della pagina Web corrispondente.
-Dave S.

Purtroppo, si è verificato un problema durante la stampa del numero di dicembre 2007 e, di conseguenza, alcune delle copie sono state inviate ai lettori senza le pagine da 49 a 64. A nome dello stampatore e del team di TechNet Magazine, ci scusiamo per l'inconveniente.
L'articolo a cui fai riferimento, insieme al resto del numero di dicembre, ora è disponibile online all'indirizzo technetmagazine.com/issues/2007/12.


 Casella degli strumenti: Nuovi prodotti per professionisti IT
Casella degli strumenti
Nuovi prodotti per professionisti IT
Greg Steen

Sblocco di file
Unlocker
ccollomb.free.fr/unlocker
A tutti sarà capitato di imbattersi in una situazione di questo tipo: un processo automatico si blocca improvvisamente provocando il blocco in scrittura di un file e impedendo la corretta esecuzione di un'altra operazione in quanto non è possibile effettuare la copia, lo spostamento, la scrittura o l'eliminazione del file. A volte non si riesce a identificare la causa del blocco su un file anche se si è in grado di determinare quale file è bloccato. Quale azione occorre intraprendere in tali casi?
Esistono diversi metodi per gestire un problema di questo tipo, ma l'unico strumento in grado di fornire una soluzione integrata in Esplora risorse®, rapida e semplice ai problemi di blocco dei file è Unlocker, uno strumento gratuito scritto da Cedrick Collomb. Grazie alla sua integrazione con Esplora risorse, è possibile identificare la causa del problema facendo semplicemente clic con il pulsante destro del mouse sul file bloccato (o anche un gruppo di file) e selezionando Unlocker dal menu di scelta rapida. Se viene rilevato un blocco, è possibile scegliere tra una serie di opzioni, tra cui terminazione del processo all'origine dell'errore, sblocco del file (chiudendo l'handle), eliminazione del file, spostamento del file o ridenominazione del file. È inoltre possibile copiare il file bloccato nello stato corrente in un'altra posizione.
Unlocker dispone di un programma di installazione di applicazioni completo e pertanto non è necessario eseguire o annullare la registrazione di eventuali DLL manualmente né occorre riavviare il sistema per avviare lo strumento. Fornisce inoltre il supporto per la notifica degli aggiornamenti automatica, che avviene tramite telefono, in modo da assicurare che si disponga della versione più recente,
nonché per l'esecuzione dalla riga di comando, che è ideale per l'automazione. Questo implica, ad esempio, la possibilità di configurare facilmente un processo di distribuzione dei log per chiudere automaticamente l'handle e terminare il processo di compressione se si rileva un file .zip bloccato durante il tentativo di spostamento dei registri, il che consente probabilmente di evitare di svegliarsi all'alba per provare a correggere il problema manualmente.
L'utilità dispone inoltre di uno strumento della barra della applicazioni denominato Unlocker Assistant. Questo strumento è in grado di avviare automaticamente l'interfaccia di Unlocker quando si tenta di spostare, rinominare o eliminare un file bloccato, eliminando la necessità di individuare il file e selezionare Unlocker dal menu di scelta rapida visualizzato tramite il tasto destro del mouse. Unlocker è compatibile con la maggior parte delle versioni di Windows, compreso Windows Vista®.

Prezzo: gratuito.
Con Unlocker è possibile individuare e sbloccare rapidamente i file bloccati
Con Unlocker è possibile individuare e sbloccare rapidamente i file bloccati

Analisi del traffico di rete
Wireshark
wireshark.org
Un analizzatore di protocollo di rete efficace consente di effettuare un'analisi di base del traffico di rete nella propria infrastruttura per determinare cosa succede esattamente sotto tutti i numerosi livelli delle applicazioni interconnesse. Probabilmente l'analizzatore open source più noto è Wireshark, che utilizza la libreria open source di acquisizione dei pacchetti WinPcap per Windows e deriva da Ethereal, il cui ideatore è Gerald Combs.
Con Wireshark, è possibile acquisire facilmente il traffico passando attraverso un'interfaccia di rete ed esaminare i dettagli di ciascun pacchetto in un'interfaccia grafica di facile utilizzo. L'avvio di una nuova sessione di acquisizione dei pacchetti prevede semplicemente la selezione dell'interfaccia e un clic del mouse sul pulsante di avvio. Nell'interfaccia utente grafica vengono visualizzati i pacchetti acquisiti in un frame codificato a colori, in cui vengono forniti in dettaglio l'ora, l'origine, la destinazione, il protocollo e una descrizione predeterminata dell'evento quasi in tempo reale. Se si fa clic su una trasmissione, vengono evidenziati i dettagli dell'evento e i dati del pacchetto vengono interpretati in un riquadro dettagli di facile consultazione. È inoltre possibile visualizzare i dati dei pacchetti non elaborati in formato esadecimale e ASCII.
Una volta ottenuto il set di dati necessario per l'analisi, è possibile ovviamente salvare o esportare la sessione per un'analisi successiva. Wireshark è in grado di decodificare diversi protocolli e dovrebbe coprire la maggior parte delle esigenze di risoluzione dei problemi.
Le reti sono rumorose e per consentire il filtraggio di tutti i dati presenti in rete, l'applicazione fornisce una straordinaria funzionalità di filtro basata sulle espressioni, che consente di restringere la ricerca in base a ciascun parametro di un protocollo. Ad esempio, è possibile filtrare tutto il traffico eccetto quello correlato a BitTorrent e a specifici IP nella rete. In alternativa, i filtri possono consentire di individuare facilmente il computer che causa i problemi di rete generando una miriade di messaggi broadcast fittizi.
L'interfaccia consente inoltre di contrassegnare facilmente i pacchetti per la revisione e impostare una specifica trasmissione in base al riferimento temporale nell'acquisizione. Una delle funzionalità che preferisco di Wireshark è la capacità di seguire un flusso TCP scegliendo tale opzione dal menu di scelta rapida visualizzato dopo aver fatto clic con il pulsante destro del mouse su un pacchetto TCP. Viene quindi visualizzata una finestra con una visualizzazione in formato testo formattato e codificato a colori del contenuto del flusso TCP, una soluzione ideale per rilevare errori di applicazioni Web, intestazioni HTTP fittizie o altri problemi di comunicazione che si potrebbero verificare. Da questa finestra è possibile stampare rapidamente o salvare la conversazione per una successiva analisi o dimostrazione.
Tuttavia, questo è solo un assaggio delle funzionalità dell'applicazione. Wireshark viene rilasciato con licenza GPL; oltre a essere compatibile con Windows, dispone anche di file binari compilati per la maggior parte delle versioni di Linux e FreeBSD.

Prezzo: gratuito.
Wireshark consente di analizzare il protocollo di rete completo
Wireshark consente di analizzare il protocollo di rete completo

Potenzia Windows PowerShell
PowerShell Community Extensions
codeplex.com/PowerShellCX
Se si è avuta l'opportunità di utilizzare Windows PowerShellTM, è probabile che si siano rilevati alcuni modelli ricorrenti di esecuzione per i quali sarebbe ottimale se si disponesse di un cmdlet o un alias. A tal fine, un gruppo di utenti e sostenitori di Windows PowerShell della community open source ha creato il progetto PowerShell Community Extensions, che include le funzionalità più comunemente richieste in un set distribuibile di cmdlet, alias, provider, funzioni, filtri e script.
Tra i cmdlet inclusi nel pacchetto figurano Get-Clipboard e Write-Clipboard, che consentono di aggiungere e recuperare i dati nel buffer degli Appunti. Get-DomainController consente di recuperare un elenco dei controller di dominio disponibili nel dominio corrente, mentre Write-GZip e Write-Zip consentono di scrivere file GZIP o ZIP.
È possibile creare un nuovo collegamento simbolico o una nuova giunzione in Windows Vista o Windows Server® 2008 con New-Symlink e New-Junction, rispettivamente. È disponibile un provider DirectoryServices molto utile che fornisce l'accesso ai server LDAP, come Active Directory® e AssemblyCache, consentendo di accedere alla cache di assembly globale di Microsoft .NET Framework e agli assembly al suo interno.
È disponibile inoltre una serie di script molto utili. Gli script Set-Writable e Set-ReadOnly consentono di modificare rapidamente lo stato di sola lettura di un file. Get-Url crea una WebRequest e restituisce la WebResponse come stringa, mentre Export-History esegue il dump della cronologia dei comandi in un file .clixml per un successivo riutilizzo. È possibile ottenere le informazioni sull'utilizzo del disco con lo script Get-DiskUsage o consentire al computer di parlare con il divertente comando Out-Speech. Il pacchetto include inoltre una serie di altre utili funzioni come Quote-List, che consente di ridurre il testo digitato sulla riga di comando, e Add-PathVariable, che consente di aggiungere un set di percorsi a un ambiente specificato.
Questo progetto aggiunge una serie molto utile di estensioni all'ambiente Windows PowerShell standard e offre a tutti coloro che hanno già dimestichezza con Windows PowerShell la possibilità di apportare il contributo delle proprie idee.

Prezzo: gratuito.
PowerShell Community Extension fornisce le funzioni più comunemente richieste
PowerShell Community Extension fornisce le funzioni più comunemente richieste

Greg Steen è un professionista IT oltre ad essere un appassionato imprenditore. È 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.


 Domande e risposte su SQL: Indici non raggruppati e conservazione delle autorizzazioni
Domande e risposte su SQL
Indici non raggruppati e conservazione delle autorizzazioni
Saleem Hakani and Dan Carollo

Indici non raggruppati e relativo utilizzo
D Cosa sono gli indici non raggruppati e quali sono i pro e i contro del loro utilizzo?
R Un indice non raggruppato è simile al tipo di indice che si trova in genere alla fine di un libro. Nell'indice sono rappresentate tutte le informazioni contenute nel libro ordinate in base all'argomento ed esistono dei puntatori sotto forma di numeri di pagina che indirizzano il lettore ai punti in cui trovare le informazioni, anche in diverse aree del libro. Inoltre, i dati in un indice di libro non sono elencati nello stesso ordine in cui sono visualizzati nel testo del libro. Accade lo stesso con gli indici non raggruppati. Se per una tabella esiste un indice raggruppato, sarà possibile specificare l'ordine delle voci. In caso contrario non esiste altro modo per essere sicuri dell'ordine applicato.
Gli indici non raggruppati presentano inoltre due limiti: nell'indice possono essere contenute solo 16 colonne e la dimensione massima della chiave di indice non può superare i 900 byte. Che cosa significa? Ecco cosa accade quando si devono indicizzare le colonne seguenti nella tabella Movie del database MovieList di esempio: MovieTitle NVarchar(50), DirectorName NVarchar(50), ShortStory NVarchar(400).
Si supponga di utilizzare l'istruzione seguente per creare la tabella:
Use MovieList;
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName, ShortStory);
Verrà generato il seguente messaggio di errore: "Avviso: la lunghezza massima della chiave è di 900 byte. La lunghezza massima dell'indice "Movie_IDX" è di 1000 byte. In presenza di alcune combinazioni di valori di grandi dimensioni, l'operazione di inserimento/aggiornamento ha esito negativo". Il messaggio viene visualizzato perché il tipo di dati di "nvarchar" utilizza 2 byte per ciascun carattere; un indice con le tre colonne precedenti supererebbe il limite di dimensione di 900 byte.
Con la versione di SQL Server® 2005, ora è possibile risolvere il problema aggiungendo le colonne alla clausola INCLUDE. Si tratta di una funzionalità molto utile se si desidera risolvere entrambi i limiti di dimensione e numero di colonne. È quindi possibile utilizzare l'istruzione seguente:
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName) INCLUDE (ShortStory);
È importante notare che, quando si utilizza la clausola INCLUDE durante la creazione dell'indice, il motore di database non considera le colonne non chiave per calcolare il numero di colonne chiave dell'indice o le dimensioni della chiave dell'indice.
Per trovare altre informazioni utili sugli indici non raggruppati, vedere l'articolo "Indici non raggruppati" all'indirizzo msdn2.microsoft.com/aa174537 e "Utilizzo degli indici non raggruppati" all'indirizzo msdn2.microsoft.com/aa933130. Per suggerimenti sull'ottimizzazione degli indici, vedere sql-server-performance.com/optimizing_ indexes.asp.

Conservazione dei dati delle autorizzazioni
D Come è possibile evitare di perdere le autorizzazioni quando viene reinizializzata una sottoscrizione? Il problema si presenta spesso quando si reinizializza uno snapshot, perché vengono perse tutte le autorizzazioni concesse.
R Per impostazione predefinita, quando si reinizializza una sottoscrizione, tutti gli oggetti presenti nel database vengono rimossi e quindi creati di nuovo. Esistono tuttavia due modi per gestire questo scenario.
È innanzitutto possibile riapplicare tutte le autorizzazioni dopo la reinizializzazione. Quando si configurano manualmente le autorizzazioni, è opportuno trasferire tutte le autorizzazioni a livello di oggetti o di istruzioni e archiviarle separatamente, in modo da poterle utilizzare subito dopo aver reinizializzato l'abbonamento.
In secondo luogo è possibile configurare la sottoscrizione in modo che non vengano rimossi oggetti quando si esegue la reinizializzazione. A tal fine è possibile utilizzare la stored procedure di sistema SP_CHANGEARTICLE per configurare il valore PRE_CREATION_CMD per il parametro @PROPERTY e il valore NONE, DELETE o TRUNCATE per il parametro @Value.
Inoltre, nella finestra di dialogo di Proprietà articolo nella sezione dell'oggetto di destinazione, selezionare i valori "Non modificare l'oggetto esistente, elimina i dati. Se all'articolo è associato un filtro di riga, elimina solo i dati che soddisfano i criteri del filtro. Tronca tutti i dati nell'oggetto esistente". Utilizzare questa impostazione nell'ambiente di test e, se si necessita di ulteriore aiuto, consultare le informazioni più aggiornate nella versione più recente della documentazione in linea di SQL Server.

Saleem Hakani è un Senior Database Engineer, Senior Problem Engineer e Worldwide Microsoft SQL Server Community Lead con 14 anni di esperienza nei sistemi di database. Gestisce il sito Web esterno della SQL Server Community sqlcommunity.com ed è possibile contattarlo all'indirizzo Saleem@sqlcommunity.com.
Dan Carollo è un Operations Engineer e amministratore di database SQL Server che lavora nel Windows Anti-Malware Research and Response in Microsoft. Ha conseguito la certificazione MCT in SQL Server.


 Utilit&#224; in primo piano: ADMX Migrator
Utilità in primo piano
ADMX Migrator
Lance Whitney
Scarica il codice per questo articolo: ADMX Migrator (2765KB)

I lettori che utilizzano regolarmente Criteri di gruppo, hanno di certo già accumulato una certa esperienza nell'utilizzo di modelli amministrativi per la configurazione delle impostazioni di sistema operativo e applicazioni. I file ADM disponibili in Windows® e in altro software di uso comune, come Microsoft® Office, coprono le configurazioni desktop più diffuse. Tuttavia, a volte è necessario creare i propri modelli ADM per incorporare impostazioni personalizzate. La progettazione di ADM da zero può rivelarsi lunga e complessa, poiché è prevista una sintassi specifica ed è richiesta la creazione tramite un editor di testo. Ma con il tempo e l'esperienza, molti professionisti di Criteri di gruppo hanno iniziato a fare un uso crescente di file ADM personalizzati.
In Windows Vista® il formato per i modelli di Criteri di gruppo è diventato una struttura basata su XML. Il nuovo formato, denominato ADMX, offre diversi vantaggi rispetto ai file ADM precedenti, come il supporto di più linguaggi e un punto di archiviazione centralizzato in cui gestire tutti i modelli.
Queste sono senza dubbio buone notizie, ma che succede quando si devono creare dei file ADMX personalizzati e non si conosce il linguaggio XML? O peggio, che ne sarà di tutti quegli ADM personalizzati che sono costati anni di lavoro? Per fortuna, l'utilità ADMX Migrator viene in soccorso. Questo strumento gratuito, sviluppato da FullArmor Corporation e concesso in licenza a Microsoft, offre due vantaggi principali: consente di creare i propri file ADMX personalizzati e di convertire i file ADM legacy in ADMX.
Interfaccia grafica di ADMX Migrator
Interfaccia grafica di ADMX Migrator
Per la creazione di modelli nel nuovo formato, ADMX Migrator è stato dotato di ADMX Editor completo di un'interfaccia utente grafica, quindi non sono più necessari editor di testo. I modelli personalizzati si creano utilizzando i menu e gli elenchi a discesa all'interno di un'interfaccia pulita e semplice (vedere la figura). Per iniziare, scegliere il comando New Template, denominare il file del modello e immettere una categoria in cui classificare il file. Quindi creare l'impostazione del criterio desiderata inserendo la chiave del Registro di sistema a cui applicare i criteri, il nome del valore del Registro di sistema e la classe interessata (User, Machine o entrambi). È inoltre possibile descrivere le operazioni eseguite dai criteri.
Al termine, salvare il nuovo modello nel formato ADMX. Il file viene archiviato sia come file ADMX che come file ADML. Il file ADMX contiene le impostazioni dei criteri reali, mentre il file ADML fornisce informazioni specifiche del linguaggio per i criteri. A questo punto, è possibile copiare entrambi i file nelle directory appropriate sul proprio dominio e incorporarli in Criteri di gruppo.
Potrebbe essere necessario convertire i file ADM esistenti in ADMX, per sfruttare i vantaggi offerti dal nuovo formato. ADMX Migrator prevede due metodi di conversione: tramite l'editor o mediante un programma a riga di comando. In ADMX Editor scegliere l'opzione per la generazione di file ADMX da file ADM. Cercare il file ADM desiderato e lo strumento lo convertirà in modo automatico e rapido. È quindi possibile aprire il file convertito nell'editor, per esaminare i valori e le proprietà e modificarlo secondo necessità. ADMX Migrator Command Window è un po' più complesso; per eseguire le conversioni, richiede infatti la digitazione di una stringa di comando piuttosto lunga al prompt. Tuttavia, lo strumento è dotato di opzioni e flessibilità non disponibili nell'editor grafico.
ADMX Migrator è uno snap-in di Microsoft Management Console (MMC), quindi richiede la presenza di MMC 3.0 e di Microsoft .NET Framework 2.0. ADMX Migrator funziona in Windows XP SP2, Windows Server® 2003 SP1 e Windows Vista. Questo strumento può essere scaricato da go.microsoft.com/fwlink/?LinkID=77409.

Lance Whitney è un consulente IT, docente e technical writer. Ha trascorso molte ore a modificare le workstation e i server di Windows. In origine Lance era un giornalista, ma circa 15 anni fa ha fatto un salto nel buio lanciandosi nel mondo dell'IT.


 The Cable Guy: Autenticazione per reti cablate IEEE 802.1X
The Cable Guy
Autenticazione per reti cablate IEEE 802.1X
Joseph Davies
Questo articolo è basato su una versione non definitiva di Windows Server 2008. Tutte le informazioni riportate sono soggette a modifica.

Dopo la grande diffusione dell'autenticazione IEEE 802.1X per le reti wireless IEEE 802.11, gli amministratori di rete pensano a utilizzare questo standard anche per le connessioni di rete cablate. Come un client wireless deve presentare una serie di credenziali da convalidare prima di consentire l'inoltro di frame wireless sulla Intranet, un
client cablato IEEE 802.1X deve eseguire l'autenticazione prima di poter utilizzare la relativa porta dello switch. L'autenticazione IEEE 802.1X costituisce una barriera di protezione aggiuntiva per la Intranet; è possibile evitare che computer guest, anomali o non gestiti, che non sono in grado di eseguire un'autenticazione corretta, si connettano alla Intranet.
L'autenticazione IEEE 802.1X è probabilmente già supportata dagli switch cablati e deve essere solo attivata e configurata. Per l'autenticazione e l'autorizzazione di una connessione cablata, gli switch che supportano 802.1X utilizzano in genere il protocollo RADIUS (Remote Authentication Dial-In User Service) per inviare le informazioni di richiesta connessione a un server RADIUS, ad esempio un server NPS (Network Policy Server) basato su Windows Server ® 2008 o un server IAS (Internet Authentication Service) di Windows Server 2003.
Dopo aver configurato gli switch per RADIUS, ma prima di richiedere l'autenticazione 802.1X, sarà necessario abilitare e configurare l'autenticazione 802.1X nei computer cablati. L'autenticazione IEEE 802.1X per le connessioni di rete cablate è supportata in Microsoft® Windows® fin da Windows XP. Tuttavia, è necessario configurare manualmente le impostazioni di autenticazione 802.1X in Windows XP e Windows Server 2003 su ciascun client cablato (dalla scheda Autenticazione per le proprietà di una connessione di rete nella cartella Connessioni di rete). Purtroppo, non è in alcun modo possibile configurare in modo centralizzato o tramite script le impostazioni per i dispositivi 802.1X cablati per questi sistemi operativi precedenti.
Invece, il supporto per le impostazioni cablate in Criteri di gruppo e il supporto per lo scripting con lo strumento Netsh in Windows Vista® e Windows Server 2008 rendono la distribuzione delle impostazioni 802.1X cablate molto più semplice di prima.

Impostazioni per reti cablate in Criteri di gruppo
Utilizzo del Servizio configurazione automatica reti cablate
In Windows XP e Windows Server 2003, il comportamento dei dispositivi 802.1X nelle connessioni cablate è gestito dal servizio Zero Configuration reti wireless. In questi sistemi operativi, il servizio era attivato per impostazione predefinita e le connessioni di rete cablate venivano impostate in modalità di ascolto passiva, in attesa che lo switch avviasse l'autenticazione.
Al contrario, in Windows Vista e Windows Server 2008, il Servizio configurazione automatica reti cablate gestisce i dispositivi 802.1X sulle connessioni cablate, ma è disabilitato per impostazione predefinita. Quindi, la scheda Autenticazione per le proprietà delle connessioni di rete viene visualizzata solo dopo l'avvio del Servizio configurazione automatica reti cablate.
Per un singolo client cablato su cui è in esecuzione Windows Vista o Windows Server 2008, è possibile utilizzare lo snap-in Servizi per avviare il Servizio configurazione automatica reti cablate e configurarlo per l'avvio automatico. Quando viene avviato il Servizio configurazione automatica reti cablate, le connessioni di rete cablate funzionano in modalità di ascolto attivo con la connessione di rete che tenta di avviare l'autenticazione con lo switch.
Per un dominio Active Directory, è possibile utilizzare Criteri di gruppo per impostare il Servizio configurazione automatica reti cablate per l'avvio automatico. Se si utilizza lo snap-in Editor Gestione Criteri di gruppo, configurare l'impostazione Configurazione computer | Impostazioni di Windows | Impostazioni di protezione | Servizi di sistema | Configurazione automatica reti cablate per la modalità di avvio automatico.

Per centralizzare e automatizzare la configurazione delle impostazioni per reti cablate, i servizi di dominio di Windows Server 2008 e Windows Server 2003 Active Directory ® supportano le impostazioni dei criteri per reti cablate in Criteri di gruppo. Le impostazioni consentono di configurare le opzioni per reti cablate come parte di Criteri di gruppo di Configurazione computer, per un oggetto Criteri di gruppo basato su dominio.
Con queste impostazioni di criteri per reti cablate, è possibile specificare il metodo di autenticazione e altre impostazioni 802.1X per i client cablati che utilizzano Windows Server 2008 o Windows Vista. Quando si accede al dominio, all'avvio o periodicamente dopo l'avvio, in questi sistemi operativi viene automaticamente eseguito il download delle impostazioni di Criteri di gruppo per reti cablate, con la conseguente applicazione. Per supportare i nuovi criteri, tuttavia, un dominio Active Directory di Windows Server 2003 deve essere esteso. Per informazioni su come estendere un dominio Active Directory di Windows Server 2003, visitare la pagina technet.microsoft.com/bb727029.
È possibile configurare i criteri per reti cablate dal nodo Configurazione computer | Impostazioni di Windows | Impostazioni di protezione | Criteri per reti cablate (IEEE 802.3) nello snap-in Editor di gestione criteri di gruppo. Per impostazione predefinita, non sono presenti criteri per reti cablate (IEEE 802.3). Per creare un nuovo criterio, fare clic con il pulsante destro del mouse su Criteri per reti cablate (IEEE 802.3) nella struttura della console e scegliere Crea un nuovo criterio di Windows Vista.
La finestra di dialogo delle proprietà di un criterio per reti cablate Windows Vista è costituita da una scheda Generale e una scheda Protezione. Nella Figura 1 è illustrata la scheda predefinita Generale. Nella scheda Generale è possibile configurare un nome e una descrizione per il criterio e specificare se utilizzare il Servizio di configurazione automatica reti cablate, che controlla il comportamento dei dispositivi 802.1X sulle connessioni cablate. Per ulteriori informazioni, vedere l'intestazione laterale "Utilizzo del Servizio configurazione automatica reti cablate".
Figura 1 La scheda predefinita Generale di un criterio per reti cablate Windows Vista
Figura 1 La scheda predefinita Generale di un criterio per reti cablate Windows Vista
Nella Figura 2 è illustrata la scheda predefinita Protezione per un criterio per reti cablate di Windows Vista. Nella scheda Protezione è possibile attivare o disattivare l'autenticazione 802.1X, selezionare e configurare il metodo di autenticazione EAP (Extensible Authentication Protocol), selezionare la modalità di autenticazione (riautenticazione utente, solo computer, autenticazione utente o autenticazione guest), configurare il numero di tentativi con esito negativo consentiti prima che l'autenticazione venga chiusa e configurare se memorizzare nella cache le informazioni utente per le connessioni successive. Quando la memorizzazione nella cache è disabilitata, i dati delle credenziali utente in Windows vengono rimossi dal Registro di sistema non appena l'utente si disconnette. Di conseguenza, all'utente successivo verranno richieste di nuovo le credenziali (come nome utente e password) al momento dell'accesso.
Figura 2 La scheda predefinita Protezione di un criterio per reti cablate Windows Vista
Figura 2 La scheda predefinita Protezione di un criterio per reti cablate Windows Vista
Quando si fa clic sul pulsante Avanzate nella scheda Protezione, è possibile configurare le impostazioni avanzate per i dispositivi 802.1X e Single Sign-On. Nella Figura 3 è riportata la finestra di dialogo predefinita Impostazioni di protezione avanzate per un criterio per reti cablate di Windows Vista. Dalla finestra di dialogo Impostazioni di protezione avanzate, è possibile configurare le impostazioni 802.1X riportate nella Figura 4.
Figure 4 Impostazioni 802.1X nella casella Impostazioni di protezione avanzate (Close Figure 4)

Impostazione | Descrizione
Numero massimo di messaggi di avvio EAPOL | Il numero di messaggi successivi di avvio EAP su LAN (EAPOL) che vengono inviati quando non si riceve alcuna risposta ai messaggi di avvio EAPOL iniziali.
Periodo di sospensione | L'intervallo di tempo fra la ritrasmissione dei messaggi di avvio EAPOL quando non si riceve alcuna risposta al messaggio di avvio EAPOL inviato in precedenza.
Periodo di avvio | Il periodo durante il quale il client di autenticazione non esegue alcuna attività di autenticazione 802.1X dopo aver ricevuto un'indicazione di autenticazione non riuscita dall'autenticatore.
Periodo di autenticazione | Il periodo di tempo per cui il client di autenticazione deve attendere prima di ritrasmettere qualsiasi richiesta 802.1X dopo l'avvio dell'autenticazione 802.1X end-to-end.
Messaggio di avvio EAPOL | Quando il client cablato invia il messaggio di avvio EAPOL.
Figura 3 La finestra di dialogo predefinita Impostazioni di protezione avanzate per un criterio per reti cablate di Windows Vista
Figura 3 La finestra di dialogo predefinita Impostazioni di protezione avanzate per un criterio per reti cablate di Windows Vista
I client cablati su cui è in esecuzione Windows Server 2008 supportano Single Sign-On per le connessioni cablate. Questa funzione è anche progettata per la prossima versione di Windows Vista Service Pack 1. Ulteriori informazioni sono disponibili alla pagina Web technetmagazine.com/issues/2007/11/CableGuy.
Sono disponibili le impostazioni Single Sign-On per eseguire l'autenticazione 802.1X a livello utente prima o dopo il processo di accesso utente e per attendere il numero configurato di secondi per l'autenticazione 802.1X a livello utente, da completare prima che inizi il processo di accesso utente. È possibile determinare se visualizzare o meno le finestre di dialogo per l'autenticazione a livello utente oltre il consolidamento dei campi di input nella schermata di accesso di Windows. Se, ad esempio, per un tipo di EAP l'utente desidera confermare il certificato inviato dal server RADIUS durante l'autenticazione, il tipo di EAP può visualizzare la finestra di dialogo.
Inoltre, è possibile specificare che una volta eseguita l'autenticazione a livello utente, il sistema deve avviare un rinnovo DHCP (Dynamic Host Configuration Protocol) della configurazione TCP/IP della scheda cablata. Scegliere questa opzione se sono presenti VLAN (LAN virtuali) distinte per i client cablati autenticati a livello computer e a livello utente e se le VLAN sono su subnet IPv4 o IPv6 diverse.

Supporto di script con lo strumento netsh
Windows Server 2008 e Windows Vista supportano i comandi nel contesto netsh lan dello strumento netsh per configurare le impostazioni per reti cablate o per esportare o importare un profilo cablato, che consiste in una serie denominata di impostazioni per reti cablate in formato XML. Con la configurazione tramite riga di comando delle impostazioni delle reti cablate, è possibile distribuire in modo più diretto le reti cablate creando degli script automatizzati per le impostazioni di reti cablate senza utilizzare Criteri di gruppo. Le impostazioni di Criteri di gruppo per le reti cablate (IEEE 802.3) sono applicabili solo a un dominio Active Directory. Per un ambiente senza un'infrastruttura Criteri di gruppo, uno script che automatizza la configurazione delle connessioni cablate con un profilo cablato può essere eseguito manualmente o automaticamente, anche come parte dello script di accesso.
Per eseguire la configurazione tramite riga di comando dei client cablati su cui è in esecuzione Windows Vista o Windows Server 2008, eseguire i comandi lan netsh con i parametri appropriati. Il comando seguente, ad esempio, consente di abilitare Single Sign-On per la connessione di rete denominata "Local Area Connection" e di configurare Single Sign-On per eseguire l'autenticazione utente prima dell'accesso:
netsh lan set profileparameter interface="Local Area Connection" ssomode=prelogon
Per ulteriori informazioni sulla sintassi dei comandi lan netsh, vedere technet.microsoft.com/aa905084.
I profili XML cablati possono essere esportati da un client cablato Windows Server 2008 o Windows Vista e importati, quindi, in un client cablato Windows Server 2008 o Windows Vista utilizzando lo strumento netsh. Per esportare un profilo cablato, utilizzare il comando netsh lan export profile. Per importare un profilo cablato, utilizzare il comando netsh lan add profile. Per alcuni esempi utili sui profili cablati, vedere msdn2.microsoft.com/aa816372.
Con il supporto per riga di comando e profilo XML, è possibile inizializzare un client cablato sulla rete cablata con autenticazione 802.1X dell'organizzazione. Un computer client cablato che non è membro del dominio non può connettersi alla rete cablata utilizzando le credenziali del computer. Inoltre, un computer non può accedere al dominio finché non si è connesso correttamente alla rete cablata. Tuttavia, il supporto per riga di comando e profilo XML consente a un computer cablato di connettersi alla rete cablata dell'organizzazione utilizzando le credenziali utente, per accedere quindi al computer nel dominio. Per ulteriori informazioni, vedere technet.microsoft.com/bb727031.

Joseph Davies è un technical writer in Microsoft. Dal 1992 tiene corsi e scrive su argomenti legati alle reti Microsoft. Ha scritto cinque libri per Microsoft Press ed è autore della rubrica mensile in linea Cable Guy su TechNet.


 Windows PowerShell: Autorizzazioni della shell
Windows PowerShell
Autorizzazioni della shell
Don Jones
Scarica il codice per questo articolo: PowerShell2008_02.exe (151KB)

Nelle discussioni su Windows PowerShell mi vengono spesso poste domande relative alle autorizzazioni, in particolare se e come la shell consente di automatizzare le modifiche alle autorizzazioni. Le domande più comuni sono probabilmente quelle relative alle autorizzazioni per i file, anche se è piuttosto frequente anche la richiesta di delucidazioni in merito alle autorizzazioni per le directory e il Registro di sistema. A proposito delle autorizzazioni e di quasi
tutte le interfacce di script o della riga di comando, compresi Windows PowerShellTM e VBScript, dobbiamo dire che abbiamo notizie buone e notizie cattive.
Le notizie cattive sono che le autorizzazioni Windows® sono per natura piuttosto complesse e Windows PowerShell non è in grado di fornire alcuna soluzione adeguata per aggirare questo problema. Il problema deriva dal fatto che in un sistema operativo Windows, quando si tratta di autorizzazioni, è necessario avere a che fare con molteplici oggetti, indipendentemente da se si stia esaminando il file system, Active Directory®, il Registro di sistema o altro.
Innanzitutto, occorre prendere in considerazione la risorsa stessa, ad esempio un oggetto directory, un file o una cartella. Successivamente è necessario tener conto dell'oggetto elenco di controllo di accesso (ACL), che è associato alla risorsa. L'ACL è composto da una o più voci di controllo di accesso o oggetti ACE. Una voce ACE essenzialmente consente di correlare un'entità di protezione (un utente o un gruppo, ovvero un altro oggetto) a un'autorizzazione, ad esempio Lettura o Controllo completo, e a uno stato di concessione o negazione. Occorre pertanto prendere in considerazione non meno di cinque oggetti: la risorsa, l'ACL, una voce ACE, un'entità di protezione e un'autorizzazione.
L'utilizzo delle autorizzazioni risulta ulteriormente complicato dal fatto che ogni tipo di risorsa dispone di diversi tipi di autorizzazione. Gli oggetti directory, ad esempio, dispongono di autorizzazioni complesse che regolano l'accesso ai singoli attributi degli oggetti. Le autorizzazioni per i file sono in confronto relativamente semplici.
Dal punto di vista tecnico, le difficoltà raddoppiano al momento di eseguire il controllo. Ogni risorsa dispone in effetti di due ACL: l'ACL discrezionale (DACL), che regola l'accesso alla risorsa e l'ACL di protezione (SACL), che monitora il controllo sulla risorsa. L'utilizzo di queste autorizzazioni implica la necessità di procedere tra un'ampia gamma di oggetti di programmazioni piuttosto complessi e solo una shell come Windows PowerShell è in grado di semplificare questa attività.

Limitazioni di .NET Framework
Risorse aggiuntive
Per ulteriori risorse su Windows PowerShell, compresa una libreria di cmdlet su cui è possibile eseguire ricerche, e per informazioni su come contattare Don Jones e altri esperti di Windows PowerShell, visitare il sito www.PowerShellCommunity.org.

La natura di Windows PowerShell rende le cose un po' più complesse. Poiché è basato su Microsoft® .NET Framework, per la rappresentazione e l'utilizzo delle autorizzazioni Windows PowerShell utilizza le classi sottostanti di .NET Framework. Le classi sottostanti di .NET Framework sono progettate per fornire agli sviluppatori software un controllo granulare e preciso sulle autorizzazioni. Ovviamente, un controllo "granulare e preciso" implica la necessità di esaminare una grande quantità di informazioni, che si traduce spesso in una maggiore complessità.
Inoltre, .NET Framework non fornisce classi che rappresentano tutte le autorizzazioni in ogni tipo di risorsa di Windows. Ad esempio, sebbene .NET Framework fornisca classi che consentono di manipolare la protezione dei file, non fornisce classi che consentono di utilizzare la protezione sulle cartelle condivise. Il risultato è che Windows PowerShell non è in grado di manipolare le autorizzazioni per ogni tipo di risorsa di Windows. In parole semplici, Windows PowerShell è limitato alle funzionalità esposte da .NET Framework.

Autorizzazioni all'interno della shell
La gestione delle autorizzazioni in Windows PowerShell viene derivata da due cmdlet: Get-ACL e Set-ACL. Come è facile immaginare, Get-ACL consente di recuperare l'ACL da una risorsa. È possibile modificare l'ACL in base alle proprie esigenze e utilizzare Set-ACL per scrivere l'ACL nuovamente nella risorsa. Entrambi questi cmdlet sono generici e si basano sul sistema di provider PSDrive di Windows PowerShell. Di conseguenza, questi due cmdlet ACL potrebbero in teoria funzionare con qualsiasi tipo di risorsa, purché sia disponibile un provider PSDrive in grado di riconoscere un determinato tipo di risorsa e di modificare le autorizzazione per il tipo di risorsa in questione. I provider PSDrive FileSystem e Registry, che vengono forniti con Windows PowerShell, supportano la gestione delle autorizzazioni tramite i due cmdlet ACL. Gli altri provider PSDrive potrebbero non fornire questo supporto.
Lo script di esempio illustrato nella Figura 1 consente di specificare una directory di partenza, un'entità di protezione e un'autorizzazione. Lo script applica quindi l'autorizzazione specificata per tale entità a tutti i file e le cartelle all'interno della directory specificata. Lo script applica l'autorizzazione anche alle sottodirectory.
Figure 1 Applicazione di un'autorizzazione per un'entità a file e cartelle in una directory (Close Figure 1)
#ChangeACL.ps1
$Right="FullControl"

#The possible values for Rights are
# ListDirectory, ReadData, WriteData
# CreateFiles, CreateDirectories, AppendData
# ReadExtendedAttributes, WriteExtendedAttributes, Traverse
# ExecuteFile, DeleteSubdirectoriesAndFiles, ReadAttributes
# WriteAttributes, Write, Delete
# ReadPermissions, Read, ReadAndExecute
# Modify, ChangePermissions, TakeOwnership
# Synchronize, FullControl

$StartingDir=Read-Host "What directory do you want to start at?"
$Principal=Read-Host "What security principal do you want to grant" `
"$Right to? `n Use format domain\username or domain\group"

#define a new access rule.
#note that the $rule line has been artificially broken for print purposes.
#it needs to be one line. the online version of the script is properly
#formatted.
$rule=new-object System.Security.AccessControl.FileSystemAccessRule
($Principal,$Right,"Allow")

foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  $acl=get-acl $file.FullName

  #Add this access rule to the ACL
  $acl.SetAccessRule($rule)

  #Write the changes to the object
  set-acl $File.Fullname $acl
  }
Lo scopo principale di questo script consiste nel definire una nuova regola di accesso nella variabile $rule. A tal fine, verrà utilizzata una classe .NET Framework "non elaborata", che rappresenta probabilmente la parte più complessa della gestione delle autorizzazioni in Windows PowerShell. Lo script recupera quindi l'ACL da ciascun file e cartella utilizzando Get-ACL, applica la nuova regola utilizzando il metodo SetAccessRule dell'ACL e scrive l'ACL modificato di nuovo nella risorsa mediante Set-ACL.
In realtà, questa procedura non è eccessivamente complessa anche se alcune operazioni, come la rimozione di una voce ACE da un ACL, sono molto più complesse. A mio parere, ciò che fa apparire questo processo complicato è il fatto che prevede un elevato numero di passaggi: ottenere l'ACL, definire una regola, modificare l'ACL e scrivere l'ACL. Non è disponibile un unico semplice comando che consenta di eseguire tutte queste operazioni in una sola volta. E poiché si intendeva modificare gli ACL in più file, si è reso necessario inserire il tutto in un ciclo foreach utilizzando Get-ChildItem per accedere a tutti i file e le cartelle.

Il metodo più semplice
Cmdlet del mese: Get-QADUser
Questo cmdlet è essenziale se si gestisce Active Directory. Non è integrato in Windows PowerShell, ma è disponibile come download gratuito come parte di Quest Software ActiveRoles Management Shell per Active Directory (www.quest.com/activeroles-server/arms.aspx).
Una volta installato lo snap-in, è possibile utilizzare Get-QADUser per recuperare gli oggetti utente dalla directory. Ovviamente, la semplice esecuzione del cmdlet determina la restituzione di tutti gli utenti, un risultato non particolarmente utile per la maggior parte delle attività amministrative. Tuttavia, il cmdlet consente di specificare criteri di filtro, che vengono applicati a livello di controller di dominio in modo che vengano restituiti a Windows PowerShell solo gli utenti a cui si è interessati. Questa è una tecnica molto più rapida rispetto al metodo precedente che prevedeva il recupero e il filtraggio di tutti gli utenti mediante il cmdlet Where-Object. Get-QADUser -l Redmond, ad esempio, consente solo di restituire gli utenti il cui attributo "l" contiene "Redmond" (l'attributo "l" sta per località e viene elencato come città nell'interfaccia utente grafica). È possibile inviare tali utenti ad altri cmdlet in modo da generare un report HTML, inserirli in un gruppo o persino eliminarli.

Ritengo che l'esempio illustrato in questo articolo non sia complesso, ma so che molti amministratori preferirebbero un metodo più semplice per l'utilizzo delle autorizzazioni. È probabile che gli amministratori desiderino rimuovere contemporaneamente uno specifico gruppo di utenti da un insieme di cartelle ma che non desiderino scrivere uno script costituito da più passaggi come quello riportato nella Figura 1.
Fortunatamente, Windows PowerShell offre un metodo semplificato per l'utilizzo delle autorizzazioni con cui probabilmente gli amministratori hanno già una certa familiarità.
L'utilizzo di Windows PowerShell non implica la necessità di rinunciare a metodi di comprovata efficienza. È possibile continuare a utilizzare gli strumenti della riga di comando, come Dsacls.exe, Cacls.exe e Xcacls.exe, progettati specificamente per fornire un metodo più semplice per l'utilizzo di diversi tipi di autorizzazioni. Anche se la sintassi di tali strumenti è completamente differente dalla sintassi standardizzata utilizzata dai cmdlet di Windows PowerShell, non è più necessario l'utilizzo ad hoc nella riga di comando di queste utilità della riga di comando, così come venivano utilizzate nella shell cmd.exe precedente. Inoltre, con Windows PowerShell è possibile automatizzare queste utilità.
Mi è talvolta capitato di imbattermi in persone, che definisco "puristi", che affermano che è sbagliato utilizzare un'utilità della riga di comando obsoleta all'interno di Windows PowerShell. In effetti, non riesco a seguire la loro logica. Se riesco a ottenere i risultati desiderati e se il metodo più semplice per ottenerli è utilizzare un'utilità della riga di comando "vecchia di dieci anni", non c'è nulla da biasimare. Non sprecherò tempo prezioso a provare di eseguire un'operazione in un certo modo solo perché tale metodo sembra "più puro". Il team di Microsoft Windows PowerShell ha un atteggiamento simile. Se uno strumento esistente consente di eseguire correttamente l'operazione desiderata, Windows PowerShell consentirà di utilizzare tale strumento all'interno della shell. Perché partire da zero?
Nella Figura 2 viene illustrato un breve script, tratto dal mio libro Windows PowerShell: TFM (SAPIEN Press, 2006), che prevede l'utilizzo di Windows PowerShell per automatizzare Cacls.exe. Questo script è una semplice dimostrazione e pertanto sarà necessario modificarlo se si desidera trasformarlo in un vero e proprio strumento di automazione. Dimostra tuttavia come uno script di Windows PowerShell sia in grado di raccogliere informazioni e utilizzarle per avviare l'utilità Cacls.exe, come se Cacls.exe fosse un comando Windows PowerShell "nativo". Sebbene questo script sia in grado di raccogliere le informazioni richiedendole all'utente, i parametri possono essere anche letti da un file o un database.
Figure 2 Automazione di Cacls.exe (Close Figure 2)
#SetPermsWithCACLS.ps1
# CACLS rights are usually
# F = FullControl
# C = Change
# R = Readonly
# W = Write

$StartingDir=Read-Host "What directory do you want to start at?"
$Right=Read-Host "What CACLS right do you want to grant? Valid choices are F, C, R or W"
Switch ($Right) {
  "F" {$Null}
  "C" {$Null}
  "R" {$Null}
  "W" {$Null}
  default {
    Write-Host -foregroundcolor "Red" `
    `n $Right.ToUpper() " is an invalid choice. Please Try again."`n
    exit
  }
}

$Principal=Read-Host "What security principal do you want to grant?" `
"CACLS right"$Right.ToUpper()"to?" `n `
"Use format domain\username or domain\group"

$Verify=Read-Host `n "You are about to change permissions on all" `
"files starting at"$StartingDir.ToUpper() `n "for security"`
"principal"$Principal.ToUpper() `
"with new right of"$Right.ToUpper()"."`n `
"Do you want to continue? [Y,N]"

if ($Verify -eq "Y") {

 foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  #display filename and old permissions
  write-Host -foregroundcolor Yellow $file.FullName
  #uncomment if you want to see old permissions
  #CACLS $file.FullName

  #ADD new permission with CACLS
  CACLS $file.FullName /E /P "${Principal}:${Right}" >$NULL

  #display new permissions
  Write-Host -foregroundcolor Green "New Permissions"
  CACLS $file.FullName
 }
}

Successo con le autorizzazioni?
Alcuni sostengono che Windows PowerShell non fornisce risultati ottimali in termini di gestione delle autorizzazioni in quanto non è in grado di fornire un cmdlet nativo che offra una gestione semplificata e universale delle autorizzazioni. Non sono affatto d'accordo. Primo, questa argomentazione viene spesso avanzata da amministratori che hanno un forte background in ambiente UNIX e occorre tenere presente che il sistema di autorizzazioni di Windows è molto più complesso di quello utilizzato in UNIX. Quando si espone tale sistema, anche l'utilizzo di Windows PowerShell diventa complesso. Tuttavia, questo non è un problema specifico di Windows PowerShell.
Inoltre, Windows PowerShell consente di utilizzare strumenti semplificati sotto forma di utilità della riga di comando obsolete ma valide, come è stato dimostrato in questo articolo. È vero che si rende necessario espandere ulteriormente .NET Framework per coprire in modo più esaustivo la gestione delle autorizzazioni sull'intera piattaforma Windows. Tuttavia, nel complesso, Windows PowerShell offre entrambi gli approcci: gestione semplificata delle autorizzazioni e accesso a strumenti di gestione granulari e precisi.

Don Jones collabora con TechNet Magazine come redattore ed è coautore del libro Windows PowerShell: TFM (SAPIEN Press, 2007). È docente di corsi su Windows PowerShell (www.ScriptingTraining.com) ed è possibile contattarlo dal sito Web www.ScriptingAnswers.com.


 Hey, Scripting Guy!: Le Olimpiadi sono alle porte (oltre a un po' di XML)
Hey, Scripting Guy!
Le Olimpiadi sono alle porte (oltre a un po' di XML)
Gli Scripting Guy di Microsoft
Scarica il codice per questo articolo: HeyScriptingGuy2008_02,exe (151KB)

È naturale, ogni volta che si parla delle leggende del mondo dello sport, tornano in mente gli stessi nomi: Babe Ruth. Pelé. Muhammad Ali. Walter Payton. ScooterK e MrRat. Johnny-
Ah ah, divertente, ma... davvero non ne hai mai sentito parlare? Mai nessuna notizia delle imprese di ScooterK e MrRat? D'accordo, per i lettori che non si sono aggiornati sulle Olimpiadi invernali dello scripting (dal 15 febbraio al 3 marzo presso il TechNet Script Center; vedere il sito microsoft.com/technet/scriptcenter/funzone/games), ScooterK e MrRat sono vere e proprie leggende, concorrenti che hanno realizzato punteggio pieno in almeno una divisione delle Olimpiadi invernali dello scripting del 2007.
Questa è la parte davvero interessante: chi di noi può realisticamente aspirare a diventare una leggenda del calcio come Pelé? Probabilmente nessuno. Qualcuno dei lettori può immaginare di diventare campione del mondo dei pesi massimi di pugilato? Qualcuno degli Scripting Guy, in effetti, quanto a peso è davvero massimo, purtroppo però gli manca la parte più propriamente pugilistica. Ma tutti, proprio tutti, possono invece aspirare a diventare il prossimo ScooterK o il prossimo MrRat.
Nota: in teoria, qualcuno potrebbe anche diventare il prossimo Babe Ruth. Basta riuscire a mangiare 24 hot dog tra una partita e l'altra di un doppio incontro di baseball.
Non è tuttavia il caso di agitarsi; siamo qui per istruire tutti i lettori su come diventare il prossimo ScooterK o MrRat (e forse anche il prossimo Bizzy o H2Data). È sufficiente presentarsi allo Script Center e partecipare alle Olimpiadi dello scripting. Il 15 febbraio pubblicheremo 10 diversi eventi (10 sfide di script) e sfideremo i partecipanti a completarne solo alcuni o tutti. I concorrenti devono scrivere uno script che risolve il problema e inviarlo via posta elettronica agli Scripting Guy (le istruzioni complete sono disponibili alla home page delle Olimpiadi dello scripting). Lo script inviato verrà testato e, se funziona, il concorrente guadagnerà dei punti. Per diventare una leggenda del mondo dello sport, basta completare in modo corretto tutti e 10 gli eventi. O almeno del mondo dello sport dello scripting, che è quasi la stessa cosa.
Le Olimpiadi dello scripting (dal 15 febbraio al 3 marzo) promettono di essere divertenti e pieni di sfide. Ciò che più conta, le Olimpiadi dello scripting sono aperte a tutti. Gli utenti che non hanno ancora accumulato una lunga esperienza nel campo degli script di amministrazione del sistema possono partecipare alla divisione per principianti; sono previsti tornei separati per i principianti in VBScript, Windows PowerShellTM e (novità di quest'anno) Perl. La divisione per principianti sembra troppo facile? Allora è meglio cimentarsi nella divisione avanzata, che prevede allo stesso modo competizioni in VBScript, Windows PowerShell e Perl.
Le Olimpiadi (abbiamo già scritto che si terranno dal 15 febbraio al 3 marzo?) sono senza false modestie l'evento principale della stagione dello scripting che non si può mancare. È già possibile visitare la home page dello Script Center per ottenere suggerimenti e trucchi su come allenarsi per la competizione, prima di tornare il 15 febbraio quando si darà ufficialmente inizio alle Olimpiadi.
Dal 15 febbraio al 3 marzo. Se qualcuno non l'avesse ancora capito.
Come? È vero: Un nuovo numero di Hey, Scripting Guy! oltre all'annuncio delle Olimpiadi dello scripting forse induce fin troppa emozione per un mese solo. Tuttavia, per rendere felici i bravi ragazzi di TechNet Magazine (il nostro scopo principale nella vita, inutile ripeterlo), abbiamo deciso di rischiare e pubblicare un nuovo articolo comunque.
Esattamente un anno fa (è passato davvero tutto questo tempo?), abbiamo pubblicato un articolo in cui si spiegava come utilizzare uno script per leggere un file XML. Ciò che non si diceva in quell'articolo è come si utilizza uno script per creare, scrivere e modificare un file XML. Questo mese abbiamo deciso di riparare quel torto. Qualcuno desiderava proprio sapere come scrivere uno script in grado di creare un file XML? Basta chiedere. O meglio, chiedere e aspettare un annetto che gli Scripting Guy riescano a risolvere il problema. Lo script è descritto nella Figura 1. È vero, sembra complicato, ma spiegheremo come funziona l'intero script.
Figure 1 Creazione di un file XML (Close Figure 1)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName

Set objDate = _
  xmlDoc.createElement("AuditDate")
objDate.Text = Date
objRecord.appendChild objDate

Set objIntro = _
  xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)

xmlDoc.Save "C:\Scripts\Audits.xml"
Per iniziare, si crea un'istanza dell'oggetto Microsoft.XMLDOM. Come è facile immaginare, questo è l'oggetto che consente di lavorare con i file XML. Lo scopo consiste nel produrre un semplice file XML che somigli alla Figura 2.
Figura 2 Il nostro obiettivo: un semplice file XML
Figura 2 Il nostro obiettivo: un semplice file XML
Per creare questo file XML, è prima di tutto necessario creare il nodo principale (ITChecklist). Come si esegue questa operazione? Così:
Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot
Facile, vero? È sufficiente chiamare il metodo createElement, passando a createElement il nome da attribuire al nodo principale. Quindi si chiama il metodo appendChild, passando il riferimento all'oggetto al nuovo elemento (objRoot) come unico parametro del metodo. A questo punto, il nodo principale è pronto.
Ma un momento; c'è dell'altro. Si crea il nodo ComputerAudit, un nodo figlio del nodo ITChecklist che rappresenta le informazioni per un singolo computer. Come si può notare, il codice per creare il nodo è simile al codice utilizzato per il nodo principale:
Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord
Una differenza esiste ed è questa: quando è stato creato il nodo principale, si è chiamato appendChild sullo stesso documento XML (vedere il riferimento all'oggetto xmlDoc). Per aggiungere un nodo figlio nuovo al nodo principale, si chiama appendChild sul nodo principale (objRoot) invece del documento XML. Basta questo.
È altrettanto facile aggiungere i nodi ComputerName e AuditDate come nodi figlio di ComputerAudit. A tal fine, si segue una procedura simile: si deve chiamare createElement per creare un nodo nuovo, quindi chiamare appendChild per aggiungere il nuovo nodo al file
(quiz rapido: dove si chiamerà appendChild da questo momento in poi? Sì, esatto: da objRecord, il nodo padre (ComputerAudit) appena creato).
Poiché, inoltre, i nodi ComputerName e AuditDate devono contenere valori, è importante specificare anche un valore per la proprietà Text di ciascuno di questi nodi subito prima di aggiungerli al documento.
Tutto apparirà più chiaro quando si analizzerà il codice che crea effettivamente il nodo ComputerName:
Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName
Come è facile prevedere, il codice per la creazione di AuditDate è quasi identico. È necessario specificare un nome di nodo diverso quando si chiama createElement e assegnare un valore diverso alla proprietà Text.
Ragazzi, sta diventando tutto troppo semplice!
Una volta creati i nodi per il primo (e, in questo caso, unico) record, si esegue questo piccolo blocco di codice:
Set objIntro = _
 xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)
Il codice si limita a inserire il tag <?xml version="1.0" ?> all'inizio del file, garantendo la corretta formattazione del documento XML.
A questo punto, non resta che chiamare il metodo Save e salvare il nuovo file come C: \Scripts\Audits.xml:
xmlDoc.Save "C:\Scripts\Audits.xml"
Ecco un documento XML nuovo di zecca.
Quanto descritto finora è molto utile: ora si è appreso come si crea un file XML nuovo utilizzando uno script. È probabile che non si passi la maggior parte del tempo a creare davvero file XML nuovi, ma che invece capiti spesso di dover aggiungere nuovi dati a un file esistente. Gli Scripting Guy sanno anche come eseguire questa operazione.
In origine avevamo deciso di non divulgare a tutti il segreto di come aggiungere dati a un file XML esistente. Poi la nostra natura di persone gentili e generose ha preso il sopravvento e abbiamo deciso di fare un patto con i lettori di TechNet Magazine: se tutti i lettori della rivista accettano di partecipare alle Olimpiadi invernali dello scripting del 2008, in cambio noi sveleremo come utilizzare uno script per aggiungere dati a un file XML. Allora intendi partecipare anche tu alle Olimpiadi dello scripting?
Stiamo aspettando che tu ci risponda, sì proprio tu di Rochester, MN, USA.
Ecco, bene così. Comunque fidati, alle Olimpiadi dello scripting c'è sempre da divertirsi. Vedrai.
Ciò che è giusto è giusto e un patto è un patto: ecco come utilizzare uno script per aggiungere dati a un file XML esistente. Basta esaminare la Figura 3.
Figure 3 Aggiunte a un file XML (Close Figure 3)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set objRoot = xmlDoc.documentElement

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objFieldValue = _
  xmlDoc.createElement("ComputerName")
objFieldValue.Text = "atl-ws-100"
objRecord.appendChild objFieldValue

Set objFieldValue = _
  xmlDoc.createElement("AuditDate")
objFieldValue.Text = Date
objRecord.appendChild objFieldValue

xmlDoc.Save "C:\Scripts\Audits.xml"
Come si può vedere, lo script non è molto diverso dal precedente con cui si è creato il file XML. Si inizia creando un'istanza dell'oggetto Microsoft.XMLDOM, impostando la proprietà Async su False, in modo che il documento venga caricato in modo sincrono piuttosto che asincrono. Qual è la differenza? Bene, se si caricasse il documento in modo asincrono, lo script sarebbe libero di procedere anche con il documento non ancora completamente caricato. Inutile dire che si possono verificare dei problemi quando si tenta di eseguire un'attività su un documento che non esiste ancora. Il caricamento sincrono del file XML garantisce inoltre che il file verrà completamente caricato prima che lo script possa procedere.
Per quanto riguarda il caricamento completo, in effetti viene chiamato il metodo Load per aprire il file C: \Scripts\Audits.xml. Non appena il file è aperto, si utilizza questa riga di codice per creare un'istanza della classe documentElement, che ha l'effetto di stabilire un'associazione all'elemento principale del documento. In questo caso, ovviamente, si tratta del nodo ITChecklist:
Set objRoot = xmlDoc.documentElement
Da qui in poi il procedimento è piuttosto semplice e diretto. Si crea una nuova istanza del nodo ComputerAudit, utilizzando il metodo appendChild per aggiungere il nuovo nodo al file. Si creano quindi delle istanze nuove dei nodi ComputerName e AuditDate, specificando i valori appropriati (rispettivamente, atl-ws-100 e la data corrente) per ciascun nuovo nodo. Questi due elementi vengono inseriti nel nuovo nodo ComputerAudit appena creato, si chiama il metodo Save per salvare il file e si torna soddisfatti a lavorare sugli script per le imminenti Olimpiadi dello scripting.
Che, se non si fosse ancora capito, sono previste tra il 15 febbraio e il 3 marzo presso il TechNet Script Center.
Fin qui tutto bene. È possibile creare un nuovo file XML e aggiungere dei nuovi record a tale file. Molto interessante, ma ci sono altri segreti da svelare e script da scrivere; ad esempio, come si modificano i record esistenti nel file? Ecco almeno un modo per eseguire l'operazione, come illustrato nella Figura 4.
Figure 4 Modifica di un file XML (Close Figure 4)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
La parte importante di questo script è la chiamata del metodo selectNodes, un metodo che determina quali record verranno restituiti dalla query. Come è possibile vedere, quando si chiama selectNodes è necessario prestare attenzione a specificare due criteri: nell'esempio si desiderano solo i record in cui l'attributo ComputerName è uguale a atl-ws-100 e la restituzione del solo attributo AuditDate.
Nota: non si capisce come funziona? Per schiarirsi le idee, basta leggere il primo articolo sui file XML (technetmagazine.com/issues/2007/02/HeyScriptingGuy); in quel documento la sintassi della query selectNodes è spiegata in maggior dettaglio.
Come è abituato a fare, selectNodes restituisce un insieme di tutti i record XML che soddisfano i criteri specificati. Ne consegue che, per aggiornare il valore dell'attributo AuditDate (il solo attributo richiesto), è sufficiente impostare un loop For Each e analizzare tutti gli elementi nella raccolta e, all'interno del loop, assegnare un nuovo valore ad AuditDate:
For Each objNode in colNodes
   objNode.Text = Date
Next
Come? Qualcuno vorrebbe addirittura modificare più di un attributo per volta? Certo che è possibile. Ma non oggi, purtroppo; di certo se ne sentirà parlare negli articoli futuri.
Un'altra domanda può sorgere spontanea: come si aggiorna la data di controllo per tutti i computer nel file? È facile; si utilizza lo script della Figura 5.
Figure 5 Modifica della data di controllo (Close Figure 5)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
Che differenza c'è tra questo script e lo script precedente di modifica del file XML? In questo script non è specificato che si desidera visualizzare solo i record in cui ComputerName è uguale ad atl-ws-100. Con l'omissione di questo criterio, si ottengono per impostazione predefinita tutti i record.
Prima di terminare l'articolo, è utile esaminare un ultimo script. Si supponga che, dopo aver giocato l'ultima mano di solitario, il caro vecchio atl-ws-100 sia passato a miglior vita nel grande cimitero dei computer nell'alto dei cieli.
Nota teologica: ma dove vanno i computer quando muoiono? A quanto sembra, vengono regalati a qualcuno degli Scripting Guy. Ad esempio, allo Scripting Guy che sta scrivendo questo articolo una volta è stato regalato un computer portatile perché "Fai un sacco di belle cose per Microsoft e un computer portatile ti servirà senz'altro". Il solo svantaggio di questa generosa offerta era l'impossibilità di accendere il computer, irrimediabilmente rotto. Ma anche una miracolosa accensione non avrebbe sortito grandi effetti, dal momento che mancava del tutto il disco rigido.
Per completare il grande ciclo della vita del silicio, è necessario eliminare atl-ws-100 dal file XML. Come si fa? Basta dare un'occhiata alla Figura 6.
Figure 6 Eliminazione dal file XML (Close Figure 6)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")

For Each objNode in colNodes
  xmlDoc.documentElement.removeChild _
    (objNode)
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
Anche questo somiglia a uno script precedente, in particolare quello utilizzato per modificare la proprietà di AuditDate. In verità qui le differenze sono due. Come è facile notare, non è stato specificato alcun valore della proprietà nella query selectNodes, quindi si ottiene l'intero record XML per atl-ws-100:
Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")
Inoltre, all'interno del loop For Each, si chiama semplicemente il metodo removeChild per eliminare tutti i record in cui ComputerName è uguale ad atl-ws-100:
xmlDoc.documentElement.removeChild _
  (objNode)
Ecco fatto! Addio, atl-ws-100; abbiamo avuto appena il tempo di conoscerci.
C'è ancora qualche redattore di TechNet Magazine che sta leggendo l'articolo di questo mese? Sono andati tutti via a tentare di risolvere il rompicapo di script mensile? Ottimo. Ora che nessuno legge, si può finalmente rivolgere il seguente invito al lettore: lascia perdere tutto ciò che stai facendo (anche leggere questa rivista) e passa subito allo Script Center per iniziare a prepararti per le Olimpiadi dello scripting. Dopotutto, TechNet Magazine resterà qui ancora per molto tempo, mentre le Olimpiadi dello scripting si tengono una sola volta l'anno e per un periodo limitato (in particolare, dal 15 febbraio al 3 marzo, tanto per essere informati). Non si può mancare!
Nota: a pensarci, abbiamo aspettato la fine dell'articolo prima di chiedere di smettere di leggere TechNet Magazine, vero? Che strano...

Il rompicapo di script del Dottor Scripto.
La sfida mensile che verifica non solo le tue capacità di risoluzione degli enigmi, ma anche le tue competenze di scripting.

Febbraio 2008: I simboli misteriosi
La tastiera di computer consente di scrivere ogni sorta di caratteri; molti di questi caratteri hanno addirittura una funzione specifica nei linguaggi VBScript o Windows PowerShell. Prova a riconoscere la funzione di ciascuno dei simboli all'interno di uno script. Il primo è tutto per te.

Il rompicapo di script del Dottor Scripto.
Risposta: I simboli misteriosi, febbraio 2008

Gli Scripting Guy di Microsoft 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. Consultare la pagina www.scriptingguys.com.


 Controllo della protezione: Island hopping: limitazione delle dipendenze non desiderate
Controllo della protezione
Island hopping: limitazione delle dipendenze non desiderate
Jesper M. Johansson

Nel numero dell'ultimo mese di Controllo della protezione sono state trattate le fasi iniziali dell'utilizzo di un'unità memoria flash USB per sferrare un attacco contro una rete. L'attacco è stato eseguito collegando un'unità memoria flash USB infetta a un computer. Successivamente, è stato eseguito il codice dannoso, automaticamente o con un intervento minimo da parte dell'utente (mediante l'uso di una semplice tecnica di
ingegneria sociale). Sebbene si trattasse di un attacco locale alla workstation, è evidente che il malware avrebbe potuto diffondersi anche al resto della rete. Ho descritto in modo dettagliato questa forma di attacco in una rete nel mio ultimo libro, disponibile a breve, Windows Server 2008 Security Resource Kit (Microsoft Press®, 2008), e ho adattato alcune parti estratte da questo libro al presente articolo.
Ovviamente, un metodo appropriato per garantire la protezione consiste nel proibire l'utilizzo di unità rimovibili. Non vi è alcun dubbio che questo sia un comportamento prudente, anche se è altrettanto chiaro che un tale "sacrificio" non sia gradito affatto dagli utenti. L'opzione migliore, appropriata a tutti gli ambienti, ad eccezione di quelli più critici per le strategie aziendali, consiste nel tentare di gestire i rischi coinvolti e contenere l'esposizione a potenziali attacchi.
Inoltre, le unità rimovibili rappresentano l'unico metodo per compromettere un computer client. Ricordi l'articolo "Le 10 leggi immutabili della protezione" (disponibile all'indirizzo microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx)? Il sentimento generale della terza legge è ancora valido: "Se un utente malintenzionato ha accesso fisico illimitato al tuo computer, non devi considerarlo più il tuo computer". Nel contesto di questa discussione, se un utente malintenzionato ha accesso a un computer, tale computer deve essere considerato compromesso. Questo attacco può anche essere perpetrato in modalità remota se l'utente malintenzionato riesce a indurre l'utente vittima dell'attacco a eseguire codice dannoso sul relativo computer. In questa affermazione è possibile riconoscere la prima delle 10 leggi immutabili: "Se un malintenzionato riesce a convincerti a eseguire il suo programma sul tuo computer, non è più il tuo computer".
È possibile presumere in tutta sicurezza che le leggi immutabili hanno ancora validità, in quanto si sono dimostrate notevolmente adattabili ed è poco probabile che cambino in modo significativo finché non si apportano modifiche radicali alla dinamica di funzionamento dei computer. Pertanto, considerando l'applicabilità di queste leggi allo scenario delineato, è di importanza fondamentale rendere innocue le unità rimovibili. A tal fine, è sufficiente apportare alcune modifiche al Registro di sistema.
Ovviamente, è necessario utilizzare anche livelli di protezione aggiuntivi. È ragionevole presupporre che la maggior parte dei computer client sia già stata compromessa o che venga utilizzata da utenti non sempre spinti dal predominante interesse a garantire il massimo livello di protezione. Questo implica la necessità di ridurre i relativi effetti sul resto della rete e accresce l'importanza di comprendere, analizzare e limitare le dipendenze di protezione.

Definizione di una dipendenza di protezione
Una dipendenza di protezione si verifica quando la protezione di un computer è dipendente dalla protezione di un altro computer. È probabile che sia capitato di sentire affermazioni del tipo "se il controller di dominio è vittima di un attacco, l'intera rete è sotto attacco". Questo è un modo semplicistico di affermare che tutti i membri del dominio sono dipendenti dai controller di dominio per la relativa protezione. Se non si garantisce la protezione del controller di dominio, non si assicura neppure la protezione dei computer membro. Se un utente malintenzionato può modificare la configurazione di protezione del dominio, potrà assumere il controllo di qualsiasi computer all'interno del dominio aggiungendo, ad esempio, nuovi account al gruppo Administrators su un computer membro. Qualsiasi vulnerabilità che consenta la compromissione di un sistema da parte di un amministratore non suscita alcun interesse. Si suppone che un amministratore abbia accesso completo a tutte le aree che gestisce.
Le dipendenze nei sistemi informatici sono inevitabili. In effetti, le dipendenze sono frequenti e spesso auspicabili; tuttavia, ciò non implica che tutte le dipendenze sono accettabili. In questo articolo verranno illustrati i tipi di dipendenze considerati accettabili e non accettabili, verranno analizzati i diversi tipi di dipendenze e verrà descritto come limitarle. In Windows Server 2008 Security Resource Kit, le specifiche dipendenze vengono descritte in maggiore dettaglio e viene illustrato come gestirle.

Dipendenze accettabili
In generale, una dipendenza è accettabile quando un sistema meno critico per le strategie aziendali dipende per la protezione da un sistema più critico. I computer e i sistemi in generale possono essere suddivisi in classi in base al relativo livello di importanza strategica. Lo specifico set di classi in uno specifico ambiente è irrilevante per la discussione generale: ciò che importa è che siano presenti classificazioni intrinseche. Ai fini di questa discussione, si suppongano due classificazioni: workstation e controller di dominio. In tale scenario, è accettabile che le workstation dipendano dai controller di dominio per la relativa protezione. La classe controller di dominio è molto più critica per le attività aziendali rispetto alle workstation e, ovviamente, necessita di una difesa più efficace.
La stessa argomentazione può essere applicata agli account utente. È accettabile che un amministratore possa compromettere i dati di proprietà di un utente. Il motivo risiede nel fatto che gli amministratori hanno maggiori responsabilità e dispongono di accesso illimitato (anche se non sempre diretto o ovvio) al computer e a tutti gli elementi in esso contenuti. Se si comprende questo punto e si gestiscono i computer in modo appropriato, una dipendenza di questo tipo non costituisce alcun problema.
Anche il software può essere analizzato dallo stesso punto di vista. È certamente accettabile che un componente software meno critico per le attività aziendali, come un browser Web, utilizzi e dipenda per la relativa protezione da un componente software più strategico per le attività aziendali, come un sistema operativo. Se il sistema operativo presenta un bug, il fatto che il browser Web diventi vulnerabile a un nuovo problema non sorprende e non costituisce affatto una priorità nell'elenco delle preoccupazioni imminenti, in quanto il punto focale dell'attenzione sarà rappresentato principalmente dal sistema operativo e da altre applicazioni e dati critici. In particolare, l'attenzione sarà rivolta alle modalità di correzione dei bug e ai componenti a cui applicare gli aggiornamenti rapidi; la correzione di un bug deve avvenire il più vicino possibile all'area problematica. In tal modo, l'impatto protettivo della correzione risulterà incrementato. Pertanto, anziché aggirare il problema nel browser Web, è necessario correggere il bug nel sistema operativo.
In alternativa, è possibile rimuovere la dipendenza modificando la progettazione del sistema. È possibile, ad esempio, riscrivere il browser Web in modo da ridurre le relative dipendenze dal sistema operativo. Quest'ultimo approccio risulta appropriato nei casi in cui le funzionalità dei componenti più protetti (in tal caso il sistema operativo) non siano state affatto progettate per essere utilizzate nel modo in cui vengono utilizzate dal componente meno strategico per le attività aziendali (il browser Web).

Dipendenze non accettabili
Sulla base della descrizione sopra fornita delle dipendenze accettabili, la definizione di una dipendenza non accettabile dovrebbe essere ovvia. In sostanza, un sistema più critico per le strategie aziendali non deve mai dipendere per la relativa protezione da un sistema meno critico.
Se la compromissione di una workstation implica che la protezione del controller di dominio è stata violata, ci si trova di fronte a un serio problema di protezione. È impossibile proteggere una rete se la relativa protezione globale dipende dalla protezione di ogni singolo computer all'interno di tale rete.
Considerare questo aspetto da un punto di vista statistico. Se ogni computer nella rete è "protetto" per il 99,999% del tempo, si potrebbe pensare che si dispone di una rete estremamente protetta. In effetti, tale percentuale è probabilmente lontana dalla realtà di ciò che accade effettivamente oggi in tutte le reti, ad eccezione delle reti di piccole dimensioni. Tuttavia, si supponga che la propria rete includa 40.000 computer, ciascuno dei quali risulta vulnerabile lo 0,001% del tempo. Da un punto di vista statistico, la rete globale potrebbe rimanere in uno stato non protetto per il 40% del tempo.
Ovviamente nel caso di dipendenze non gestite, è sufficiente un solo computer vulnerabile per lo 0,001% del tempo per compromettere l'intera rete. In questi termini, qual è il livello di protezione della rete? Ovviamente, è assolutamente fondamentale che i sistemi più critici per le strategie aziendali siano protetti dai sistemi meno critici.
Questa argomentazione può essere facilmente estesa agli account utente e al software. Ad esempio, il nuovo client Servizi terminal per Windows® consente di memorizzare i nomi e le password degli utenti per garantire un accesso trasparente a Servizi terminal. Tali credenziali vengono memorizzate mediante l'API Gestione credenziali e sono protette dalle credenziali utilizzate per la sessione di accesso principale.
Questo può creare una dipendenza di protezione. Si consideri il caso di un amministratore di rete che accede alla workstation personale. L'amministratore utilizza questa workstation per la posta elettronica, l'esplorazione del Web e altre attività tipiche degli Information Worker. Naturalmente, l'amministratore utilizza per tali attività un account di dominio con privilegi di basso livello.
A un certo punto nel corso della giornata, l'amministratore si connette a un controller di dominio per eseguire alcune attività di gestione. A tal fine, utilizza il client Servizi terminal e sceglie di memorizzare la password in modo da rendere più agevoli le connessioni future. Questa situazione crea almeno una e probabilmente due dipendenze di protezione inaccettabili. La prima riguarda il fatto che le credenziali dell'account amministrativo di dominio ora sono protette dalle credenziali degli Information Worker con privilegi di basso livello. Se questo account utente con privilegi di basso livello viene compromesso, anche l'account utente amministrativo di dominio verrà compromesso e, pertanto, risulterà compromesso l'intero dominio.
La seconda dipendenza deriva dal fatto che l'amministratore ha digitato una credenziale amministrativa di dominio in un controller non di dominio. A meno che il livello di protezione della workstation personale non sia identico a quello dei controller di dominio, e probabilmente non è così, una situazione di questo tipo determina una dipendenza in cui la protezione dei controller di dominio dipende dalla protezione della workstation personale dell'utente. Se un dipendente insoddisfatto nello stesso ufficio, ad esempio, ha installato un keystroke logger nella workstation dell'amministratore di rete, le credenziali amministrative di dominio a questo punto sono state acquisite. Ogni volta che si digita una credenziale amministrativa di dominio in un controller non di dominio, si espone l'intero dominio alle potenziali vulnerabilità di protezione presenti nel controller non di dominio.
Ora si supponga che un utente malintenzionato inserisca un'unità rimovibile in un computer a cui un amministratore di dominio è correntemente connesso o a cui si è connesso in precedenza o a cui si connetterà. Il computer dell'amministratore di dominio in questione viene compromesso e, per estensione, risulta compromesso anche l'intero dominio. È assolutamente necessario comprendere questa situazione in modo da poter evitarla. Ovviamente, la stessa situazione può verificarsi con il software quando un'applicazione protetta si basa sulle funzionalità di un'applicazione meno protetta per eseguire una determinata attività.

Analisi di un attacco
In precedenza sono state illustrate le situazioni che possono verificarsi se un'unità rimovibile dannosa viene inserita in un computer. Tuttavia, può risultare ovvio solo ciò che accade al computer in cui viene inizialmente inserita l'unità. Si supponga che il computer in questione faccia parte di un dominio, come illustrato nella Figura 1.
Figura 1 Dipendenze di dominio ideali
Figura 1 Dipendenze di dominio ideali
Nello scenario riportato nella figura viene illustrata una dipendenza ideale. Le frecce sono direzionali e fanno riferimento al punto da cui la dipendenza viene ereditata. Ad esempio, la protezione della workstation dipende dalla protezione del controller di dominio, e la protezione dell'utente dipende dalla protezione della workstation. L'utente malintenzionato potrebbe compromettere la workstation, il che comprometterebbe tutte le informazioni memorizzate nella workstation in questione, ma la compromissione sarebbe isolata a tale dispositivo.
Tuttavia, si supponga che l'utente che si connette alla workstation sia un membro del gruppo di amministratori locali sul server e che l'amministratore di dominio acceda di frequente al server. Un situazione di questo tipo ha come risultato le dipendenze illustrate nella Figura 2.
Figura 2 Dipendenze di dominio compromesse
Figura 2 Dipendenze di dominio compromesse
Modificando semplicemente l'ipotesi relativa al tipo di utente che ha accesso ai computer in questione, la protezione dell'intera rete risulta completamente compromessa. Poiché un amministratore di dominio accede al server, la protezione del controller di dominio e, quindi, l'intero dominio dipende dalla protezione del server in questione.
Questa dipendenza sarebbe accettabile se il server venisse gestito con lo stesso livello di protezione garantito per il controller di dominio. Tuttavia, in questo caso, un utente che accede alla workstation è membro del gruppo Administrators sul server. Pertanto, la protezione del server dipende dalla protezione della workstation. Ne consegue che la protezione dell'intero dominio dipende dalla protezione della workstation. E guarda un po': l'utente della workstation ha eseguito involontariamente lo strumento dell'utente malintenzionato.
Esistono probabilmente pochi concetti nel mondo della protezione delle informazioni attuale che rivestono un'importanza maggiore rispetto alle dipendenze di protezione. Se si inizia con un'analisi della rete e si tenta di comprendere quali sono le dipendenze presenti, quasi certamente si rileveranno dipendenze inaccettabili. Nello scenario peggiore, che è molto più comune di quanto si potrebbe pensare, la protezione dell'intera rete dipende dall'intera rete; in altre parole, la protezione di ogni singolo computer dipende, in qualche modo, dalla protezione di ogni altro computer. È pertanto impossibile creare in questo tipo di ambiente una strategia di gestione dei rischi ragionevole e realistica in quanto le relazioni sfuggono a ogni tipo di controllo e la complessità risulta incomprensibile. La soluzione consiste nell'analizzare e nel gestire le dipendenze rilevate.
In questo articolo è stata presentata solo una breve panoramica delle dipendenze ed è stato illustrato come analizzarle e ridurle. Ulteriori informazioni sono disponibili nel mio libro Windows Server 2008 Security Resource Kit. Il libro contiene un intero capitolo dedicato all'argomento della protezione della rete in cui le dipendenze vengono analizzate e gestite sia mediante tecniche sofisticate, ad esempio la funzionalità di isolamento di server e domini, che mediante tecniche più comuni, come la gestione di account amministrativi.
Vorrei ringraziare David LeBlanc per aver contribuito con le sue idee alla realizzazione di questo articolo.

Jesper M. Johansson, Software Architect, si occupa dei problemi di protezione software e collabora con TechNet Magazine in qualità di redattore. Ha conseguito il titolo di PhD in MIS e ha oltre 20 anni di esperienza nel settore della protezione.


 File desktop: Avvio doppio con Windows XP e Windows PE 2.0
File desktop
Avvio doppio con Windows XP e Windows PE 2.0
Wes Miller
Scarica il codice per questo articolo: Desktop2008_02.exe (151KB)

Negli articoli precedenti di File desktop, ho accennato a come Windows PE sia diventato uno strumento per il ripristino e ho spiegato come sia possibile utilizzarlo da una seconda partizione. Una domanda ricevuta di recente mi ha spinto ad approfondire questa discussione sull'utilizzo contemporaneo di Windows PE 2.0 e Windows XP.
Dopotutto, sono molti i lettori che utilizzeranno Windows® XP ancora per un po' e Windows PE 2.0 è la versione che Microsoft supporterà in futuro (non ci saranno altri aggiornamenti a Windows PE 1.x).
Una differenza importante tra Windows PE 1.x e 2.x è che Windows PE 2.x può essere avviato tramite un'interfaccia di avvio standard (a differenza del metodo specifico utilizzato per Windows PE 1.x). Sebbene sia possibile avviare Windows PE 1.x o 2.x da una seconda partizione, l'avvio dalla stessa partizione in cui è installato il sistema operativo presenta molteplici potenzialità che saranno illustrate di seguito.

Avvio doppio per Windows
Windows NT® si è sempre dimostrato tollerante all'avvio doppio. Ma non appena si è iniziato a sostituire con i computer basati su EFI (Extensible Firmware Interface) il precedente BIOS AT dei PC IBM, Microsoft ha modificato il meccanismo di avvio di Windows perché funzioni in modo ottimale con EFI e per avere un meccanismo di avvio unico su tutte le architetture. Il nuovo meccanismo di avvio per Windows, a partire da Windows Vista®, viene definito come Database di configurazione di avvio o BCD (vedere microsoft.com/whdc/system/platform/firmware/bcd.mspx). Ma che si parli del precedente boot.ini o del nuovo meccanismo di BCD, Windows è in genere in grado di eseguire l'avvio di entrambi i sistemi operativi, anche se ciò significa passare il processo di avvio a un altro caricatore di avvio.
Prima di iniziare, è importante ricordare che Windows PE 2.0 funziona solo su sistemi dotati sia di compatibilità APCI (Advanced Configuration and Power Interface) completa che di una RAM di 384 MB (meglio se di 512 MB). Come accennato nell'articolo di maggio (technetmagazine.com/issues/2007/05/DesktopFiles), sui sistemi non ACPI non sarà possibile eseguire l'avvio di Windows PE 2.0 e, poiché l'avvio di Windows PE 2.0 deve essere eseguito su un RAMDisk, è necessario disporre di RAM sufficiente a contenere il RAMDisk, eventuali aree scratch e l'intero working set della RAM. Se il sistema che si utilizza dispone di meno di 384 MB di RAM, anziché seguire questa strada è consigliabile utilizzare Windows PE 1.6. Anche una mano esperta nella riduzione delle dimensioni di Windows PE non può garantirne una corretta esecuzione con 256 MB.

I problemi che si possono risolvere
Di seguito sono elencati i problemi che sarà possibile affrontare eseguendo l'avvio di Windows PE 2.0 dalla stessa partizione di Windows XP.
Ripristino completo del sistema Si tratta solo di una delle attività rese possibili dall'avvio di Windows PE direttamente dalla partizione di Windows XP. Poiché Windows PE 2.0 (come Windows PE 1.6) può essere avviato interamente su un RAMDisk, è possibile creare una nuova immagine dell'intero disco o utilizzare ImageX per ripristinare i file Windows XP, poiché non è necessario ripristinare l'intera partizione.
Se si consente agli utenti di eseguire l'avvio di Windows PE, essi potranno ripristinare i relativi sistemi anche lavorando in modalità remota. L'immagine potrebbe provenire da una partizione secondaria, una condivisione di rete (se gli utenti non saranno mobili), un disco rigido USB o un DVD di ripristino oppure, se si utilizza ImageX, sarà persino possibile memorizzarla sulla partizione da recuperare. Questo tipo di ripristino su disco è una valida soluzione per molti problemi (ad eccezione del danneggiamento fisico del disco). Non è ovviamente una soluzione altrettanto valida per il ripristino dei dati utente, a meno che i dati vengano prima protetti e quindi ripristinati come parte del ripristino. Per evitare perdite di questo tipo, è opportuno utilizzare profili mobili ed eseguire il backup dei dati dal computer. È inoltre necessario accertarsi che il meccanismo di ripristino utilizzato sia in grado di ridurre il rischio di qualsiasi potenziale perdita di dati da parte dell'utente (compresa la perdita dovuta alla reimpostazione delle chiavi di crittografia EFS).
Ripristino di file Windows PE fornisce anche un meccanismo per ottenere un sistema funzionante, anche quando non si riesce a eseguire l'avvio dell'installazione primaria di Windows. In questo caso sarà possibile eseguire l'avvio e il ripristino dei dati utenti su un altro sistema (purché siano disponibili sistemi di backup a caldo per gli utenti) o in un'altra posizione, in modo che l'utente possa iniziare a lavorare subito.
Ripristino del sistema Infine, l'avvio di Windows PE su Windows XP consente di ripristinare un sistema mediante l'esecuzione di un set di script di risoluzione dei problemi o una semplice applicazione di ripristino gestita dall'utente. Il processo è simile al ripristino completo del sistema, ma l'ambito risulterà più ristretto (e non vi saranno rischi per i dati dell'utente).
Ora che sono più chiari i vantaggi dell'avvio di Windows PE sulla partizione di Windows XP, si illustrerà cosa accade dietro le quinte, in modo che sia possibile applicare il processo a qualsiasi soluzione si desideri.

Prima di Windows Vista
Prima dell'avvento di Windows Vista, ecco come veniva eseguito l'avvio dei sistemi basati su BIOS/Record di avvio principale (MBR): Il BIOS rilevava il dispositivo di avvio (nel caso del disco rigido, al record MBR del disco). Il record MBR eseguiva il codice che specifica la partizione da cui eseguire l'avvio, ovvero della prima partizione per cui era impostato il flag di partizione attiva. Nelle prime versioni di diskpart, non era possibile rendere inattiva una partizione (vale a dire che non era possibile rimuovere il flag di partizione attiva). Per ovviare a questo problema è stata aggiunta un'opzione a diskpart. In caso contrario si sarebbe trattato della prima partizione della tabella delle partizioni con il flag di partizione attiva. La partizione contiene il settore di avvio che indica il codice successivo da eseguire. Da Windows NT a Windows Server® 2003, il codice da eseguire è in un file denominato ntldr, senza estensione del file. Se qualche volta si è formattato un disco, non si è installato Windows e si è quindi tentato di eseguire l'avvio, si sarà notato il messaggio di errore "NTLDR non trovato".
Per i lettori sarà interessante sapere che il file ntldr è completamente compatibile con le versioni precedenti, ma naturalmente non con le versioni future. Ne consegue che il file ntldr di Windows XP può eseguire l'avvio di Windows 2000, ma non viceversa. Per questo motivo, quando si intende eseguire un avvio doppio, è sempre importante installare per primo il sistema operativo meno recente. Poiché al file ntldr non è associato un numero di versione, è ancora più importante osservare queste indicazioni.
Il file Ntldr è un'applicazione in modalità reale (16 bit) che avvia NTDetect.com, che esegue il rivelamento dei dispositivi di base e avvia quindi il kernel, ntoskrnl.exe (che può essere uno di diversi file, sempre rinominato in ntoskrnl.exe). Il kernel è il componente fondamentale nel processo di avvio di Windows.
Questo riepilogo del processo di avvio è piuttosto semplicistico ed è stata omessa l'intera inizializzazione di Win32® che tuttavia non è attinente all'argomento dell'articolo. Se si desiderano ulteriori informazioni al riguardo, è consigliabile leggere Windows Internals, Fourth Edition di Mark Russinovich e David Solomon (Microsoft Press®, 2004).
Un altro aspetto importante è che, quando si esegue l'avvio da CD, l'Installazione di Windows e Windows PE eseguono setupldr.bin anziché ntldr. Questo file contiene in realtà codice di avvio leggermente diverso perché sia possibile eseguire l'avvio da CD (cosa impossibile per il file ntldr). Per avviare Windows PE 1.x, è quindi necessario rinominare setupldr.bin in ntldr e metterlo su disco. Inoltre il file non può caricare un file boot.ini (perché setupldr.bin è stato progettato proprio per l'avvio da CD e, di conseguenza, boot.ini non doveva essere necessario).

Dopo Windows Vista
Windows Vista ha modificato molte parti di questo processo. Windows Server 2008 lo modifica ulteriormente attivando IA32 (il supporto di 32 bit) per l'avvio da EFI, operazione che non è stato possibile effettuare al di fuori dei sistemi basati su Itanium. Per i sistemi basati su BIOS, i passaggi iniziali del processo di avvio sono in gran parte identici. La differenza principale è che BOOTMGR è il caricatore di avvio che viene inizializzato e che esegue quindi i passaggi successivi.
Cerca nella directory di avvio il file BCD, che è in realtà l'hive corrispondente del Registro di sistema. Il file BCD contiene le voci di avvio (compresa quella predefinita) da avviare. Vedere la Figura 1 per i tipi di immagine (i tipi di file eseguibili) e la Figura 2 per i tipi di applicazione specifici da avviare. Una o più di una di queste voci può essere un riferimento al file ntldr. Solo una delle voci può fare effettivamente riferimento al GUID noto utilizzato per caricare il file ntldr (vedere la quinta riga della Figura 3). BOOTMGR decide quindi la voce successiva da caricare, a seconda che si stia eseguendo l'avvio del sistema, che il sistema sia stato sospeso o che venga eseguito l'avvio su ntldr o su un altro Boot Manager (nel qual caso farebbe riferimento a un altro settore di avvio ed eseguirebbe il caricatore corrispondente). Questa è la situazione più comune quando si configura l'avvio doppio con un sistema operativo non Windows. È possibile trovare ulteriori informazioni all'indirizzo microsoft.com/whdc/system/platform/firmware/bcd.mspx.
Figure 3 Oggetti applicazione standard (Close Figure 3)

Descrizione | ID BCDEdit | GUID
Windows Boot Manager | {bootmgr} | 9dea862c-5cdd-4e70-acc1-f32b344d4795
Boot Manager firmware | {fwbootmgr} | a5a30fa2-3d06-4e9f-b5f4-a01df9d1fcba
Tester memoria Windows | {memdiag} | b2721d73-1db4-4c62-bf78-c548a880142d
Applicazione Windows Resume | Nessun alias | 147aa509-0358-4473-b83b-d950dda00615
Caricatore di Windows preesistente | {ntldr} | 466f5a88-0af2-4f76-9038-095b170dc21c
Voce di avvio corrente | {current} | fa926493-6f1c-4193-a414-58f0b2456d1e
Voce di avvio predefinita | {default} | nessun GUID predefinito
Figure 2 Tipi di applicazione (Close Figure 2)

Descrizione | Valore | Descrizione
Boot Manager firmware | 0x1 | Applicabile solo ai sistemi EFI.
Windows Boot Manager | 0x2 | Controlla il flusso di avvio. In un sistema ad avvio doppio, presenta all'utente un menu di selezione dell'avvio.
Caricatore di avvio di Windows | 0x3 | Carica una specifica versione o configurazione di Windows.
Applicazione Windows Resume | 0x4 | Ripristina Windows nello stato di esecuzione proprio di quando un computer si riattiva dalla sospensione.
Tester memoria Windows | 0x5 | Un'applicazione di diagnostica della memoria.
Ntldr | 0x6 | Applicabile solo ai sistemi BIOS PC/AT. Carica versioni di Windows precedenti a Windows Vista.
Settore di avvio | 0x8 | Applicazione in modalità reale a 16 bit. Applicabile solo ai sistemi BIOS PC/AT. Può essere utilizzato per riavviare il processo di avvio e caricare un sistema operativo non Windows.
Figure 1 Tipi di immagini (Close Figure 1)

Descrizione | Valore
Applicazione firmware | 0x1
Applicazione di avvio | 0x2
Oggetto basato su Ntldr | 0x3
Applicazione in modalità reale | 0x4
Si noterà che la nuova infrastruttura di avvio di Windows Vista è molto più organizzata rispetto alle versioni precedenti: al di fuori di bootmgr, tutto il codice di avvio si trova nella directory principale/di avvio e viene passato ai file binari specifici di Windows quando BCD lo specifica.

Avvio di Windows XP e Windows PE 2.0
Ora probabilmente si inizia a comprendere come Windows PE, utilizzando il Boot Manager di Windows Vista, possa agire da intermediario e consentire di continuare ad avviare Windows XP o le versioni precedenti di Windows aggiungendo Windows PE 2.0 come strumento di ripristino integrato.
Certo sarà necessario aggiungere un altro passaggio al processo di avvio, ma si tratta di un passaggio progettato da Microsoft. Con la consapevolezza che la nuova infrastruttura di bootmgr doveva essere compatibile con le versioni precedenti del file ntldr esistenti e con gli altri Boot Manager di terze parti, bootmgr è stato creato intenzionalmente per supportare tali soluzioni.
Dopo aver esaminato come avviene l'avvio di Windows e come funziona il nuovo BCD, è il momento di scoprire come sia possibile unire tali conoscenze e utilizzare Windows PE 2.0 nelle installazioni di Windows XP esistenti. Esistono due modi per impostare il settore di avvio di Windows Vista, la parte di codice che chiede al sistema di avviare bootmgr. Uno consiste nell'utilizzare diskpart e creare e formattare una nuova partizione con Windows PE 2.0. Ma non si tratta di un'opzione applicabile in questo caso, perché esiste già un'installazione di Windows XP che non si può rischiare di danneggiare o spostare. È possibile seguire invece questa procedura:
  1. Accertarsi di disporre di una copia di bootsect.exe e di bcdedit.exe sul CD di avvio di Windows PE 2.0 (è possibile trovare entrambi sul DVD di installazione di Windows Vista).
  2. Avviare il sistema Windows XP con il CD di Windows PE 2.0.
  3. Una volta eseguito l'avvio, eseguire il seguente comando:
    bootsect.exe /NT60 ALL
In questo modo il settore di avvio compatibile con Windows Vista in grado di avviare bootmgr verrà impostato come settore di avvio.
4. Copiare Boot Manager sul disco rigido:
    xcopy BOOTMGR C:\BOOTMGR /I
5. Copiare il file boot.SDI nella directory \BOOT sul disco rigido. Prima di eseguire l'avvio sarà necessario farne una copia, dato che verrà bloccato e non sarà possibile copiarlo durante l'esecuzione di Windows PE:
    xcopy BOOT.SDI C:\BOOT\
Correggere il percorso di origine di conseguenza.
6. Copiare boot.WIM sul disco rigido: Come per il file SDI, dovrebbe essere disponibile un'altra copia perché non sarà possibile copiare il file durante l'esecuzione:
    xcopy BOOT.WIM C:\BOOT\BOOT.WIM
Correggere il percorso di origine di conseguenza.
7. Creare adesso un nuovo archivio BCD:
    bcdedit /createstore
8. Creare quindi le voci BCD per caricare Windows PE:
    bcdedit /create {ramdiskoptions} /d
    "Boot Windows PE"
    bcdedit /set {ramdiskoptions}
    ramdisksdidevice partition=c:
    bcdedit /set {ramdiskoptions}
    ramdisksdipath \boot\boot.sdi
    bcdedit /create /d "Windows PE" /
    application
    OSLOADER
9. L'ultima riga restituirà un GUID. Sostituire {YOURGUID} con il GUID restituito. Queste sono le voci di RAMDisk che consentono l'avvio di Windows PE dal disco rigido, riportate nella Figura 4.
Figure 4 Le voci di RAMDisk che consentono l'avvio di Windows PE dal disco rigido (Close Figure 4)
bcdedit /set {YOURGUID} device ramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} path \windows\system32\winload.exe
bcdedit /{YOURGUID} osdeviceramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} systemroot \windows
bcdedit /set{YOURGUID} winpe yes
bcdedit /set {YOURGUID} detecthal yes
10. Creare adesso le voci di bootmgr per consentire l'avvio di Boot Manager:
    bcdedit /create {bootmgr} /d
    "Boot Manager"
    bcdedit /set {bootmgr} device boot
11. Impostare infine una voce di BCD per l'installazione di Windows esistente (modificare il testo visualizzato da Windows XP in base a come si desidera che venga visualizzato nel menu di avvio di Boot Manager). L'ultimo comando imposta anche tale voce in modo che sia la prima voce (predefinita) nel menu di avvio:
    bcdedit /create {ntldr} /d "Windows XP"
    bcdedit /set {ntldr} device partition=C:
    bcdedit /set {ntldr} path \ntldr
    bcdedit /displayorder {ntldr} /addfirst
12. Dovrebbe ora essere possibile riavviare il sistema e fare in modo che avvii l'installazione precedente di Windows o Windows PE 2.0 selezionando la voce appropriata del menu di avvio. Nella Figura 5 è illustrato l'output di esempio di bcdedit /enum all. Con questo comando si ottiene un elenco con tutte le voci in BCD dopo l'aggiunta delle voci (da Windows PE 1.6).
Input di esempio
Input di esempio
Sto lavorando a uno script che consenta di eseguire questa attività automaticamente. Al momento lo script è in grado di copiare solo i file di avvio sul disco rigido e configurare le voci di BCD. Non è ancora in grado di impostare il settore di avvio come nuovo valore di Windows Server 2008 durante l'esecuzione di Windows: l'operazione deve essere eseguita non in linea, in Windows PE. È possibile trovare lo script nel download disponibile nel sito Web TechNet Magazine all'indirizzo technetmagazine.com. Per eseguire lo script, è necessario che nella stessa directory del VBScript che si sta eseguendo siano presenti gli elementi seguenti:
  1. BCDEdit
  2. BOOTMGR
  3. Una directory \BOOT\ (dal supporto di Windows Vista o Windows PE 2.0)
  4. Una directory \SOURCES\ con un file BOOT-WIM di Windows PE 2.0 valido e avviabile
Lo script creerà il BCD e copierà i file di avvio appropriati. Dopo aver eseguito l'avvio con Windows PE e aver eseguito il bootsect, dovrebbe essere possibile eseguire l'avvio doppio.

Annullamento dell'avvio doppio
Annullare l'avvio doppio è un'operazione ancora più semplice della configurazione. È solo necessario ripristinare il settore di avvio sul settore di avvio precedente a Windows Vista eseguendo il comando seguente:
bootsect.exe /NT52 ALL
Una volta ripristinato, sarà possibile eliminare il bootmgr e la directory \boot. Al riavvio successivo, il settore di avvio forzerà l'avvio di ntldr e rimuoverà completamente Windows PE 2.0 e tutti i file binari di avvio di Windows Vista dal flusso di avvio.

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


 Taccuino: La donazione di dispositivi informatici
Taccuino
La donazione di dispositivi informatici
Jim Lynch

Il buon senso convenzionale percepito per molti anni sul modo più economico per smaltire i vecchi computer è stato espresso al meglio in un documento di ricerca, pubblicato nel 2003 da Frances O'Brien del The Gartner Group, intitolato "PC Disposal: TCO's Last Surprise". Con questa analisi comparativa dello smaltimento dei computer, si è scoperto che la donazione dell'apparecchiatura era l'opzione più costosa (delle sei opzioni di smaltimento prese in considerazione) a causa del tempo necessario per individuare l'organizzazione di beneficienza giusta disposta ad accettare le donazioni.
Suggerimenti per le donazioni
TechSoup.org offre ulteriori suggerimenti su come effettuare o ottenere donazioni all'indirizzo techsoup.org/recycle. Ecco alcuni aspetti da considerare prima di regalare i computer:
  • Evitare di conservare ancora l'apparecchiatura informatica dopo averla sostituita con dell'hardware nuovo. I computer perdono il proprio valore di riutilizzo dopo cinque anni. Allo stesso modo, la vita utile dei telefoni cellulari in genere termina dopo tre anni.
  • Donare l'apparecchiatura informatica con meno di cinque anni alle organizzazioni per la rigenerazione dei computer piuttosto che direttamente agli enti senza scopo di lucro o alle scuole.
  • Donare l'intera l'apparecchiatura, comprensiva di tastiera, mouse, stampante, modem, dischetti del software e manuali forniti con il computer.
  • Tenere un elenco di ciò che si dona, per il proprio archivio e per ottenere una ricevuta. Quando si effettuano donazioni a organizzazioni per la rigenerazione dei computer senza scopo di lucro, è possibile che si abbia diritto a delle deduzioni dalle imposte. Negli Stati Uniti le aziende donatrici possono dedurre il valore non ammortizzato del computer, mentre i privati possono dedurre dalle imposte il valore di mercato corrente del computer. Per determinare il valore di mercato corretto di un computer, utilizzare lo Used Computer Evaluator all'indirizzo (servlets.edeal.com/servlets/PcEval).

Oggi tutto è cambiato. Infatti, l'Environmental Protection Agency (EPA) degli Stati Uniti ha avviato di recente una campagna denominata "Do the PC Thing" allo scopo di informare gli utenti su come preparare il vecchio hardware per il riutilizzo e offrire un elenco di risorse utili. La campagna è inclusa nel sito dell'EPA dedicato al riciclaggio e riutilizzo dei dispositivi elettronici, Plug-In To eCycling (epa.gov/plugin/). Fare clic sul collegamento "Reuse It!" per gli articoli indirizzati ai consumatori o alle aziende.
Sul sito si apprenderà che il problema più importante relativo alla donazione o al riciclaggio dell'hardware è la protezione dei propri dati. Nella documentazione della campagna "Do the PC Thing" vengono fornite delle indicazioni di massima sull'eliminazione dei dati dal disco rigido e informazioni sui requisiti normativi per la protezione e la riservatezza dei dati. Quando si devono smaltire dei computer, sia per il riciclaggio alla fine della vita utile che per il riutilizzo, è necessario rimuovere i propri dati riservati, come le password, i documenti, le informazioni sulle carte di credito, i messaggi di posta elettronica e i registri Web.
La maggior parte delle organizzazioni di riciclaggio, rigenerazione e gestione dei cespiti forniscono servizi di protezione dei dati, distruggendo i dischi rigidi o utilizzando un software che sovrascrive i dati in modo da renderli irrecuperabili. Se i computer sono indirizzati al riutilizzo, è preferibile lasciare l'hardware intatto.
Le aziende più affermate che si occupano di ripulire i dischi rigidi utilizzano le specifiche 5220.22-M dello U.S. Department of Defense. Questo tipo di pulizia dei dati basato su software sovrascrive sistematicamente tutte le posizioni indirizzabili sul disco rigido con un carattere, verifica la sovrascrittura e sovrascrive di nuovo tutte le posizioni indirizzabili con caratteri casuali. Nel 2004 presso la U.S. National Security Agency (NSA Advisory LAA-006-2004) si è rilevato che una sola sovrascrittura eseguita secondo le specifiche del ministero della difesa è sufficiente a rendere i file elettronici irrecuperabili.
Oggi è relativamente facile eseguire la pulizia del sistema da soli. Esistono ottime applicazioni gratuite come Active@ Kill Disk Hard Drive Eraser (killdisk.com/eraser.htm) o Darik's Boot and Nuke (dban.sourceforge.net). Quando è necessario eliminare i dati da più computer, è opportuno utilizzare applicazioni commerciali più robuste, come Blancco Data Cleaner (blancco.com) o WipeDrive (whitecanyon.com).
Se i dispositivi informatici hanno più di cinque anni o sono seriamente danneggiati, una delle sei opzioni di smaltimento che Gartner ha considerato è il riciclaggio completo. Esistono più di 900 aziende che operano in questo settore negli Stati Uniti. Per riciclare i dispositivi informatici più datati in modo corretto, vedere l'elenco disponibile sul sito della Electronic TakeBack Coalition (www.computertakeback.com/the_solutions/recyclers_map.cfm).

Jim Lynchè Program Director per il riciclaggio e il riutilizzo di computer presso TechSoup.org, una società senza scopo di lucro di San Francisco la cui missione è fornire hardware e software a basso costo, oltre che conoscenze, tecnologiche a organizzazioni di beneficenza in tutto il mondo.


 Windows Confidential: Eliminazione delle funzionalit&#224; obsolete
Windows Confidential
Eliminazione delle funzionalità obsolete
Raymond Chen

Non capita spesso, ma a volte una funzionalità obsoleta viene eliminata, con grande soddisfazione del team responsabile del prodotto. In Windows® XP, ad esempio, è stata eliminata l'interfaccia per l'impostazione di un motivo del desktop. La funzionalità sottostante è ancora disponibile per chi riesce a scrivere un programma che chiami SystemParametersInfo(SPI_SETDESKPATTERN), ma non esiste più un'interfaccia incorporata corrispondente. Perché l'interfaccia per i motivi del desktop è stata eliminata dal pannello di controllo del desktop?
Con una rapida ricerca si è scoperto che praticamente nessuno utilizzava più i motivi del desktop. Erano molto diffusi quando la memoria era più costosa e gli utenti non volevano sprecare un quarto della memoria del computer per un bitmap di sfondo da 1 MB. Un piccolo motivo 8×8 monocromatico ripetuto su uno schermo 640×480 garantiva un minimo di personalizzazione a costi molto più bassi.
Tuttavia, il progresso negli anni ha reso i motivi del desktop sempre meno attraenti. Un primo motivo, ovviamente, è la maggiore disponibilità di memoria nei computer rispetto al 1983. Un secondo motivo è l'aumento della risoluzione dei monitor che si utilizzano oggi. Un suggestivo motivo 8×8 diventa fondamentalmente una macchia grigia se visualizzato su un monitor alla risoluzione di 1600×1200.
Questa non è l'unica funzionalità obsoleta eliminata. Un altro esempio sono i frammenti. Introdotti in Windows 95, i frammenti venivano visualizzati come frammenti di documenti acquisiti in un file. Il frammento di file era in realtà un oggetto OLE. L'idea di fondo dei frammenti era la possibilità, ad esempio, di evidenziare del testo in un elaboratore di testo e trascinarlo sul desktop, dove veniva quindi creato un frammento. In seguito era possibile riprendere il frammento e trascinarlo di nuovo nell'elaboratore di testo o in un altro programma, in modo che il testo utilizzato per creare il frammento venisse inserito nel nuovo documento. È una specie di copia e incolla, con la differenza che invece di memorizzare i dati temporaneamente negli appunti, questi venivano memorizzati in un file.
Una volta creato il file di un frammento, l'unica operazione possibile consisteva nel trascinare il frammento in un altro documento, come d'altra parte l'unico possibile utilizzo del contenuto degli Appunti è tramite l'operazione Incolla. Qualcuno ha avuto a un certo punto l'idea di aggiungere una funzionalità che consentiva di fare doppio clic sul file del frammento per aprirlo nell'applicazione utilizzata per crearlo (il contenuto poteva essere in qualsiasi formato, quindi l'unico modo per visualizzare il frammento consisteva nell'attivare il programma con cui era stato creato).
Non è chiaro se questa funzionalità sia stata aggiunta come strumento di debug o per consentire agli utenti di visualizzare il contenuto del frammento senza dover creare un documento fittizio in cui trascinarlo. In ogni caso agli autori di virus questa funzionalità "apri l'applicazione che ha creato il frammento" piaceva molto, perché ha consentito loro di creare un file di frammento e riempirlo di dati che sostanzialmente equivalevano a "l'applicazione originale è cmd.exe e il frammento di documento è questo file batch". Quando qualcuno faceva doppio clic su un file di frammento di questo tipo per vedere cosa contenesse, il visualizzatore del frammento passava un file batch al processore dei comandi chiedendo educatamente di aprire il file e mostrarlo all'utente.
Il team della shell conosceva la storia dei frammenti e ha iniziato a pensare di eliminare la funzionalità da Windows Vista®. A tal fine, il team ha dovuto avviare una ricerca per capire l'utilizzo dei frammenti quanto fosse diffuso nel mondo reale. Il team della shell ha quindi chiesto al gruppo di supporto del prodotto di recuperare i registri del gruppo e scoprire quante persone avevano chiamato per domande sui frammenti. In teoria, le funzionalità più diffuse sono all'origine di un numero di chiamate al supporto maggiore rispetto alle funzionalità meno diffuse (perché nessuno le utilizza). L'utilizzo dei frammenti non rientrava esattamente nella categoria delle funzionalità più intuitive, quindi non era possibile giustificare la presenza di un numero ridotto di chiamate con il fatto che la funzionalità fosse molto semplice da utilizzare.
La risposta del gruppo di supporto del prodotto è stata immediata: nell'anno precedente erano state ricevute solo quattro chiamate sull'argomento. Tutte erano del tipo: "Ho creato uno strano file. Cos'è e come faccio a eliminarlo"?

Raymond Chen, The Old New Thing, così come nel suo libro che porta lo stesso titolo (Addison-Wesley, 2007), vengono illustrate la storia di Windows e la programmazione in Win32. Raymond non ti vede da anni e si chiede come te la passi e i tuoi come stanno.