Settembre 2008 Settembre 2008
ISA Server: Guida alla protezione di ISA Server 2006
Sebbene molte organizzazioni facciano affidamento su ISA Server 2006 per proteggere il loro ambiente, poche si preoccupano della sicurezza dello stesso ISA Server. Questa guida all'uso di Configurazione guidata impostazioni di sicurezza e dei ruoli amministrativi spiega come limitare la superficie di attacco e proteggere l'implementazione di ISA Server 2006. Alan Maddison
ISA Server: Miglioramento della protezione del gateway di Servizi terminal con ISA Server 2006
Grazie all'utilizzo della nuova funzionalità gateway di Servizi terminal, Windows Server 2008 consente agli utenti di accedere ai desktop da qualsiasi luogo, senza utilizzare una VPN. Questo articolo spiega come pubblicare il gateway di Servizi terminal mediante ISA Server 2006 e come estenderne lo scenario di pubblicazione per includere l'imposizione dell'integrità dei client. Dott. Thomas W. Shinder e Yuri Diogenes
IIS 7.0: I 10 miglioramenti principali delle prestazioni in IIS 7.0
L'ultima versione di IIS introduce una piattaforma modulare ed espandibile con supporto migliorato per scenari comuni di distribuzione e gestione, consentendo significativi miglioramenti delle prestazioni. In questo articolo vengono presentate le dieci aree principali di IIS 7.0 che offrono tali miglioramenti. Mike Volodarsky
Mobility: Suggerimenti per la mobilità delle applicazioni line-of-business
Oggigiorno molti professionisti che non si trovano in sede devono essere in grado di accedere alle applicazioni line-of-business che utilizzano in ufficio (CRM, ERP e simili) dai loro dispositivi portatili. Nell'articolo viene descritto come Windows Mobile e Mobile Device Manager consentono di distribuire complesse funzionalità "mobile" per applicazioni line-of-business di importanza critica. Matt Fontaine
Security: Informazioni sulla gestione di password per account condivisi
Le password degli account condivisi e privilegiati sono ampiamente utilizzate, ma non sono gestite in modo adeguato da molte organizzazioni. Questo crea un serio problema di protezione. Nell'articolo vengono illustrati i rischi associati agli account condivisi e privilegiati e vengono descritti metodi ottimali per la gestione di password più sicure. Chris Stoneff
Columns
From the Editor: Ritorno a scuola: | Letters: La parola ai lettori: | Toolbox: Nuovi prodotti per professionisti IT:
Exchange Queue & A: Allineamento delle partizioni del disco, pianificazione SCR e altro ancora: Nell'articolo Exchange Queue & A di settembre 2008 rispondiamo a domande su come calcolare il numero di server di catalogo globale necessari, cambiare l'appartenenza di sito di un server e altro ancora.Henrik Walther | Utility Spotlight: Strumento di diagnostica memoria Windows: Scopri come questa utilità gratuita può aiutarti a capire se i problemi che si verificano durante l'esecuzione di Windows dipendono da difetti della memoria.Lance Whitney | Inside SharePoint: Integrazione di directory di SharePoint: Pav Cherny discute i limiti del Servizio di gestione directory incorporato in SharePoint e spiega come sostituire questo componente con una soluzione personalizzata che permette di sincronizzare le informazioni destinatario SharePoint con altre soluzioni di directory.Pav Cherny
Windows PowerShell: Teoria sulle stringhe: Nonostante sia orientato agli oggetti, Windows PowerShell può analizzare anche stringhe complicate. Don Jones dimostra come farlo in Windows PowerShell utilizzando il comando Select-String.Don Jones | Hey, Scripting Guy!: Stai connesso al tuo tostapane: Scopri come usare i recordset disconnessi, tabelle di database virtuali, per rimediare ai limiti di VBScript riguardanti la classificazione dei dati ed il lavoro con grandi quantità di dati.Microsoft Scripting Guys | The Desktop Files: Funzionalità avanzata in WDS: Nel suo terzo articolo sui Windows Deployment Services, Wes Miller esplora alcune funzionalità in grado di migliorare la prestazione e la scalabilità, la registrazione e l'automazione di riga di comando.Wes Miller
Security Watch: Password e carte di credito, Parte 3: Nella parte finale di questa serie in tre parti, Jesper Johansson esamina i modi in cui i fornitori di software, le suite di protezione e il marketing ostacolano i veri sforzi volti a garantire la sicurezza degli utenti e fornisce informazioni su come queste pratiche possono condurre al collasso dell'ecosistema di protezione tecnologica.Jesper M. Johansson | Field Notes: Innovazione dall'interno: Romi Mahajan spiega la sua teoria di 'Innovazione dall'interno", che sottolinea il ruolo della creatività umana e del capitale come fattori chiave per un vantaggio competitivo nel lungo periodo.Romi Mahajan | Windows Confidential: Windows 95 Unplugged: Raymond Chen spiega come un codice diagnostico abbia portato inaspettatamente a rallentare Windows 95.Raymond Chen


Guida alla protezione di ISA Server 2006
Alan Maddison
Panoramica:
  • Procedure consigliate per la protezione dei server
  • Impostazione di Configurazione guidata impostazioni di sicurezza
  • Analisi di Configurazione guidata impostazioni di sicurezza
  • Assegnazione di ruoli amministrativi

Indice
Protezione dei server
Impostazione di Configurazione guidata impostazioni di sicurezza
Esecuzione di Configurazione guidata impostazioni di sicurezza
Ruoli amministrativi
Sebbene molti professionisti IT facciano affidamento su ISA Server 2006 (Internet Security and Acceleration Server 2006) per proteggere le loro risorse tecnologiche, pochi si preoccupano della sicurezza dello stesso ISA Server. Se si è
recentemente installato ISA Server 2006, è possibile che ci si ricordi di un promemoria che richiedeva di proteggere il server non appena terminata l'installazione. Sfortunatamente molti di noi professionisti IT rare volte dedichiamo tempo (o abbiamo tempo da dedicare) all'esecuzione di questa importante operazione, e quindi finisce sulla lista delle cose da fare che rimangono nel cassetto.
Negli attuali scenari di protezione in costante evoluzione, non è più accettabile rimandare la protezione di ISA Server. Fortunatamente gli strumenti utilizzati per proteggere ISA Server hanno fatto passi da gigante. Non si devono più affrontare le numerose sfide poste dalle procedure guidate di protezione avanzata presenti nelle versioni anteriori a ISA Server 2004. Si può invece fare affidamento su passaggi ben definiti e strumenti utili, come quello della Configurazione guidata impostazioni di sicurezza, fornito in dotazione con Windows Server® 2003.
In quest'articolo fornirò una breve panoramica delle procedure consigliate per la protezione dei server. Poi mi occuperò più a fondo delle strategie di protezione avanzata per ISA Server, utilizzando sia Configurazione guidata impostazioni di sicurezza per ridurre l'area di superficie di attacco di ISA Server, sia i ruoli amministrativi per limitare l'accesso a ISA Server.

Protezione dei server
Ci sono molti elementi e procedure consigliate associati alla protezione del server, e possono trovarsi in un datacenter o nella stanza dei server accanto agli uffici. È responsabilità dell'amministratore capire quali sono le procedure consigliate e adoperarsi per implementare questi requisiti in modo pratico per l'organizzazione. Dato che la protezione è diventata molto importante negli ultimi anni, siamo diventati abbastanza abituati alle attività che formano il nucleo centrale di tali requisiti, pertanto non insisterò sui dettagli ma fornirò soltanto una breve panoramica.
La prima operazione da eseguire per proteggere il proprio ambiente è verificare che i server siano protetti fisicamente, il che significa, in pratica, limitare l'accesso fisico ai server. Negli ambienti più piccoli questo significa assicurarsi che la porta della stanza dei server rimanga chiusa a chiave e che il numero di individui che possono accedervi sia esiguo. Negli ambienti più grandi questo requisito fondamentale rimane praticamente lo stesso, ma può essere realizzato in modo più sofisticato. Molte organizzazioni utilizzano, ad esempio, un meccanismo di monitoraggio elettronico. In questo modo, le organizzazioni possono controllare l'ingresso alle postazioni dei server e addirittura limitare l'accesso alle gabbie o ai singoli rack, a seconda di come sono strutturate le responsabilità di lavoro.
Ci sono alcuni fattori unici da considerare quando si pensa al furto e al danneggiamento fisico di un normale server ISA o di un server archivio di configurazione ISA. La natura delle informazioni che possono essere ottenute dal server rubato può compromettere potenzialmente tutti i server ISA e il traffico nel proprio ambiente (compreso il traffico crittografato).
Se si sospetta che un server sia stato compromesso, rubato o messo in qualche modo a repentaglio, rimuovere subito il server interessato (se è ancora presente nel sito) e seguire le procedure standard per la protezione delle prove. Dopo avere eseguito queste operazioni necessarie, si può avviare il processo di modifica di tutte le informazioni riservate: tutti i certificati installati sul server devono essere revocati e tutte le chiavi precondivise e i segreti condivisi devono essere modificati. Inoltre, se si dispone di una replica del server archivio di configurazione, assicurarsi che tutti i dati correlati al server compromesso vengano rimossi.
Dopo aver protetto fisicamente i server, l'operazione successiva consiste nel verificare che esista una metodologia strutturata per l'applicazione di patch a tutto il software, compresi il livello di virtualizzazione, il sistema operativo e le applicazioni. Le patch, le correzioni e gli aggiornamenti rapidi devono essere esaminati e applicati a intervalli regolari. Ma ricordarsi di testare questi aggiornamenti prima di applicarli ai sistemi di produzione. Una patch servirà infatti a poco se finisce col causare un problema che compromette l'integrità delle applicazioni o dei dati.
Se l'integrità dei dati è compromessa, sarà necessario ricorrere ai backup. Questo mi fa venire in mente un altro elemento importante nella protezione dell'infrastruttura. Se non si è in grado di ripristinare rapidamente tutti i dati nel caso in cui vi fosse bisogno, i tempi di inattività possono avere un impatto significativo sulle operazioni e, di conseguenza, il costo di un'intrusione aumenta notevolmente.
Altri due elementi da tenere in considerazione sono il monitoraggio e il controllo. Il monitoraggio delle applicazioni e dei sistemi ha moltissima importanza in qualsiasi piano di protezione valido. Se non si dedica tempo a esaminare i registri, soprattutto i registri relativi alla protezione, è improbabile che si riesca a individuare tentativi di intrusione prima che il danno sia già fatto.
Analogamente, il controllo è fondamentale. In molte organizzazioni, soprattutto nei grandi ambienti, il controllo è spesso ufficializzato ed è anche richiesto dalle leggi. Indipendentemente dalle dimensioni, in tutti gli ambienti è importante esaminare regolarmente i controlli e la metodologia utilizzata per la protezione delle risorse per garantire l'efficacia dei propri sforzi.
Infine, poiché ISA Server 2006 è installato su Windows Server® 2003, è importante rivedere la Guida alla protezione di Windows Server 2003 e adottare i suggerimenti ritenuti necessari. La Guida alla protezione di Windows Server 2003 è disponibile all'indirizzo microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/sgch00.mspx.
Al momento Microsoft consiglia di implementare il modello del criterio di protezione di base, ma non i filtri IPsec (Internet Protocol Security).

Impostazione di Configurazione guidata impostazioni di sicurezza
Ma come si può rendere ISA Server più sicuro? Lo strumento principale per la protezione di ISA Server è Configurazione guidata impostazioni di sicurezza. Si tratta di uno strumento che riduce la superficie di attacco del sistema. Crea criteri di protezione che agiscono sui servizi del server, la protezione della rete, il Registro di sistema e i criteri di controllo, configurando il sistema solamente per i servizi e le funzionalità richiesti. È importante osservare che sarebbe opportuno configurare solo quei servizi di ISA Server che si ha intenzione di utilizzare. Ad esempio, il servizio proxy Web è attivato per impostazione predefinita, ma si dovrebbe disattivare questa funzionalità se non si ha intenzione di utilizzarla. Di conseguenza, occorre prestare molta attenzione alle opzioni di configurazione presenti in Configurazione guidata impostazioni di sicurezza.
Configurazione guidata impostazioni di sicurezza non è installato per impostazione predefinita in Windows Server 2003, quindi la prima cosa da fare è installarlo utilizzando l'applet Installazione componenti di Windows® nel pannello di controllo Installazione applicazioni. Si noti che Configurazione guidata impostazioni di sicurezza è installato per impostazione predefinita in Windows Server 2008. Dopo avere caricato la schermata dei componenti di Windows, scorrere verso il basso e selezionare la casella Configurazione guidata impostazioni di sicurezza.
Al termine dell'installazione, l'applicazione è disponibile in Strumenti di amministrazione. Prima di iniziare a utilizzare Configurazione guidata impostazioni di sicurezza, è necessario aggiornarlo scaricando l'aggiornamento per ISA Server 2006 (disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=122532). Questo aggiornamento aggiunge i ruoli per ISA Server 2006 Standard Edition, ISA Server 2006 Enterprise Edition e ISA Server Configuration Storage Server.
Dopo aver scaricato l'aggiornamento, è necessario eseguire il pacchetto ed estrarne i file. Dopo aver estratto i file, copiare i due file xml (isa.xml e isaloc.xml) nella cartella kbs di Configurazione guidata impostazioni di sicurezza (in un'installazione predefinita di Windows Server, sarà c:\windows\security\msscw\kbs).
Durante la copia dei file, verrà richiesto di sovrascrivere due file esistenti con lo stesso nome. Questi due file sono utilizzati da ISA Server 2004, quindi bisognerebbe copiarli prima di sovrascriverli. L'ultima operazione da fare è copiare il file isascwhlp.dll nella cartella del cestino, che si trova generalmente in c:\windows\security\msscw\bin. Dopo aver aggiunto i ruoli ISA a Configurazione guidata impostazioni di sicurezza, si potrà avviare l'installazione.
In genere Microsoft consiglia di eseguire Configurazione guidata impostazioni di sicurezza solo dopo aver completato la configurazione di ISA Server. Se si ha Enterprise Edition, questa edizione contiene già la configurazione di tutti gli array e di tutti i membri array.

Esecuzione di Configurazione guidata impostazioni di sicurezza
La prima operazione da fare è avviare Configurazione guidata impostazioni di sicurezza da Strumenti di amministrazione (si tenga presente che sono necessarie autorizzazioni amministrative per completare la configurazione delle impostazioni di sicurezza).
La Figura 1 mostra la prima pagina della procedura guidata. Se si legge il testo di questa schermata, in modo particolare l'avviso che dice "Questa procedura guidata rileva le porte in ingresso su cui il server effettua l'ascolto", si può capire perché è importante che il server ISA e gli array siano completamente configurati prima dell'inizio di questo processo.
Figura 1 Avvio di Configurazione guidata impostazioni di sicurezza (fare clic sull'immagine per ingrandirla)
Se l'ambiente non è stato configurato integralmente, è molto probabile che si debba rivedere quanto selezionato in Configurazione guidata impostazioni di sicurezza dopo aver completato la configurazione del server ISA. Nella schermata successiva, mostrata in Figura 2, viene richiesto di scegliere l'azione da eseguire. Selezionare l'opzione Crea un nuovo criterio di protezione.
Figura 2 Creazione di un nuovo criterio di protezione (fare clic sull'immagine per ingrandirla)
Viene poi richiesto di selezionare il server che fungerà da base di riferimento per i criteri. Poiché si sta creando un criterio nuovo, la selezione predefinita è rappresentata dal computer su cui è in esecuzione Configurazione guidata impostazioni di sicurezza. Questa opzione predefinita può però cambiare a seconda dell'azione scelta nella schermata precedente. Nonostante ciò, si raccomanda vivamente di installare Configurazione guidata impostazioni di sicurezza sul server che verrà utilizzato come base di riferimento (procedura consigliata). Se Configurazione guidata impostazioni di sicurezza non è installato sul server di destinazione, mancheranno le informazioni necessarie a completare il criterio. Di conseguenza, per non complicarsi inutilmente la vita, installare ed eseguire Configurazione guidata impostazioni di sicurezza dal server che fungerà da base di riferimento.
Quando si sceglie Avanti, Configurazione guidata impostazioni di sicurezza avvierà l'analisi del server ISA. L'analisi includerà i ruoli determinanti che sono installati sul server, i ruoli che sono probabilmente installati sul server, i servizi installati e le informazioni di rete essenziali. Al termine dell'elaborazione, è possibile visualizzare il database scegliendo Visualizza il database di configurazione. Il database di configurazione contiene molte informazioni, compresi tutti i ruoli server supportati, le funzionalità client e le porte.
La procedura guidata avvia quindi l'analisi della Configurazione dei servizi in base ai ruoli. Scegliendo Avanti si passa alla schermata successiva, dove verrà richiesto di selezionare i ruoli server, come mostrato in Figura 3. Poiché l'analisi iniziale eseguita da Configurazione guidata impostazioni di sicurezza è affidabile, i ruoli server corretti dovrebbero essere già stati identificati. Tuttavia, è molto importante ricontrollarli ed eliminare tutti i ruoli inutili. E se il server svolge più ruoli, assicurarsi di aver selezionato tutti i ruoli appropriati.
Figura 3 Selezione dei ruoli server (fare clic sull'immagine per ingrandirla)
Un punto importante da ricordare quando si esegue ISA Server 2006 Enterprise Edition è che si deve considerare anche il server archivio di configurazione. Se il server archivio di configurazione è installato su un server che funge anche da server ISA (questa configurazione non è fra le procedure consigliate, ma la si implementa spesso), occorre controllare di aver selezionato anche il ruolo Server archivio di configurazione. È importante ricordarsi che non si dovrebbe utilizzare l'analisi di base di un server che ospita entrambi i ruoli per i server che hanno soltanto il ruolo ISA Server 2006.
Nella schermata successiva viene richiesto di selezionare le funzionalità client del server. In altre parole, occorre specificare i servizi richiesti dal server. Ad esempio, quasi tutti i server richiederanno il client DNS, e se un server è membro di un dominio, richiederà la funzionalità di membro di dominio.
Dopo aver selezionato le funzionalità, si apre la schermata Opzioni di amministrazione e altre opzioni. Qui occorre selezionare l'applicazione, l'amministrazione e le opzioni del sistema operativo che utilizzano i servizi o la connettività di rete. Tutti i servizi che non saranno selezionati qui risulteranno disattivati. Dopo avere effettuato le selezioni e aver fatto clic su Avanti, verrà richiesto di scegliere gli altri servizi che si desidera attivare.
Si passa poi alla schermata di configurazione dei servizi non specificati. Qui si può decidere cosa accade quando si individuano servizi che non sono contenuti nel database principale o installati sul server di riferimento al momento dell'applicazione dei criteri. In generale, una delle procedure consigliate suggerisce di disattivare i servizi non specificati perché così si limiteranno i potenziali vettori di attacco. Sfortunatamente questa opzione può avere conseguenze negative se i server sono molto dissimili; è necessario inoltre ricordarsi di questa impostazione se in futuro si aggiungono applicazioni o servizi di rete.
La sezione successiva della procedura guidata, mostrata in Figura 4, consente di riesaminare i servizi che vengono modificati da Configurazione guidata impostazioni di sicurezza. Questa schermata di conferma fornisce una vista che mette a confronto lo stato attuale e lo stato modificato dei servizi dopo l'applicazione dei criteri.
Figura 4 Revisione e conferma delle modifiche dei servizi (fare clic sull'immagine per ingrandirla)
Una volta confermati i servizi da modificare, si passa alla sezione Protezione di rete. Qui è possibile modificare le impostazioni di IPsec e del firewall di Windows. Poiché in questa sede si sta configurando ISA Server 2006, non si può far altro che tralasciare questa sezione, come illustrato in Figura 5.
Figura 5 Omissione delle impostazioni di Protezione di rete (fare clic sull'immagine per ingrandirla)
La procedura guidata passa poi alla configurazione delle impostazioni del Registro di sistema per i metodi di autenticazione di rete e la protezione. La prima schermata in questa sezione richiede la firma di SMB (Server Message Block). Il protocollo SMB è uno dei principali protocolli di rete Microsoft e queste impostazioni richiedono comunicazioni firmate per ridurre la probabilità di attacchi di intercettazione, quali quelli conosciuti in crittografia come "man in the middle".
Le impostazioni predefinite, come mostrato in Figura 6, assicurano un buon livello di protezione per le comunicazioni SMB del server ISA. Ma si deve tenere conto dell'impatto che la firma di tutte le comunicazioni avrà sul sistema. Se non si hanno a disposizione cicli della CPU di riserva, è opportuno deselezionare la seconda opzione. E bisogna ricordarsi di considerare tutti i server a cui questi criteri saranno applicati: se si hanno server con carichi di lavoro diversi, è necessario prendere come riferimento il server col più alto utilizzo della CPU per la selezione o la deselezione di questa opzione.
Figura 6 Specificare se si richiedono comunicazioni firmate (fare clic sull'immagine per ingrandirla)
Il gruppo successivo di schermate consente di definire il livello di compatibilità LM che ISA Server deve utilizzare. La prima di queste schermate contiene tre opzioni. A meno che non si abbiano client con versioni obsolete di Windows (come Windows 95 o Windows 98) o non si utilizzino account locali per il controllo dell'accesso, non modificare la selezione predefinita Account di dominio.
La seconda schermata relativa al livello di compatibilità LM consente di fornire informazioni sui controller di dominio in uso. Se non si ha nessun dominio Windows NT® 4.0, non modificare la selezione predefinita (Windows NT 4.0 Service Pack 6a o sistemi operativi successivi). In questa finestra di dialogo, occorre anche richiedere che gli orologi vengano sincronizzarti con l'opzione orologio del server selezionato. Fare clic su Avanti per passare alle altre opzioni di configurazione delle comunicazioni LM (LAN Manager) in ingresso, come mostrato in Figura 7.
Figura 7 Selezione dei metodi di autenticazione in ingresso (fare clic sull'immagine per ingrandirla)
Questa terza schermata relativa al livello di compatibilità LM serve a stabilire se è necessario Windows NT LAN Manager (NTLM) versione 2 e se gli hash LM sono stati memorizzati. Verificare che nessuna di queste opzioni sia selezionata (a condizione che il proprio ambiente supporti questa configurazione), perché la loro deselezione migliorerà considerevolmente la protezione. Si passa poi alla schermata Riepilogo impostazioni Registro di sistema. Esaminare ogni voce del registro e confermare che le impostazioni dei criteri sono corrette.
Si passa infine alla sezione finale, quella del Controllo. Un punto importante da tenere presente per tutte le opzioni di configurazione che si modificano in questa sezione è che non possono essere ripristinate. Ma poiché le opzioni di controllo non influiscono sulle funzionalità del sistema, è possibile effettuare delle scelte in questa sezione.
La selezione predefinita denominata "Controlla operazioni riuscite" non genera voci nel registro eventi per le operazioni di accesso non riuscite. Ma le informazioni sulle operazioni di accesso non riuscite possono offrire informazioni preziose sui tentativi di intrusione. Si consiglia quindi di selezionare "Controlla operazioni riuscite e non riuscite" (procedura consigliata).
Una volta esaminata la configurazione di controllo, fare clic due volte su Avanti per salvare i criteri di protezione. Nella schermata risultante, mostrata in Figura 8, è necessario specificare un nome file, ma è anche possibile fornire una breve descrizione. La descrizione può risultare utile nei grandi ambienti dove diversi amministratori condividono le responsabilità di protezione.
Figura 8 Immissione di un nome e di una descrizione per i criteri di protezione (fare clic sull'immagine per ingrandirla)
Dopo aver salvato il file, si può decidere se applicare i criteri immediatamente o in seguito. Se si sceglie di applicarli in un secondo momento, il processo è terminato. Se ci si rende conto di aver commesso errori nella configurazione dei criteri, è possibile eseguire il rollback dei criteri, ad eccezione delle impostazioni di controllo.

Ruoli amministrativi
Ridurre la superficie di attacco di ISA Server è un'operazione molto importante ai fini della riduzione delle possibili violazioni della sicurezza da parte di fonti esterne. Tuttavia, è altrettanto importante rivedere l'assegnazione dei ruoli amministrativi all'interno di ISA Server per limitare possibili compromessi da parte di fonti interne. I ruoli amministrativi e un elenco parziale delle attività comuni sono riportati nelle figure 9 e 10.
Figura 9 Ruoli e attività associati a Standard Edition
Attività | Revisore di monitoraggio | Revisore | Amministratore completo
Visualizzazione del pannello personale (o dashboard), avvisi, connettività, sessioni e servizi | Consentita | Consentita | Consentita
Conferma degli avvisi | Consentita | Consentita | Consentita
Visualizzazione delle informazioni di registro | – | Consentita | Consentita
Creazione di definizioni di avviso | – | – | Consentita
Creazione di report | – | Consentita | Consentita
Arresto e avvio di sessioni e servizi | – | Consentita | Consentita
Visualizzazione dei criteri firewall | – | Consentita | Consentita
Configurazione dei criteri firewall | – | – | Consentita
Configurazione della cache | – | – | Consentita
Configurazione di una rete privata virtuale (VPN) | – | – | Consentita
Figura 10 Ruoli e attività associati a Enterprise Edition
Attività | Revisore di monitoraggio dell'array | Revisore dell'array | Amministratore dell'array
Visualizzazione del pannello personale (o dashboard), avvisi, connettività e sessioni | Consentita | Consentita | Consentita
Conferma e reimpostazione degli avvisi | Consentita | Consentita | Consentita
Visualizzazione delle informazioni di registro | – | Consentita | Consentita
Creazione di definizioni di avviso | – | - | Consentita
Creazione di report | – | Consentita | Consentita
Arresto e avvio di sessioni e servizi | – | Consentita | Consentita
Visualizzazione dei criteri firewall | – | Consentita | Consentita
Configurazione dei criteri firewall | – | – | Consentita
Configurazione della cache | – | – | Consentita
Configurazione di una rete privata virtuale (VPN) | – | – | Consentita
Esecuzione dello svuotamento/arresto di NLB | – | Consentita | Consentita
Visualizzazione della configurazione locale (nel registro del membro array) | – | Consentita | Consentita
Modifica della configurazione locale (nel registro del membro array) | – | – | –
Come si può vedere, c'è un alto grado di segmentazione nelle attività amministrative associate a ISA Server, il che dovrebbe rendere più semplice l'assegnazione dei ruoli appropriati agli utenti all'interno dell'organizzazione.
Oltre a ciò, occorre tenere presente che l'approccio migliore nell'assegnazione dei ruoli è l'uso del concetto del privilegio minimo. Ogni utente dovrebbe cioè avere la minore quantità di privilegi necessaria per consentirgli di svolgere il proprio lavoro.
È anche importante ricordare che i membri del gruppo Administrators locale di ISA Server 2006 Standard Edition hanno gli stessi diritti di un amministratore completo di ISA Server. In Enterprise Edition, i membri del gruppo Administrators locale sul server che svolge il ruolo di server archivio di configurazione hanno il controllo completo sulla configurazione di Enterprise. Ciò significa che occorre esaminare attentamente l'appartenenza al gruppo Domain Admins (se il proprio server ISA è membro di un dominio), come pure a qualsiasi altro gruppo che sia membro del gruppo Administrators locale di ISA Server.

Alan Maddison è Senior Consultant presso Strategic Business Systems, una divisione di Brocade, ed è specializzato in tecnologie Microsoft.


ISA Server
Miglioramento della protezione del gateway di Servizi terminal con ISA Server 2006
Dott. Thomas W. Shinder e Yuri Diogenes
Panoramica:
  • Due scenari in cui il gateway di Servizi terminal è utilizzato con ISA Server
  • Configurazione di ISA Server 2006
  • Verifica e monitoraggio

Indice
Oltre il perimetro
Primo scenario
Configurazione di ISA Server 2006
Verifica e monitoraggio dell'accesso client
Monitoraggio mediante ISA Server
Secondo scenario
Considerazioni sul client
Conclusioni
In seguito al successo di Outlook via Internet in Exchange Server 2007, anche Windows Server 2008 rende disponibile una funzionalità che consente di accedere al proprio desktop da qualsiasi luogo in modo sicuro e controllato.
Il nuovo servizio gateway di Terminal Server in Windows Server® 2008 offre la flessibilità dei servizi Terminal Server di Windows®, oltre alla possibilità di collegarsi a un server terminal da qualsiasi luogo mediante una connessione HTTP. Questo servizio utilizza il protocollo RDP (Remote Desktop Protocol) su HTTPS (SSL) per aumentare la protezione, fornendo al contempo un'unica interfaccia client per l'accesso alle risorse di Servizi terminal.
Il nuovo servizio gateway offre notevoli vantaggi a coloro che devono accedere al computer in modalità remota:
  • Non è necessario stabilire una sessione di rete privata virtuale (VPN) prima di connettersi a risorse interne utilizzando RDP.
  • La protezione è ottimizzata grazie all'utilizzo di Protezione accesso alla rete (NAP, Network Access Protection) e di verifiche dell'integrità della protezione Windows per controllare le connessioni RDP.
  • Non è necessario aprire la porta TCP 3389 in ingresso per consentire pubblicazioni Web più sicure attraverso i firewall.
È possibile utilizzare Microsoft® Internet Security and Acceleration (ISA) Server 2006 per migliorare la protezione del servizio gateway di Servizi terminal, consentendo contemporaneamente accesso esterno alle risorse interne. È possibile configurare uno scenario di bridging da SSL a SSL in cui ISA Server 2006 riceve richieste e le trasferisce al gateway di Servizi terminal interno, utilizzando inoltre l'HTTPS. Mentre esegue il bridging della richiesta, il firewall ISA decrittografa le comunicazioni SSL ed esegue un'ispezione a livello di applicazione.
Se il flusso del protocollo HTTP supera l'ispezione, la comunicazione viene nuovamente crittografata e inoltrata al proxy di Servizi terminal. Se il flusso del protocollo non supera l'ispezione, la connessione viene annullata.

Oltre il perimetro
Microsoft ha investito molto nella protezione e, al momento, Windows Server 2008 è la versione più sicura e affidabile di Windows. Tuttavia, l'azienda si interessa anche delle modalità in cui gli utenti implementeranno i prodotti e vorrebbe che si attenessero alle procedure consigliate per mantenere gli ambienti sicuri. Le procedure consigliate richiedono un'azione di difesa totale, in modo da garantire protezione in più punti di accesso o livelli. In questo caso, i livelli a cui si fa riferimento sono costituiti da criteri, procedure e informazioni sulla presenza, perimetro, rete interna e host.
Quando si consente a utenti esterni di accedere a una risorsa interna mediante ISA Server, è opportuno comprendere i limiti di tutti i prodotti interessati. ISA Server 2006 e il gateway di Servizi terminal forniranno protezione a livello di perimetro, ma per le risorse interne occorre definire criteri per consentire o negare l'accesso a seconda delle esigenze. I Servizi di accesso e criteri di rete (NPAS, Network Policy and Access Services) consentono di raggiungere tale obiettivo, operando a livello di criteri, procedure e informazioni sulla presenza. L'accesso alle risorse interne (unità, appunti, stampanti e così via) è definito dai criteri di autorizzazione delle risorse di Servizi terminal, che si riferiscono al livello della rete interna.
In questo articolo esaminerò dapprima la modalità di pubblicazione del gateway di Servizi terminal tramite ISA Server 2006. Successivamente amplierò lo scenario di pubblicazione di ISA Server 2006, includendo l'imposizione dell'integrità dei client tramite l'utilizzo di Protezione accesso alla rete. Quest'ultima consente di creare criteri di integrità client per controllare l'accesso al livello host.

Primo scenario
L'obiettivo è illustrare la modalità di pubblicazione del gateway di Servizi terminal tramite ISA Server 2006. Nella figura 1 è presente un riepilogo dei computer e del flusso di dati durante la connessione. In questo scenario, viene implementato il ruolo Server dei criteri di rete (NPS) sul gateway di Servizi terminal stesso. Tuttavia, nel secondo scenario la situazione verrà modificata e verrà utilizzato un Server dei criteri di rete centrale. Esaminare la sequenza riportata di seguito per comprendere come avvengono le comunicazioni fra i componenti della soluzione di pubblicazione del gateway di Servizi terminal:
Figura 1 Pubblicazione del gateway di Servizi terminal tramite ISA Server 2006 (fare clic sull'immagine per ingrandirla)
  1. L'utente RDP esterno avvia la connessione. La prima operazione che il client deve eseguire è risolvere il nome esterno del gateway di Servizi terminal (in questo caso, tsg.contoso.com). Il DNS esterno risolve questo nome, che indica l'indirizzo IP esterno di ISA Server.
  2. Viene stabilito un tunnel SSL tra il client RDP e l'interfaccia esterna di ISA Server. ISA Server dispone di una regola di pubblicazione sul Web sulla porta TCP 443, che utilizza un certificato rilasciato a tsg.contoso.com.
  3. Dopo aver valutato la regola e verificato che il traffico sia consentito, ISA Server invierà una query DNS al server DNS interno (situato sul controller di dominio) per risolvere il nome del server specificato nella regola di pubblicazione sul Web.
  4. Quindi, ISA Server apre un tunnel SSL verso il gateway di Servizi terminal, trasferendovi la richiesta di autenticazione.
  5. Il server gateway di Servizi terminal convalida le credenziali dell'utente e verifica che questo sia autorizzato a stabilire la connessione.
  6. Dopo aver definito che l'utente è autorizzato a stabilire la connessione, il servizio gateway di Servizi terminal riceve le richieste sulla porta TCP 443 e inoltra i pacchetti RDP tramite la porta TCP 3389 (per impostazione predefinita) al Server terminal interno in cui risiede l'applicazione (ad esempio, un'applicazione CRM).
Da questo punto in poi, tutti i pacchetti inviati dal client RDP al servizio gateway di Servizi terminal tramite ISA Server saranno inoltrati al Server terminal interno e viceversa.
È importante ricordare che l'RDP su HTTPS in realtà non è nient'altro che un RDP/RPC/HTTPS. Il client RDP incapsula le comunicazioni RDP in un'intestazione RPC, che è a sua volta incapsulata in un'intestazione HTTP protetta tramite SSL (o TLS, Transport Level Security). In questo caso, tutti i componenti necessari per una soluzione RPC su HTTPS devono essere presenti. È questa la ragione per cui, quando si installa il servizio del ruolo Gateway di Servizi terminal, viene automaticamente installato il proxy RPC su HTTP. Per comprendere in modo più approfondito come opera questo protocollo, si consiglia di leggere l'articolo "Esecuzione di un test di RPC su HTTP tramite ISA Server 2006 Part 1; protocolli, autenticazione e elaborazione" presente sul blog del team di ISA Server (disponibile all'indirizzo blogs.technet.com/isablog).
Per questa implementazione è necessario Windows Server 2008 con il gateway di Servizi terminal installato e tale funzionalità dipende dal proxy RPC su HTTP. Affinché la funzionalità RDP sul proxy RPC su HTTP funzioni correttamente, Internet Information Services (IIS) 7.0 deve essere installato e in esecuzione. È inoltre necessaria la funzionalità Servizi di accesso e criteri di rete. Tuttavia, se si preferisce, è possibile configurare il gateway di Servizi terminal affinché utilizzi il server dei criteri di rete, in precedenza noto come Servizio autenticazione Internet (IAS, Internet Authentication Service), per centralizzare le operazioni di memorizzazione, gestione e convalida dei criteri di autorizzazione delle connessioni di Servizi terminal. Infine, se non si dispone di un certificato SSL per il server gateway di Servizi terminal, è necessario ottenerlo. È importante sottolineare che ISA Server 2006 deve considerare attendibile l'autorità di certificazione che rilascia il certificato. Accertarsi pertanto di importare il certificato nell'archivio delle autorità di certificazione affidabili.
Lo strumento Servizi di dominio Active Directory® è necessario solo se si configurano criteri di autorizzazione del gateway di Servizi terminal in base ai quali gli utenti devono essere membri di un gruppo di protezione Active Directory per connettersi al server gateway. Per questa configurazione specifica, verrà utilizzato Active Directory su un computer che esegue Windows Server 2003 SP2.
Una volta terminata l'installazione del gateway di Servizi terminal, verrà visualizzata la schermata mostrata nella figura 2, che mostra i componenti che sono stati installati. Per connettere il gateway di Servizi terminal, i client devono essere eseguiti su uno dei sistemi operativi riportati di seguito: Windows Vista®, Windows XP con SP2 e RDP 6.0 o successivo, Windows Server 2008, Windows Server 2003 con SP1 o successivo e RDP 6.0 o successivo. Per ulteriori informazioni sulla configurazione del gateway di Servizi terminal, consultare la guida dettagliata relativa all'installazione in Windows Server 2008, disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=122251. Ora spiegherò come configurare ISA Server 2006.
Figura 2 Riepilogo dell'installazione del gateway di Servizi terminal (fare clic sull'immagine per ingrandirla)

Configurazione di ISA Server 2006
La prima operazione consiste nella creazione di un listener Web che gestisca le richieste provenienti dal client RDP esterno. Il listener Web deve avere i seguenti parametri:
  • Autenticazione: base
  • Convalida autenticazione: Windows (Active Directory)
  • Connessioni: abilitare le connessioni SSL (HTTPS) sulla porta 443
  • Certificati: certificato rilasciato a tsg.contoso.com
  • Reti: esterne
Successivamente, occorre creare la regola di pubblicazione sul Web. Per ISA Server 2006, il client RDP utilizzerà lo stesso protocollo usato da Outlook® via Internet, quindi selezionare la procedura guidata di Exchange Server 2007. Procedere come descritto di seguito:
  1. Fare clic con il pulsante destro del mouse su Criterio firewall, selezionare Nuovo, quindi fare clic su Regola di pubblicazione accesso client Web Exchange.
  2. Nella pagina Creazione guidata regola di pubblicazione sul Web, immettere il nome della regola, quindi fare clic su Avanti.
  3. Nella pagina Seleziona azione regola, selezionare l'opzione Consenti, quindi fare clic su Avanti.
  4. Nella pagina Creazione guidata regola di pubblicazione Exchange, selezionare la versione di Exchange, in questo caso Exchange Server 2007, quindi Outlook Anywhere (RPC/HTTP(s)) e fare clic su Avanti. (Nota: non selezionare l'opzione Pubblica cartelle aggiuntive nei client del server Exchange per Outlook 2007).
  5. Nella pagina Tipo di pubblicazione, selezionare l'opzione Pubblica un singolo sito Web o un sistema di bilanciamento del carico, quindi fare clic su Avanti.
  6. Nella pagina Protezione connessione server, selezionare Utilizzare SSL per connettersi al server Web pubblicato o alla server farm, quindi fare clic su Avanti.
  7. Nella pagina Dettagli pubblicazione interna, all'interno della casella Nome sito interno, immettere il nome del server gateway di Servizi terminal. Selezionare la casella di controllo Utilizza nome computer o indirizzo IP per la connessione al server pubblicato, quindi immettere il nome del server nella casella Indirizzo IP o nome computer. Se non si conosce il nome del server gateway di Servizi terminal, fare clic su Sfoglia per ricercarne la posizione. Il nome utilizzato su questa pagina deve corrispondere al nome soggetto o al nome comune presente nel certificato del sito Web collegato al sito del gateway di Servizi terminal.
  8. Nella pagina Dettagli nome pubblico, dall'elenco a discesa Accetta richieste per, selezionare Questo nome dominio (immettere di seguito). Quindi, nella casella Nome pubblico, immettere il nome pubblico corrispondente al nome del certificato rilasciato per questo URL (in questo caso, il nome era tsg.contoso.com.). Fare clic su Avanti.
  9. Nella pagina Scegliere Listener Web, fare clic sull'elenco a discesa e selezionare il listener Web creato in precedenza, quindi fare clic su Avanti.
Nella pagina Delega autenticazione, selezionare l'opzione Nessuna delega, ma il client può eseguire l'autenticazione direttamente, quindi fare clic su Avanti.
Nella pagina Gruppo di utenti, verificare che sia selezionata l'opzione predefinita (Tutti gli utenti), fare clic su Avanti, quindi su Fine e applicare le impostazioni.
Facendo doppio clic sulla regola e selezionando la scheda relativa al percorso, si noterà che l'unico percorso presente è /rpc/*. Questo è dovuto al fatto che è stata utilizzata la procedura guidata di Outlook via Internet di Exchange Server 2007.

Verifica e monitoraggio dell'accesso client
Come detto in precedenza, per la connessione al gateway di Servizi terminal è necessario un client RDP 6.0 o successivo. Per configurare l'applicazione del client RDP, avviarla e immettere il nome del Server terminal al quale si desidera eseguire la connessione nel campo Computer. Fare clic sul pulsante Opzioni, sulla scheda Avanzate, quindi su Impostazioni e immettere il nome esterno del server gateway di Servizi terminal, come illustrato nella figura 3. In questo esempio, si tratta del nome presente sul certificato legato al listener Web utilizzato dalla regola di pubblicazione sul Web per accettare le richieste in arrivo. Nell'esempio, viene utilizzata l'autenticazione NT® LAN Manager di Windows. Una volta terminata l'operazione, fare clic su OK, quindi su Connetti. Verrà visualizzata una richiesta di autenticazione. Immettere le credenziali di un utente con accesso al Server terminal, quindi fare clic su OK.
Figura 3 Configurazione del client RDP (fare clic sull'immagine per ingrandirla)
Nel client RDP 6.0 (per Windows XP e Windows Server 2003) verrà visualizzata la schermata mostrata nella figura 3. L'autenticazione sarà richiesta due volte: la prima è per il computer del gateway di Servizi terminal, mentre la seconda è per il Server terminal al quale si desidera accedere. Si tratta di un'informazione importante, in quanto, sebbene si potrebbe pensare che la richiesta sia dovuta alla configurazione di ISA Server, in realtà ISA Server non si occupa affatto dell'autenticazione perché la regola di pubblicazione sul Web viene applicata a tutti gli utenti, il che consente connessioni anonime attraverso il firewall ISA.
Il client RDP fornito con Windows Server 2008 dispone dell'opzione Usa credenziali del gateway di Servizi terminal per il computer remoto, come illustrato nella figura 4. Selezionando questa opzione, non è necessario immettere le credenziali due volte, garantendo una migliore esperienza utente. Questa opzione di accesso singolo è disponibile anche in Windows Vista dopo l'applicazione del SP1.
Figura 4 Il client RDP di Windows Server 2008 (fare clic sull'immagine per ingrandirla)
Utilizzando l'opzione Monitoraggio, è possibile monitorare la connessione tramite Gestione gateway di Servizi terminal. Il servizio gateway di Servizi terminal fornisce inoltre informazioni dettagliate quando un utente non autorizzato tenta di connettersi al server. Nella figura 5, il Visualizzatore eventi mostra un tentativo di connessione da parte di un utente che non dispone dell'autorizzazione necessaria per collegarsi tramite il gateway di Servizi terminal.
Figura 5 Evento registrato nel servizio gateway di Servizi terminal (fare clic sull'immagine per ingrandirla)
Per questo evento viene registrato l'indirizzo IP interno di ISA Server 2006, poiché nella regola di pubblicazione sul Web è selezionata l'opzione Le richieste sembrano provenire dal computer ISA Server. Per registrare l'indirizzo IP del client originale, occorre modificare la regola di pubblicazione sul Web di ISA Server 2006 e selezionare l'opzione Le richieste sembrano provenire dal client originale nella scheda A.

Monitoraggio mediante ISA Server
Utilizzando le nuove funzionalità di ISA Server 2006 Supportability Pack, è possibile esaminare nei dettagli e comprendere tutte le connessioni alla rete interna. Nella figura 6 è presente una connessione evidenziata e, sulla riga Request: il verbo RPC_IN_DATA indica l'URL per il proxy RPC su HTTP.
Figura 6 Registrazione di ISA Server 2006 mediante l'aggiornamento Supportability Pack (fare clic sull'immagine per ingrandirla)
Continuando a osservare la registrazione, sarà possibile visualizzare l'altro verbo RPC su HTTP, RPC_OUT_DATA. È importante conoscere i metodi HTTP utilizzati, ossia RPC_IN_DATA e RPC_OUT_DATA per RDP/HTTP, perché se il filtro HTTP è configurato per bloccare tali metodi, il traffico su ISA Server verrà bloccato. Per bloccare l'ambiente in uso, è possibile configurare la regola di pubblicazione sul Web RDP/HTTP in modo che consenta solo questi due metodi. Per ulteriori informazioni sui metodi HTTP utilizzati in genere per le pubblicazioni, consultare l'articolo relativo ai filtri HTTP in ISA Server 2004, disponibile all'indirizzo technet.microsoft.com/library/cc302627.

Secondo scenario
Per questo scenario, il gateway di Servizi terminal utilizzerà un criterio NPS centrale situato su un altro server. Verrà imposto un criterio di Protezione accesso alla rete per i client che si connettono in modalità remota tramite il gateway di Servizi terminal. In questo caso, saranno utilizzati gli stessi componenti usati nello scenario 1, aggiungendo unicamente il server dei criteri di rete. Tuttavia, a causa dell'imposizione di Protezione accesso alla rete, sarà utilizzato un numero superiore di componenti sul lato client, come illustrato nella figura 7.
Figura 7 Componenti principali della topologia dello scenario 2 (fare clic sull'immagine per ingrandirla)
Di seguito è riportata una spiegazione dei singoli componenti. Sul client Windows Vista, l'Agente integrità sistema (SHA) è costituito da componenti sul lato client responsabili del monitoraggio e della segnalazione dello stato di integrità del client stesso. Windows Vista dispone dell'Agente integrità sistema Windows, ma altre aziende stanno lavorando alla creazione di propri agenti.
Quando il client tenta di accedere alla rete, l'Agente Protezione accesso alla rete (Agente NAP) presente sul client deve stabilire la comunicazione con il server di imposizione Protezione accesso alla rete. L'Agente Protezione accesso alla rete invia a questo server il rapporto di integrità del client.
Sul gateway di Servizi terminal, il criterio di autorizzazione delle risorse di Servizi terminal (TS RAP) è il componente che consente di determinare quali computer saranno disponibili per la ricezione di richieste RDP in ingresso. Il criterio di autorizzazione delle risorse di Servizi terminal determina inoltre a utenti possono stabilire connessioni RDP a server specifici.
Il Server dei criteri di rete centrale deve controllare condizioni, vincoli e impostazioni che regolano l'accesso ai computer interni. Le istanze di Convalida integrità di sistema (SHV) sul Server dei criteri di rete centrale devono valutare se il rapporto di integrità inviato dal client è conforme ai criteri definiti dall'amministratore.
Ora si modifichi il gateway di Servizi terminal affinché faccia riferimento a un Server dei criteri di rete centrale. Aprire la console di gestione del gateway di Servizi terminal, fare clic con il pulsante destro del mouse sul nome del server, quindi selezionare l'opzione Proprietà. Nella finestra relativa alle proprietà del server, fare clic sulla scheda Archivio criteri di autorizzazione delle connessioni di Servizi terminal, quindi selezionare Server dei criteri di rete centrale. Immettere il nome o l'indirizzo IP del server dei criteri di rete e fare clic sul pulsante Aggiungi. Verrà visualizzata la finestra Segreto condiviso. Immettere il segreto, fare clic su OK, quindi fare nuovamente clic su OK per chiudere la finestra. È necessario memorizzare questo segreto, poiché sarà utilizzato sul server dei criteri di rete.
Se il server dei criteri di rete è già installato su un altro server, attenersi alla procedura seguente:
  1. Aprire la console Server dei criteri di rete e, nel riquadro di sinistra, fare clic su Server dei criteri di rete (locale).
  2. Nel riquadro di destra, fare clic su Configurazione Protezione accesso alla rete. Verrà visualizzata la pagina Selezione del metodo di connessione alla rete da utilizzare con Protezione accesso alla rete.
  3. In Metodo di connessione alla rete, selezionare Gateway di Servizi terminal dall'elenco a discesa, quindi fare clic su Avanti.
  4. Nella pagina Specifica server di imposizione Protezione accesso alla rete che eseguono Gateway di Servizi terminal, fare clic sul pulsante Aggiungi.
  5. Nella finestra Nuovo server gateway di Servizi terminal, immettere il nome descrittivo e l'indirizzo IP del server gateway di Servizi terminal. Nella parte inferiore della finestra, immettere il segreto condiviso, utilizzando lo stesso segreto presente nella configurazione del server gateway di Servizi terminal. Quindi fare clic su OK.
  6. Nella pagina Configura reindirizzamento dispositivi client e metodi di autenticazione, è possibile specificare quali dispositivi saranno reindirizzati e il metodo di autenticazione consentito (password o smart card). Ai fini di questo esempio, lasciare inalterate le opzioni predefinite e fare clic su Avanti.
  7. Nella pagina Configurazione gruppi di utenti o di computer, aggiungere il gruppo di utenti al quale è consentito stabilire la connessione. In questo esempio, fare clic sul pulsante Aggiungi utenti in Gruppi di utenti (obbligatorio) e selezionare Domain Admins. Fare clic su OK, quindi su Avanti.
  8. Nella pagina Definizione criterio di integrità di Protezione accesso alla rete, si noterà che è già selezionata l'istanza di Convalida integrità di sistema predefinita. Si noti inoltre, nella parte inferiore di questa pagina, che ai computer non conformi è negato l'accesso. Lasciare inalterate le impostazioni predefinite e fare clic su Avanti.
  9. Nella pagina Completamento criteri di imposizione Protezione accesso alla rete e configurazione client RADIUS, riesaminare le opzioni selezionate in precedenza. Inoltre, se si fa clic sul collegamento ipertestuale Dettagli configurazione, verrà visualizzata una pagina HTML con un riepilogo delle selezioni effettuate. Al termine della revisione, fare clic su Fine.
Questa procedura guidata consente di configurare le impostazioni per numerosi criteri importanti (criteri di richiesta connessione, di rete e di integrità), il che riduce in modo significativo le operazioni necessarie per configurare la Protezione accesso alla rete per questo scenario.

Considerazioni sul client
Ora che il server è installato e configurato correttamente, è opportuno esaminare le operazioni necessarie per il client.
Per poter sfruttare i criteri di imposizione di Protezione accesso alla rete, il client deve eseguire Windows Server 2008 o Windows Vista. Per Windows XP, è necessario aver installato SP3, che include il client di Protezione accesso alla rete.
Oltre ai requisiti relativi al sistema operativo, esistono servizi e impostazioni che è necessario abilitare sul lato client. Di seguito ne vengono riportati alcuni:
  • Aggiunta del nome del server gateway di Servizi terminal all'elenco dei server trusted sul client.
  • Avvio del servizio Agente Protezione accesso alla rete e impostazione del tipo di avvio del servizio su Automatico.
  • Attivazione del client imposizione quarantena del gateway di Servizi terminal.
Al fine di semplificare l'implementazione di questa soluzione, Microsoft ha creato il comando per la configurazione client di Protezione accesso alla rete di Servizi terminal (Tsgqecclientconfig.cmd), che è possibile scaricare dalla pagina go.microsoft.com/fwlink/?LinkId=122267. Dopo aver eseguito il comando, il client sarà configurato come client di imposizione Protezione accesso alla rete per il gateway di Servizi terminal. Si tenga presente che il comando deve essere eseguito con privilegi elevati.
L'obiettivo principale di questo articolo è stato non solo descrivere la nuova funzionalità gateway di Servizi terminal disponibile in Windows Server 2008 e spiegare come pubblicarla in modo sicuro tramite ISA Server 2006, ma anche fornire una panoramica sui vantaggi di protezione che la combinazione di questi due prodotti può fornire alle aziende.
Oggigiorno, potersi connettere da qualsiasi luogo è un requisito fondamentale per qualsiasi azienda di successo. Tuttavia, è anche necessario che tale connettività non impedisca di offrire un'esperienza ottimale all'utente e, cosa più importante, è essenziale che le modalità di connessione garantiscano la massima protezione.

Il Dott. Thomas W. Shinder ha ottenuto le qualifiche di MCSE e MVP per ISA Server. Lavora come docente, scrittore e consulente nel campo della tecnologia informatica dal 1996 ed è autore di sei libri sul firewall ISA. È inoltre leader di riferimento e principale sostenitore di ISAserver.org, la più grande community di amministratori e appassionati del firewall ISA su Internet.

Yuri Diogenes, MCSE+S, MCTS, MCITP, Security+, Network+ e CCNP, è Security Support Engineer all'interno del team di Microsoft ISA Server/IAG. Scrive articoli per Microsoft TechNet Library e sul blog del team di ISA Server. Yuri lavora con la tecnologia Microsoft dal 1993. Prima dell'assunzione presso Microsoft, ha lavorato come docente, support analyst e consulente Microsoft.


IIS 7.0
I 10 miglioramenti principali delle prestazioni in IIS 7.0
Mike Volodarsky
Panoramica:
  • Riduzione al minimo del footprint dell'applicazione
  • Riduzione dei costi di larghezza di banda
  • Utilizzo di funzionalità avanzate di memorizzazione nella cache

Indice
Server Web più snelli
Costruzione su un sistema operativo snello
Topologie specializzate delle applicazioni
Supporto migliorato delle applicazioni
Aumento della densità delle applicazioni
Riduzione della larghezza di banda con la compressione
Limitazione della velocità in bit per contenuti multimediali
Cache di output
Conversione di codice ISAPI in moduli IIS 7.0
Estendibilità del server
Conclusioni
Quando incontro delle aziende che stanno pensando di adottare IIS 7.0, una domanda che inevitabilmente si pone è se il passaggio a IIS 7.0 migliorerà le prestazioni dei server e delle applicazioni. La
risposta è generalmente sì, tuttavia non c'è da stupirsi se all'inizio non si riscontrano miglioramenti delle prestazioni quando si esegue la migrazione delle applicazioni a IIS 7.0.
Per capire questo fenomeno, è necessario comprendere la natura dell'ultima versione. IIS 6.0 era una versione di progettazione con tre obiettivi principali: miglioramento della sicurezza, maggiore affidabilità e prestazioni ottimizzate. IIS 7.0 è invece una versione per piattaforma, il cui scopo consiste nel convertire gli eccellenti componenti di base del server Web (server core) della versione precedente in una piattaforma modulare ed espandibile che supporti i principali scenari attuali di distribuzione e gestione.
Molte delle modifiche architettoniche e delle nuove funzionalità potrebbero avere in realtà un impatto negativo sulle prestazioni del server Web — considerando, ad esempio, che una delle modifiche principali consiste nella "scomposizione" di percorsi di codice server Web altamente ottimizzati in moduli autonomi che non ricevono nessun trattamento speciale dal server Web. Tuttavia, grazie al duro lavoro sulle prestazioni eseguito dal team di IIS, IIS 7.0 mantiene le prestazioni allo stesso livello della versione precedente e in alcuni casi le supera. Come posso testimoniare personalmente avendo lavorato sui componenti di base del server Web e sulla pipeline integrata, questo risultato ha richiesto molta creatività nella progettazione e un grosso impegno nell'implementazione del prodotto.
Ciò nonostante, IIS 7.0 ha potenzialità molto più alte di produrre miglioramenti significativi delle prestazioni e di ridurre i costi associati alle prestazioni della server farm rispetto a qualsiasi altra versione precedente di IIS.
Non è detto che questi vantaggi siano visibili semplicemente eseguendo la migrazione a IIS 7.0, tuttavia in alcuni ambienti questo potrebbe verificarsi. Ad esempio, Microsoft.com ha rilevato un miglioramento del 10% nell'efficienza della CPU (è possibile consultare l'analisi completa sul blog del team di Microsoft.com alla pagina go.microsoft.com/fwlink/?LinkId=122497). È anche possibile rilevare dei miglioramenti notevoli in aree specifiche, compresi Secure Sockets Layer (SSL) e l'autenticazione Windows® (entrambi eseguiti nel kernel) e una migliore scalabilità verticale nei computer multiprocessore e multicore.
Tuttavia, la vera forza di IIS 7.0 non deriva dai miglioramenti incrementali delle prestazioni apportati alle funzionalità esistenti. I miglioramenti derivano invece dalle nuove funzionalità, che occorre utilizzare attivamente. Queste si basano sulla flessibilità, sulla natura espandibile della piattaforma e sulle nuove caratteristiche di prestazioni. In questo articolo desidero illustrare i 10 più importanti miglioramenti delle prestazioni che è possibile ottenere passando a IIS 7.0.

Server Web più snelli
La capacità di distribuire server IIS 7.0 snelli deriva dall'architettura modulare del server. In pratica, tutte le funzionalità del server Web vengono implementate come componenti modulari che possono essere aggiunti o rimossi singolarmente. In questo modo, è possibile rimuovere le funzionalità del server che non sono necessarie per il funzionamento di un'applicazione apportando vantaggi notevoli, ad esempio una superficie di attacco considerevolmente ridotta, un footprint operativo inferiore e prestazioni migliorate.
La funzionalità server Web completa di IIS 7.0 comprende 44 moduli, tra cui moduli IIS nativi e moduli ASP.NET che forniscono servizi per la pipeline integrata. Questi moduli offrono servizi come l'autenticazione (moduli Autenticazione Windows e Autenticazione digest), il supporto per il framework applicazione (modulo FastCGI), i servizi applicazione (modulo Stato sessione), la protezione (modulo Filtro richieste) e le prestazioni (modulo Cache di output). A prescindere dal numero di moduli disponibili, un server Web minimo che gestisce solamente contenuto statico può essere operativo con appena 2 moduli!
I moduli non necessari potrebbero causare un overhead notevole, ad esempio quando si eseguono operazioni di registrazione delle richieste e analisi delle richieste non riuscite. La rimozione di tali moduli negli ambienti in cui non sono richiesti può comportare un aumento della velocità effettiva e risposte più rapide che abbassano i criteri di misurazione tempo di ricezione primo byte (TTFB, time to first byte) e tempo di ricezione ultimo byte (TTLB, time to last byte) per il carico di lavoro del server.
La Figura 1 illustra i risultati di un semplice test sulla velocità effettiva di un file HTML (carico di lavoro statico) e di una pagina ASP.NET Hello World (carico di lavoro ASP.NET) quando si utilizza una configurazione contenente il set completo di funzionalità, il set predefinito di funzionalità per quel particolare carico di lavoro e il set di funzionalità minimo necessario per il carico di lavoro. Anche se la maggior parte delle funzionalità non essenziali è già disattivata nella configurazione completa, la loro rimozione completa nella configurazione minima comporta un aumento notevole della velocità effettiva sia per il carico di lavoro statico che per il carico di lavoro ASP.NET.
Figura 1 Valori della velocità effettiva del carico di lavoro statico e del carico di lavoro ASP.NET nelle tre diverse configurazioni con 100 client simultanei (fare clic sull'immagine per ingrandirla)
Inoltre, è possibile riscontare miglioramenti nel footprint di memoria e una più elevata densità del sito, soprattutto in ambienti di hosting condiviso o nei casi in cui si utilizzano molti processi di lavoro. Questo si ottiene di solito caricando meno DLL in ogni processo ed eliminando eventuali allocazioni di memoria che si verificano durante l'inizializzazione del modulo e l'elaborazione delle richieste. La Figura 2 illustra l'utilizzo della memoria (byte privati del processo di lavoro IIS) nello stesso test della velocità effettiva. In questo esempio i miglioramenti non sono particolarmente evidenti, tuttavia gli aumenti sono in linea con le aspettative, in quanto l'overhead dell'appdomain ASP.NET è relativamente più alto dei risparmi iniziali forniti dai moduli rimossi.
Figura 2 Utilizzo della memoria (byte privati) del carico di lavoro statico e nel carico di lavoro ASP.NET in tre diverse configurazioni con 100 client simultanei (fare clic sull'immagine per ingrandirla)
IIS 7.0 fornisce inoltre maggiore controllo sull'abilitazione dei moduli a livello di applicazione, oltre al controllo sull'utilizzo dei moduli basato sul carico di lavoro tramite le precondizioni del modulo. Sebbene questo richieda una configurazione avanzata, può fornire vantaggi aggiuntivi in ambienti multisito o per applicazioni che supportano più carichi di lavoro distinti.
Attenzione però: determinare le funzionalità richieste non è sempre facile. Occorre considerare non solo la funzionalità minima necessaria a supportare il framework applicazione, ma anche eventuali funzioni aggiuntive di cui l'applicazione potrebbe avere indirettamente bisogno. Ad esempio, l'applicazione potrebbe dipendere da forme di autenticazione specifiche o utilizzare la semantica di autorizzazione fornita dalle varie funzionalità IIS che, se rimosse, potrebbero compromettere la protezione dell'applicazione. Analogamente, per funzionare correttamente o per raggiungere prestazioni ottimali l'applicazione potrebbe aver bisogno di alcuni moduli che, se rimossi, potrebbero causare comportamenti errati o un peggioramento delle prestazioni.

Costruzione su un sistema operativo snello
Windows Server® 2008 rende anche disponibile la componentizzazione a livello di sistema operativo, che è possibile utilizzare per ridurre ulteriormente la superficie del server Web. Server Core è un'opzione di installazione minima per il sistema operativo Windows Server 2008 e contiene un set minimo di sottosistemi di base del sistema operativo. Server Core è l'ambiente ideale per i server Web IIS 7.0 snelli.
Tuttavia, quando si valuta Server Core, si tenga presente che alcune limitazioni potrebbero avere conseguenze sull'applicazione. Server Core non fornisce supporto per Microsoft® .NET Framework, il che significa che ASP.NET, l'estendibilità .NET per IIS e Gestione IIS non sono disponibili. Inoltre, le attività di gestione locali richiedono strumenti della riga di comando perché non è presente Microsoft Management Console (MMC). Dal punto di vista delle prestazioni, se si sta già utilizzando correttamente la componentizzazione di IIS, potrebbero non essere visibili miglioramenti nel footprint della memoria o nella velocità effettiva del carico di lavoro dell'applicazione in esecuzione su Server Core rispetto a un'implementazione Windows Server completa. Questo perché il lavoro eseguito da IIS e dall'applicazione è lo stesso su entrambe le piattaforme. Tuttavia, c'è un elemento in cui la differenza è visibile: il footprint globale del server, sia per quanto riguarda lo spazio su disco sia per quanto riguarda l'utilizzo della memoria.
Ad esempio, la Figura 3 illustra la differenza di footprint dopo aver eseguito il test del carico di lavoro statico su una configurazione Windows Server 2008 completa e su una configurazione Server Core. Mentre il footprint di IIS è praticamente identico in entrambi i casi, il footprint più basso del sistema operativo in Server Core richiede decisamente meno memoria per supportare il carico di lavoro. Il footprint più basso potrebbe inoltre consentire di distribuire il carico di lavoro dell'applicazione su hardware meno potente, spostando l'attenzione dall'ambiente di funzionamento alle richieste di elaborazione dell'applicazione. Ovviamente, questo rende Server Core un'ottima opzione per gli ambienti virtualizzati.
Figura 3 Footprint di memoria della versione completa di Windows Server 2008 rispetto a Server Core dopo l'esecuzione del test del carico di lavoro statico (fare clic sull'immagine per ingrandirla)

Topologie specializzate delle applicazioni
Quando si cerca di ottimizzare i carichi di lavoro delle applicazioni, è possibile dividere il carico di lavoro in parti distinte. Ad esempio, anziché eseguire l'applicazione su una farm di 30 server Web identici, è possibile eseguirla su 10 server Web, 5 server applicazioni e 3 server proxy che eseguono la memorizzazione nella cache e la compressione.
Questa specializzazione comporta dei vantaggi per diversi motivi. In primo luogo, le prestazioni di molti carichi di lavoro delle applicazioni dipendono soprattutto da una serie di risorse condivise, come la memoria, che potrebbero essere reclamate da varie parti dell'applicazione. La competizione per queste risorse può creare dei colli di bottiglia che impediscono a ciascun server di essere pienamente utilizzato da altre risorse. La separazione delle parti dell'applicazione consente alle parti di accedere immediatamente alle risorse senza creare competizione, migliorando l'efficienza dello stesso set di risorse hardware.
In secondo luogo, la specializzazione potrebbe consentire all'applicazione di migliorare la memorizzazione locale nella cache, con un conseguente miglioramento delle prestazioni. Questo comprende le cache di livello inferiore, come il TLB (Translation Lookaside Buffer) della memoria virtuale, la cache del file system e le altre cache del sistema operativo e dell'applicazione. Anche la CPU contribuisce a migliorare lo sfruttamento locale delle risorse. Riducendo il numero di attività parallele in esecuzione e concentrandosi soltanto su una parte specifica, l'applicazione può ridurre il numero di commutazioni di contesto e incrementare al massimo il lavoro eseguito dalla CPU.
Inoltre, la specializzazione consente l'ottimizzazione in base ai carichi di lavoro, in modo che ciascuna parte dell'applicazione possa lavorare in modo più efficace. Molte di queste ottimizzazioni non sono possibili quando l'intera applicazione è supportata sullo stesso server, a causa di confitti di esigenze tra le diverse parti dell'applicazione.
Uno scenario comune in cui questo si verifica è la configurazione del threading di IIS e ASP.NET, che ha influisce notevolmente sull'esecuzione simultanea e indirettamente sull'utilizzo della memoria, la latenza e la velocità effettiva di molte applicazioni. Il carico di lavoro statico dei file in IIS è estremamente asincrono e richiede un limite elevato di richieste simultanee, ma trae vantaggio da un numero molto basso di thread disponibili. D'altra parte, molte delle funzionalità di ASP.NET sono sincrone, comportano blocchi di lunga durata e richiedono un numero elevato di thread, mentre altre richiedono un limite di esecuzione simultanea più basso per ridurre l'impatto sulla memoria. Separando il carico di lavoro statico e dividendo le parti della pipeline di elaborazione delle richieste in un processo o server separato, è possibile ottimizzare l'esecuzione simultanea di ciascun carico di lavoro.
Infine, la specializzazione può comportare una maggiore scalabilità globale, in quanto consente all'applicazione di utilizzare la scalabilità orizzontale per carichi di lavoro discreti o per parti dell'applicazione indipendenti l'una dall'altra. In questo modo è possibile abilitare la topologia dell'applicazione per migliorarne la capacità e la ridondanza dove è più necessario, piuttosto che richiedere di applicare lo stesso modello all'intera applicazione. In questo modello, le risorse specializzate potrebbero essere server fisici, server virtuali o anche pool di applicazioni sullo stesso computer.
Quando si valutano i possibili vantaggi della specializzazione per la topologia dell'applicazione, è necessario innanzitutto individuare i colli di bottiglia dovuti all'elaborazione o a un utilizzo intensivo delle risorse nell'applicazione. Queste aree dovrebbero essere i primi candidati per la specializzazione, in quanto potrebbero fornire potenziale significativo per l'ottimizzazione se isolate, e in quanto richiederanno la più elevata scalabilità orizzontale. Inoltre, occorre valutare se l'isolamento consente al resto dell'applicazione di utilizzare le risorse in modo più efficace. Infine, occorre valutare l'overhead del meccanismo di connettività necessario per rimettere insieme i componenti isolati dell'applicazione.

Supporto migliorato delle applicazioni
IIS 7.0 è dotato di supporto esteso per i framework applicazione tramite FastCGI, un protocollo aperto supportato da molti framework applicazione open source che altrimenti non potrebbero supportare un'integrazione nativa con IIS stabile e ad elevate prestazioni. A differenza del protocollo CGI (Common Gateway Interface), che è stato supportato da IIS per lungo tempo, FastCGI fornisce prestazioni notevolmente migliorate sulla piattaforma Windows. Questo è dovuto principalmente all'architettura di processo riutilizzabile di FastCGI, che elimina la necessità di creare un processo per ciascuna richiesta, consentendo ai client di sfruttare le connessioni keep-alive permanenti.
Se il supporto dei framework applicazione di IIS è assicurato da CGI o da un altro meccanismo, è possibile migliorare le prestazioni (e in alcuni casi la stabilità) passando al protocollo FastCGI.
Il primo framework applicazione che sfrutta questo supporto è PHP. Il team di IIS ha lavorato direttamente con Zend Technologies per garantire che l'implementazione di FastCGI in IIS funzioni bene con PHP e consenta miglioramenti delle prestazioni nel framework PHP su Windows. Per ulteriori informazioni sul progetto, consultare il mio blog alla pagina go.microsoft.com/fwlink/?LinkId=122509. Se si ha a disposizione un misto di tecnologie server Web costituite da applicazioni ASP o ASP.NET in esecuzione su IIS, oltre a PHP o altri framework applicazione compatibili con FastCGI tramite altre tecnologie, è possibile consolidare queste applicazioni sulla piattaforma IIS 7.0.
Spostando PHP e altri framework applicazione in IIS 7.0 e FastCGI, è possibile usufruire di varie funzionalità di IIS 7.0, tra cui la pipeline integrata ASP.NET. Questa opzione è particolarmente utile per migliorare i framework applicazione con servizi ASP.NET senza convertirli in ASP.NET. Consente inoltre alle applicazioni di utilizzare framework diversi per collaborare. Per un esempio di come utilizzare questa opzione per migliorare la funzionalità e le prestazioni delle applicazioni esistenti senza modificare il codice, consultare il mio articolo su MSDN® Magazine "Potenzia le tue applicazioni con la pipeline ASP.NET integrata" (disponibile all'indirizzo msdn.microsoft.com/msdnmag/issues/08/01/PHPandIIS7).

Aumento della densità delle applicazioni
IIS 7.0 comprende molti miglioramenti intesi ad accrescere la densità delle applicazioni ospitate su un unico server. Questi miglioramenti fanno parte delle numerose funzionalità rese disponibili da IIS 7.0 per ottimizzare la qualità dell'hosting condiviso, fra cui il provisioning migliorato dei siti e un maggiore isolamento delle applicazioni.
Dal punto di vista delle prestazioni, i miglioramenti si concentrano principalmente su due aspetti della densità delle applicazioni: l'aumento del numero di applicazioni di cui può essere effettuato il provisioning su un server IIS 7.0 e l'aumento del numero di applicazioni che possono essere attive in qualsiasi momento.
Si tenga presente che con IIS 7.0 è possibile effettuare il provisioning su ogni server di un numero di applicazioni più elevato di quanto consentito in passato — in alcuni test interni si è arrivati fino a 100.000 siti su un solo server. Questo è possibile grazie alla capacità di creare e configurare un gran numero di siti e applicazioni.
Attenzione però: per ottenere un provisioning ad alta velocità, è necessario passare alle API della nuova configurazione, in quanto le API della configurazione precedente sono inadeguate. Inoltre, non tutte le API della configurazione IIS forniscono le stesse caratteristiche di prestazioni, quindi è necessario effettuare una scelta attenta per ottimizzare le prestazioni. Se non si è sicuri, optare per opzioni di configurazione che sfruttano direttamente i nuovi oggetti di configurazione IIS, tra cui il namespace Microsoft.Web.Administration, lo strumento della riga di comando AppCmd.exe e gli oggetti di configurazione IIS COM accessibili da script o da codice .NET o C++.
La differenza tra il numero di siti di cui è possibile effettuare il provisioning e il numero di siti che possono essere attivi è una distinzione molto importante nell'architettura IIS, che utilizza processi di lavoro e applicazioni permanenti per l'elaborazione delle richieste. In questo modello, le applicazioni attive utilizzano più risorse sul server, ma garantiscono anche prestazioni costantemente migliori grazie alla memorizzazione nella cache e all'eliminazione dei costi di inizializzazione.
Dato che ogni applicazione attiva richiede una certa quantità di memoria e un processo di lavoro separato (se si utilizza il modello di isolamento dell'applicazione consigliato), il numero di applicazioni attive dipende in gran parte dal footprint di memoria dell'applicazione. Quindi, mentre una singola applicazione utilizzata soltanto per il contenuto statico potrebbe richiedere solo 3 MB per il suo processo di lavoro (e può anche condividere lo stesso processo di lavoro con altre applicazioni di contenuto statico), alcune applicazioni dinamiche potrebbero richiedere 100 MB o più di RAM anche in condizioni di basso utilizzo. In questo caso, l'overhead di memoria del processo di lavoro IIS è praticamente irrilevante se paragonato al footprint dell'applicazione quando si definisce la densità massima possibile.
Nello scenario tipico dell'hosting condiviso, è piuttosto comune la cosiddetta "distribuzione 80/20", in cui l'80% delle richieste viene inviato al 20% dei siti. Questo fa sì che solo una piccola percentuale di siti sia attiva in un dato momento. Per consentire un numero più elevato di siti attivi, IIS 7.0 rende disponibile la gestione attiva della durata. Questa aiuta a recuperare memoria dalle applicazioni non attive per consentire l'hosting di più applicazioni attive.
IIS 7.0 introduce un nuovo algoritmo chiamato inattività dinamica, che regola i tempi di inattività dei processi di lavoro in base alla memoria disponibile sul server. Man mano che la memoria disponibile diminuisce, le applicazioni inattive vengono rimosse più rapidamente, consentendo l'hosting di più applicazioni attive. Tuttavia, se la memoria è disponibile, i timeout possono rimanere ampi, per consentire prestazioni migliori e mantenere lo stato delle applicazioni. Oltre a consentire a più applicazioni di essere attive, l'inattività dinamica aiuta anche a evitare condizioni di memoria scarsa, che causano un notevole peggioramento delle prestazioni a causa del sovraccarico.
Per consentire l'hosting di molte applicazioni attive, è necessario utilizzare un sistema operativo a 64 bit, perché in questo modo il sistema operativo può sfruttare più di 4 GB di memoria. Inoltre, è possibile configurare i processi di lavoro IIS perché vengano eseguiti in modalità 32 bit (SysWoW64), in modo che utilizzino meno memoria e consentano al sistema operativo di sfruttare più memoria rispetto a un ambiente a 32 bit.

Riduzione della larghezza di banda con la compressione
Non stupisce che i costi di larghezza di banda siano uno dei costi più elevati per un datacenter che utilizza Internet. Inoltre, la larghezza di banda necessaria per trasmettere il contenuto richiesto è un fattore chiave per la capacità di risposta percepita dell'applicazione.
Uno dei modi più efficaci per ridurre la larghezza di banda necessaria ad assicurare la capacità di risposta dell'applicazione è utilizzare la compressione HTTP. Questa può ridurre notevolmente le dimensioni della risposta, spesso di circa il 10% se applicata a contenuto di testo facilmente comprimibile come l'HTML. L'aspetto migliore è che praticamente tutti i browser desktop la supportano, e i costi di decompressione sull'hardware del desktop sono minori rispetto ai risparmi di latenza ottenuti dall'invio di un numero minore di dati. E poiché la compressione è basata sulla negoziazione Content-Encoding definita nel protocollo HTTP 1.1, la sua attivazione è sicura per i client che non supportano la compressione — questi client ricevono semplicemente una versione non compressa del contenuto.
IIS 7.0 rende disponibili due funzionalità di compressione introdotte nella versione precedente: la compressione statica e la compressione dinamica. La compressione statica effettua una compressione preliminare del contenuto statico e lo salva su disco, consentendo alle richieste future di utilizzare direttamente il contenuto compresso senza dover effettuare la compressione. La compressione dinamica comprime le risposte in tempo reale, pertanto consente la compressione per le risposte generate dalle applicazioni. Tutti i framework applicazione di IIS 7.0 possono sfruttare la compressione dinamica, compresi ASP, ASP.NET o PHP.
Contrariamente a quanto si crede, la compressione dinamica solitamente non comporta un overhead insostenibile per la CPU. Infatti, alla compressione dinamica è spesso attribuibile meno del 5% dell'utilizzo totale della CPU su un server occupato. La compressione dinamica può essere distribuita in modo piuttosto libero per risparmiare al massimo sulla larghezza di banda per i carichi di lavoro dell'applicazione.
È possibile ottimizzare ulteriormente l'overhead della compressione configurando la forza di compressione per raggiungere la compressione desiderata rispetto al valore dell'overhead della CPU. E non solo: è anche possibile configurare l'applicazione per attivare la memorizzazione nella cache del contenuto compresso, che elimina l'overhead della compressione nei riscontri della cache in quanto viene utilizzato contenuto già compresso. Si tenga presente che sia la cache dell'output di ASP.NET che la cache dell'output di IIS sono state dotate della funzionalità opzionale che memorizza nella cache il contenuto compresso per i client che lo supportano, oltre a gestire le richieste provenienti dai client che richiedono contenuto non compresso.

Limitazione della velocità in bit per contenuti multimediali
Poiché sempre più siti offrono contenuti multimediali, i costi di larghezza di banda per molte aziende sono saliti alle stelle. Quel che è peggio, un'ampia percentuale di larghezza di banda viene sprecata, in quanto il contenuto multimediale inviato al client non viene mai realmente utilizzato. Perché questo si verifica?
Immagina l'ultima volta in cui hai guardato un video online o hai visto un annuncio video mentre navigavi su Internet. Hai guardato il video fino alla fine? Molto spesso gli utenti navigano nei siti di video per guardare soltanto una parte di un video, prima di passare al video successivo o chiudere la pagina. Tuttavia, un server Web che utilizza il download progressivo per rendere disponibile il video invia solitamente molti più dati del necessario per quei pochi secondi di riproduzione. La maggior parte dei dati non viene mai utilizzata.
Se i video vengono mediamente riprodotti per 5 secondi ma il sistema esegue il buffering di 30 secondi di dati video in quei 5 secondi, viene potenzialmente sprecato oltre l'80% della larghezza di banda.
Un anno fa, per risolvere questo problema per un cliente in possesso di una versione beta di IIS 7.0, ho scritto un modulo di limitazione della larghezza di banda che rilevava automaticamente la velocità in bit del video per assicurare che il server trasmettesse il video al client più o meno alla stessa velocità. Il team multimediale di IIS ha adottato questo modulo, denominato "Bit Rate Throttling Module" (vedere la Figura 4), e lo ha reso disponibile nell'area download di iis.net (iis.net/downloads/?tabid=34&g=6&i=1640). Per ulteriori informazioni su questo modulo, consultare il blog di Scott Guthrie (disponibile alla pagina go.microsoft.com/fwlink/?LinkId=122514).
Figura 4 La limitazione della velocità in bit riduce l'utilizzo della larghezza di banda (fare clic sull'immagine per ingrandirla)
Il modulo per la limitazione della velocità in bit rileva automaticamente la velocità di codifica dei tipi di video più comuni. È possibile controllare quanti dati si desidera pre-inviare al client per eliminare i ritardi di buffering iniziali (avvio veloce) e stabilire a quale percentuale di velocità codificata si desidera trasmettere il contenuto. È anche possibile configurare molte altre opzioni, come la larghezza di banda massima e le connessioni simultanee, e controllare il modulo a livello di programmazione.

Cache di output
In generale, la memorizzazione nella cache è il metodo migliore per migliorare le prestazioni delle applicazioni che eseguono operazioni ripetitive. A differenza dei miglioramenti delle prestazioni specifici di un'applicazione, che richiedono spesso molti sforzi e vengono sminuiti dall'overhead di elaborazione dell'applicazione, la memorizzazione nella cache elimina la necessità di richieste ripetute per lo stesso contenuto.
Prima di IIS 7.0, sia IIS che ASP.NET offrivano funzionalità di memorizzazione nella cache tramite la cache del kernel IIS e la cache di output di ASP.NET. La cache del kernel IIS garantiva le prestazioni migliori, ma serviva principalmente per il contenuto statico. La cache di output di ASP.NET era una soluzione decisamente più completa per memorizzare nella cache il contenuto dinamico, ma le prestazioni erano più lente e la gestione della memoria meno efficiente. La nuova cache di output di IIS 7.0 elimina il divario tra la cache del kernel IIS e la cache di output di ASP.NET.
La cache di output di IIS 7.0 consente la memorizzazione nella cache del contenuto dinamico da qualsiasi applicazione, tra cui ASP, ASP.NET, PHP e qualsiasi altro framework applicazione compatibile con IIS 7.0. Fornendo supporto di base per la variabilità e la scadenza del contenuto, questa nuova funzionalità consente di memorizzare nella cache il contenuto che non può essere memorizzato dalla cache del kernel IIS. Attiva anche l'uso della cache del kernel per il contenuto conforme alle restrizioni.
Inoltre, la cache di output di IIS 7.0 rappresenta anche un'alternativa dalle prestazioni migliori rispetto alla cache di output di ASP.NET per il contenuto ASP.NET che non richiede funzionalità cache avanzate (come l'invalidamento e le dipendenze della cache) che sono disponibili solo nella cache di output di ASP.NET.
Per quanto riguarda la cache di output, le difficoltà maggiori risiedono solitamente nel definire la scadenza corretta del contenuto, l'invalidamento e i criteri di variabilità che consentono un'efficace memorizzazione nella cache delle risposte pur mantenendo la correttezza e l'aggiornamento della cache necessari. Nella maggior parte dei casi, è sufficiente configurare regole corrette di memorizzazione nella cache, ma alcune situazioni richiedono criteri più complessi che dipendono dalle informazioni di runtime. Per risolvere questo problema, la cache di output di IIS 7.0 fornisce API programmatiche che possono essere utilizzate per garantire il corretto comportamento della cache. In questo modo si liberano le potenzialità delle prestazioni di memorizzazione nella cache per i contenuti che altrimenti non potrebbero usufruirne. Inoltre, la pipeline integrata ASP.NET consente l'utilizzo della cache di output di ASP.NET per contenuti non ASP.NET.
L'utilizzo della cache di output per il contenuto dinamico può presentare delle difficoltà e potrebbe richiedere una strategia multilivello per sfruttare al massimo l'efficienza e la flessibilità delle varie funzioni di memorizzazione nella cache sulla piattaforma IIS 7.0. Questo comprende spesso la descrizione di più parametri che influiscono sulla risposta e la definizione di strategie sia di scadenza che di invalidamento per mantenere aggiornata la cache, e infine la determinazione di quale cache debba supportare la semantica richiesta.
Ma il gioco vale quasi sempre la candela. L'implementazione della cache di output di IIS 7.0, consente di ottenere miglioramenti di svariati ordini di grandezza nella velocità effettiva dell'applicazione e una corrispondente riduzione del carico del database e dei componenti a livello aziendale.

Conversione del codice ISAPI in moduli IIS 7.0
IIS 7.0 introduce una nuova API server su cui sono basati tutti i moduli IIS 7.0. Questa sostituisce il filtro ISAPI e le API di estensione ISAPI utilizzate nelle versioni precedenti di IIS. Per i moduli nuovi che non richiedono il supporto per le versioni precedenti, le nuove API sono più facili da utilizzare, aiutano a produrre codice più affidabile sul lato server e sono molto più potenti.
Tuttavia, IIS 7.0 rende disponibile un'opzione per supportare i filtri ISAPI e le estensioni esistenti utilizzando un livello di compatibilità implementato tramite moduli IIS 7.0 opzionali. Questo consente ai componenti ISAPI esistenti di funzionare su IIS 7.0 senza che debbano essere riscritti.
Sebbene l'utilizzo degli investimenti ISAPI esistenti agevoli la migrazione a IIS 7.0, è necessario considerare attentamente la portabilità del codice ISAPI precedente alle nuove API di IIS 7.0. Questo consente di eliminare l'overhead del livello di compatibilità ISAPI e di sfruttare i vantaggi di prestazioni che non erano disponibili per i componenti ISAPI. A seconda del lavoro eseguito dal componente ISAPI, tali vantaggi di prestazioni possono essere decisamente significativi. Ad esempio, l'API dei moduli IIS 7.0 fornisce supporto incorporato per la memorizzazione nella cache dei metadati di configurazione e di altri dati arbitrari associati a siti, applicazioni e URL, il che può accelerare notevolmente le operazioni interne del componente.
Inoltre, l'API dei moduli IIS consente ai moduli di eseguire operazioni di lunga durata in modo asincrono, come la ricezione dei dati di entità delle richieste o l'invio di risposte. L'esecuzione di queste operazioni in modo asincrono consente al server di sfruttare la scalabilità su un numero molto vasto di client simultanei (decine di migliaia), invece di limitarsi solamente a decine, o al massimo a poche centinaia, di client simultanei a causa dei limiti nel numero dei thread di richiesta. L'elaborazione asincrona può anche eliminare l'effetto dell'elaborazione su altre richieste e attività nell'applicazione, ridurre l'utilizzo della memoria e migliorare notevolmente l'utilizzo della CPU.
Oltre ai modelli specifici di miglioramento delle prestazioni, l'API nativa offre agli sviluppatori una flessibilità molto più ampia nelle attività di elaborazione delle richieste. Questo consente di migliorare la progettazione del componente server e, di conseguenza, ne migliora l'efficienza. Ad esempio, alcune operazioni di filtraggio che in precedenza richiedevano le estensioni ISAPI per i caratteri jolly e l'esecuzione di richieste di oggetto figlio possono ora essere eseguite in un modulo durante la richiesta originale, ed è anche possibile attivare la memorizzazione nella cache del kernel IIS per le risposte.
Questo potrebbe richiedere la creazione di prototipi e alcuni esperimenti per determinare la configurazione migliore che ottimizzi i benefici della migrazione. A causa delle differenze fondamentali di architettura tra ISAPI e l'API dei moduli IIS 7.0, la portabilità diretta non rappresenta necessariamente la scelta giusta. La buona notizia è che l'API dei moduli IIS 7.0 è anche più semplice da utilizzare rispetto a ISAPI, e questo rende la migrazione meno difficile.

Estendibilità del server
IIS 7.0 offre estendibilità end-to-end. Questa richiede una buona conoscenza del funzionamento del server, ma apre nuove potenti strade per migliorare le prestazioni specifiche delle applicazioni. Partendo da una buona conoscenza dell'architettura del server e dall'elaborazione delle richieste, è possibile sfruttare tale estendibilità per progettare soluzioni personalizzate di miglioramento delle prestazioni e adattarle all'applicazione, al carico di lavoro e ai requisiti hardware.
Questo può avvenire, ad esempio, sostituendo alcune delle funzionalità di IIS 7.0 incorporate con implementazioni personalizzate. Le funzionalità di IIS 7.0 sono state ampiamente ottimizzate per quando riguarda le prestazioni, ma ovviamente anche per tutti gli usi possibili. Quindi è possibile migliorare le prestazioni di determinati moduli integrando ottimizzazioni per il carico di lavoro specifico. Ad esempio, è possibile reimplementare il modulo di visualizzazione directory in modo da archiviare le visualizzazioni directory nella memoria anziché utilizzare le API del file system per enumerare i file.
In alternativa, l'estendibilità può essere utilizzata per creare nuove funzionalità di prestazioni. Gli esempi di tali funzionalità comprendono la cache di output, i moduli di compressione e varie altre cache interne.
Per determinare la necessità di una funzionalità di prestazioni personalizzata, occorre conoscere le caratteristiche delle prestazioni dell'applicazione e il carico di lavoro della stessa, oltre a sapere quale collo di bottiglia si desidera risolvere. IIS 7.0 fornisce ampio supporto di diagnostica per l'analisi delle prestazioni, che può aiutare a chiarire i requisiti e la possibile progettazione delle funzionalità.

Conclusioni
IIS 7.0 è soprattutto una versione funzionale, ma offre anche notevoli miglioramenti delle prestazioni grazie all'architettura modulare, alla configurabilità e alle nuove funzionalità di prestazioni. Questi miglioramenti possono comportare notevoli risparmi aziendali grazie al consolidamento del server e alla riduzione dei costi di larghezza di banda, oltre a migliorare l'utilizzo da parte dell'utente.
Per implementare correttamente molti di questi miglioramenti, è spesso necessario eseguire un'analisi approfondita della piattaforma applicativa attuale e comprendere bene l'architettura di IIS 7.0. Per ulteriori informazioni sull'architettura e le funzionalità di IIS 7.0 descritte in questo articolo, visitare il sito www.iis.net. Nel mio blog mvolo.com parlerò ancora delle tecniche che sfruttano attivamente IIS 7.0 per migliorare le prestazioni delle applicazioni e ridurre i costi operativi.
Mike Volodarsky è stato Program Manager del team IIS di Microsoft. Negli ultimi cinque anni, ha gestito la progettazione e lo sviluppo delle funzionalità principali di ASP.NET 2.0 e IIS 7.0. Ora si occupa dello sviluppo di tecnologie server Web avanzate per Web farm ad alte prestazioni utilizzando IIS 7.0 e Windows Server 2008. Mike è l'autore principale del libro IIS 7.0 Resource Kit e scrive regolarmente su MSDN Magazine e sul suo blog mvolo.com dedicato a IIS 7.0.


Mobility
Suggerimenti per la mobilità delle applicazioni line-of-business
Matt Fontaine
Panoramica:
  • Le aziende hanno bisogno di applicazioni mobile line-of-business (mLOB)
  • Piattaforma affidabile per lo sviluppo e la distribuzione di applicazioni mLOB
  • Protezione, gestione e provisioning via radio

Indice
Attivazione e gestione dei lavoratori fuori sede
Protezione e gestione dei dispositivi
Interoperabilità
IT e produttività degli utenti
Sviluppo e distribuzione
Conclusioni
Oltre alle tradizionali funzioni di produttività, messaggistica e servizi vocali, oggigiorno molte aziende desiderano che i professionisti fuori sede possano accedere agli stessi sistemi line-of-business (LOB) che utilizzano in
ufficio mediante applicazioni mobile LOB (mLOB). I sistemi in questione includono applicazioni CRM (Customer Relationship Management), ERP (Enterprise Resource Planning), BI (Business intelligence), di amministrazione e contabilità. Ovviamente, disporre di funzionalità mLOB consente agli utenti fuori sede di visualizzare e utilizzare applicazioni aziendali complesse e di interagire con i dati in tempo reale, il che riduce i tempi di vendita, migliora la soddisfazione del cliente e aumenta la produttività aziendale. Ecco alcuni esempi di scenari aziendali tipici:
  • Il personale addetto alle vendite può utilizzare Microsoft Dynamics™ CRM Mobile per visualizzare e aggiornare i dati dei clienti da qualsiasi luogo. Un'altra applicazione mLOB potrebbe consentire l'accesso ai dati di magazzino e ai prezzi in tempo reale. Inoltre, gli addetti alle vendite potrebbero utilizzare speciali dispositivi per preparare documenti di vendita sul campo, dal completamento di ordini alla raccolta di firme. Esistono anche applicazioni POS per dispositivi Windows Mobile® che possono eseguire la scansione di codici a barre e leggere carte di credito, per poi connettersi a sistemi di dati LOB back-end per l'elaborazione.
  • Le attività dei dipendenti in servizio sul campo possono essere pianificate mediante soluzioni ERP che creano itinerari appositi per il personale in base agli appuntamenti e al luogo in cui si trovano e che consentono di rilevare automaticamente gli spostamenti grazie a dispositivi Windows Mobile abilitati per GPS. I dipendenti che operano sul campo iniziano con il primo impegno della giornata e, a lavoro ultimato, vengono indirizzati automaticamente all'appuntamento successivo (vedere Figura 1).
  • Nelle aziende manifatturiere, le funzionalità di scansione RFID (Radio Frequency Identification) dei dispositivi Windows Mobile possono essere utilizzate per la gestione delle scorte in un magazzino RFID, in quanto consentono di inserire informazioni in un database istantaneamente e in modalità wireless. Inoltre, esistono dispositivi Windows Mobile realizzati in versioni particolarmente resistenti o considerati "intrinsecamente sicuri" per ambienti di lavoro pericolosi che forniscono le informazioni necessarie e soddisfano al contempo importanti requisiti di sicurezza.
  • I dirigenti che lavorano fuori sede e nell'arco di una giornata si spostano da riunioni con i clienti a riunioni aziendali a conferenze stampa, magari lontano dall'ufficio, possono ottenere analisi finanziarie, rendiconti delle spese e informazioni sui clienti in qualsiasi luogo si trovino.
Questi e molti altri scenari spingono le aziende all'avanguardia ad adottare applicazioni mLOB. In questo articolo descriverò come Windows Mobile e Mobile Device Manager siano in grado di collaborare, consentendo ai professionisti IT di distribuire le complesse funzionalità "mobile" sempre più richieste dalle aziende di oggi.
Figura 1 Un'applicazione mLOB indicante un'attività di servizio sul campo completata

Attivazione e gestione di lavoratori fuori sede
Windows Mobile si è rivelata una piattaforma efficace per l'attivazione dei lavoratori fuori sede in vari settori, in quanto può collaborare senza problemi con risorse IT esistenti basate su Windows®, si avvale di comunicazioni unificate e messaggistica mobile fornite da Exchange Server e Office Communications Server ed è basata su Windows, il che significa che sia gli utenti sia i professionisti IT utilizzano un sistema noto che richiede una minore formazione ai fini dell'uso e della comprensione.
Con il rilascio di Mobile Device Manager, Windows Mobile è diventata una piattaforma addirittura migliore per la distribuzione di dispositivi portatili in ambienti aziendali. Mobile Device Manager consente di eseguire le attività di provisioning, gestione e protezione dei dispositivi portatili via radio tramite l'utilizzo di Active Directory® e Criteri di gruppo, proprio come se si trattasse di computer collegati in rete o di condivisioni di file. I criteri e i programmi software possono essere trasferiti ai telefoni in modo automatico, e i criteri relativi a protezione, software e hardware possono essere gestiti in modo estremamente accurato con complesse funzionalità di report e inventario.
L'impulso per tali innovazioni è l'idea che i dispositivi portatili dovrebbero essere estensioni naturali dei sistemi IT, anziché limitarsi a esistere in qualità di dispositivi middleware. Per le aziende che desiderano molto di più di semplici funzionalità di messaggistica, comunicazione e produttività di base dai dispositivi Windows Mobile, trasformare tali dispositivi in elementi fondamentali della rete è di importanza assoluta.
Ma cosa devono fare le organizzazioni che vogliono andare oltre le semplici funzionalità di base? Di seguito descriverò come sia possibile utilizzare al meglio le funzionalità di Windows Mobile e Mobile Device Manager grazie a una fantastica piattaforma per applicazioni mLOB.

Protezione e gestione dei dispositivi
Le stesse funzionalità che rendono attraenti le applicazioni mLOB, ossia il fatto che permettano di accedere in qualsiasi momento e luogo a importanti informazioni aziendali riguardanti clienti, amministrazione, magazzino e così via, rendono più complesse le attività di protezione. Gli utenti, infatti, immettono queste informazioni e vi accedono tramite dispositivi di piccole dimensioni su reti pubbliche e da diverse postazioni.
Molte aziende hanno già attivato l'accesso mobile alle applicazioni LOB, nonché ad altre risorse e strumenti condivisi sull'intranet mediante computer portatili con connessioni alla rete privata virtuale (VPN). Mobile Device Manager estende tale funzionalità ai dispositivi Windows Mobile grazie a Mobile VPN (vedere Figura 2). Il server gateway Mobile Device Manager attiva un tunnel crittografato IPsec tra il client Windows Mobile e la rete, fornendo accesso sicuro a informazioni protette dal firewall aziendale su connessioni pubbliche, come Internet o reti a pacchetti di dati wireless. In questa configurazione, Windows Mobile supporta più tipi di crittografia.
Figura 2 Gestione avanzata dei dispositivi, protezione e VPN per dispositivi mobili con Mobile Device Manager (fare clic sull'immagine per ingrandirla)

Interoperabilità
I criteri di crittografia possono essere impostati e applicati ai dati sui dispositivi e le schede di memoria. I dipendenti che utilizzano applicazioni mLOB potrebbero scaricare informazioni riservate sui loro dispositivi portatili, che sono molto più facili da smarrire rispetto ad altri dispositivi di rete. Fortunatamente, sui dispositivi Mobile VPN che dispongono di una connessione dati è possibile eseguire la cancellazione dei dati in modalità remota (vedere Figura 3). Ad esempio, se un addetto alle vendite di una società farmaceutica scarica dei file relativi a diversi clienti dal sistema CRM aziendale sul dispositivo portatile e poi lascia inavvertitamente quest'ultimo su un taxi, potrebbero verificarsi gravi conseguenze.
Figura 3 Se un dispositivo portatile viene perso o rubato, le informazioni che contiene possono essere rimosse in modalità remota. (fare clic sull'immagine per ingrandirla)
Mobile Device Manager è stato progettato per far fronte a questo tipo di problemi. Consente infatti di gestire quasi tutti gli aspetti relativi alle funzionalità dei dispositivi e ai criteri utente di Windows Mobile, dalla disattivazione di specifiche funzionalità hardware al controllo delle applicazioni installabili, fino alla limitazione dell'accesso a determinate risorse di rete. Queste attività possono essere eseguite con un'unica soluzione e tutte via radio. Quando gli utenti hanno a disposizione funzionalità mLOB, tali caratteristiche assumono una rilevanza ancora maggiore. Ad esempio, si potrebbe impedire agli utenti di utilizzare connessioni di rete Bluetooth per evitare il download di dati su dispositivi non controllati. Oppure, se si desidera che solo alcuni utenti possano installare il client del software di contabilità mobile, si potrebbe far sì che venga caricato e installato automaticamente solo sui dispositivi degli utenti che ne hanno bisogno.
Risorse aggiuntive
  • Microsoft System Center Mobile Device Manager 2008
  • Introducing Microsoft System Center Mobile Device Manager 2008
  • Microsoft System Center Mobile Device Manager 2008: A Technical White Paper
  • Microsoft System Center Mobile Device Manager 2008 An Introduction for Business Audiences
  • Windows Mobile Line of Business Solution Accelerator 2008
Inoltre, Mobile Device Manager non richiede che i dati aziendali passino attraverso un NOC (Network Operations Center) di terzi, che potrebbe rappresentare un altro punto di disponibilità o violazione della protezione. Sostanzialmente, Mobile Device Manager garantisce un controllo completo sulle implementazioni di dispositivi portatili a qualsiasi livello, controllo che a sua volta semplifica le operazioni di distribuzione, gestione e protezione delle funzionalità mLOB.
L'integrazione con la rete offre anche un altro vantaggio: il controllo estremamente accurato è realizzato per mezzo di Active Directory e Criteri di gruppo, eliminando la necessità di gestire i dispositivi portatili separatamente da altri client di rete. In questo modo si risparmiano tempo e denaro e, cosa più importante, si utilizzano criteri di accesso e protezione uniformi. I Criteri di gruppo rappresentano un metodo molto efficiente per controllare l'accesso mobile ai dati LOB: consentono di concedere in modo semplice l'accesso agli utenti che hanno bisogno di tali dati e di limitarlo in massa o singolarmente agli altri utenti.
Un altro importante aspetto da considerare sulla gestione di implementazioni mLOB, e sui dispositivi portatili in generale, è l'interoperabilità con le infrastrutture esistenti. A differenza di Windows Mobile, i sistemi operativi di alcuni dispositivi portatili non sono collegati ad altre risorse IT e richiedono quindi linguaggi, server e strumenti appositi. Questi fattori assumono un'importanza rilevante quando si fornisce l'accesso ad applicazioni complesse e a dati importanti sui dispositivi portatili.
Windows Mobile e Mobile Device Manager offrono tale interoperabilità. Poiché fa parte del sistema operativo Windows, Windows Mobile interagisce senza problemi con altre risorse IT basate su Windows, quali Microsoft® Exchange Server, Microsoft Forefront™, SQL Server® e Microsoft Office Communications Server. Questa interoperabilità all'interno di una famiglia di prodotti semplifica la progettazione e la realizzazione di funzionalità mLOB all'avanguardia.
Ad esempio, Windows Communication Foundation (WCF) — la tecnologia di Microsoft .NET Framework per l'attivazione delle comunicazioni tra le applicazioni — è in grado di utilizzare Exchange Server come utilità di inoltro dei messaggi alle implementazioni mLOB avvalendosi di un'architettura orientata ai servizi (SOA). Gli account dei dipendenti che si connettono occasionalmente possono essere aggiornati utilizzando la nuova tecnologia Sync Framework, che semplifica la sincronizzazione dei dati tra i dispositivi Windows Mobile grazie a SQL Server Compact 3.5 e a SQL Server 2008 per i dati aziendali. Senza un'infrastruttura mobile in grado di interagire con così tante risorse di rete pronte all'uso, l'implementazione di tali scenari potrebbe risultare molto più complessa.

IT e produttività degli utenti
L'incremento della produttività è un obiettivo importante delle implementazioni mLOB. Tuttavia, se l'utilizzo e la gestione delle funzionalità creano difficoltà a dipendenti e professionisti IT, i costi potrebbero superare i vantaggi o comunque ridurre il rendimento degli investimenti (ROI). Uno degli obiettivi degli sviluppatori di Windows Mobile è renderne l'utilizzo il più simile possibile a quello del desktop Windows perché la familiarità che ne deriva può aumentare il valore della soluzione per tutti gli utenti.
Dal punto di vista informatico, Windows Mobile, che si avvale di Mobile Device Manager, è stato progettato per integrare perfettamente i dispositivi Windows Mobile alla rete. Lo può fare grazie all'utilizzo di tecnologie note, in particolare Active Directory e Windows Server®. Mobile Device Manager fa parte della famiglia di soluzioni di gestione IT System Center, utilizzate da molti professionisti IT in tutto il mondo. Anziché dover apprendere una serie di nuove procedure e strumenti, i professionisti IT che hanno familiarità con un ambiente Windows possono utilizzare gli snap-in di Microsoft Management Console che già conoscono.
Lo stesso vale per gli utenti. L'esperienza di Windows Mobile, simile a quella di un desktop, consente di acquisire sicurezza e rapidità in breve tempo. Gli utenti possono utilizzare la suite Office Mobile, compreso Office Mobile Outlook®, per svolgere il loro lavoro senza dover imparare a utilizzare nuove applicazioni. Non devono preoccuparsi della gestione dei dispositivi, in quanto viene eseguita a livello centrale. Le applicazioni mLOB possono essere progettate in modo da funzionare con modalità familiari agli utenti delle versioni desktop degli stessi programmi. È possibile realizzare nuovi strumenti che abbiano lo stesso aspetto e si comportino come il software Windows. La familiarità degli utenti può ridurre il numero di chiamate al servizio di assistenza e la gravità degli incidenti, il che costituisce un vantaggio anche per i professionisti IT.
Altri aspetti della piattaforma Windows Mobile e Mobile Device Manager migliorano inoltre la produttività. Mobile VPN fornisce una connettività perfetta e continua anche tra reti diverse, oltre alla funzionalità di riconnessione rapida, che consente agli utenti di collegarsi quando è necessario e diminuisce il numero di chiamate al servizio di assistenza per questo tipo di problemi. I form factor per più dispositivi supportati da Windows Mobile consentono alle aziende di utilizzare un numero ridotto di dispositivi standard, offrendo comunque ai dipendenti la possibilità di scegliere quelli che soddisfano al meglio le loro esigenze. La diversità dei dispositivi consente inoltre di implementare scenari mLOB per l'incremento della produttività, ad esempio scenari di gestione delle scorte basati su codici a barre e di creazione di itinerari con dispositivi abilitati per GPS.

Sviluppo e distribuzione
Gli attributi che definiscono le applicazioni LOB — complessità dei dati, potenza e funzionalità specializzate — tendono a funzionare meglio su una piattaforma mobile progettata per una produttività basata sulle applicazioni. Windows Mobile offre ai dipendenti fuori sede un'esperienza simile a quella del desktop, il che rende più semplici lo sviluppo, la distribuzione e la gestione delle applicazioni mLOB.
Per iniziare, Windows Mobile supporta una versione di .NET denominata .NET Compact Framework. Poiché .NET Framework è un set di strumenti di programmazione utilizzato da milioni di sviluppatori in tutto il mondo, molti team operativi IT dispongono già di competenze di sviluppo interne per la personalizzazione e la creazione di applicazioni mLOB per Windows Mobile. In caso contrario, tali competenze possono essere acquisite sul mercato.
Windows Mobile supporta molte applicazioni mLOB attualmente in commercio. Microsoft offre soluzioni mLOB all'interno della famiglia di prodotti Microsoft Dynamics, fra cui Microsoft Dynamics CRM Mobile e Microsoft Dynamics AX Mobile Sales. Inoltre, Microsoft Dynamics Mobile Development Tools fornisce agli sviluppatori tecnologie per l'estensione del software nell'ambiente "mobile" dei dispositivi portatili. Microsoft è anche impegnata ad adattare all'ambiente "mobile" altre soluzioni Microsoft Dynamics, ad esempio il supporto per Microsoft Dynamics NAV sarà disponibile a breve. La maggior parte dei principali produttori di soluzioni LOB, quali SAP, Siebel, PeopleSoft e SalesForce.com, fornisce versioni delle suite di applicazioni compatibili con Windows Mobile.
Una volta acquistate o sviluppate, le applicazioni mLOB possono essere distribuite e gestite via radio mediante Mobile Device Manager e Windows Server Update Services 3.0. Per stabilire quali dispositivi debbano ricevere l'applicazione e a quali funzioni possano accedere, è possibile utilizzare Criteri di gruppo. Anche gli aggiornamenti delle applicazioni possono essere eseguiti in questo modo.

Conclusioni
Un numero crescente di aziende sta iniziando a fornire ai propri dipendenti e dirigenti applicazioni mLOB, aprendo nuove prospettive per gli addetti alla distribuzione e alla gestione dei sistemi IT. Windows Mobile e Mobile Device Manager assicurano dispositivi portatili pronti all'uso sulla rete e offrono una piattaforma di facile gestione per lo sviluppo e la distribuzione di applicazioni mLOB. Si tratta di una piattaforma che ottimizza la protezione e la produttività degli utenti, riducendo al minimo gli investimenti nelle infrastrutture e i problemi informatici. Inoltre, poiché Mobile Device Manager consente di distribuire applicazioni mLOB a molti utenti, il costo delle attività di sviluppo e distribuzione per ogni utente si riduce, mentre il ROI aumenta. La gestione semplificata di Windows Mobile con Mobile Device Manager lascia il tempo di pensare con creatività a come utilizzare le applicazioni mLOB nel modo più efficiente possibile, anziché a come farle funzionare.

Matt Fontaine è uno scrittore e consulente che vive a Seattle, nello Stato di Washington. È impegnato in numerosi settori, compresi il calcolo ad alte prestazioni, il software gestionale, la matematica attuariale, i beni immobili commerciali, l'ingegneria, l'edilizia e i beni di consumo confezionati. Matt è laureato al The Evergreen State College.


Security
Informazioni sulla gestione di password per account condivisi
Chris Stoneff
Panoramica:
  • Rischi delle password per account condivisi e privilegiati
  • Modalità di memorizzazione delle password
  • Gestione e protezione di password condivise
  • Conformità alle normative

Indice
Comprensione del problema
Lunghezza superiore equivale a protezione superiore
Violazione di dominio
Scuse, scuse, scuse
Requisiti degli enti di vigilanza
Un approccio automatizzato
Conclusioni
Uno dei problemi comuni che gli amministratori devono affrontare sempre più spesso è la modifica periodica delle password per gli account condivisi e privilegiati, ad esempio per l'account predefinito
Administrator o account radice, per gli account di emergenza o anche per quelli di processo. Per definizione, l'account predefinito Administrator o radice è l'account presente in tutte le versioni di Windows®, Linux e UNIX che ha sempre lo stesso identificatore di protezione (SID) o identificatore utente (UID). Gli account di emergenza vengono creati per facilitare l'accesso di emergenza a un sistema protetto. Gli account di emergenza e Administrator sono a volte utilizzati da utenti non privilegiati per accedere ai sistemi principali in caso di problemi. Infine, gli account di processo sono utilizzati per eseguire servizi, attività, applicazioni COM+ ed elementi incorporati, quali script e altri file binari che devono accedere al sistema.
Probabilmente i lettori avranno implementato i propri sistemi utilizzando immagini o script di installazione. Inoltre, tutte le workstation o i server avranno lo stesso nome per l'account Administrator e la stessa password di 8 caratteri, che probabilmente non è stata modificata dall'implementazione iniziale dei sistemi. Per questo motivo, utilizzo il singolare "la password" anziché "le password".
L'amministratore potrebbe essere obbligato a modificare queste password per attenersi a procedure consigliate o soddisfare requisiti di conformità, come quelli presenti nelle normative SOX (Sarbanes-Oxley), PCI (Payment Card Industry) e HIPAA (Health Insurance Portability and Accountability Act). A volte deve modificarle quando un ex amministratore o un tecnico a conoscenza delle password lascia l'azienda, in quanto teme che la protezione sia violata pubblicamente o che venga meno la capacità di elaborare carte di credito. Al di là di questi motivi, in realtà è compito dell'amministratore modificare le password semplicemente per la sicurezza dell'azienda e dei dati che l'azienda deve proteggere.

Comprensione del problema
Esistono alcuni fattori che è necessario comprendere quando si gestiscono questi account e le relative password:
  1. Se una password è meno recente, è anche meno sicura.
  2. In generale, più le password sono lunghe, più difficili saranno da decifrare.
  3. La modalità con cui i computer eseguono l'autenticazione non cambia solo perché questi appartengono a un dominio. Ogni dominio è praticamente un gruppo di lavoro.
L'affermazione "se una password è meno recente, è anche meno sicura" può risultare ingannevole. Il vero significato è che, se si desidera violare un computer, l'unico elemento davvero indispensabile è il tempo. Alla domanda "Quanto tempo è necessario per individuare una password?" in genere non è possibile dare una risposta univoca, ma è possibile ottenere alcuni indizi che consentono di determinare la risposta per un dato sistema:
  • Quanti utenti conoscono la password?
  • Tutti questi utenti lavorano ancora per l'azienda?
  • Se alcuni degli utenti che conoscono la password dell'account non lavorano più per l'azienda, l'hanno lasciata in termini amichevoli?
  • Viene negato l'accesso all'avvio da unità floppy, CD, DVD o dalla rete?
  • Gli utenti dei computer sono anche amministratori locali?
  • Tutti i sistemi utilizzano esattamente la stessa password per gli account privilegiati?
Partendo dall'inizio dell'elenco, si può affermare che più utenti conoscono un segreto, maggiore è la probabilità che questo diventi di dominio pubblico. Ricordo che in alcune aziende per le quali ho lavorato, gli amministratori ritenevano più pratico impostare la password condivisa sullo stesso valore e comunicare al personale IT e ai tirocinanti le password, anziché immetterle al loro posto come previsto. Ovviamente, con il passare del tempo, l'azienda ha iniziato a scoprire computer con diverse impostazioni non approvate e utenti abituali della rete in grado di accedere a tali account.
Se tutti gli utenti a conoscenza delle password lavorano ancora per l'azienda e sono dipendenti soddisfatti e ligi al dovere, questo rischio si attenua. Ma non è mai possibile sapere se ci sono utenti malintenzionati con i quali dover fare i conti. Se qualcuno degli utenti ha lasciato l'azienda in termini non amichevoli, esiste una persona ostile che sa come violare la rete utilizzando un account non rintracciabile.
Se non viene negato l'accesso all'avvio da unità diverse dal disco rigido, si consente agli utenti di eseguire l'avvio utilizzando immagini non autorizzate, quali Windows PE o vari sistemi Linux in grado di leggere direttamente dal file system del computer e accedere all'archivio protetto. Si tenga presente che molte violazioni sono causate da elementi interni e che, anche se tutto il personale e i tirocinanti sono ancora impiegati presso l'azienda, ciò non garantisce in alcun modo che le password e i sistemi siano sicuri.
Conosco molte persone che hanno continuato ad accedere alla rete di un ex datore di lavoro solo perché potevano. Suscita ilarità il fatto che questi utenti sottolineino semplicemente la pessima abitudine di non modificare le password di sistema, ma è anche allarmante considerare i danni che avrebbero potuto provocare se fossero stati malintenzionati.
Se si consente l'avvio da un DVD o dalla rete, si rischia di non essere in grado di controllare le attività degli utenti. In questi casi, un'immagine di rete o un disco di avvio di Linux spesso possono accedere direttamente al file system dell'azienda. Se i sistemi aziendali utilizzano lo stesso nome utente e la stessa password per gli account privilegiati, si espongono i sistemi a gravi rischi. Ma approfondirò questi argomenti in seguito.
La validità e la lunghezza delle password risultano adeguate a seconda del metodo utilizzato per decifrarle. Nel caso di un metodo di determinazione delle password a forza bruta, il tempo è il vero nemico da fronteggiare: se una password è modificata con minor frequenza, aumenta il tempo a disposizione di chi tenta di scoprirla.
Analogamente, le password più lunghe hanno maggiori variazioni di caratteri, quindi per decifrarle occorre più tempo. È importante considerare se la lunghezza delle password in uso è inferiore a 7 caratteri, è compresa tra 8 e 14 caratteri o superiore a 15 caratteri. Se le password sono inferiori a 15 caratteri e si utilizza Windows, gli hash LM (LAN Manager) sono stati disattivati nella configurazione di sistema o in base ai criteri di gruppo?
In che modo la lunghezza della password influisce su altri elementi? Nel caso di Windows, la risposta è semplice. Omettendo la storia degli hash di Microsoft, l'azienda implementa due tipi di hash per le password: gli hash LM e gli hash MD4 (Message Digest 4). Per impostazione predefinita, Microsoft utilizza gli hash LM e i valori vengono memorizzati per tutte le password fino a 14 caratteri a meno che non si disattivi manualmente tale funzione. Queste password sono suddivise in due valori di 7 caratteri: il primo valore corrisponde ai primi 7 caratteri, il secondo agli ultimi 7, come illustrato nella figura 1.
Figura 1 Esempio di tabella hash
Nome account | RID | Hash LM | Hash NT | Password | Note
Administrator | 500 | aad3b435b51404ee: aad3b435b51404ee | 31d6cfe0d16ae931: b73c59d7e0c089c0 | PW vuota | L'hash LM è identico all'hash LM della password di 20 caratteri.
Administrator | 500 | 0182bd0bd4444bf8: aad3b435b51404ee | 328727b81ca05805: a68ef26acb252039 | PW di 7 caratteri = 1234567 | La prima parte, che rappresenta i primi 7 caratteri, è identica alla password di 8 caratteri.
Administrator | 500 | 0182bd0bd4444bf8: 36077a718ccdf409 | 0182bd0bd4444bf8: 36077a718ccdf409 | PW di 8 caratteri = 12345678 | La prima parte, che rappresenta i primi 7 caratteri, è identica alla password di 8 caratteri, ma la seconda è diversa.
Administrator | 500 | aad3b435b51404ee: aad3b435b51404ee | b79d07c2ecb3d565: 033ece663f5a0b2e | PW di 20 caratteri = 9876543210 9876543210 | L'hash LM è identico alla password vuota, in quanto non è possibile creare hash LM per password superiori a 14 caratteri.
Fred | 1221 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | Identica | In questi tre esempi, gli hash LM e NT sono identici. Ciò significa che tutte le password per tutti questi account sono identiche. Microsoft non modifica mai l'algoritmo hash.
Lunedì | 1385 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | Identica
SvcAcctX | 1314 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | Identica
Quindi, se la password è di soli 7 caratteri, è contenuta in un unico hash LM. Per anni, Microsoft ha consigliato di utilizzare almeno 8 caratteri nelle password. La ragione è che l'ottavo carattere fa sì che la password sia suddivisa in due valori hash LM.
Tuttavia, è importante sottolineare che gli hash LM sono ormai largamente noti e molto semplici da eludere. Il loro unico scopo nelle soluzioni attuali è consentire di mantenere la compatibilità con le versioni precedenti dei sistemi di basso livello, come Windows NT® 4.0.
Oggigiorno è consigliabile utilizzare password (in realtà, passphrase) di almeno 15 caratteri o preferibilmente più lunghe, poiché per definizione non genereranno un hash LM. Se richiedere l'utilizzo di password di 15 caratteri nell'ambiente in uso non è un'opzione possibile, occorre disattivare la memorizzazione degli hash LM sia nel processo di creazione immagini (utilizzando i criteri locali), sia nei criteri di gruppo di Active Directory®.
Questi criteri sono disponibili in Configurazione computer\Impostazioni di Windows\Impostazioni protezione\Criteri locali\Opzioni di protezione. È sufficiente abilitare il criterio "Protezione di rete: non memorizzare il valore hash di LAN Manager al prossimo cambio di password".
È importante ricordare che, sebbene un buon criterio preveda l'uso di lettere maiuscole e minuscole, nonché di caratteri numerici o speciali, un ottimo criterio dovrà anche prevedere una lunghezza pari o superiore a 15 caratteri.

Lunghezza superiore equivale a protezione superiore
Uno dei metodi utilizzati di recente per violare i computer sono le cosiddette Rainbow Table, che sfruttano gli hash LM. Tuttavia, le password più lunghe possono rendere tale metodo inefficace.
È sorprendente che molti amministratori responsabili della protezione abbiano pochissime informazioni (o addirittura nessuna) sulle Rainbow Table. Esistono vari metodi per creare Rainbow Table in grado di gestire algoritmi diversi, ma si tratta semplicemente di elenchi pre-calcolati di tutti gli hash LM aventi da 0 a 14 caratteri.
L'aspetto fondamentale delle Rainbow Table è che l'hacker deve innanzitutto ottenere gli hash LM. Questo si ricollega alle domande precedenti relative alle modalità di avvio del sistema (da CD o DVD) e al fatto che gli utenti siano o meno amministratori locali. Oggigiorno è possibile estrarre gli hash LM in pochi secondi utilizzando strumenti gratuiti come pwdump. Utilizzando le Rainbow Table, si cercano quindi gli hash per determinare la password.
Per curiosità, ho impostato una password per l'account predefinito Administrator di un sistema. Era di 14 caratteri e conteneva diverse lettere maiuscole e minuscole, nonché caratteri speciali e numeri. Quindi, utilizzando Rainbow Table scaricate gratuitamente da Internet, mi è stato possibile estrarre gli hash delle password per tutti gli account del sistema e determinare la password dell'amministratore in meno di due minuti.
È piuttosto interessante osservare come venga individuato facilmente il primo hash LM, seguito dal secondo, e come, unendoli, sia possibile risalire alla password. Ripetendo quanto detto in precedenza, se gli hash LM fossero stati disattivati utilizzando i criteri menzionati, questo particolare vettore di attacco sarebbe stato notevolmente limitato, se non del tutto bloccato.

Violazione di dominio
L'appartenenza a un dominio non risolve il problema. Per i computer all'interno di un dominio, infatti, l'autenticazione avviene comunque nello stesso modo e, come già sottolineato, ogni dominio è praticamente un gruppo di lavoro. Non sempre questa semplice affermazione è ovvia. Nelle numerose conversazioni sull'argomento, spesso ho dovuto ricordare agli amministratori quali sono gli elementi necessari per accedere a un computer: un nome utente e una password. Di seguito spiegherò come Windows funziona in un gruppo di lavoro.
Se si tenta di accedere a un sistema, occorre fornire un nome utente e una password al sistema remoto. Utilizzando l'autenticazione integrata, Windows tenterà di eseguire tale operazione per l'utente. Questo significa che, se si accede a un altro sistema Windows, Windows utilizzerà il nome utente e la password utilizzati per l'accesso corrente. Pertanto, quando si tenta di accedere a un altro sistema Windows, se il sistema remoto dispone dello stesso nome utente e della stessa password, questi non verranno richiesti.
Tale processo è anche definito autenticazione pass-through e funziona in gruppi di lavoro, nonché tra domini diversi. Nel peggiore dei casi, il sistema chiederà il nome utente e la password e l'utente dovrà limitarsi a immettere nuovamente le informazioni di accesso.
Anche se si aggiungono una workstation o un server a un dominio e Active Directory diventa l'archivio account centrale, tutti gli archivi account locali e i sistemi di gestione account di protezione (SAM) locali su tali sistemi non scompaiono come per magia. L'unica modifica che sembra verificarsi nei SAM locali è che non vengono più gestiti e protetti, ed è proprio questa la radice del problema. A quando risale l'ultima modifica dell'account predefinito Administrator o account radice sul sistema in uso? Per saperlo, è sufficiente scaricare una qualsiasi utilità di generazione report che mostri la validità delle password per tutti gli account e verificare se i risultati supererebbero un controllo.
Se ancora non si è convinti, selezionare una qualsiasi delle workstation di dominio e accedervi come account di dominio con privilegi di amministratore. Accedere a Gestione computer nel proprio sistema e creare un account utente locale denominato ToldYouSo. Assegnare all'account una password e aggiungerlo al gruppo di amministratori locali del sistema. Ripetere la procedura su un secondo sistema del dominio.
Quindi, da uno dei due sistemi, eseguire l'accesso con l'account locale ToldYouSo e tentare di accedere al secondo computer tramite \\systemName\c$. Sarà possibile accedere all'area di amministrazione condivisa e non verrà neppure richiesta una password! Spero che questo esempio non sia una sorpresa per il lettore. Se lo fosse, dovrebbe trarne insegnamento: anche se il sistema appartiene a un dominio, ciò non cambia il fatto che tutti questi sistemi operano come se facessero parte di un gruppo di lavoro.
Il punto è che, se per gli account condivisi e privilegiati si utilizzano password che vengono modificate raramente, o addirittura mai, tali account sono a rischio. La compromissione dell'intera rete sarà solo una questione di tempo.

Scuse, scuse, scuse
Quando discuto con gli amministratori e con i CIO, spesso sento le stesse ragioni per non modificare le password degli account:
  • Abbiamo migliaia di sistemi e non abbiamo tempo o personale sufficienti per modificare gli account.
  • Non abbiamo le risorse economiche necessarie.
  • Abbiamo disattivato completamente gli account amministratore.
  • Non si sono ancora verificate violazioni, quindi non lo riteniamo un vero problema.
  • I revisori non se ne sono accorti.
Sebbene le prime due ragioni siano comprensibili, non sono scuse valide. L'idea che le proprie informazioni personali siano memorizzate da aziende che per un motivo o per l'altro non si occupano di questo problema fa rabbrividire.
Pur essendo vero che non tutti i sistemi di una rete contengono informazioni riservate, potenzialmente gli utenti dei computer hanno accesso a informazioni di questo tipo, ad esempio numero di previdenza sociale, cartelle mediche e dati finanziari. In quanto amministratore di sistema, un utente può installare keystroke logger e utilità di acquisizione schermate, impedire l'applicazione di criteri di gruppo, introdurre shim in vari sottosistemi per l'acquisizione e la trasmissione di dati e così via. Inoltre, quando l'utente esegue tali operazioni a livello di singolo computer, la possibilità di individuarlo è limitata, poiché utilizza il nome amministratore.
I lettori sanno che la disattivazione dell'account predefinito Administrator in Windows non impedisce di eseguire l'accesso con tale account? Provare per credere: riavviare il sistema in modalità provvisoria ed eseguire l'accesso con l'account predefinito Administrator. Probabilmente, sarà possibile utilizzare la password assegnata all'account dall'immagine originale ed eseguire l'accesso. Per ulteriori informazioni in merito, consultare l'articolo della Microsoft® Knowledge Base "Modalità di accesso al computer dopo la disattivazione dell'account dell'amministratore" (support.microsoft.com/kb/814777).

Requisiti degli enti di vigilanza
Occuparsi di SOX, PCI, HIPAA e di altre normative può risultare complesso. Analogamente, comprenderne i requisiti non è facile, perché sono numerosi e non definiti in modo chiaro. In generale, gli obiettivi di tali normative si possono riepilogare come segue:
Innanzitutto, occorre garantire chi ha accesso a tutte le informazioni e agli account privilegiati in qualsiasi momento e dotarsi di un metodo di verifica. Si tratta di un buon comportamento in ogni scenario, in quanto un account privilegiato dispone dei diritti per l'esecuzione di qualsiasi operazione su qualsiasi sistema. Rientrano in questa tipologia l'account predefinito Administrator, l'account di emergenza e tutti gli account probabilmente noti a tutto il personale di assistenza e a tutti gli amministratori che lavorano presso l'azienda.
Quando si sceglie di implementare una soluzione per la gestione delle password di questi account condivisi, si crea un audit trail per l'account predefinito Administrator (nel caso in cui non ne esista uno) e si ottiene una password fluida. E, poiché la soluzione è automatizzata, non è necessario sottrarre settimane di tempo alle attività produttive per modificare le password. Infine, poiché la soluzione rende disponibili funzionalità di verifica, l'azienda avrà fatto un altro passo avanti verso il superamento dei controlli degli enti di vigilanza.

Un approccio automatizzato
Il metodo più efficace per gestire account come questi è modificarli regolarmente, in modo che due account non condividano mai la stessa password. In caso di password condivise, infatti, compromettere un sistema equivarrebbe a compromettere anche l'altro. In altre parole, non devono esistere account locali o di dominio comuni.
Quando si utilizzano soluzioni automatizzate in grado di gestire e impostare le password in modo casuale, evitare di fare il minimo indispensabile richiesto dai revisori. Ad esempio, perché utilizzare solo 8 caratteri per le password quando se ne potrebbero utilizzare 15, 20 o 127 senza ulteriori sforzi (vedere figura 2)?
Figura 2 Utilizzo di un sistema automatico per la creazione di password molto lunghe (fare clic sull'immagine per ingrandirla)
Inoltre, prendere in considerazione la possibilità di impostare ogni giorno in modo casuale gli account privilegiati, come illustrato nella figura 3. Non c'è motivo per limitarsi a eseguire questa operazione ogni 90 giorni, quando è possibile eseguirla una o due volte al mese, o persino tutti i giorni. D'altronde, se la procedura è automatizzata, non costituisce un ulteriore carico di lavoro per l'utente. Inoltre, se si esegue questa operazione regolarmente, gli utenti saranno obbligati a recuperare le password dall'apposita interfaccia controllata dello strumento, fornendo un altro audit trail nel caso in cui non ne esista già uno. (Se le password vengono conservate per iscritto in una busta all'interno di una cassetta di sicurezza nell'angolo di un ufficio, per tali password non si ha alcun audit trail, che sarebbe invece disponibile se si utilizzasse una soluzione di gestione password.)
Figura 3 Impostazione casuale giornaliera degli account privilegiati (fare clic sull'immagine per ingrandirla)
Infine, assicurarsi che, quando le password vengono recuperate, possano essere reimpostate casualmente dopo un determinato periodo di tempo successivo al recupero e che tale operazione venga eseguita. In questo caso, non mi riferisco all'impostazione casuale delle password in base a una pianificazione, ma alla creazione di password per un unico utilizzo la cui validità sia di poche ore anziché di alcuni mesi. Anche questo metodo obbligherà gli utenti a recuperare le password dall'apposita interfaccia controllata dello strumento, fornendo un audit trail.

Conclusioni
Il problema della gestione delle password per gli account condivisi deve essere assolutamente affrontato. Per farlo, occorre individuare un metodo per modificare le password con cadenza regolare e in modo affidabile. La soluzione deve essere scalabile e flessibile, deve fornire un accesso sicuro alle password e deve controllare tutte le operazioni eseguite dallo strumento e da ogni utente dello strumento. Inoltre, le password generate devono essere univoche su ciascun sistema, al fine di evitare violazioni dovute alla condivisione di informazioni relative agli account.
Molti produttori si occupano del problema da anni e molti altri sono entrati in questo settore solo di recente. Prima di acquistare una soluzione, condurre ricerche approfondite e provare tutti i nuovi strumenti disponibili, per assicurarsi che si tratti della soluzione più adatta al proprio ambiente.

Christopher Stoneff è Product Manager presso Lieberman Software (liebsoft.com), un'azienda che sviluppa software per la gestione della protezione e dei sistemi. Il suo obiettivo principale sul lavoro consiste nel comprendere non solo "come" ma soprattutto "perché" ogni cosa funziona in un certo modo.


Nelle ultime settimane sono stato abbastanza fortunato da ricevere un corso di aggiornamento su ciò che significa essere un professionista IT. Dato che l'estate è giunta quasi al termine e si pensa già al ritorno a scuola, la tempistica sembra certamente appropriata. Ma devo ammettere che è stato comunque un po' scioccante.
Vedete, noi del team Magazine di Microsoft (il gruppo responsabile della pubblicazione di MSDN Magazine e TechNet Magazine) stiamo per rivedere e migliorare... beh… il nostro processo. Abbiamo finalmente deciso che, essendo nel 2008, dovevamo abbandonare gli ultimi layout cartacei e gli evidenziatori colorati e passare completamente al digitale. Lo so, lo so, siamo dei veri e propri innovatori! Seriamente... era ora che mettessimo in pratica alcune di quelle procedure super efficienti che le grandi aziende software continuano a elogiare.
Mentre ci stavamo abituando al nuovo flusso di lavoro digitale, è diventato subito evidente che venivamo ostacolati dallo strumento che teneva traccia dello stato degli articoli. Era già "digitale," ma era basato su una tecnologia piuttosto antiquata (che speriamo di eliminare dal nostro mondo per sempre) ed era accompagnato da piccole caselle colorate stampate in cima a ogni layout. Alta tecnologia, eh? Così mi sono messo al lavoro per trovare un modello di prova valido e ho pensato che SharePoint sarebbe stato perfetto.
Lasciatemi andare avanti e dire solamente che ho appena riscoperto un sentimento di profondo rispetto per gli amministratori di Sharepoint. Questa non è una critica a SharePoint, tutt'altro, tanto di cappello alla potenza e alla flessibilità della piattaforma, ma creare una soluzione personalizzata del flusso di lavoro in SharePoint è davvero difficile! Grazie al cielo, il nostro articolo Inside SharePoint che mi è venuto in aiuto. Affrontare questa nuova sfida dopo anni di assenza dalle prime linee mi ha fatto capire che mi serviva aiuto: era ora di tornare in aula!
Al momento ci sono molte risorse utili che possono aiutare a riesaminare i concetti di base o a proiettare l'utente verso qualcosa di nuovo: da tutto ciò che si trova nella nuova serie di video "Come?" su TechNet (technet.microsoft.com/cc138021), agli screencast che facciamo nella rivista (.com/video), a TechNet Edge (edge.technet.com) e molto altro ancora. Credo però che sia ormai ora di ampliare la copertura dei "concetti di base" in TechNet Magazine. Non per vantarci, ma penso che siamo stati abbastanza bravi nel fornirvi il materiale tecnico approfondito che avete letto e, speriamo, apprezzato. Penso però che non farebbe male a nessuno riesaminare i principi di base di tanto in tanto. Quindi... godetevi ciò che resta dell'estate, perché presto dovremo tutti tornare a scuola! -Joshua Hoffman

Si ringraziano i seguenti esperti tecnici Microsoft: Nathan Bigman, Nino Bilic, Mai-lan Tomsen Bukovec, Eric Charran, Trina Gorman, Gershon Levitz, Thomas Marquardt, Mandy Maxwell, Michael Murgolo, Sanjeev Nair, Michelle Rutzer, Jez Sadler, Jim Truher e Shimon Yannay.


Letters La parola ai lettori

Strumento SharePoint Capacity Planning
La mia azienda ha meno di 600 dipendenti, molti dei quali non utilizzano in modo attivo i loro computer e l'intranet aziendale, ma esiste comunque l'esigenza comune di comunicazione e collaborazione a livello aziendale. Credo che Windows® SharePoint® Services (WSS) 3.0 sarebbe perfetto per il nostro ambiente, ma il mio manager ha preventivato l'utilizzo di un unico server a questo scopo.
Ho tentato di utilizzare lo strumento SharePoint Capacity Planning, ma non sembra consentire la simulazione di un modello di server unico. Esiste un'opzione di simulazione per un unico server?
— Allen M.
Non credo esista un'opzione per un unico server, ma è difficile parlare di dimensioni senza considerare i comportamenti di tutti gli utenti. Io utilizzerei una CPU quad-core, iniziando con 8 GB di RAM. Fondamentalmente, un server di gamma media dovrebbe essere adatto.
Joel Oleson ha raccolto diversi riferimenti per il dimensionamento, disponibili sul suo blog all'indirizzo blogs.msdn.com/joelo/archive/2007/07/09/capacity-planning-key-links-and-info.aspx. Questi potrebbero aiutarti a prendere la decisione migliore per soddisfare le esigenze della tua azienda.
— Pav Cherny, Columnist
Inside SharePoint

Microsoft Bob
So che l'intento dell'articolo Windows Confidential "E la storia continua" (luglio 2008, technet.microsoft.com/magazine/cc565089) era rivelare che il programma Microsoft® Bob è nascosto sul disco di Windows XP, ma si è trattato anche dell'ennesima stroncatura di un programma che i miei figli adoravano e che è servito loro per imparare il funzionamento di base degli elaboratori di testo. Abbiamo ricevuto Bob in dotazione con il nostro primo computer, un NEC Ready con Windows 95. Crescendo, tutti i miei figli hanno giocato con Bob per ore.
Nell'articolo, Bob è stato ridicolizzato in quanto prodotto con una pessima tecnologia, ma in realtà si trattava di un ottimo software che è stato semplicemente lanciato sul mercato sbagliato, . . ossia quello degli adulti. Era destinato ai bambini e, se fosse stato presentato in questo modo, sarebbe stato visto sotto una luce diversa e forse avrebbe avuto un altro destino. Chi può saperlo? Se fosse stato lanciato sin dall'inizio come programma per bambini, forse sarebbe ancora in circolazione e i miei nipoti in futuro potrebbero ancora giocarci.
— Jim S.

La stampa è morta
Ho trovato molto interessante l'articolo del redattore "La stampa è morta" di luglio 2008 (disponibile all'indirizzo technet.microsoft.com/magazine/cc595615). A mio parere, i testi di IT in versione stampata passeranno presto a miglior vita e saranno sostituiti da supporti digitali. Tuttavia, secondo l'articolo, il 90% dei lettori consultati preferisce la carta stampata. L'indagine era rappresentativa? Oppure hanno risposto al questionario solo i lettori che acquistano il giornale in forma cartacea? In tal caso, il gruppo non includerebbe la generazione dei più giovani, che non si abbonano più a giornali come questo, ottengono tutte le informazioni in linea e non hanno mai sentito parlare dell'indagine.
Un lettore di un testo stampato non può avviare un video o un webcast tramite il testo scritto. Non può fare clic con il mouse su un collegamento Internet per aprire una home page, un newsgroup o un blog. Non può utilizzare il mouse per scaricare un componente aggiuntivo o uno strumento che nel testo stampato è stato solo citato.
Per riassumere il mio punto di vista: la carta stampata è un pessimo compromesso. Il lettore presto si renderà conto che la lettura su carta offre solo una minima parte dei vantaggi del DVD, il cui contenuto può ad esempio essere copiato su un computer portatile e consultato in qualsiasi momento e luogo.
— Ulrich S.
Grazie per la nota e i commenti! Per rispondere alle domande specifiche relative al 90% dei lettori che affermano di preferire la stampa, il sondaggio è stato condotto tra gli abbonati al giornale in forma cartacea e i lettori Web (con circa la stessa percentuale di entrambi) come parte della nostra ricerca editoriale annuale, presentata in forma elettronica, non cartacea. La domanda è stata posta a coloro che hanno affermato di aver letto entrambe le versioni (stampata e in linea) e il 90% ha detto di preferire la stampa.
Sebbene sia completamente d'accordo con te riguardo ai vantaggi della pubblicazione di contenuti in linea (supporti completi, portata globale, collegamenti sui quali fare clic e così via), continuo a pensare che leggere un articolo su carta stampata sia un'esperienza più coinvolgente. Mi sento più a mio agio e più in sintonia con il contenuto e molti altre persone sembrano condividere le mie stesse sensazioni. Detto questo, il fatto che ogni mezzo presenti i propri vantaggi è il motivo per cui continuiamo a pubblicare TechNet Magazine in entrambe le versioni. Grazie ancora!
— Joshua Hoffman, caporedattore


Toolbox Nuovi prodotti per professionisti IT
Greg Steen

Monitoraggio dei server
Mastering SQL Server 2005 Reporting Services Infrastructure Design
sybex.com
Più le infrastrutture diventano complesse, più gli amministratori sono sommersi da informazioni, la maggior parte delle quali è registrata in file o in database. Ma per utilizzare al meglio tutte queste informazioni sono necessari un motore analitico e uno strumento che presenti i dati analizzati in un formato significativo. Uno strumento molto utile per queste operazioni è Microsoft® SQL Server® 2005 Reporting Services, che aggrega tutti i dati per poi presentarli in un formato leggibile dall'utente. Inoltre, può fornire informazioni a diverse postazioni in modo automatico o su richiesta, fornendo quasi in tempo reale agli utenti aziendali i dati di cui hanno bisogno per prendere decisioni appropriate.
Pianificare, distribuire e gestire un'ottima infrastruttura di Reporting Services (o qualsiasi nuova infrastruttura di server) che soddisfi le esigenze aziendali e sia scalabile richiede preparazione, competenze tecniche e un po' di coraggio. Se si ha intenzione di implementare un'istanza di Reporting Services, il libro Mastering SQL Server 2005 Reporting Services Infrastructure Design di Joseph L. Jorden (Sybex, 2007) può essere utile perché aiuta a comprendere l'infrastruttura e illustra i punti chiave della sua installazione.
Il libro copre gli aspetti riguardanti l'implementazione dei sistemi (sui quali spesso si sorvola), per poi approfondire i dettagli tecnici relativi alla distribuzione di Reporting Services. Questi aspetti fondamentali comprendono le ragioni per cui si implementa il sistema e i requisiti d'uso aziendale, come pure la gestione delle aspettative degli utenti finali. Uno dei capitoli è dedicato alle strategie per la gestione delle modifiche nel sistema di reporting. Questo capitolo descrive diversi approcci alla gestione delle modifiche e fornisce un modello e linee guida per i moduli di richiesta delle modifiche. In genere, la burocrazia non presenta molti vantaggi, ma in questo caso una struttura adeguata garantirà un ambiente molto più stabile.
Dopo aver esaminato Reporting Services dal punto di vista delle aspettative aziendali, il libro approfondisce l'argomento della distribuzione, trattando i concetti base di installazione, scalabilità, automazione e configurazione. Il testo contiene anche suggerimenti sulla modalità di integrazione con Microsoft Windows® SharePoint® Services (WSS) e fornisce un buon punto di partenza per stilare un elenco di controllo che consenta di evitare ostacoli in fase di distribuzione.
Tra le nuove caratteristiche di SQL Server 2005 Reporting Services sono presenti funzionalità di reporting ad hoc, che consentono agli utenti di creare report in tempo reale. Il libro spiega come attivare queste funzionalità e come configurare lo strumento Generatore report. Passa poi alla descrizione di come creare sottoscrizioni per i report, che consentono di generare e distribuire i report in base a una pianificazione utilizzando messaggi di posta elettronica, la condivisione dei file o la funzionalità di consegna integrata di SharePoint.
Col tempo, tutti i sistemi necessitano di manutenzione e il capitolo successivo descrive attività essenziali quali backup dell'istanza, gestione dei contenuti dei report e risoluzione dei problemi avvalendosi dei registri disponibili. Inoltre, è presente un capitolo con informazioni utili sulla protezione, che descrive le opzioni di autenticazione e autorizzazione per la distribuzione.
I programmatori apprezzeranno il capitolo relativo all'estensione di Reporting Services, nonché quello sull'accesso e la manipolazione dei report tramite applicazioni basate su Microsoft .NET Framework. Il linguaggio RDL (Report Definition Language) è uno degli aspetti fondamentali di Reporting Services e un capitolo è dedicato ad alcuni elementi principali a disposizione dell'utente, alla struttura di un file RDL e ai concetti base per la creazione e la distribuzione di tali file.
Il libro termina con alcuni suggerimenti per l'ottimizzazione delle prestazioni dell'istanza di Reporting Services. Fornisce informazioni su come valutare le prestazioni, apportare modifiche ai file di configurazione e utilizzare la console delle prestazioni. Infine, l'appendice contiene informazioni utili sull'integrazione di Reporting Services con SharePoint. Questo libro può essere molto utile per chi intende implementare SQL Server 2005 Reporting Services nel proprio ambiente, poiché fornisce consigli preziosi in merito.

Prezzo: $49.99 (diretto).

Controllo dell'ambiente
Alloy Discovery Professional Edition
alloy-software.com
Poter recuperare rapidamente informazioni per un determinato sistema nella propria area di copertura è di fondamentale importanza per svolgere il proprio lavoro, risolvere i problemi e verificare che i sistemi siano aggiornati e conformi ai criteri relativi a software e protezione. Inoltre, disporre di tali informazioni in un formato intuitivo per gli utenti aziendali e che consenta di eseguire valutazioni rapide dell'infrastruttura, può essere un grande vantaggio (senza menzionare che può fare un'ottima impressione ai dirigenti aziendali). Se ciò non fosse ancora sufficiente, questo rapido accesso alle informazioni può consentire di individuare i singoli utenti che utilizzano un determinato software al fine di assicurarsi che dispongano della licenza appropriata. Uno strumento per inventario e controllo al quale vale la pena dare un'occhiata è Alloy Discovery Professional Edition di Alloy Software.
È molto semplice configurare questa applicazione ed è possibile avviare il controllo su un gruppo o una serie di computer sulla LAN in tempi molto rapidi. Nell'interfaccia utente i computer sono raggruppati in una vista organizzata molto simile a quella di Internet Explorer® e, una volta configurati il gruppo o i gruppi di computer controllabili, è possibile eseguire un controllo su qualsiasi gruppo con un semplice clic. Le informazioni raccolte sono esaustive e riguardano componenti hardware e software, dispositivi, stampanti, condivisioni e persino gli eventi. È inoltre possibile visualizzare codici di matricola, numeri di serie, statistiche sui tempi di attività, variabili dell'ambiente, configurazione di rete e account utente locali. In pratica, è possibile reperire qualsiasi informazione sull'ambiente in uso senza neppure lasciare la propria scrivania (nonostante faccia bene sgranchirsi le gambe di tanto in tanto).
Oltre a eseguire controlli dei computer su richiesta, è anche possibile pianificarli. Per i computer al di fuori della LAN diretta e per quelli ai quali non è possibile connettersi in modalità remota con privilegi sufficienti per eseguire le attività di controllo, Alloy Discovery offre un metodo basato sull'agente per controllare i computer di destinazione. Questo tipo di controllo può essere inserito in uno script e pianificato affinché venga eseguito periodicamente oppure può essere eseguito tramite l'agente e inviato in un messaggio di posta elettronica dall'agente stesso all'archivio principale di Alloy Discovery. Un'altra opzione consiste nel copiare l'agente su un'unità di memoria flash, quindi passare di computer in computer per avviare il controllo. Dopo il controllo, è possibile sincronizzare le informazioni automaticamente o manualmente, a seconda del metodo utilizzato nell'archivio principale.
Alloy Discovery dispone inoltre di filtri che possono essere applicati ai risultati dei controlli per analizzare l'inventario a livello globale. Ad esempio, è possibile verificare per quanti computer è necessario un aggiornamento di memoria per il supporto di un'applicazione oppure controllare quali computer nel proprio ambiente eseguono Windows® XP Professional e quali Windows Vista® Business Edition.
Una volta ottenuti i dati, è possibile creare dei report che possono essere pubblicati dall'applicazione in pagine HTML nelle quali è disponibile la funzione drill-down. È anche possibile configurare un'attività pianificata per la generazione di tali report a intervalli regolari, un'opzione estremamente utile per il Network Operations Center (NOC). Infine, è possibile esportare tutte le informazioni relative ai controlli in formato XML, CSV o Microsoft Excel®, ad esempio per fornire prove ai revisori.

Prezzo: $795 (diretto) per il prodotto di base, più $3 per ciascun nodo. ﻿
Controllo dell'ambiente in uso con Alloy Discovery (fare clic sull'immagine per ingrandirla)

Gestione delle password
Password Corral
cygnusproductions.com
Nel mondo odierno, caratterizzato da un'estrema interconnettività, le password sono un'esigenza naturale (per lo meno finché non sarà tutto basato sulla biometrica o finché non creeremo un mondo utopico in cui tutti si fidano di tutti, ma nessuno dei due scenari si concretizzerà nell'imminente futuro). In genere, gli utenti dispongono di diversi tipi di password per diversi tipi di ambiente e modificano tali password su supporti diversi.
Oltre alle password d'uso comune, esistono password di sistema per account amministratore, account di servizio e vari account di dominio. E, naturalmente, esistono diversi nomi utente associati a tali password. E potrei andare avanti così per un po'. Quindi com'è possibile tenere traccia di tutte queste password in modo semplice e sicuro?
Un metodo consiste nell'utilizzare un archivio di password i cui dati siano protetti in un file con crittografia avanzata e un'ottima soluzione di questo tipo è fornita da Password Corral. Questa applicazione intuitiva e dalla crittografia avanzata, che utilizza Diamond2 o Blowfish per crittografare tutte le password all'interno di un file, è sul mercato dal 2001. Nel tempo, l'applicazione è stata sottoposta a diversi test e prove e viene tuttora supportata e sviluppata con miglioramenti destinati alle versioni attuali e future.
Dopo aver installato il programma, è possibile ottenere un nuovo file di password creando un nuovo utente e selezionando la posizione sul sistema (o unità di rete) in cui verrà memorizzato il file . Va da sé che, se si ha intenzione di conservare tutte le informazioni riservate relative alle password per tutti gli account in un unico file di Password Corral, la password di quest'ultimo dovrà essere incredibilmente complessa e modificata di frequente. Questa sarà l'unica vera password da ricordare e proteggere con maggiore attenzione.
Una volta eseguita l'autenticazione, Password Corral offre un'interfaccia utente molto simile a quella di Internet Explorer, con una struttura gerarchica di cartelle sulla sinistra e un riquadro contenente dettagli sulla destra. È possibile organizzare le password in una struttura di cartelle ad albero. Tutte le password possono avere una descrizione, un nome utente, una password, un URL di riferimento, un indirizzo di posta elettronica di riferimento e commenti relativi all'account. Inoltre, è possibile comunicare all'applicazione i criteri password per ciascun account, specificando il numero di giorni nel ciclo di scadenza e il numero di giorni rimanenti fino alla scadenza di una determinata password.
Una delle opzioni di visualizzazione consente di impostare un filtro per le password scadute, in modo da visualizzare gli account che dovranno essere reimpostati la prossima volta che li si utilizza. Un'altra funzionalità molto utile è la possibilità di generare password tramite il programma, in modo che non spetti all'utente inventare password complesse per ciascun account. Il generatore di password è personalizzabile e consente di impostare la lunghezza, la complessità e la composizione di caratteri desiderate.
Un'altra funzionalità utile è la possibilità di ricercare facilmente tutte le password, dopo averle inserite, in base a uno qualsiasi dei campi per i quali sono stati immessi dati. Ciò consente, ad esempio, di individuare gli account utente utilizzati con minor frequenza in una struttura di cartelle complessa. È anche possibile impostare un timeout in modo che, se si dimentica di chiudere Password Corral, l'applicazione si bloccherà in modo automatico, proteggendo le informazioni riservate. Per impostazione predefinita, l'applicazione cancellerà inoltre gli appunti in modo automatico all'uscita, qualora la password copiata nel buffer sia stata lasciata in tale posizione dopo averla utilizzata.
Se è necessario accedere costantemente alle password, è possibile utilizzare l'icona di Password Corral nella barra delle applicazioni, che consente di avviare l'applicazione con un semplice doppio clic. Se si desidera utilizzare Password Corral e memorizzare gli account in altre posizioni, l'applicazione permette di importarli da un file, eliminando l'esigenza di immettere i dati manualmente. Permette inoltre di esportare le password e stamparle, ma sarà necessario mangiare la carta a lavoro ultimato! Nel complesso, si tratta di uno strumento gratuito estremamente utile.

Prezzo:gratuito.
Monitoraggio delle password con Password Corral (fare clic sull'immagine per ingrandirla)

Utilizzo di file di controllo
File System Auditor
scriptlogic.com
Disporre di un audit trail su file system condivisi può evitare molti problemi ed è comunque necessario per soddisfare alcuni standard relativi ai criteri di conservazione delle informazioni. Per individuare chi ha eseguito certe operazioni e quando, può risultare utile l'utilizzo di File System Auditor prodotto da ScriptLogic. Questa applicazione è un sistema di gestione centralizzato che controlla l'utilizzo di file su sistemi di destinazione quasi in tempo reale, memorizzando le informazioni in un database SQL Server ai fini della generazione di report sull'utilizzo.
File System Auditor supporta Microsoft SQL Server Desktop Engine (MSDE), SQL Server 2000 e tutte le versioni di SQL Server 2005 (inclusa la versione gratuita SQL Server 2005 Express). Per ciascun sistema monitorato, è necessario installare un agente, che viene utilizzato per controllare l'utilizzo dei file e generare un report per SQL Server. Dopo l'installazione, è possibile utilizzare la procedura guidata database per creare l'archivio database nel quale saranno memorizzate tutte le informazioni di controllo.
Gli amministratori di sistema probabilmente staranno pensando alla larghezza di banda e al livello di dettaglio dei sistemi utilizzati di frequente, ma l'applicazione sfrutta un sistema di controllo intelligente che combina diverse operazioni in una sola voce di controllo. Per quanto riguarda la larghezza di banda, File System Auditor utilizza solo 100 byte di dati per il primo accesso a un file e da 10 a 20 byte per ogni accesso successivo.
Ci si potrebbe domandare perché non utilizzare il controllo nativo di Windows per queste operazioni, ma le funzionalità di reporting, combinazione eventi e amministrazione centralizzata di un'applicazione di monitoraggio dedicata sono più flessibili e facilmente utilizzabili. Inoltre, il fatto che tutte le informazioni si trovino in un database SQL ne semplifica la consultazione da altri sistemi.
Dopo aver configurato il database, impostare gli agenti sui server di destinazione mediante l'apposita console. È possibile immettere il nome di un server oppure selezionarlo mediante Active Directory®. File System Auditor supporta inoltre file server in cluster, quindi è possibile immettere il nome della propria istanza di cluster. In seguito, occorre installare il servizio agente (se l'account dispone di accesso remoto, è sufficiente un semplice clic) e selezionare l'account Windows o SQL Server che l'agente deve utilizzare per connettersi al database di File System Auditor.
Per ciascun server, è possibile configurare tre tipi diversi di esclusioni di monitoraggio: filtri di percorso, filtri di esclusione processi e filtri di esclusione utenti. I filtri di percorso consentono di selezionare un percorso e scegliere se includere o escludere determinati eventi relativi a file e cartelle, quali modifiche, creazione ed eliminazione di autorizzazioni. Le esclusioni di processi e utenti consentono di eseguire la stessa operazione per eventi di file e cartelle associati a un determinato processo sul server di destinazione, ma non supportano i filtri di tipi di file.
Dopo aver eseguito la configurazione e aver iniziato a raccogliere eventi di controllo, avviare la console di configurazione report per poter utilizzare tali dati. Per configurare un report, è possibile impostare vari filtri per i dati, compresi utenti, determinati eventi relativi a file o cartelle, percorsi, server, processi e intervalli di date. Inoltre, è possibile pianificare il report e fare in modo che l'applicazione invii il report pubblicato per posta elettronica mediante il server SMTP in uso. Infine, per controllare ciò che accade ai file in un sistema in tempo reale, si può avviare il visualizzatore in tempo reale per osservare gli eventi scorrere come se si stesse "pedinando" un file di registro.

Prezzo: si parte da $800 (diretto) per il programma e una licenza server.
Utilizzo di file di controllo con File System Auditor (fare clic sull'immagine per ingrandirla)

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


Utility Spotlight Strumento di diagnostica memoria Windows
Lance Whitney

Il download del codice è disponibile in: Utility2008_09.exe (640 KB)

Indice
Come ottenere lo Strumento di diagnostica memoria Windows
Test della memoria
Uno dei computer di cui si è responsabili ne sta combinando di tutti i colori: si blocca, si arresta, visualizza una schermata blu. È colpa di un componente hardware? È un'applicazione installata di recente che causa problemi? O potrebbe trattarsi di memoria difettosa? Un modo per scoprirlo con sicurezza è l'utilità gratuita di diagnostica della memoria di Microsoft® Windows®. Questo strumento esegue una serie di test sulla RAM del computer per determinare se sono presenti difetti in alcuni dei moduli.

Come ottenere lo Strumento di diagnostica memoria Windows
Per utilizzare lo Strumento di diagnostica memoria Windows, scaricare ed eseguire il singolo file mtinst.exe da oca.microsoft.com/en/windiag.asp. Si tenga presente che non è necessario installare lo Strumento di diagnostica memoria Windows. Lo strumento si presenta con due opzioni, come visualizzato nella schermata seguente:
Figura 1 Opzioni dello Strumento di diagnostica memoria Windows per la creazione di supporti avviabili (fare clic sull'immagine per ingrandirla)
  • Create Startup Disk... (Crea disco di avvio), da cui è possibile creare un disco floppy di avvio con il programma.
  • Save CD Image to Disk... (Salva immagine CD su disco), da cui è possibile salvare un'immagine ISO del programma sul disco rigido. È quindi possibile salvare l'immagine su CD e renderlo avviabile utilizzando il software di creazione CD. Dopo aver creato il supporto avviabile, riavviare il computer e iniziare la diagnostica dal floppy o dal CD.
Test della memoria
Quando il programma viene caricato, inizia immediatamente la scansione della RAM. Lo Strumento di diagnostica memoria Windows inizia in modalità standard, che contiene 6 diversi test di memoria consecutivi, ciascuno dei quali utilizza un algoritmo unico per eseguire la scansione per diversi tipi di errori. Una schermata visualizza ogni singolo test mentre viene eseguito, indicandone l'avanzamento e l'intervallo di indirizzi di memoria dei quali si sta eseguendo la scansione. Al termine dei 6 test, lo strumento riprende l'analisi utilizzando gli stessi test e proseguirà in questo modo finché non si esce dal software. In genere, è comunque sufficiente una sola esecuzione dei test per determinare se la memoria è difettosa.
Se si desidera eseguire test più approfonditi, è possibile passare alla modalità estesa, che esegue 11 test di memoria. Esiste anche una modalità di base che esegue soltanto 2 test, ma se si desidera effettuare test accurati, si consiglia di utilizzare le modalità standard ed estesa. Se si esegue la suite di test estesa, si consiglia di lasciare lo Strumento di diagnostica memoria Windows in esecuzione durante la notte.
Al completamento di ogni test, lo strumento indica se il test è stato completato correttamente o se sono stati rilevati problemi. Se sono stati rilevati problemi, ne vengono riportati i dettagli e spesso questo indica che uno dei moduli RAM è difettoso. A seconda dell'ambiente del computer, la diagnostica potrebbe essere in grado di associare un problema di memoria a un modulo specifico.
In questo caso, nel menu appare un'opzione per la visualizzazione degli errori in base al modulo di memoria. Questa opzione può aiutare a individuare i moduli difettosi specifici che devono essere sostituiti.
Nelle schermata delle opzioni avanzate, è possibile scegliere la modalità di base, standard o estesa. Inoltre è possibile disattivare la cache del processore durante le scansioni, per obbligare lo strumento ad accedere ai dati direttamente dalla RAM, il che garantisce una maggiore affidabilità dei test. Il comando relativo alle informazioni di sistema elenca la capacità e il tipo di RAM installati in ciascuno slot.
Lo Strumento di diagnostica memoria Windows supporta le piattaforme basate su x86, tra cui i processori Intel Pentium e Celeron e le CPU AMD K6, Athlon e Duron. Tuttavia, lo strumento può analizzare soltanto un massimo di 4 GB di RAM e non eseguirà la scansione oltre questo limite.
È anche possibile trovare una versione di questo strumento di diagnostica installata in Windows Vista® in Strumenti di amministrazione e nei supporti di installazione di Windows Vista nell'opzione di ripristino. Tuttavia, la versione di Windows Vista non fornisce altrettante opzioni e altrettanti commenti visivi. Quindi è importante tenere a portata di mano la versione autonoma per la prossima volta in cui uno dei computer comincia a fare i capricci.
Lance Whitney è consulente IT, docente e technical writer. Ha dedicato molto tempo alle modifiche di workstation e server di Windows. All'inizio della sua carriera faceva il giornalista, ma circa 15 anni fa ha fatto un salto nel buio lanciandosi nel mondo dell'IT.


Inside SharePoint Integrazione di directory di SharePoint
Pav Cherny

Download codice disponibile in: SharePoint2008_09.exe (2,775 KB)

Indice
Servizio di gestione directory di SharePoint
Servizio di gestione directory personalizzato
SharePoint e ILM
Conclusioni
Microsoft Windows SharePoint Services (WSS) 3.0 e Microsoft Office SharePoint Server (MOSS) 2007 comprendono funzionalità di sincronizzazione di directory sotto forma di un Servizio di gestione directory che può effettuare il provisioning degli oggetti di gruppo e dei contatti abilitati alla posta per le risorse di SharePoint in Active Directory. Il provisioning di questi tipi di
oggetti destinatario per risorse di SharePoint® permette agli utenti di selezionare le raccolte, gli elenchi ed i gruppi di SharePoint direttamente dalla Rubrica di Microsoft® Outlook® durante l'invio di documenti e di altre informazioni.
Gli oggetti destinatario SharePoint forniscono anche un modo per controllare il trasferimento di messaggi e le conversioni del formato in un'organizzazione Exchange Server. Tra l'altro, è possibile impedire ai mittenti non autenticati, come gli spammer, di inviare messaggi alle raccolte di SharePoint impostando le restrizioni di consegna dei messaggi in Active Directory®.
Tuttavia, le capacità di gestione della directory SharePoint sono limitate e, nel momento della stesura del presente articolo, Exchange Server 2003 viene considerato il sistema di messaggistica sottostante. Per ora, se si utilizza Exchange Server 2007 o un sistema di messaggistica di terze parti, è necessario estendere o sostituire le funzionalità di gestione directory incorporate con una soluzione personalizzata per conseguire il livello di interoperabilità desiderato.
In questo articolo esaminerò brevemente le funzionalità di gestione directory di SharePoint e discuterò poi un approccio per superare i limiti esistenti. La mia premessa è che il Servizio di gestione directory incorporato soddisfa soltanto i requisiti basilari dell'utente. Gli ambienti con una varietà di piattaforme di sistemi di messaggistica e di directory necessitano di maggiore flessibilità e funzionalità. Sostituendo il componente incorporato con una soluzione personalizzata, potrete sincronizzare le informazioni destinatario SharePoint con qualsiasi soluzione di directory che fornisca delle funzionalità di importazione o API.
Per dimostrarlo, vi mostrerò come sincronizzare le informazioni destinatario SharePoint in maniera compatibile con Exchange Server 2007. Allo stesso modo, potrete utilizzare una soluzione personalizzata per sincronizzare le informazioni destinatario con IBM Lotus Notes o con altri sistemi.
Avrete inoltre la possibilità di centralizzare i processi di provisioning della directory basata su un servizio di metadirectory, come l'Identity Information Server, incluso nel Feature Pack 1 (FP1) di Microsoft Identity Lifecycle Manager (ILM) 2007. In particolare, vi mostrerò come integrare SharePoint con ILM 2007 per coordinare il provisioning degli oggetti di directory per le librerie di documenti SharePoint. Potete trovare gli strumenti, il codice sorgente e le istruzioni dettagliate per creare questa soluzione nel materiale di accompagnamento di questo articolo, disponibile nella sezione di Code Download del .com.

Servizio di gestione directory di SharePoint
A differenza di Exchange Server, che utilizza Active Directory per quasi tutte le informazioni sulla configurazione e di destinatario, SharePoint si basa sui database di configurazione e di contenuti. SharePoint deve quindi propagare le informazioni destinatario per le raccolte, gli elenchi ed i gruppi abilitati alla posta dai database a una directory. Dopotutto, i client di messaggistica prevedono di trovare le informazioni destinatario in una rubrica, che solitamente è generata dagli oggetti di directory.
Subito disponibile, a tale scopo SharePoint include un Servizio di gestione directory, che fa parte del servizio Web di integrazione posta elettronica (SharepointEmailWS.asmx) che è possibile configurare in Amministrazione Centrale SharePoint 3.0, nella pagina Operazioni, sotto la voce Impostazioni posta elettronica in arrivo. Figura 1 mostra il funzionamento del Servizio di gestione directory incorporato.
Figura 1 Architettura del Servizio di gestione directory di SharePoint (fare clic sull'immagine per ingrandirla)
Quando si attiva una Web farm per la gestione directory e poi si assegna un indirizzo di posta elettronica ad una raccolta, ad un elenco o ad un gruppo per ricevere i messaggi, come se si utilizzasse EmailSettings.aspx, si chiama implicitamente il servizio Web di integrazione posta elettronica per effettuare il provisioning degli oggetti destinatario corrispondenti in Active Directory. Primo, SharePoint memorizza le informazioni di indirizzo di posta elettronica nel database dei contenuti. Secondo, SharePoint invia la richiesta di provisioning al servizio Web di integrazione posta elettronica utilizzando l'identità dell'account pool di applicazioni Web. Se la richiesta di provisioning fallisce, avrete le informazioni di indirizzo di posta elettronica nel database dei contenuti, ma senza gli oggetti destinatario corrispondenti in Active Directory.
Risorse aggiuntive
  • Sito Web di Prodotti e tecnologie SharePoint
  • TechCenter di Windows SharePoint Services
  • Centro per sviluppatori Windows SharePoint Services
  • Blog del team prodotti e tecnologie Microsoft SharePoint
È possibile che le richieste di provisioning non siano completate correttamente per vari motivi. Il più comune è l'assenza di autorizzazioni per l'accesso al metabase IIS. Poiché SharePointEmailWS.asmx è progettato per essere un servizio Web per gli account pool applicazioni, questo servizio Web controlla il metabase IIS per vedere se il chiamante è un account pool applicazioni e, in caso contrario, nega l'accesso senza badare al sito SharePoint ed ai livelli di autorizzazione Active Directory.
SharePointEmailWS.asmx esegue questo controllo dell'accesso con l'identità del chiamante, comunque, perciò l'account pool applicazioni della chiamata richiederà l'accesso al metabase per verificare le proprie autorizzazioni all'accesso. Questo obbliga a concedere autorizzazioni elevate agli account pool applicazioni per avere una buona riuscita.
Ovviamente, le autorizzazioni elevate su un server Web generano rischi per la sicurezza. Ci sono modi migliori per controllare l'accesso a un servizio Web ASP.NET. Inoltre, SharePoint prevede di trovare il Servizio di gestione directory nel sito Amministrazione centrale, ma questo sito è disponibile solo temporaneamente in una Web farm bloccata per ridurre la superficie di attacco. Così se si desidera utilizzare il Servizio di gestione directory incorporato nell'ambiente di produzione SharePoint, è necessario accettare una configurazione con bassi livelli di protezione.
Gli ulteriori limiti esistenti testimoniano come il Servizio di gestione directory incorporato sia basato su un'architettura client/server strettamente connessa. Microsoft.SharePoint.dll utilizza direttamente System.DirectoryServices.dll, dunque non è possibile implementare la logica per personalizzare il processo di provisioning. Ad esempio, l'implementazione del servizio di gestione directory incorporata non scrive tutti gli attributi destinatario per supportare Exchange Server 2007 e non esiste alcuna opzione per personalizzare le regole di generazione degli attributi.
L'impossibilità di implementare la propria logica implica anche che non è possibile personalizzare il processo di provisioning, ad esempio, per implementare le approvazioni personalizzate. SharePoint supporta i processi di approvazione per i gruppi, ma questa funzionalità è basata sul sito Amministrazione centrale. Soltanto gli amministratori della farm SharePoint possono approvare le richieste in sospeso, ma non è necessariamente compito loro approvare i processi di provisioning di Active Directory.
Cosa forse anche più importante, non esistono processi di approvazione per le raccolte documenti e gli elenchi abilitati alla posta abilitata. Se si attiva la gestione directory, fondamentalmente si concede a tutti gli amministratori nella Web farm il diritto di creare in Active Directory gruppi e contatti abilitati alla posta elettronica. Né è possibile strutturare una gestione destinatario basata su unità organizzative (OU), perché tutti gli oggetti destinatario per Web farm sono collocati nella stessa OU.
Non è possibile spostare gli oggetti destinatario in un'altra OU perché il Servizio di gestione directory prevede di trovare gli oggetti destinatario nell'OU SharePoint ed è necessario concedere all'account pool di applicazioni dell'Amministrazione centrale SharePoint le autorizzazioni amministrative in Active Directory. Inoltre, non c'è modo di implementare la sincronizzazione bidirezionale tra SharePoint e Active Directory. Una modifica degli attributi oggetto in Active Directory non consente la propagazione delle modifiche anche nell'ambiente SharePoint.

Servizio di gestione directory personalizzato
Avendo stabilito che il Servizio di gestione directory incorporato lascia un po' di spazio per creare della flessibilità aggiuntiva, vengono analizzate alcune alternative. La buona notizia è che SharePoint permette di implementare il servizio di gestione directory. È necessario solo registrare il servizio Web come Servizio di gestione directory remoto nell'Amministrazione Centrale SharePoint 3.0, nella pagina Operazioni, sotto la voce Impostazioni posta elettronica in arrivo.
Per le istruzioni dettagliate sulla distribuzione e registrazione ad un servizio Web personalizzato, vedere il foglio di lavoro "Integrazione directory basata su un Servizio di gestione directory personalizzato .xps" nel materiale di accompagnamento. Inoltre, il servizio Web personalizzato illustra come effettuare il provisioning di oggetti destinatario compatibili con Exchange Server 2007 in Active Directory senza strumenti di gestione cmdlet o Exchange. Il relativo codice sorgente si trova nella cartella EmailIntegrationService. Figura 2 mostra l'architettura della soluzione.
Figura 2 Architettura del Servizio di gestione directory personalizzato (fare clic sull'immagine per ingrandirla)
L'interfaccia del servizio Web personalizzato deve aderire all'interfaccia di Servizio di gestione directory, come documentato nell'SDK di SharePoint. Ricercando "SharePointEmailWS" nel sito Web MSDN® (msdn.microsoft.com) è possibile trovare tutte le informazioni necessarie. È, inoltre, possibile consultare il file Service.cs nella cartella EmailIntegrationService\App_Code nel materiale di accompagnamento. Questo file implementa l'interfaccia di servizio Web richiesta, mentre il codice effettivo di provisioning per gli oggetti Active Directory si trova in SPRecipient.cs. Ad esempio, la funzione UpdateRecipientAttributes in SPRecipient.cs genera gli attributi di Exchange Server 2007 richiesti. SPRecipient.cs è il file di codice da sostituire se si vuole sviluppare il proprio servizio di gestione directory personalizzato.
Un servizio di gestione directory personalizzato è un ottimo strumento per risolvere richieste di autorizzazioni elevate ed integrare SharePoint con sistemi di messaggistica o directory di terze parti. Non è necessario controllare il metabase IIS per limitare l'accesso del servizio Web agli account pool applicazioni. È, invece, possibile aggiungere una sezione <authorization> al file web.config del servizio Web (per un esempio, vedere il materiale di accompagnamento).
Persistono, tuttavia, alcuni problemi poiché non sarà possibile controllare se e quando SharePoint chiama il Servizio di gestione directory. Inoltre, SharePoint non chiama il Servizio di gestione directory quando si elimina un elenco o una raccolta di documenti abilitata alla posta e quindi un oggetto destinatario non valido rimane in Active Directory. Che si utilizzi il Servizio di gestione directory incorporato o una soluzione personalizzata, non è possibile garantire che le informazioni destinatario in Active Directory siano compatibili con le risorse SharePoint.

SharePoint e ILM
Per conseguire un'integrazione di directory affidabile, sarebbe opportuno distribuire un pacchetto di gestione directory professionale, come ILM. Questo sistema si basa su un modello di sincronizzazione di directory basato sul pull-model (o su richiesta). Gli agenti di gestione estraggono le informazioni dalle origini connesse, le importano in una metadirectory comune e da questa le esportano ai sistemi connessi. I sistemi di origine solitamente non inseriscono le informazioni nella metadirectory. Estraendo le informazioni, si ottiene certamente coerenza all'interno di ogni ciclo di sincronizzazione.
Un altro vantaggio è che la gestione del ciclo di vita delle informazioni (ILM) contiene diversi agenti di gestione per supportare Active Directory, Lotus Notes ed una serie di altri sistemi forniti con il prodotto. È necessario solo implementare un agente di gestione personalizzato per SharePoint al fine di sincronizzare le informazioni SharePoint con un'altra piattaforma di directory supportata nell'ambiente.
È necessario implementare la logica per recuperare le informazioni desiderate da SharePoint, salvare le informazioni in un file di importazione e trasferire le informazioni importate nella metadirectory. Ma non è necessario implementare la logica per esportare tali informazioni dalla metadirectory in Active Directory o in un'altra piattaforma di directory. Figura 3 illustra come implementare la sincronizzazione da SharePoint a Active Directory utilizzando ILM. È anche possibile conseguire la sincronizzazione nella direzione inversa per effettuare il provisioning delle risorse SharePoint per gli oggetti directory, anche se ciò può sembrare inutile o facoltativo.
Figura 3 Integrazione di directory basata su Identity Lifecycle Manager (fare clic sull'immagine per ingrandirla)
Un buon punto di partenza per sviluppare un agente di gestione SharePoint è rappresentato dall'articolo di Alex Tcherniakhovski "Connessione di ILM 2007 agli elenchi SharePoint Services" su blogs.msdn.com/alextch/archive/2007/09/02/wsslistsandilm.aspx. Alex mostra come creare una soluzione di gestione directory basata su ILM, fondata su richieste di provisioning basate su Infopath® presentate ad una raccolta documenti. L'agente di gestione di Alex recupera tutte le richieste approvate dalla raccolta documenti e crea gli oggetti metadirectory corrispondenti che possono quindi essere esportati nelle directory connesse.
Per impostazione predefinita, SharePoint non genera richieste di provisioning basate su Infopath quando un elenco o un gruppo è abilitato alla posta. Questo si ottiene attraverso un servizio di gestione directory personalizzato, ma poi si verificano dei problemi di coerenza menzionati in precedenza perché SharePoint non chiama il servizio di gestione directory in ogni circostanza. Per questa motivo, consiglio di far recuperare all'agente di gestione le informazioni destinatario di SharePoint desiderate direttamente dagli elenchi e dai gruppi nella raccolta siti. Se sono necessari dei processi di approvazione, è possibile generare richieste di provisioning basate su InfoPath per le nuove risorse nell'agente di gestione ed in seguito elaborare tutte le richieste approvate.
Sono disponibili diverse opzioni per recuperare le informazioni di SharePoint. È possibile leggere le informazioni direttamente dai database del contenuto, utilizzare il modello a oggetti SharePoint o sfruttare i servizi Web di SharePoint.
Sconsigliamo l'accesso diretto ai database del contenuto perché le strutture di database potrebbero cambiare nelle versioni successive, il che interromperebbe la soluzione di gestione directory.
Anche l'utilizzo diretto del modello a oggetti SharePoint nell'agente di gestione risulta difficile perché il modello a oggetti vi richiederà di eseguire il codice localmente, inoltre l'installazione di ILM su un server Web in ogni farm SharePoint dell'ambiente può complicare l'infrastruttura di gestione della directory.
Si possono utilizzare i servizi Web di SharePoint, ma ciò crea un'altra difficoltà poiché le informazioni desiderate non sono facilmente accessibili attraverso i servizi Web di SharePoint, come le informazioni di indirizzo di posta elettronica per i gruppi SharePoint o l'Indirizzo visualizzato server posta elettronica in arrivo.
Dunque, la cosa migliore sembrerebbe implementare un servizio Web di SharePoint personalizzato che utilizzi il modello a oggetti SharePoint per recuperare le informazioni desiderate, inoltrandole al chiamante sotto forma di documento XML. Ora potete centralizzare la distribuzione di ILM ed integrare un numero qualsiasi di farm e raccolte di siti attraverso richieste singole del servizio Web SharePoint personalizzato, come illustrato nella Figura 3.
C'è un ultimo aspetto che vale la pena menzionare, ossia che l'integrazione di directory basate su ILM non elimina il bisogno di un servizio di gestione directory personalizzato. Questo servizio personalizzato non deve eseguire alcuna operazione perché ILM effettua il provisioning degli oggetti directory, tuttavia è necessario fornire un servizio personalizzato in modo da attivare la gestione di directory in Amministrazione centrale di SharePoint 3.0. Altrimenti, ad esempio, in primo luogo, non si può essere in grado di assegnare gli indirizzi di posta elettronica ai gruppi. La Figura 4 illustra l'architettura della soluzione risultante.
Figura 4 Integrazione di directory SharePoint basata su Web Service (fare clic sull'immagine per ingrandirla)
È possibile rendere fittizio il servizio di gestione directory personalizzato incluso nel materiale di accompagnamento, impostando il parametro OpMode nel file web.config (<add key="OpMode" value="dummy"/>). In questa configurazione, il servizio personalizzato restituisce sempre OPERAZIONE COMPLETATA in risposta alle chiamate di provisioning senza eseguire alcuna operazione.
Inoltre, il servizio personalizzato presenta un metodo ResolveUsers che l'agente di gestione SharePoint può chiamare per scomporre i nomi dell'account utente basati su NetBIOS in nomi distinti, che è un passaggio obbligatorio nel provisioning dei gruppi. (SharePoint offre informazioni sull'appartenenza al gruppo sotto forma di elenco di nomi di account utente basati su NetBIOS, ma Active Directory prevede dei nomi distinti). Ed ecco il risultato. Per ulteriori informazioni su come distribuire la soluzione risultante, vedere "Configurazione di integrazione directory basata su ILM 2007.xps" nel materiale di accompagnamento.
WSS 3.0 e MOSS 2007 comprendono un Servizio di gestione directory per integrare SharePoint con Exchange Server 2003 per la collaborazione multipiattaforma basata su messaggistica.
Tuttavia, ciò presenta anche dei limiti. Gli utenti devono sostituire il Servizio di gestione directory incorporato con una soluzione personalizzata. Inoltre, è possibile utilizzare anche una soluzione di gestione directory professionale, come ILM, per integrare SharePoint in un'infrastruttura di gestione directory. Ciò fornisce il maggiore livello di flessibilità e consente di assicurare la coerenza delle informazioni all'interno di un modello di sincronizzazione basato su pull.

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


Windows PowerShell Teoria sulle stringhe
Don Jones

Indice
Un caso reale
Corrispondenze complesse
È un mondo di stringhe
Quando parlo alle conferenze, come Tech•Ed o TechMentor, mi ritrovo spesso a fare dichiarazioni di natura generale che aiutano gli utenti a ricordare le informazioni più importanti su argomenti come Windows PowerShell. La mia ultima dichiarazione è: "Se analizzi una stringa in Windows PowerShell, stai facendo una cosa sbagliata".
Questo deriva dalla mia filosofia in base alla quale Windows PowerShell™ è una shell orientata agli oggetti. Se si eseguono operazioni come copiare elenchi di servizi in un file di testo e analizzare tale file per vedere quali servizi sono stati avviati, si sta sprecando del tempo. Si tratta di un approccio valido in un sistema operativo basato su testo come UNIX, ma Windows PowerShell (come pure Windows®) consente di utilizzare gli oggetti in modo molto più efficiente.
Video
Don Jones dimostra come utilizzare Windows PowerShell per analizzare stringhe complesse.

Anche gli script utilizzati dovrebbero produrre oggetti, non testo formattato, in modo che la formattazione, i filtri, l'esportazione e gli altri comandi della shell possano essere utilizzati per manipolare l'output degli script. (Il mio articolo di luglio 2008 su Windows PowerShell contiene ulteriori informazioni sul concetto degli oggetti personalizzati come output degli script).
Alla recente conferenza TechMentor di Orlando, Florida, uno dei miei studenti mi ha ricordato che quasi tutte le regole, e soprattutto quelle generali, hanno delle eccezioni. "E per quanto riguarda la ricerca di informazioni in un file di registro di IIS? In questo caso non bisogna analizzare il testo?".
Effettivamente sì. E fortunatamente, per quanto possa essere orientato agli oggetti, Windows PowerShell non delude quando si tratta di analizzare stringhe di testo. Pensandoci bene, i file di registro di IIS, i file di registro del firewall e altri file di registro basati su testo costituiscono esempi perfetti.

Un caso reale
In passato ho dovuto analizzare una serie di file di registro del firewall per un'azienda per la quale lavoravo. Un dipendente era stato sorpreso a consultare alcuni siti Web inappropriati e, come parte dell'indagine che ne seguì, l'ufficio delle risorse umane aveva bisogno di un elenco completo dei siti Web che aveva visitato. Estrarre queste informazioni dal file di registro di un solo giorno già non è tanto semplice, e il personale delle risorse umane voleva avere informazioni relative a intere settimane — un'operazione che non avevo intenzione di eseguire manualmente.
Il server DHCP (Dynamic Host Configuration Protocol) dell'azienda indicava che il computer del dipendente aveva utilizzato lo stesso indirizzo IP (ad esempio 192.168.17.54) per diversi mesi. Questo non è insolito, poiché si trattava di un computer desktop che non veniva spento quasi mai. E poiché il file di registro del firewall conteneva informazioni sugli indirizzi IP di origine, sapevo che Windows PowerShell avrebbe potuto aiutarmi.
Il segreto sta nel comando Select-String, che viene spesso trascurato. Occorre anche una certa conoscenza delle espressioni regolari (di cui ho parlato nell'articolo di novembre 2007 riguardante Windows PowerShell).
Il comando Select-String accetta un percorso pieno di file di testo, un'espressione regolare o semplicemente una stringa da ricercare. Restituisce quindi tutte le righe di ciascun file di registro che corrispondono all'espressione regolare o alla semplice stringa. Per iniziare l'operazione, volevo semplicemente ottenere tutte le righe contenenti l'indirizzo IP del computer desktop del dipendente. Ogni riga del file di registro conteneva un timbro data/ora, che è proprio quello che cercava l'ufficio delle risorse umane.
Ecco il comando:
select-string -path c:\logs\*.txt -pattern "192.168.17.54"
-allmatches –simplematch
Il parametro -simpleMatch specifica che il modello che ho fornito è una stringa semplice, non un'espressione regolare. La Figura 1 illustra una parte dell'output, che potrebbe anche essere trasferito in un file. È importante notare che l'output comprende sia il nome del file sia il numero della riga in cui è stata rilevata la corrispondenza, che può risultare molto utile se a un certo punto si desidera ritornare ai risultati e cercare ulteriori informazioni.
Cmdlet del mese: Start-Sleep
Si tratta di un cmdlet che può offrire proprio quello che serve nel corso di una lunga giornata di lavoro... un pisolino! Start-Sleep offre una piccola pausa, per gli script Windows PowerShell.
Non è insolito che ci sia bisogno di una pausa veloce in uno script. Se, ad esempio, occorre avviare un servizio, si consiglia di attendere alcuni secondi in modo che si avvii, quindi eseguire altre operazioni che dipendono da tale servizio. Start-Sleep è proprio quello che serve per questo tipo di comportamento. Se ad esempio si esegue Start-Sleep 10, la shell farà una pausa di 10 secondi. Se occorre esercitare un controllo più preciso, è possibile eseguire Start-Sleep -milli 100, ad esempio, per fare una pausa di 100 millisecondi. Start-Sleep sospende completamente la shell, compresi gli script, le pipeline e tutto il resto, per il periodo di tempo specificato. Sarebbe proprio bello se qualcuno si decidesse a scrivere il famoso cmdlet Start-Pisolino che aspetto da tanto tempo...
Figura 1 Output del comando Select-String (fare clic sull'immagine per ingrandirla)

Corrispondenze complesse
Dopo che ho passato al personale delle risorse umane le informazioni che mi avevano chiesto, si sono accorti che non era quello che volevano. Il mio report indicava visite a vari indirizzi IP, come 207.68.172.246 (il sito Web MSN®). La richiesta successiva consisteva nel semplificare il mio report, in modo che contenesse soltanto le visite a un indirizzo IP specifico, che corrispondeva a uno dei siti Web inappropriati. In questo articolo, non rivelerò il vero indirizzo IP della ricerca. Utilizzerò 207.68.172.246 come esempio (sebbene il sito Web MSN solitamente non sia considerato inappropriato).
Questa richiesta potrebbe sembrare un po' più difficile. Nel file di registro su cui stavo lavorando, gli indirizzi IP di origine e di destinazione si trovavano l'uno accanto all'altro ed erano separati da una virgola. Quindi potevo semplicemente modificare la mia stringa di ricerca in "192.168.17.54,207.68.172.246" e ripetere la ricerca.
In un file di registro più complesso, tuttavia, è possibile che siano presenti dati variabili memorizzati tra i due indirizzi IP, quindi la semplice corrispondenza della stringa non è sufficiente. In tale scenario è necessario utilizzare un'espressione regolare, che funziona bene anche per i formati di file di registro più semplici, come dimostrerò qui.
All'interno di un'espressione regolare, il punto è un carattere jolly che indica un carattere qualsiasi. È possibile utilizzare l'espressione secondaria (.)* per cercare un numero qualsiasi di caratteri tra i miei due indirizzi IP. Tuttavia, è necessario utilizzare una barra rovesciata per evitare i punti letterali che compaiono negli indirizzi IP stessi.
Il comando risultante è:
select-string -path c:\logs\*.txt -pattern
"192\.168\.17\.54(.)*207\.68\.172\.246" –allmatches
Ho rimosso il parametro -simpleMatch perché questa volta utilizzo un'espressione regolare. L'output risultante illustra soltanto le visite effettuate dal computer del dipendente a un sito Web specifico identificato come inappropriato. L'output comprende anche le informazioni sulla data e l'ora che erano state richieste dal personale delle risorse umane. La Figura 2 illustra una porzione di output che potrebbe essere generata quando si esegue un comando come questo.
Figura 2 Risultati della ricerca semplificati che illustrano soltanto le visite a un sito specifico (fare clic sull'immagine per ingrandirla)
Tuttavia, posso anche migliorare l'output utilizzando il comando Format-Table e visualizzare le colonne calcolate. Nella tabella è possibile includere il nome del file di registro e il numero di riga in cui è stata trovata la corrispondenza, ed è anche possibile visualizzare la riga stessa in cui la corrispondenza è stata rilevata. Tuttavia, farò anche in modo che la shell sostituisca la corrispondenza dell'espressione regolare con una stringa vuota, in modo che venga visualizzato soltanto il resto della riga, con le informazioni sulla data e l'ora nel mio esempio. Si tratta di un suggerimento avanzato, ma dimostra ulteriormente come Windows PowerShell sia in grado di manipolare i dati delle stringhe e produrre output estremamente personalizzato, il tutto con un'unica riga di comando:
select-string -path c:\logs\*.txt -pattern
"192\.168\.17\.54(.)*207\.68\.172\.246" -allmatches |
ft  filename,linenumber,@{"Label"="Time";
"Expression"={$_.line.replace
($_.matches[0],"")}} –auto
La Figura 3 illustra i possibili risultati finali che potrei ottenere.
Figura 3 Output formattato da un comando Select-String (fare clic sull'immagine per ingrandirla)

È un mondo di stringhe
Sono sempre pronto a riconoscere la natura orientata agli oggetti di Windows PowerShell come uno dei suoi maggiori punti di forza. Tuttavia, vi sono situazioni in cui gli oggetti non aiutano.
Windows PowerShell potrebbe vivere in un mondo orientato agli oggetti. Fortunatamente, il team di Windows PowerShell si è accorto che spesso si ha a che fare con dati esterni in stringhe formattate, quindi ha aggiunto il comando Select-String. Grazie al comando Select-String e a una certa familiarità con le espressioni regolari, è possibile utilizzare Windows PowerShell per scrivere comandi di una riga che analizzeranno anche le stringhe più complicate.

Don Jones è coautore di Windows PowerShell: TFM e autore di decine di altri libri di informatica. È possibile contattarlo dal suo blog: www.concentratedtech.com.


Hey, Scripting Guy! Stai connesso al tuo tostapane
Microsoft Scripting Guys

Download codice disponibile in: HeyScriptingGuy2008_09,exe (150 KB)

Se questo nostro mondo moderno potesse essere riassunto in due parole, queste sarebbero: stai connesso. Grazie ai telefoni cellulari, non c'è più bisogno di essere in casa per rispondere ad una chiamata; siamo raggiungibili ovunque, in qualsiasi momento del giorno e della notte. (Oh, che… bellezza). Grazie alle connessioni wireless, non c'è bisogno di stare in ufficio per lavorare; ora si può lavorare da casa, dalla spiaggia, da qualsiasi posto vi venga in mente.
Ecco una storia vera: I genitori dell'Editor di script sono andati in campeggio, ma sono stati costretti a rinunciare ad ogni comfort, proprio come i grandi esploratori Lewis e Clark, per dei problemi con la connessione alla rete wireless del camping. E meno male che la tv satellitare funzionava!
Ma il bello deve ancora venire. I dispositivi GPS sono in grado di individuare esattamente dove ci si trova, metro più, metro meno, e, a seconda del dispositivo, possono comunicare ad altri l'esatta posizione. (Il vecchio detto "potrai correre ma non nasconderti" non è mai stato più azzeccato di quanto lo sia oggigiorno). Se solo volesse, lo Scripting Guy che sta scrivendo questo articolo potrebbe farsi telefonare dal suo conto corrente ogni volta che viene emesso un pagamento; allo stesso modo, potrebbe chiedere alla sua automobile un resoconto mensile sullo stato via mail. E come se non bastasse, il tostapane si è offerto di portare a spasso il cane ed annaffiare le piante quando lui è in vacanza.
Beh, OK, forse quest'ultima parte non è del tutto vera - almeno per ora. Ma se solo avesse voluto, lo Scripting Guy avrebbe potuto comprare un tostapane con connessione Internet. Poi avrebbe potuto telefonare al suo tostapane tornando a casa in modo da trovare una fetta di pane tostato caldo caldo ad aspettarlo. Ad essere sinceri, non sappiamo perché dovreste volere del pane tostato caldo appena varcata la soglia di casa. Ma non si sa mai…
Ovviamente, se lo scopo di tutti è essere connessi, non dovrebbe sorprendere il fatto che gli Scripting Guys, che non hanno mai seguito le mode, auspichino una disconnessione. Significa forse che gli Scripting Guys vi consigliano di buttare via il telefono cellulare o il computer portatile? No; persino per gli Scripting Guys sarebbe troppo stupido. Tuttavia, gli piacerebbe che aggiungeste dei recordset disconnessi al vostro arsenale di script. Ma se vuoi comunque buttare via il tuo cellulare o il tuo computer portatile, beh, non saremo noi a fermarti.
Nota Secondo un'indagine condotta da Harris Interactive, il 43% degli americani ha utilizzato un computer portatile durante le vacanze per controllare ed inviare messaggi di posta elettronica per motivi di lavoro. E più del 50% degli americani utilizza il proprio telefono cellulare in vacanza per controllare i messaggi di posta elettronica e/o i messaggi vocali. E ciò non include il 40% degli americani che non vanno affatto in vacanza nell'arco dell'anno.
È ovvio che molti utenti sarebbero felici di aggiungere dei recordset disconnessi al proprio arsenale di script, eccetto per una cosa: non hanno idea di cosa sia un recordset disconnesso. Dunque, qualora il concetto vi sfugga, un recordset disconnesso è (più o meno) una tabella del database che non è legata ad un database effettivo, ma è creata da uno script, esiste soltanto in memoria e scompare nel momento in cui lo script finisce. In altre parole, un recordset disconnesso è una struttura di dati che esiste soltanto per pochi minuti e poi scompare, portando con sé i tuoi dati. Cavolo, sembrerebbe davvero utile, cari Scripting Guys. Grazie per l'aiuto!
Va bene, lo ammettiamo: i recordset disconnessi non sembrano poi così divertenti. E la verità è che non lo sono. Ma possono essere estremamente utili. Come gli scrittori veterani di VBScript ben sanno, il VBScript non ha esattamente le migliori capacità di classificazione dati al mondo. (Beh, a meno che non si consideri una capacità di classificazione dati pari a zero come capacità migliore al mondo). Allo stesso modo, la capacità del VBScript di trattare grandi serie di dati è limitata, nel migliore dei casi. Oltre all'oggetto Dictionary (che limita il lavoro ad elementi che hanno al massimo due proprietà) o all'array (che è strettamente limitato agli elenchi con proprietà singole di dati), beh… non c'è altro.
I recordset disconnessi vi permettono di risolvere entrambi i problemi (e non solo). Avete bisogno di classificare i vostri dati, in particolare quelli in proprietà multipla? Nessun problema; come abbiamo detto, un recordset disconnesso è l'equivalente virtuale di una tabella del database e non c'è niente di più facile al mondo che classificare una tabella del database. (OK, ad essere puntigliosi, è chiaro che non classificare la tabella di un database sia più facile che farlo). E se c'è bisogno di una grande quantità di elementi, elementi in proprietà multipla, di cui tenere traccia? Nessun problema; abbiamo già detto che un recordset disconnesso è l'equivalente virtuale della tabella di un database? Queste informazioni devono essere in qualche modo filtrate oppure è necessario effettuare una ricerca secondo un valore specifico? Oh, se solo ci fosse un modo per utilizzare l'equivalente virtuale di una tabella del database…
Esatto: forse è arrivato il momento di spiegare di cosa stiamo parlando. (Presupponendo di sapere di cosa stiamo parlando). Per i principianti, supponiamo di avere la statistica di baseball illustrata in Figura 1, statistica raccolta dal sito Web MLB.com e memorizzata in un file di valori separati da tabulazione, C: \Scripts\Test.txt.
Figura 1 Statistica memorizzata in un file di valori separati da tabulazione
Player | Home Run | RBI | Media
D. Pedroia | 4 | 28 | .276
K. Kouzmanoff | 8 | 25 | .269
J. Francouer | 7 | 35 | .254
C. Guzman | 5 | 20 | .299
F. Sanchez | 2 | 25 | .238
I. Suzuki | 3 | 15 | .287
J. Hamilton | 17 | 67 | .329
I. Kinsler | 7 | 35 | .309
M. Ramirez | 12 | 39 | .295
A. Gonzalez | 17 | 55 | .299
E tutto ciò è cosa buona e giusta, ma supponiamo di voler ottenere un elenco di giocatori divisi per numero di home run effettuati. Un recordset disconnesso può essere utile per qualcosa del genere? Stiamo per scoprirlo; dai un'occhiata alla Figura 2. Sì, ci sono un sacco di codici, non è vero? Ma non preoccuparti; presto scoprirai che can che abbaia non morde.
Figura 2 Un recordset disconnesso
Const ForReading = 1
Const adVarChar = 200
Const MaxCharacters = 255
Const adDouble = 5

Set DataList = CreateObject("ADOR.Recordset")
DataList.Fields.Append "Player", _
  adVarChar, MaxCharacters
DataList.Fields.Append "HomeRuns", adDouble
DataList.Open

Set objFSO = _
  CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile _
  ("C:\Scripts\Test.txt", ForReading)

objFile.SkipLine

Do Until objFile.AtEndOfStream
    strStats = objFile.ReadLine
    arrStats = Split(strStats, vbTab)

    DataList.AddNew
    DataList("Player") = arrStats(0)
    DataList("HomeRuns") = arrStats(1)
    DataList.Update
Loop

objFile.Close

DataList.MoveFirst

Do Until DataList.EOF
    Wscript.Echo _
        DataList.Fields.Item("Player") & _
        vbTab & _
        DataList.Fields.Item("HomeRuns")
    DataList.MoveNext
Loop
Per iniziare, definiamo quattro costanti:
  • ForReading. Utilizziamo questa costante quando apriamo e leggiamo il file di testo.
  • AdVarChar. Questa è una costante ADO standard per creare un campo che utilizza il tipo di dati Variant.
  • MaxCharacters. Questa è una costante ADO standard per indicare il numero massimo di caratteri (in questo caso, 255) che un campo Variant può ammettere.
  • adDouble. Un'ultima costante ADO, per creare un campo che utilizza un tipo di dati double (numerici).
Dopo aver definito le costanti, troviamo questo blocco di codice:
Set DataList = CreateObject _
    ("ADOR.Recordset")
DataList.Fields.Append "Player", _
    adVarChar, MaxCharacters
DataList.Fields.Append "HomeRuns", _
    adDouble
DataList.Open
Questa è la parte dello script dove stabiliamo e configuriamo concretamente il recordset disconnesso. Per realizzare questa attività, la prima cosa che facciamo è creare un'istanza dell'ADOR.Oggetto recordset; inutile a dirsi, ciò consente di creare la tabella del database virtuale (ossia, il nostro recordset disconnesso).
Utilizziamo poi questa riga di codice (ed il metodo Append) per aggiungere un campo nuovo al recordset:
DataList.Fields.Append "Player", adVarChar, MaxCharacters
Come puoi vedere, non c'è niente di elaborato qui: Chiamiamo semplicemente il metodo Append seguito da tre parametri:
  • Il nome del campo (Players).
  • Il tipo di dati per il campo (adVarChar).
  • Il numero massimo di caratteri che possono essere memorizzati nel campo (MaxCharacters).
Dopo aver aggiunto il campo Players, possiamo aggiungere un secondo campo: HomeRuns, che ha un tipo di dati numerico (adDouble). Una volta finito con questa attività, chiamiamo il metodo Open per dichiarare il nostro recordset aperto e pronto a lavorare.
Poi creiamo una richiesta di Script.FileSystemObject ed apriamo il file: C:\Scripts\Test.txt. Questa porzione dello script in realtà non ha niente a che fare col recordset disconnesso; è lì solo perché dobbiamo recuperare i dati da un file di testo. La prima riga nel file di testo contiene le nostre informazioni di intestazione:
Player     Home Runs     RBI        Average
Non abbiamo bisogno di queste informazioni per il recordset, dunque la prima cosa da fare dopo aver aperto il file è chiamare il metodo SkipLine per ignorare questa prima riga:
objFile.SkipLine
Ora che siamo passati alla prima riga contenente dati effettivi, prepariamo un loop Do Until progettato per leggere il resto del file riga per riga. Ogni volta che leggiamo una riga dal file, memorizziamo quel valore in una variabile denominata strLine, utilizzeremo poi la funzione Split per convertire quella riga in un array di valori (dividendo la riga ogni volta che incontriamo una scheda):
arrStats = Split(strStats, vbTab)
Lo ammettiamo, è solo una panoramica veloce, ma crediamo che ormai siate abbastanza bravi a recuperare informazioni dai file di testo. Per farla breve, al primo loop l'array, arrStats, conterrà gli elementi in Figura 3.
Figura 3 Contenuti dell'array
Numero elemento | Nome elemento
0 | D. Pedroia
1 | 4
2 | 28
3 | .276
Ora inizia il divertimento:
DataList.AddNew
DataList("Player") = arrStats(0)
DataList("HomeRuns") = arrStats(1)
DataList.Update
Qui aggiungiamo le informazioni per il giocatore 1 (D. Pedroia) al recordset disconnesso. Per aggiungere un record al recordset, iniziamo chiamando il metodo AddNew; questo crea un record nuovo, vuoto su cui lavorare. Utilizziamo le due righe seguenti di codice per assegnare i valori a due campi di recordset (Player e HomeRuns), poi chiamiamo il metodo Update per scrivere ufficialmente quel record sul recordset. E poi si ricomincia il loop ancora una volta, ripetendo il processo con la riga successiva—il prossimo giocatore—del file di testo. Visto? Anche se avessimo molti codici, sarebbe tutto piuttosto semplice e diretto.
Dunque che succede dopo che tutti i giocatori sono stati aggiunti al recordset? Beh, dopo aver chiuso il file di testo, eseguiamo questo blocco di codice:
DataList.MoveFirst

Do Until DataList.EOF
  Wscript.Echo _
    DataList.Fields.Item("Player") & _
    vbTab & _
    DataList.Fields.Item("HomeRuns")
  DataList.MoveNext
Loop
Nella riga 1 utilizziamo il metodo MoveFirst per posizionare il cursore all'inizio del recordset; in caso contrario, correremmo il rischio di mostrare soltanto alcuni dei dati nel recordset. Avvieremo poi un loop Do Until che continuerà fino ad esaurimento dati (cioè, finché la proprietà EOF, end of file, del recordset non sarà True).
All'interno del loop, tutto ciò che facciamo è ripetere i valori dei campi Player e HomeRuns (notare la sintassi piuttosto bizzarra usata per indicare un campo particolare: DataList.Fields.Item("Player"). E poi chiamiamo semplicemente il metodo Move-Next per passare al record successivo nel recordset.
Inutile a dirsi, era davvero facile. Alla fine dei giochi dovremmo ottenere quanto segue:
D Pedroia       4
K Kouzmanoff    8
J Francouer     7
C Guzman        5
F Sanchez       2
I Suzuki        3
J Hamilton      17
I Kinsler       7
M Ramirez       12
A Gonzalez      17
Come potete vedere, è... beh, se ci pensi bene, non è che sia tutta questa meraviglia, eh? Certo, abbiamo ottenuto i nomi dei giocatori e gli home run totali, ma non abbiamo ottenuto questi totali in un ordine specifico. Mannaggia! Perché il recordset disconnesso non ha classificato i dati al posto nostro?
In realtà c'è un'ottima ragione: non abbiamo detto al recordset che campo volevamo classificare. Ma rimediare è abbastanza facile: basta modificare lo script per aggiungere informazioni di classificazione appena prima della chiamata del metodo MoveFirst. In altre parole, fate in modo che quella parte di script risulti così:
DataList.Sort = "HomeRuns"
DataList.MoveFirst
Ovviamente non c'è nessun trucco qui; assegniamo semplicemente il campo HomeRuns alla proprietà di Ordinamento. Ora date un'occhiata all'output che si ottiene quando eseguiamo lo script:
F Sanchez       2
I Suzuki        3
D Pedroia       4
C Guzman        5
J Francouer     7
I Kinsler       7
K Kouzmanoff    8
M Ramirez       12
J Hamilton      17
A Gonzalez      17
Molto meglio. Fatta eccezione per un punto: di solito gli home run totali sono elencati in ordine decrescente, col giocatore che ha realizzato il maggior numero di home run al primo posto. Esiste un modo per classificare un recordset disconnesso in ordine decrescente?
Ma certo; tutto ciò che si deve fare è aggiungere l'utilissimo parametro DESC, così:
DataList.Sort = "HomeRuns DESC"
E che cosa farà per noi il parametro DESC? Esatto:
A Gonzalez      17
J Hamilton      17
M Ramirez       12
K Kouzmanoff    8
I Kinsler       7
J Francouer     7
C Guzman        5
D Pedroia       4
I Suzuki        3
F Sanchez       2
A proposito, è perfettamente legale classificare proprietà multiple; tutto ciò che devi fare è assegnare ad ogni proprietà un ordinamento di dati. Ad esempio, supponi di voler classificare prima gli home run e poi gli RBI. Nessun problema; questo comando lo farà al posto tuo:
DataList.Sort = "HomeRuns DESC, RBI DESC"
Prova e lo vedrai con i tuoi occhi. Non sarà divertente come controllare la posta elettronica in vacanza, ma quasi.
Nota Ricorda che non è possibile classificare secondo un campo che non è stato aggiunto al recordset. Cosa significa? Significa che prima di aggiungere una proprietà come gli RBI all'istruzione di ordinamento, è necessario aggiungere queste righe allo script nelle posizioni appropriate:
DataList.Fields.Append "RBI", adDouble

DataList("RBI") = arrStats(2)
E se vuoi vedere il risultato, devi anche modificare l'istruzione Wscript.Eco:
Wscript.Echo _
  DataList.Fields.Item("Player") & _
  vbTab & _
  DataList.Fields.Item("HomeRuns") & _
  vbTab & DataList.Fields.Item("RBI")
Vediamo, cos'altro si può fare con i recordset disconnessi? Oh, ecco qualcosa. Supponiamo di aver recuperato tutte le informazioni per tutti i giocatori ed aver classificato quei dati secondo la media di battuta. (Fra le altre cose, ciò significa che dobbiamo modificare lo script originale per creare i campi denominati RBI e Media-Battuta.) L'output è simile al seguente:
J Hamilton      17      67      0.329
I Kinsler       7       35      0.309
A Gonzalez      17      55      0.304
C Guzman        5       20      0.299
M Ramirez       12      39      0.295
I Suzuki        3       15      0.287
D Pedroia       4       28      0.276
K Kouzmanoff    8       25      0.269
J Francouer     7       35      0.254
F Sanchez       2       25      0.238
Benissimo, ma se volessimo solo un elenco dei battitori da .300 o oltre? Come possiamo limitare i dati visualizzati ai giocatori che soddisfano alcuni criteri specifici? Beh, un modo è quello di assegnare un Filtro al recordset:
DataList.Filter = "BattingAverage >= .300"
Un filtro di recordset serve lo stesso scopo generale di una query sul database: Fornisce un meccanismo per limitare i dati ottenuti ad un sottoinsieme di tutti i record nel recordset. In questo caso chiediamo semplicemente al Filtro di eliminare tutti i record eccetto quelli in cui la Media-Battuta ha un valore superiore o uguale a .300 E indovinate un po'? Il filtro farà esattamente ciò che gli chiediamo:
J Hamilton      17      67      0.329
I Kinsler       7       35      0.309
A Gonzalez      17      55      0.304
Se solo i nostri figli fossero così ricettivi, eh?
Comunque, puoi utilizzare criteri multipli in un solo filtro. Ad esempio, questo comando limita i dati risultanti ai record in cui il campo MediaBattuta è maggiore o uguale a .300 ed il campo HomeRuns è maggiore di 10:
DataList.Filter = _
  "BattingAverage >= .300 AND HomeRuns > 10"
Per contro, questo filtro limita i dati risultanti ai record in cui il campo MediaBattuta è maggiore o uguale a .300 o il campo HomeRuns è maggiore di 10:
DataList.Filter = "BattingAverage >= .300 OR HomeRuns > 10"
Prova con entrambi e noterai la differenza. E che diamine: solo per divertirti, ecco un altro filtro che puoi provare:
DataList.Filter = "Player LIKE 'I*'"
Andando avanti, potrai utilizzare anche dei caratteri jolly nei filtri. Per fare questo, utilizza l'operatore LIKE (invece del segno di uguale) e poi utilizza l'asterisco come faresti per eseguire un comando MS-DOS ® come dir C: \Scripts\*.txt. Nell'esempio precedente, dovremmo inserire un elenco di giocatori il cui nome inizia con la lettera I; poiché la sintassi che abbiamo impiegato dice: "Mostrami un elenco di tutti i record dove il valore del campo Player inizia con una I seguita da, beh, qualsiasi cosa". Ora prova, beh, OK; ormai hai imparato la procedura.
Comunque, non sarai ancora fermo alle medie di battuta tipo .309. (In genere le medie di battuta sono espresse senza lo 0, in questo caso .309, ad esempio). Ma va bene; puoi semplicemente utilizzare la funzione FormatNumber per formattare la media di battuta in qualsiasi maniera antiquata tu voglia:
FormatNumber (DataList.Fields.Item("BattingAverage"), 3, 0)
Inserisci semplicemente questa funzione nell'istruzione Wscript.Echo quando visualizzi il numero (o altrimenti, puoi assegnare l'output a una variabile e inserire la variabile nell'istruzione Echo) :
Wscript.Echo _
  DataList.Fields.Item("Player") & _
  vbTab & _
  DataList.Fields.Item("HomeRuns") & _
  vbTab & DataList.Fields.Item("RBI") & _
  vbTab & _
  FormatNumber _
  (DataList.Fields.Item("BattingAverage"), _
   3, 0)
Roba divertente, eh?
Ma purtroppo, sembra che il tempo per questo mese sia agli sgoccioli. Per concludere, vorrei solo dire che, scusate, sta squillando il telefono.
Comunque, volevamo sottolineare che—oh, grande, ora squilla il cellulare. Ed abbiamo appena ricevuto un messaggio di posta elettronica dal tostapane. Roba seria: il toast caldo è pronto, ci vuoi il burro o la marmellata? Dobbiamo andare, al prossimo mese!
Il rompicapo di script del Dottor Scripto
La sfida mensile che verifica non solo l'abilità nella risoluzione dei puzzle, ma anche le competenze di scripting.

Settembre 2008: Ricerca di script
Ecco qui una semplice (o forse non così semplice) ricerca di parole. Trova tutte le funzioni VBScript e le istruzioni nell'elenco. Ma ecco la sorpresa: le lettere che rimangono formano una parola nascosta, che per puro caso, indovina un po', è un cdmlet Windows PowerShell™!
Elenco di parole: Abs, Array, Atn, CCur, CLng, CInt, DateValue, Day, Dim, Else, Exp, Fix, InStr, IsEmpty, IsObject, Join, Len, Log, Loop, LTrim, Mid, Month, MsgBox, Now, Oct, Replace, Set, Sin, Space, Split, Sqr, StrComp, String, Timer, TimeValue, WeekdayName.

RISPOSTA:
Il rompicapo di script del Dottor Scripto
Risposta: Settembre 2008: Ricerca di script

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


The Desktop Files Funzionalità avanzata in WDS
Wes Miller

Indice
Gestione della riga di comando
Archivio immagini
Multicast
Registrazione WDS
Altri problemi
Conclusioni
Nei due articoli precedenti di questa rubrica, ho esplorato i Servizi di distribuzione Windows (WDS). Ho iniziato guardando la cronologia degli strumenti di distribuzione Microsoft basati su Pre-boot eXecution Environment (PXE), seguita da una panoramica su WDS. Questo mese indagherò su alcuni argomenti avanzati:
WDSUtil (la potente utilità della riga di comando per WDS), Archivio immagini WDS, Registrazione WDS e si lavorerà con la funzionalità multicast in WDS per Windows Server® 2008.
Quando i Servizi di installazione remota (RIS) sono stati forniti in Windows® 2000 e Windows Server 2003, non vi era la ricchezza di funzionalità che molti avrebbero desiderato. Si sono distinte in particolare tre aree:
  • Prestazione (maggiore distribuzione scalabile)
  • Registrazione/Controllo
  • Automazione della riga di comando
Leggendo questo articolo, è possibile notare che con la versione iniziale di WDS e più specificamente con WDS in Windows Server 2008, per ciascuno di questi fronti si sono compiuti progressi significativi.

Gestione della riga di comando
Come sottolineato il mese scorso, WDS ha rilasciato un sistema di gestione notevolmente migliorato. Inoltre, cosa ancora più importante per la maggior parte delle aziende, WDS ha fornito una nuova utilità della riga di comando per la gestione, WDSUtil.exe (vedere Figura 1). WDSUtil è installato con il componente facoltativo WDS su Windows Server 2003 (SP1+WDS o SP2) e con WDS Role su Windows Server 2008.
Figura 1 Impostazione dell'opzione di rilevamento dell'architettura con WDSUtil su Sì (fare clic sull'immagine per ingrandirla)
WDSUtil è un'utilità sorprendentemente potente, ma è piuttosto complicata. In effetti, tutto ciò che è possibile fare tramite Microsoft® Management Console (MMC), può essere fatto tramite WDSUtil. Infatti, poichè è anche una delle maniere migliori per fare una diagnosi in caso di problemi, è consigliabile eseguire:
wdsutil /get-server /show:config
I risultati rispecchiano completamente ciò che si vedrebbe nell'intera MMC di WDS, nonostante WDSUtil possa emetterlo in un formato facilmente consultabile che è possibile poi esportare in un file di testo.
Le informazioni non sono sufficienti? È consigliabile in tal caso eseguire il comando riportato di seguito, che restituisce ulteriori valori:
wdsutil /get-server /show:all /detailed
È possibile fermare e riavviare il server WDS eseguendo:
wdsutil /stop-server
wdsutil /start-server
Un riferimento ai comandi per WDSUtil si può trovare all'indirizzo go.microsoft.com/fwlink/?LinkId=112194. Se si preferisce, è possibile inoltre scaricarne una versione .chm (assieme a tutti i documenti WDS 2008) all'indirizzo go.microsoft.com/fwlink/?LinkId=89381.
Con RIS, non vi era una maniera facile (sempre che l'utente non fosse un guru di Active Directory® Service Interfaces) di scoprire tramite la riga di comando se un indirizzo MAC o GUID specifico fosse associato o meno a un Machine Account Object (MAO) in Active Directory. Con WDSUtil, è possibile eseguire una query basata su entrambi.
I GUID possono confondere, poiché è possibile inserirli come stringhe binarie o come una stringa GUID e la sola differenza è l'ordinamento dei byte e l'assenza di trattini. Gli indirizzi MAC possono essere inseriti con o senza trattini utilizzando una delle seguenti righe di codice:
wdsutil /get-device /id:01-23-45-67-89-AB
wdsutil /get-device /id:0123456789AB
È possibile ottenere informazioni sul dispositivo tramite stringhe binarie utilizzando questo comando:
wdsutil /get device /id:ACEFA3E81F20694E953EB2DAA1E8B1B6
Altrimenti, è possibile ottenere informazioni sul dispositivo tramite stringhe GUID utilizzando questo comando:
wdsutil /get device /id:E8A3EFAC-201F-4E69-953-B2DAA1E8B1B6
Molti computer sono probabilmente capaci di eseguire la versione a 64 bit di Windows, ma alcuni, sfortunatamente, non riportano correttamente la loro architettura. È possibile che WDS tenti di determinare se un sistema sia in grado o meno di supportare i 64 bit eseguendo un piccolo programma netboot fornito come parte di WDS. Come illustra la Figura 1, è possibile fare ciò con il seguente:
wdsutil /set-server /architecturediscovery:yes
Infatti, il comando set-server di WDSUtil permette di configurare numerose impostazioni del server. Per vedere le opzioni eseguire il comando:
wdsutil /set-server /?
Se è stato aggiornato un server WDS Windows Server 2003 a Windows Server 2008, è possibile convertire qualsiasi immagine RIPrep a immagini Windows Imaging Format (WIM) eseguendo:
WDSUtil /convert-RIPrepImage
Nonostante WDSUtil sia in grado di convertire le immagini RIPrep, qualsiasi restante immagine RISetup (installazioni codificate in WDS tradizionale o RIS/legacy) non può essere convertita.
La forza di WDSUtil risiede nella sua capacità di automatizzare le attività ripetitive. I comandi nella Figura 2 forniscono un'idea delle funzionalità di WDSUtil. Qualora si stiano implementando nuovi server WDS, aggiungendo o modificando immagini attraverso più server, amministrando la propria infrastruttura multicast o specificando quale programma di avvio di rete utilizzare per un client boot specifico, WDSUtil fornisce qualcosa di assolutamente potente che non era precedentemente disponibile nei RIS.
Figura 2 comandi WDSUtil
Comando | Descrizione
/add | Aggiunge periferiche, immagini o gruppi di immagine.
/approve-AutoAddDevices | Approva le periferiche di aggiunta automatica in sospeso e imposta le relative informazioni di configurazione.
/convert-RiprepImage | Converte un'immagine RIPrep legacy a un'immagine WIM.
/copy-Image | Duplica un'immagine all'interno di un archivio immagini.
/delete-AutoAddDevices | Elimina tutti o alcuni dei dispositivi di aggiunta automatica in sospeso.
/disable | Disabilita un server WDS o un server di trasporto.
/disconnect-Client | Disconnette un client da una trasmissione multicast o da uno spazio dei nomi.
/enable | Abilita un server WDS o un server di trasporto.
/export-Image | Come il comando /export in ImageX, anche questo esporta un'immagine esistente da un archivio immagini a un'immagine WIM.
/get | Richiede proprietà e attributi per un dispositivo, un'immagine, un gruppo di immagini, un server WDS o un server di trasporto.
/initialize-Server | Configura un server WDS per l'uso dopo la prima installazione.
/new | Crea immagini di acquisizione o di individuazione, le trasmissioni multicast e gli spazi dei nomi.
/progress | Visualizza informazioni sullo stato di esecuzione di un dato comando.
/reject-AutoAddDevices | Rifiuta tutti o alcuni dispositivi di aggiunta automatica in sospeso.
/remove | Rimuove immagini, gruppi di immagini, trasmissioni multicast e spazi dei nomi.
/replace-Image | Sostituisce (sovrascrive) un'immagine con un'immagine nuova.
/set | Imposta proprietà e attributi per un dispositivo, un'immagine, un gruppo di immagini, un server WDS o un server di trasporto.
/start | Inizializza un server WDS o un server di trasporto.
/stop | Termina un server WDS o un server di trasporto.
/uninitialize-Server | Reimposta le modifiche fatte al server durante l'inizializzazione del server (riportandolo allo stato non configurato).
/update-ServerFiles | Aggiorna i file nella condivisione REMINST del server con le versioni più recenti dalla directory System32\RemInst del server.
/verbose | Visualizza un output dettaglaito mentre durante l'esecuzione di un dato comando.

Archivio immagini
Il mese scorso ho accennato al modo in cui Archiviazione istanza singola (SIS), utilizzata dai RIS per una memorizzazione più efficiente dei file su disco, è stata abbandonata in WDS. Ora, tutta le immagini in modalità nativa (WIM), indipendentemente dal sistema operativo, sono conservate in Archivio immagini WDS. Come ho indicato negli articoli precedenti, quella funzionalità di singola istanza ha permesso di risparmiare spazio nei file .wim quando il volume delle immagini aveva file associati. Archivio immagini WDS funziona alla stessa maniera. Infatti, utilizza le funzionalità WIM per memorizzare le immagini.
Per lavorare con Archivio immagini, è necessario disporre almeno di un Gruppo immagini; l'inizializzazione WDS generalmente richiede di crearne uno. È possibile creare anche un Gruppo immagini nuovo aggiungendo un'Immagine di installazione e l'immagine sarà aggiunta al gruppo (vedere Figura 3).
Figura 3 Creazione di un nuovo Gruppo immagini (fare clic sull'immagine per ingrandirla)
Dunque che cos'è Archivio immagini? All'interno della directory RemoteInstall, nella directory delle immagini, sono contenute delle directory per ogni Gruppo immagini creato. Come illustra la Figura 4, esiste un file .wim per ciascuna Immagine di installazione importata nel Gruppo immagini ed un solo file .rwm (risorsa WIM).
Figura 4 Contenuti di un Gruppo immagini (fare clic sull'immagine per ingrandirla)
Guardare attentamente i file nella Figura 4. Questo Gruppo immagini è composto da:
  • install.wim (Windows Server 2008, Standard Edition)
  • install-(2).wim (Windows Server 2008, Enterprise Edition)
  • install-(3).wim (Windows Server 2008, Datacenter Edition)
  • install-(4).wim (Windows Server 2008, Standard Edition (Server Core)
  • install-(5).wim (Windows Server 2008, Enterprise Edition (Server Core)
  • install-(6).wim (Windows Server 2008, Datacenter Edition (Server Core)
Si paragonino ora le dimensioni di quei file con quelli dalla MMC (illustrati nella Figura 5). Le dimensioni di ciascun file .wim nella Figura 4 rappresentano una frazione delle dimensioni del file Res.rwm. Perché? Bene, per salvare lo spazio, i file .wim illustrati sono semplicemente degli stub di file effettivi. Contengono i metadati per ripristinare il file .wim, ma in realtà non contengono le risorse del file. Tutte le risorse del file in un Gruppo immagini sono memorizzate nel file .rwm per quel determinato gruppo.
Figura 5 Immagini illustrate in Server Manager (fare clic sull'immagine per ingrandirla)
Per modificare un'Immagine di installazione in un Archivio immagini, è possibile esportare l'immagine, apportare le proprie modifiche e sostituire poi l'immagine (o importarla nuovamente) oppure interagire con essa disattivando l'appropriata Immagine di installazione da MMC e apportando le modifiche attraverso il montaggio e il cambiamento del file .wim.
Un problema frequente dei RIS è sempre stato la replica delle immagini. Quando vengono copiati i file SIS in rete, l'attributo SIS si perde essendo un attributo NTFS. Questo significa avere 40GB di immagini RISetup e RIPrep e replicarle in un altro server e anche se il SIS Groveler li aveva ridotti fino a 5GB, si stanno tuttavia replicando 40GB in rete. Non è questo il caso con Archivio immagini WDS. Infatti, a causa dell'architettura di Archivio immagini, è possibile salvare i 40GB su un server File system distribuito (DFS) e utilizzare Replica DFS (DFS-R) per replicarlo da sito al sito.
Le relative specifiche variano a seconda della versione di WDS. Per Windows Server 2003, vedere il Capitolo 7, "Lavorare con le immagini," nella documentazione scaricabile all'indirizzo go.microsoft.com/fwlink/?LinkId=81031. Per Windows Server 2008, vedere "Memorizzazione e replica di immagini utilizzando DFS" all'indirizzo go.microsoft.com/fwlink/?LinkId=121960. Poiché le risorse sono tutte memorizzate nel file .rwm, anche quando si copia un Gruppo immagini da un server a un altro, la quantità di dati che attraversa la rete rappresenta una frazione di ciò che vi sarebbe se ogni file .wim intero fosse trasmesso (o nella vecchia architettura SIS RIS).
Allora, quando creare un Gruppo immagini nuovo e quando utilizzarne uno vecchio? Le regole sono generalmente le stesse per un file .wim. Nonostante sia possibile mettere un'immagine di Windows XP Professional SP3 in un Gruppo Immagini composto per la maggior parte da immagini di Windows Server 2008, questo non avrebbe molto senso, dato che non si sta risparmiando molto spazio. Così come con i file .wim, generalmente si desidera avere un Gruppo immagini per almeno:
  • ogni versione specifica di Windows (dove una versione è sia uno SKU (Windows XP Professional) e una revisione Service Pack (SP3)).
  • Windows Server 2003 e versioni successive: ogni versione in lingua locale (non l'interfaccia utente multilingue). Prima di Windows Vista®, le versioni localizzate erano binari interamente diversi, dunque non erano in grado di eseguire una memorizzazione corretta in un file .wim in termini di singole istanze.
  • ciascun Service Pack di ogni versione. Sebbene sia possibile memorizzare immagini Windows Server 2008 insieme ad immagini Windows Vista SP1, è necessario considerare se ciò ha o meno un senso funzionale nella propria organizzazione.
Archivio immagini, anche più del precedente SIS, svolge un buon lavoro di conservazione dello spazio, sia su disco che in rete, e non ha bisogno di particolare manutenzione per un corretto funzionamento.

Uno dei punti più deboli dei RIS consisteva nella mancanza di scalabilità. La distribuzione multicast ha come ultimo scopo la rettifica di quanto detto in precedenza. Gli utenti pensano spesso al multicast come a una distribuzione più "veloce", ma in realtà non è più veloce, bensì "maggiore". È possibile distribuire più sistemi tramite RIS. Infatti, i RIS potrebbero gestire la distribuzione simultanea di circa 75 sistemi.
Ma molto prima che si raggiungesse questo obiettivo, le prestazioni erano compromesse e ogni singola installazione impiegava progressivamente più tempo. Ancor peggio, all'aumentare del numero di installazioni, aumentava anche il rischio di errore. Allo stesso tempo, installazioni multiple hanno saturato la rete con il traffico di rete SMB (Server Message Block) (in modo che durante la distribuzione, i dipendenti possono non essere in grado di accedere alle risorse di rete critiche come Microsoft Exchange Server).
Il multicast scala i numeri di distribuzione. Se si stanno distribuendo quattro server o un centro congressi con 100 sistemi, il multicast permette di completare quella distribuzione senza perdere troppo tempo e senza saturare la rete. Sebbene sia possibile utilizzare il multicast per eseguire la distribuzione a un solo sistema, i benefici della scalabilità si vedono solamente quando più sistemi ascoltano la trasmissione.
Per utilizzare il multicast, è necessario avere router che supportano il multicast. Generalmente, questo significa che lo snooping IGMP (Internet Group Management Protocol) dovrebbe essere attivato. È necessario avere anche Windows PE 2.1 (Windows Server 2008 RTM o Windows Vista SP1), poichè la versione (2.0) fornita con Windows Vista RTM non è in grado di ricevere una trasmissione multicast.
Inoltre, è necessario assicurarsi di disporre di più server WDS (o altro multicast) sulla stessa rete, per poter specificare un intervallo di indirizzi IP personalizzato. Questo può essere facilmente modificato tramite MMC WDS facendo clic con il pulsante destro del mouse sul server, facendo clic su Proprietà, quindi sulla scheda Impostazione di rete.
Quando si esegue un multicast broadcast, il server multicast può sia adattarsi alla velocità con cui il client più lento può ricevere la trasmissione oppure può regolare la velocità a un livello più alto e lasciare i client che non riescono a stare al passo. Per l'affidabilità, WDS verrà eseguito alla velocità del client più lento a ricevere la trasmissione.
Nel caso in cui la prestazione della trasmissione è più lenta del previsto, è consigliabile eseguire wdsutil /Get-MulticastTransmission/Show-clients. Questo rivela il client che limita la trasmissione. È possibile poi disabilitare quel client, ritornando così a utilizzare SMB anziché multicast. Uno script di esempio in grado di disabilitare automaticamente i client lenti si trova all'indirizzo go.microsoft.com/fwlink/?LinkId=121961.
Per creare una trasmissione multicast, è possibile fare clic col pulsante destro del mouse su un'Immagine di installazione e scegliere Crea trasmissione multicast, oppure è possibile fare clic col pulsante destro del mouse su Trasmissioni multicast nella console WDS e scegliere Crea trasmissione multicast. Nel momento in cui si crea una trasmissione multicast, è possibile creare sia un Multicast automatico o un Multicast pianificato. Il Multicast automatico è utile quando si hanno diversi client che si connettono regolarmente, avendo tutti bisogno della stessa identica immagine; i client nuovi saranno automaticamente aggiunti alla trasmissione in corso che era iniziata per il primo client che richiedeva un'immagine di installazione. Il Multicast pianificato permette di impostare una dimensione di gruppo che, se raggiunta, farà iniziare una trasmissione.
È possibile inoltre impostare la trasmissione affinché inizi a un'ora specificata. Una volta che i client utilizzano la trasmissione multicast, è possibile visualizzarli facendo clic sul nome dell'immagine. Nel riquadro a destra, è possibile vedere le specifiche dei client connessi alla trasmissione.
Generalmente, gli utenti finali utilizzano il multicast dal client di installazione WDS. Esiste, tuttavia, un'utilità riga di comando, denominata WDSMCast, che è fornita nel Windows Automated Installation Kit (WAIK) di Windows Server 2008 e permette di richiedere un file .wim tramite una trasmissione multicast da WDS. Il file .wim deve essere trasferito completamente e applicato al client, in modo da poter assicurare lo spazio su disco adeguato per l'immagine da memorizzare e applicare. Il prossimo mese, discuterò come poter integrare WDSMCast nel proprio processo di distribuzione personalizzato.

Registrazione WDS
WDS è capace di eseguire considerevoli registrazioni e tracce, nonostante la maggior parte sia disabilitata per impostazione predefinita allo scopo di ripsarmiare spazio. Esistono due tipi di registro eventi (quando un client scrive sul Registro eventi di Windows e quando scrive per tenere traccia delle altre funzionalità WDS.
In Windows Server 2008, tuttavia, WDS esegue un certo numero di log per impostazione predefinita Questi registri sono disponibili in Strumenti di amministrazione | Visualizzatore eventi. I registri WDS sono visibili nel Visualizzatore eventi in Registri applicazioni e servizi | Microsoft | Windows | Diagnostica di servizi di distribuzione. Questi sono gli stessi registri che sono visibili al momento di osservare i ruoli WDS nella MMC (vedere Figura 6).
Figura 6 Visualizzazione degli eventi WDS in Server Manager (fare clic sull'immagine per ingrandirla)
La registrazione del client WDS (visibile nei Registri eventi nella Figura 6) può essere avviata eseguendo WDSUtil con i seguenti argomenti:
wdsutil /wdsclientlogging /enabled:yes /logginglevel:info
È inoltre possibile attivare la traccia di registrazione su diversi sottocomponenti WDS. Per configurare la traccia, è necessario impostare un valore di registro DWORD conforme nella/e chiave/i del Registro di sistema, illustrato nella Figura 7. Tutte le tracce di registrazione sono memorizzate in \Windows\tracing. Per iniziare, è necessario riavviare il componente appropriato per la registrazione.
Figura 7 Preparazione della traccia di log
Componente WDS | Chiave del registro di sistema | Valore del registro di sistema | Nome del log
Server | HKLM\SOFTWARE\Microsoft\Tracing\WDSServer\EnableFileTracing | 1 | wdsserver.log
Multicast | HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSMC\TraceDisabled | 0 | wdsserver.log
Componenti di gestione | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMGMT\EnableFileTracing | 1 | wdsmgmt.log
MMC | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMMC\EnableFileTracing | 1 | wdsmmc.log
WDS possiede inoltre contatori di prestazione (descritti all'indirizzo go.microsoft.com/fwlink/?LinkId=121962) da poter monitorare in caso di problemi di prestazione del sistema (o per eseguire le analisi di prestazione del sistema in anticipo). Come indicato in precedenza, è possibile ottenere più informazioni dettagliate in caso si verifichino problemi utilizzando le opzioni /detailed, /verbose o /progress con WDSUtil.
In caso di problemi con i client WDS che sono connessi o che interagiscono con un server WDS, Microsoft Network Monitor (Netmon) è uno strumento eccellente per eseguire il debug dei problemi. Network Monitor è disponibile per il download all'indirizzo go.microsoft.com/fwlink/?LinkId=121491.

Altri problemi:
Ho riscontrato un paio di problemi che vale la pena menzionare. Il primo riguarda la memoria (ricordiamoci che WDS si basa essenzialmente su Windows PE 2.x). Ciò significa che i client WDS hanno bisogno di almeno 384MB di RAM e in uno scenario reale si dovrebbero garantire 512MB per ottenere una prestazione ottimale. Bisogna ricordare anche che Windows PE 2.x non può essere lanciato su sistemi non ACPI (Advanced Configuration and Power Interface) e ciò non significa sempre hardware vecchio. Esistono report di sistemi abbastanza recenti che non supportano ACPI.
Tali sistemi non supportano nemmeno Windows Vista o Windows Server 2008. Per i sistemi che non supportano ACPI, vi è la necessità di mantenere Windows Server 2003 o un server WDS o RIS precedente disponibile con quei client prestaged, oppure di installare Windows tramite un meccanismo non PXE.
Bisogna ricordare infine che se si desidera inizializzare Windows PE 1.x dal proprio server, è necessario inoltre utilizzare Windows Server 2003 o server WDS o RIS, così come WDS in Windows Server 2008 non può inizializzare un'immagine Windows PE 1.x (RAMDisk o PXE).

Fino ad ora ho trattato la cronologia WDS, i principi di base e gli argomenti avanzati. Il prossimo mese daremo un'occhiata ad alcuni scenari WDS personalizzati, più nello specifico, come sia possibile interagire con WDS e modificarlo per eseguire le attività necessarie, spesso senza utilizzare procedura di installazione WDS esistente.

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


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

Indice
Sovraccarico delle tecnologie di aggiornamento
Messaggi sulla sicurezza incoerenti
È una questione di caselle di controllo
Chiamata alle armi
Negli ultimi due numeri di TechNet Magazine, ho illustrato come i professionisti della sicurezza e l'industria dell'IT in generale confondono i consumatori e di fatto ostacolano l'efficacia delle attività volte a garantirne la sicurezza. Nei primi due articoli di questa serie mi sono concentrato su problemi come quelli relativi a soluzioni che forniscono ai consumatori informazioni fuorvianti, sovraccaricano il
flusso di lavoro d'accesso e insegnano cattivi comportamenti. Fino ad ora, ho illustrato molti esempi diversi di come l'industria dell'IT, con i suoi zelanti sforzi per apparire interessata alla sicurezza del consumatore, ha di fatto peggiorato la situazione molto più di quanto fosse necessario. In questo terzo e ultimo articolo dimostrerò che alcune delle più importanti tecnologie a disposizione dei consumatori non sono all'altezza delle aspettative che quei consumatori ripongono in esse. Tutto questo determina la mia chiamata alle armi.

Sovraccarico delle tecnologie di aggiornamento
Uno dei principi primari, un requisito veramente indiscutibile, per garantire la sicurezza elettronica, è tenere aggiornato il proprio software. Quasi tutti i maggiori fornitore di software possiedono ormai qualche meccanismo semiautomatico per tenere aggiornata almeno una parte del proprio software. Tuttavia, la situazione non è così semplice.
Per prima cosa, più software si ha, più software va aggiornato. E maggiore è il numero di fornitori da cui si acquistano software, più sono i meccanismi di aggiornamento con cui si deve lavorare. Questo fattore genera confusione.
Ad esempio, se si lasciano attive le impostazioni predefinite, Internet Explorer® si aggiorna da sé. Ma Internet Explorer è in realtà solo un contenitore per altre tecnologie. Il potenziale impatto di questa condizione è stato dimostrato in occasione della conferenza CanSecWest del 2008, quando Shane Macaulay ha utilizzato una combinazione di vulnerabilità in Java e Adobe Flash per attaccare un Mac. (Al momento della stesura di questo articolo i dettagli erano un po' scarsi poiché il difetto non era ancora stato scoperto). Quello che intendo dire, però, è che sebbene nessuna di tali tecnologie rappresenti un componente incorporato, sono comunque entrambe disponibili nella maggior parte dei computer in quanto largamente utilizzate in Internet. Per entrambe l'aggiornamento è un po' problematico, ciascuna presenta un meccanismo di aggiornamento automatico che però non si attiva molto spesso.
Inoltre, la maggior parte degli utenti finali semplicemente non si rende conto della presenza di tali tecnologie e della necessità di eseguirne l'aggiornamento. In molti casi, queste tecnologie erano state fornite nell'immagine OEM del computer che, per il cliente, è indistinguibile dal sistema operativo. Per quanto riguarda l'utente finale, se non viene segnalato alcun aggiornamento tramite Windows® Update significa che non vi sono aggiornamenti disponibili.
Il secondo problema è che i meccanismi di aggiornamento sono spesso più complicati del necessario. Qualsiasi meccanismo di aggiornamento che non dispone di una modalità completamente automatica è improbabile che venga utilizzato spesso, poiché gli utenti in genere non sanno di dovere eseguire lo strumento di aggiornamento. Inoltre, nella maggior parte dei casi, l'utente deve essere un amministratore per installare gli aggiornamenti. Nel peggiore dei casi, l'utente deve essere un amministratore anche solo perché gli sia notificata la disponibilità un aggiornamento.
Infine, sta diventando sempre più comune per i fornitori utilizzare tecnologie di aggiornamento del software per distribuire software completamente non correlato che l'utente non ha installato, barre degli strumenti e così via. Le tecnologie di aggiornamento del software, da mezzo destinato specificamente alla distribuzione di aggiornamenti per il software sono diventate un mezzo per distribuire software aggiuntivo.
Due casi molto evidenti sono il servizio Windows Update di Microsoft® (illustrato nella Figura 1) e Apple Software Update (illustrato nella Figura 2). Sia Apple che Microsoft hanno scelto di utilizzare i loro meccanismi di aggiornamento non solo per aggiornare il software ma anche per distribuire software nuovo che l'utente originariamente non aveva installato.
Figura 1 Utilizzo di Windows Update per distribuire Silverlight (fare clic sull'immagine per ingrandirla)
Figura 2 Utilizzo di Apple Software Update per distribuire Safari (fare clic sull'immagine per ingrandirla)
Nel caso di Apple, viene offerto sia iTunes che Safari, anche se è stato installato solo QuickTime. È interessante notare che tali i programmi sono selezionati per impostazione predefinita.
Nel caso di Windows Update, il nuovo software distribuito più recentemente tramite il servizio di aggiornamento è Silverlight™. In passato, Microsoft ha utilizzato questa tecnica per distribuire software nuovo. Almeno possiamo dare credito a Microsoft di non avere spuntato la casella per installare il nuovo software per impostazione predefinita.
Questo approccio, ovvero distribuire software nuovo attraverso un meccanismo di aggiornamento, causa due problemi agli utenti. Innanzitutto, molti finiranno per avere sul proprio computer più software di quelli inizialmente installati. Come sapete, tutti i software, di qualsiasi natura siano, presentano dei bug e alcuni potrebbero rivelarsi delle potenziali vulnerabilità di protezione. E alcune di quelle vulnerabilità potrebbero essere utilizzate per alcune forma di attacco. Di conseguenza, un certo numero di utenti riceverà un attacco attraverso il software di cui non ha bisogno o che neanche utilizza, distribuito sul computer attraverso un meccanismo di aggiornamento del software.
Un altro effetto è che gli utenti potrebbero farsi un'idea sbagliata del valore dei meccanismi di aggiornamento del software. Se gli utenti vedono che i meccanismi di aggiornamento del software sono utilizzati per distribuire software nuovo, invece di nuovi aggiornamenti, potrebbero considerare tali meccanismi un inganno e smettere di utilizzarli. Si provi anche solo ad immaginare come si può sentire un utente dopo aver ricevuto un attacco a causa di una vulnerabilità proveniente da un programma che non usa mai, ma che ha ricevuto attraverso un meccanismo di aggiornamento del software.
Per la salute e la protezione dell'ecosistema tecnologico esistono poche cose più pericolose degli utenti che perdono la fiducia nelle tecnologie che dovrebbero proteggerli. Una volta che gli utenti perdono fiducia, quelle tecnologie inizieranno a essere respinte e alla fine cadranno in disuso. Se tecnologie essenziali per la sicurezza, come le tecnologie di aggiornamento,non vengono più utilizzate, l'intero ecosistema tecnologico sarà a rischio. La difesa di questo ecosistema è la ragione per cui Microsoft distribuisce aggiornamenti sulla protezione anche ai computer sui quali sa che viene eseguito software pirata.
Per questa ragione, apprezzo profondamente l'interfaccia di aggiornamento chiara e appositamente progettata di Mozilla Firefox, mostrata nella Figura 3. Spero veramente che Mozilla continui a evitare la tentazione di distribuire software aggiuntivo attraverso il proprio strumento di aggiornamento del software.
Figura 3 L'interfaccia di aggiornamento software per Firefox è una delle più chiare del settore (fare clic sull'immagine per ingrandirla)

Messaggi sulla sicurezza incoerenti
Sarebbe bello se il settore concordasse un messaggio comune da visualizzare ai consumatori. Mentre nell'industria IT la competizione è essenziale, i consumatori dovrebbero imparare il significato di sicurezza. Sfortunatamente, ciò non è facile se l'industria continua a inviare messaggi contraddittori. Francamente, mi accontenterei che ogni azienda fosse coerente nei propri messaggi.
Mentre l'industria probabilmente non concorderà mai un tale messaggio comune, almeno ci dovrebbe essere coerenza e onestà nei messaggi delle singole aziende. Data l'estrema importanza di garantire che i consumatori continuino a fidarsi delle tecnologie di protezione, l'industria nel suo insieme deve fare di meglio.
Allo stesso modo, anche gli utenti si devono chiedere cosa ha veramente valore oggi. Ad esempio, io credo che i software antivirus siano ben lontani dall'essere tanto efficaci ed essenziali quanto l'industria ci spinge a pensare. Considerate il computer che mio figlio di sette anni usa e il computer che si trova nella mia cucina. Entrambi hanno un software antivirus e nei tre anni successivi all'installazione nessuno dei due ha mai lanciato un allarme per qualsivoglia motivo. Ora, non dico che dovremmo abbandonare i software antivirus, ormai rappresentano dei componenti di base dell'ecosistema tecnologico. Ovviamente, se all'improvviso eliminassimo tutti i software antivirus, gli utenti malintenzionati sfrutterebbero rapidamente la situazione e si inizierebbe ad individuare un maggior numero di infezioni.
Qui il punto è che l'industria deve considerare quali sono le funzionalità di cui gli utenti hanno realmente bisogno nei propri prodotti per la sicurezza, quanto efficaci sono queste funzionalità e come le aziende possono comunicare questi bisogni e valori ai clienti. Per come stanno le cose, oggi gli utenti ricevono sulla sicurezza troppi messaggi contraddittori, esagerati e spesso falsi.

È una questione di caselle di controllo
Per fare un esempio, osserviamo che l'industria dei software di protezione è tutta incentrata sulle suite. Oggigiorno, il software di protezione è quasi esclusivamente distribuito come bundle di funzionalità apparentemente non correlate. E praticamente non esistono indicazioni riguardo a quale di quelle funzionalità gli utenti hanno davvero bisogno.
Questo sembra portare a una gara per selezionare sempre più caselle di controllo. Se da una parte gli elenchi di controllo offrono un buon modo per confrontare i prodotti, possono anche dare origine a funzionalità non necessarie o non desiderabili o nemmeno sensate. Dalla figura 4 alla 7 sono illustrati quattro diversi elenchi di segni di spunta di quattro diversi fornitori di software di protezione. È giusto supporre che il prodotto con 17 segni di spunta sia superiore a quello con soltanto 10 segni di spunta?
Io trovo queste figure davvero molto divertenti. Nella Figura 4, il prodotto ha ricevuto un segno di spunta perché è una versione nuova. Il prodotto nella Figura 5 ottiene un segno di spunta perché, sostiene l'azienda, "Ferma gli attacchi provenienti da siti Web nefandi". Il prodotto nella Figura 6 ottiene dei punti extra perché "protegge i bambini online". Ovviamente nessuno vuole un prodotto che non sia in grado di proteggere i bambini. Il vincitore, tuttavia, ottiene un premio per la creatività per avere incluso in una suite di protezione funzionalità quali la pulitura dei registri e la deframmentazione del disco rigido. La prima funzionalità è raramente o completamente non necessaria e l'altra è già presente nel sistema operativo. Infatti, il sistema operativo Windows contiene già le soluzioni per 15 dei 17 segni di spunta illustrati nella Figura 7.
Figura 4 Questo prodotto di eccellenza ha soltanto 10 segni di spunta (fare clic sull'immagine per ingrandirla)
Figura 5 Questo prodotto con 11 segni di spunta deve essere migliore (fare clic sull'immagine per ingrandirla)
Figura 6 Un momento, questo ha 12 segni di spunta (fare clic sull'immagine per ingrandirla)
Figura 7 Questo prodotto che presenta 17 segni di spunta deve essere la soluzione migliore, giusto? (fare clic sull'immagine per ingrandirla)
Qui vediamo alcune tendenze fastidiose. Questi prodotti non solo duplicano funzionalità già contenute nel sistema operativo (fatto non menzionato nel materiale per il marketing), ma fanno anche affermazioni assolutamente false. Ad esempio, nessun software di protezione al mondo può davvero fermare gli attacchi provenienti da qualsiasi fonte, è possibile solo aiutare a impedirli. Né può un qualsiasi prodotto nascondere realmente la nostra presenza agli utenti malintenzionati.
Il problema è che il mercato della protezione dei software è nato in gran parte per proteggere gli utenti dalle vulnerabilità insite nei prodotti creati da altri fornitori. Quei fornitori però stanno facendo costanti progressi nella protezione dei propri clienti e, di conseguenza, l'industria dei software di protezione vede minacciato il proprio modello di business. Comunque, a causa del continuo emergere di nuovi rischi l'industria dei software di protezione ha certamente molto da offrire, ma i fornitori devono aiutare i clienti a gestire il rischio, non semplicemente a proteggersi da quelle che non sono più reali minacce.

Chiamata alle armi
Se c'è una cosa di questa serie in tre parti che vorrei rimanesse impressa nei lettori, è la considerazione che noi, come industria, dobbiamo parlare agli utenti e ai clienti in modo franco. Dobbiamo spiegare quali sono i rischi e come gli utenti possono fronteggiarli. E, infine, dobbiamo iniziare a fornire loro i mezzi per proteggersi.
Ciò che maggiormente mi preoccupa riguardo a queste "soluzioni" è che esiste la reale possibilità che a lungo termine finiscano per danneggiare la sicurezza. Se gli utenti e anche i manager dell'industria IT, credono veramente che questi prodotti risolvano rischi reali per la protezione e soprattutto tutti quei rischi che ingannevolmente affermano di poter risolvere, potremmo perdere l'opportunità per insegnare agli utenti come proteggersi davvero.
Prendiamo ad esempio i sistemi di autenticazione basati su password. Se gli utenti credono di essere davvero protetti dai deboli componenti aggiuntivi ai sistemi di autenticazione basati su password, di cui ho discusso nella prima parte di questa serie, potrebbero assumere atteggiamenti ancor più rilassati e utilizzare password ancor meno sicure. Nei casi peggiori evidenziati in questa serie, la tecnologia di fatto forza l'utente a utilizzare una protezione più debole di quella che sarebbe stata utilizzata se la nuova tecnologia non fosse stata implementata. Questo significa che, nel momento in cui gli utenti malintenzionati scopriranno come sconfiggere questi sistemi, spesso non è così difficile, la situazione sarà peggio di quella attuale. Ciò potrebbe dare origine a un significativo problema di sfiducia e causare l'abbandono di soluzioni realmente valide da parte degli utenti.
È necessario intraprendere sin da ora le azioni necessarie per proteggere l'ecosistema tecnologico che sostiene le nostre aziende. L'innovazione naturalmente va incoraggiata, ma è necessario anche stare molto attenti a evitare che l'innovazione fine a se stessa ostacoli l'analisi dei rischi reali. Altrimenti le misure di protezione saranno solo apparenti e alla fine cederanno.
Lo stesso vale per gli altri esempi trattati. Consideriamo ad esempio l'inutile e ingannevole simbolo di protezione. Non porta assolutamente alcun vantaggio agli utenti, li fa adagiare su un senso di sicurezza malriposto e consente ai fornitori di servizi in linea di rifilare ottimizzazioni che in realtà danneggiano indirettamente gli utenti. Oltretutto, il costo per fornire agli utenti informazioni adeguate in merito è solo di poche migliaia o, nel peggiore dei casi, di qualche decina di migliaia di dollari. È veramente troppo chiedere ai fornitori di spendere questi soldi per cercare di proteggere i propri clienti e le loro attività?
Questa considerazione comporta molte implicazioni. Per prima cosa dobbiamo affrontare la nostra percezione che gli utenti siano incapaci di prendere decisioni e quindi si debba impedire loro di farlo. Gli utenti non sono incapaci di imparare a prendere decisioni. Dopotutto, questi utenti ne hanno prese molte, come decidere di comprare un computer, utilizzare il nostro sito o comprare uno dei nostri prodotti o servizi. Proprio come si deve imparare a guidare un'automobile in modo sicuro, allo stesso modo bisogna imparare a utilizzare un computer in modo sicuro. Oggi gli attacchi sono diretti personalmente agli utenti e non si può fare affidamento sulla tecnologia per prendere decisioni. Piuttosto, le tecnologie di protezione devono essere dei sistemi di supporto alle decisioni e fornire le giuste informazioni al momento giusto per mettere in grado l'utente di fare una scelta intelligente.
Alcune delle peggiori interfacce utente del mondo provengono da soluzioni di protezione, perché le applicazioni sono state pensate o per nascondere all'utente qualsiasi tipo di processo decisionale o per scaricare (in modo per nulla user-friendly) tutti i dati disponibili sull'utente. Nessuno dei due approcci funziona. Il primo mette in pericolo l'utente perché non ci si può affidare alla tecnologia per fare la scelta giusta. E, se si percepisce che la tecnologia ostacola gli obiettivi aziendali dell'utente, non passerà molto tempo prima che venga disattivata. L'altro approccio invece fallisce perché la gente non vuole essere infastidita da indirizzi IP, ID di processo e altri dati apparentemente privi di senso. Vogliono solo sapere cosa fa il computer con le password e le carte di credito. Questo, dopotutto, è il compito delle soluzioni di protezione.

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


Field Notes Innovazione dall'interno
Romi Mahajan

Nel suo libro, Il futuro del management, Gary Hamel, famoso esperto di gestione e strategie aziendali, spiega che il vantaggio competitivo nel lungo periodo deriva dalla creazione di una cultura innovativa che è di per sé un prodotto dell'evoluzione delle tecnologie di gestione. Sebbene, sotto molti aspetti, l'industria si sia rinnovata e reinventata innumerevoli volte, la maggior parte delle aziende è ancora pervasa da una cultura di gestione gerarchica. Ciò impedisce a qualsiasi cultura veramente innovativa di emergere perché non produce rendimenti dignitosi sulla creatività umana e sul capitale.
Tali gerarchie costituiscono dei veri e propri anatemi per l'innovazione e la creatività umana, quando è libera di esprimersi, rappresenta lo stimolo principale del vantaggio competitivo nel lungo periodo. Quando la creatività umana è tenuta a freno, oltre l'80% di lavoratori non si impegna nel lavoro che svolge. Hamel crede che questa situazione non solo sia un fallimento commerciale, ma anche morale.
In linea di massima, ciò costituisce un pressante richiamo all'industria per una doverosa messa al bando dell'eccessiva gerarchia. Nella sua essenza, il ragionamento è fondamentalmente antiburocratico. Il potere decisionale non dovrebbe essere una prerogativa di manager lontani dalla realtà e di ricchi dirigenti.
Hamel spiega che la gestione, e non l'IT, è il motore dell'innovazione. L'IT, dopotutto, può essere mercificata, quindi come può generare un vantaggio competitivo? Se l'IT non è il motore dell'innovazione, e se i miglioramenti della produttività, i tempi di attività, l'affidabilità, l'adozione rapida di nuove applicazioni e della tecnologia single sign-on (e simili) non generano un vantaggio competitivo, allora perché preoccuparsi così tanto?
Si è disposti a fare un esame approfondito della propria azienda e della propria organizzazione IT nel suo complesso per accertare la validità dell'osservazione di Hamel? Come si può essere sicuri che l'IT non sia considerata una merce?
Adottando quelli che ritengo i migliori concetti di Hamel e usandoli per aiutare le organizzazioni IT ad assicurarsi un futuro come centri di innovazione, ho sviluppato una teoria denominata "Innovazione dall'interno". L'uso ottimale della creatività umana e del capitale è fondamentale per il vantaggio competitivo nel lungo periodo e le organizzazioni all'avanguardia devono connaturare l'innovazione alle loro funzioni. Le organizzazioni devono abbracciare la comunità, non la burocrazia. E, cosa più importante, la gestione spesso si contrappone alla vera innovazione. Pertanto, solo quando la gestione si evolve, la vera innovazione risulta possibile.
Diamo un'occhiata alle organizzazioni IT. Il personale IT tende a essere intelligente, dedicato e ha voglia di contribuire al successo aziendale. Spesso chiamato a fare di più con meno risorse, impiega la maggior parte del tempo a svolgere le attività principali, il che lascia poco tempo all'innovazione.
Il mio concetto di "Innovazione dall'interno" si applica alla teoria di Hamel nel campo dell'IT. I principi fondamentali sono:
  • Dato che la creatività è connaturata nel personale IT, è nel nostro interesse assicurare un modello di gestione IT che sfrutti al meglio questo potenziale.
  • L'innovazione viene da un processo sistematico ed irriverente fatto di pensiero-prova-errore-revisione, un processo che è intrinseco all'IT.
  • Quando si abbraccia la comunità profondamente e apertamente, ecco che emergono le soluzioni tecniche. L'IT può aprire la strada, a iniziare dal proprio lavoro.
  • Nell'informatica, le persone sono l'unico motore del vantaggio competitivo.
  • La gestione IT deve evolversi spostando l'attenzione dal progetto e dal budget verso una nuova e stimolante gestione dell'innovazione.
  • L'IT non dovrebbe occuparsi di come contenere i costi, ma di come conseguire grandi risultati.
Sei pronto a credere in questa teoria? È possibile applicare il concetto di "Innovazione dall'interno" e dimostrare che le organizzazioni IT sono il posto giusto per condurre questo importante esperimento? I manager sono pronti a privarsi del potere e ad abbracciare le loro comunità? La direzione è pronta a rinunciare al suo potere e ad abbracciare il talento collettivo?

Romi Mahajan è Chief Marketing Officer presso Ascentium Corporation. Prima di passare ad Ascentium, ha lavorato per più di sette anni presso Microsoft, ricoprendo da ultimo il ruolo di Director of Technical Audience and Platform Marketing. Romi ha pubblicato molte opere in materia di tecnologia, politica, scienze economiche e sociologia.


Windows Confidential Windows 95 Unplugged
Raymond Chen

Sebbene i programmi a 32 bit per Windows® 95 fossero in grado di utilizzare un compilatore standard a 32 bit e programmi a 16 bit un compilatore standard a 16 bit, per lo stesso Windows 95 è stato necessario un compilatore speciale, in grado di interpretare entrambi i mondi a 32 e 16 bit e di colmare tale lacuna. Per Windows 95 è stato inoltre necessario un linker personalizzato che capisse come unire questi due tipi di codice e un linker personalizzato per VxDs (il formato driver per Windows 95).
Il team Windows 95 si è affidato al reparto linguaggi e strumenti per fornire compilatori e linker per applicazioni specifiche. Sono sicuro che il reparto linguaggi ha trovato la seguente richiesta alquanto strana: "Vorresti un compilatore che faccia X, Y, e Z e che sia utilizzato per compilare soltanto due DLL per tutta la sua durata"? È vero. Ma questi erano, dopotutto, due DLL piuttosto importanti.
Malgrado l'assurdità apparente della richiesta, il reparto linguaggi e strumenti è riuscito nell'intento, facendo diventare il compilatore e il linker parti altamente specializzate del processo di generazione di Windows 95. Certo, il compilatore non era stato completato alla sua prima uscita. Il team di Windows ha ricevuto una versione preliminare e in seguito aggiornamenti periodici man mano che nuove ottimizzazioni erano implementate e gli errori riparati.
Un giorno la generazione Windows 95 rallentò inaspettatamente. Un file che solitamente utilizzava pochi secondi per creare un collegamento improvvisamente impiegava minuti. Il file veniva tuttavia generato correttamente, ma impiegava molto tempo. E non era un problema che colpiva solamente un computer di uno sviluppatore: l'intero team venne colpito. Il nostro codice ha scoperto improvvisamente un caso patologico nel linker? Ci siamo imbattuti in un errore del linker?
Dopo alcuni tentativi di debug, abbiamo identificato la sorgente del problema. La versione più recente del linker conteneva del codice diagnostico che il reparto linguaggi aveva dimenticato di rimuovere prima di dare il codice al team di Windows. Questo codice diagnostico ha registrato il suo output in un file memorizzato in un computer nell'ufficio di un membro del team del compilatore. E il computer in quel momento si è spento. (Questo riporta a Leslie Lamport, famoso per aver descritto un sistema distribuito come uno in cui non è possibile concludere alcun lavoro perché un computer di cui non hai mai sentito parlare è spento).
Quella versione del linker aveva lavorato tranquillamente per settimane. Ogni volta che qualcuno tentava di collegare un VxD durante la generazione di Windows 95, veniva eseguito un aggiornamento del file posto in quel computer dello sviluppatore. Finché quel computer è rimasto acceso e connesso alla rete, nessuno ha mai notato nulla. Ma un giorno quel computer si è spento e tutto è estremamente rallentato.
Una volta identificato il problema, il team del compilatore non ha impiegato molto tempo a fornire al team di Windows una patch che rimuovesse il codice diagnostico dal linker.
Esistono diversi punti salienti di questa storia, a seconda di chi la racconta. Quando racconto la mia storia, il punto saliente è, "E quello sviluppatore del compilatore trasferitosi in seguito nel team di Windows è finito per diventare il mio capo". Ho spesso avuto il piacere di raccontare nuovamente questa storia come una lieve presa in giro.
Tuttavia, se fosse il mio capo a raccontare questa storia, il punto saliente sarebbe piuttosto diverso: "E il risultato è che non ho nemmeno scritto io quel codice diagnostico. È stato uno dei miei colleghi che ha deciso di riempire il mio computer con le informazioni diagnostiche, al posto del suo!"

Sul sito Web di Raymond Chen, The Old New Thing, così come nell'omonimo libro, vengono illustrate la storia di Windows e la programmazione con Win32. Nel suo DNA vi è codice morto.