 TechNet Magazine December 2007

TechNet Magazine December 2007

Comunicazioni: 16 nuove funzionalità di Exchange Server 2007 Service Pack 1

A differenza dei soliti Service Pack, il Service Pack 1 di Exchange Server 2007 offre molto più di aggiornamenti rapidi e miglioramenti della protezione. Ecco una panoramica su alcune delle nuove funzionalità e potenzialità più importanti offerte dal SP1.

Tony Smith Comunicazioni: Replica continua di standby in Exchange Server 2007 Service Pack 1

Una delle funzionalità più interessanti offerte dal Service Pack 1 è la replica continua di standby. Nell'articolo si descrive come questa funzionalità consenta di incrementare i tempi di attività, limitare le perdite di dati e semplificare la manutenzione e il mantenimento della posta elettronica.

Scott Schnoll Comunicazioni: Utilizzo di Exchange in Windows Server 2008

È ora di prepararsi a utilizzare Exchange in Windows Server 2008. Il team di sviluppo di Microsoft Exchange lo fa già da qualche tempo e Paul Bowden dispensa qui utili consigli e alcune lezioni impartite dall'esperienza.

Paul Bowden Comunicazioni: Distribuzione della messaggistica unificata con Exchange Server 2007

La combinazione di funzionalità di posta vocale, fax e posta elettronica in una singola cassetta postale può sembrare un'attività molto complessa. Ma è molto più semplice di quanto si possa pensare. Questa è una guida per la distribuzione della messaggistica unificata in un'organizzazione.

Jeff Goodwin Protezione: Una guida introduttiva alle indagini forensi sui computer

Alcuni semplici ed economici approcci alle indagini forensi sui computer che gli amministratori possono utilizzare per le proprie ricerche di base.

Tom Cloward and Frank Simorjay Rete: Report Microsoft sullo stato della protezione

Microsoft raccoglie i dati sui rischi di protezione affrontati dagli utenti. Ecco una panoramica sulle tendenze più recenti, sulle prestazioni fornite dalle varie versioni di Windows, sulle aree del mondo più colpite e altro ancora.

Tim Rains Rete: Individuazione dei problemi di rete più elusivi

Quando un computer non comunica con gli altri computer della rete senza alcuna causa apparente, questi suggerimenti possono aiutare a diagnosticare e risolvere rapidamente il problema.

Christopher Stoneff Dal redattore: Che la conversazione inizi

Joshua Hoffman Lettere: La parola ai lettori

Casella degli strumenti: Nuovi prodotti per professionisti IT

Greg Steen Domande e risposte su SQL: Configurazione della memoria, profiling delle prestazioni, impostazione del fattore di riempimento e altro

Edited by Nancy Michell Utilità in primo piano: Microsoft Security Assessment Tool

Questa utilità gratuita e il questionario elettronico possono aiutare le organizzazioni di dimensioni medie a individuare e risolvere i rischi di protezione di rete.

Lance Whitney The Cable Guy: Server dei criteri di rete (Network Policy Server)

Il servizio Server dei criteri di rete (NPS, Network Policy Server) in Windows Server 2008 sostituisce Servizio autenticazione Internet (IAS, Internet Authentication Service) utilizzato in Windows Server 2003 e apporta numerose novità, dalla possibilità di imporre requisiti di integrità del sistema a funzionalità di gestione migliorate

Joseph Davies Windows PowerShell: Approfondimenti

Windows PowerShell fornisce un'ampia gamma di funzionalità che vengono spesso sottovalutate. Adottando un approccio metodico all'esplorazione dei cmdlet di Windows PowerShell, si avrà modo di scoprire alcune potenti funzionalità finora trascurate.

Don Jones Hey, Scripting Guy!: Il ritorno di WinRM

È stato il maggiordomo? Era nascosto nella dispensa con il candeliere? In questo articolo non verrà data risposta ad alcuna di queste domande. Ma dopo quattro lunghe settimane, gli Scripting Guy tornano a colpire con la Parte 2 della serie in due parti su WinRM.

The Microsoft Scripting Guys Controllo della protezione: Criteri password del dominio Windows

Finora, Windows ha consentito l'implementazione di un singolo criterio password per ciascun dominio. Windows Server 2008, tuttavia, consente agli amministratori di implementare più criteri password, personalizzando i criteri in base alle esigenze dei diversi tipi di utenti.

Derek Melber Desktop file: Distribuzione di Windows in un mondo virtuale

Chi non ha ancora preso in considerazione la virtualizzazione dovrebbe iniziare a pensarci. Tutto ciò che serve sapere per distribuire sistemi virtuali: cosa evitare e come funziona la virtualizzazione dietro l'interfaccia.

Wes Miller Taccuino: Il futuro intercambiabile

L'informatica tende sempre più a rivolgersi al pubblico dei consumatori, seguendo la tendenza della tecnologia e delle percezioni della vita privata a fondersi con la tecnologia e le percezioni della vita professionale. Gli effetti sulla vita privata e professionale sono profondi.

Romi Mahajan Windows Confidential: Un joystick non deve essere un microonde

Il modo in cui l'interfaccia del joystick force feedback DirectInput specifica forze periodiche, con alcuni risultati imprevisti.

Raymond Chen


 Comunicazioni: 16 nuove funzionalit&#224; di Exchange Server 2007 Service Pack 1
Comunicazioni Tony Smith

16 nuove funzionalità di Exchange Server 2007 Service Pack 1
Panoramica:
  • Nuove funzionalità di gestione
  • Ruoli del server migliorati
  • Miglioramento della messaggistica unificata

La maggior parte degli amministratori ha dimestichezza con il processo di download e applicazione dei Service Pack per server e sistemi desktop. Questi download, naturalmente, forniscono aggiornamenti rapidi e miglioramenti della protezione che
consentono di tenere sempre aggiornati i propri sistemi. A volte, tuttavia, un Service Pack offre vantaggi che vanno oltre i semplici aggiornamenti. Questo è quanto avviene con la versione imminente di Microsoft® Exchange Server 2007 Service Pack 1, che include nuove interessanti funzionalità.
Il download, disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=91472, può essere utilizzato per eseguire un'installazione completa di Exchange Server 2007 (con l'implementazione di tutti gli aggiornamenti di SP1) e per aggiornare le installazioni esistenti di Exchange Server 2007. Sebbene possa essere installato in Windows Server® 2003 SP1, SP2 e R2, Exchange Server 2007 SP1 supporta la compatibilità con la nuova versione Windows Server 2008.
Con il Service Pack 1 vengono introdotte molte nuove funzionalità e alcuni miglioramenti che verranno illustrati in questa breve panoramica. L'articolo contiene un elenco descrittivo di alcune delle modifiche più importanti di cui è possibile avvalersi per migliorare l'ambiente Exchange. Per un'illustrazione dettagliata di tutte le modifiche, vedere l'articolo "Novità di Exchange Server 2007 SP1" all'indirizzo technet.microsoft.com/bb676323.aspx.

Modifiche a Exchange Management Console
Il Service Pack 1 introduce alcune utili funzionalità in Exchange Management Console, illustrata nella Figura 1. Per iniziare, Casella degli strumenti, che contiene un insieme di strumenti di diagnostica, risoluzione dei problemi e ripristino installati per impostazione predefinita con Exchange Server 2007, ora include le funzionalità Public Folder Management Console, Editor modelli di informazioni e visualizzatore del registro di routing.
Figura 1 Exchange Management Console con Service Pack 1
Figura 1 Exchange Management Console con Service Pack 1
È possibile utilizzare Exchange Management Console, Public Folder Management Console, Editor modelli di informazioni e Visualizzatore code per esportare elenchi dal riquadro dei risultati e dal riquadro di lavoro. Gli elenchi possono essere esportati come Testo (delimitato da tabulazione), Testo (delimitato da separatore elenco), testo Unicode (delimitato da tabulazione) e testo Unicode (delimitato da separatore elenco). Oltre a filtrare il riquadro dei risultati in Exchange Management Console, ora è possibile filtrare il riquadro dei risultati in Public Folder Management Console, Editor modelli di informazioni e Visualizzatore code.
L'aspetto più interessante, tuttavia, è che Exchange Management Console include una serie di nuove interfacce di gestione, ad esempio la funzionalità Public Folder Management Console, sopra menzionata. Nell'articolo queste interfacce di gestione verranno trattate separatamente.

Supporto per IPv6
Dal supporto per Windows Server 2008 deriva il supporto per Internet Protocol versione 6 (IPv6). Ovviamente, questo supporto prevede l'installazione di Exchange Server 2007 in Windows Server 2008 e l'attivazione degli stack di protocollo IPv4 e IPv6. Se si disattiva IPv4 prima dell'installazione, Exchange non fornirà il supporto per IPv6.
È possibile immettere gli indirizzi e gli intervalli IP nel formato IPv4 o IPv6. Tutti i ruoli del server possono inviare e ricevere dati da e verso dispositivi, server e client che utilizzano gli indirizzi IPv6. L'unica eccezione è rappresentata dal ruolo del server Messaggistica unificata. Il motivo è che il ruolo Messaggistica unificata richiede l'utilizzo di IPv4 a causa delle limitazioni con alcuni componenti di telefonia e sintesi vocale necessari.

Interfaccia utente di amministrazione per POP3 e IMAP4
Exchange Management Console prevede una nuova interfaccia utente di amministrazione per la gestione di POP3 e IMAP4. Nell'interfaccia utente è possibile configurare tutte le impostazioni POP3 e IMAP4 per il server Accesso client, comprese le impostazioni della porta, di autenticazione e di connessione. Nella Figura 2 viene illustrata la finestra di dialogo per la configurazione delle proprietà per IMAP4; le stesse opzioni sono disponibili per POP3.
Figura 2 Exchange Management Console per POP3/IMAP4
Figura 2 Exchange Management Console per POP3/IMAP4

Gestione delle cassette postali più efficiente
Le funzionalità di gestione delle cassette postali in Exchange Management Console ora supportano la creazione globale delle cassette postali per gli account utente esistenti. Le nuove procedure guidate inoltre consentono agli amministratori di concedere o rimuovere i diritti di accesso completo per una cassetta postale e di configurare le autorizzazioni Invia come per una casetta postale.

Nuove funzionalità per la gestione dei dati delle cassette postali
Ora, un amministratore può importare ed esportare i file .pst per la gestione dei dati delle cassette postali. È possibile eseguire questa operazione anche in Exchange Management Shell, utilizzando rispettivamente i cmdlet Import-Mailbox ed Export-Mailbox.
La gestione dei record di messaggistica (MRM, Messaging Records Management) può essere applicata alle cartelle predefinite gestite residenti su un server Exchange che dispone di licenza CAL (Client Access License) Standard di Exchange. Per la gestione dei record di messaggistica per le cartelle personalizzate gestite è necessaria una licenza CAL Enterprise di Exchange. Il nuovo parametro RemoveManagedFolderAndPolicy, utilizzato per il cmdlet Set-Mailbox, rimuove tutti i criteri di gestione dei record di messaggistica da una cassetta postale, rimuove le proprietà di gestione dei record di messaggistica da tutte le cartelle gestite create come parte del criterio di gestione dei record di messaggistica applicato alla cassetta postale e converte tutte le cartelle gestite in cartelle standard.
I nuovi contatori di Performance Monitor consentono di monitorare diverse informazioni sulla deframmentazione in linea, in particolare informazioni relative alla data dell'ultima esecuzione della deframmentazione in linea, al tempo necessario per il completamento del processo e ai risultati ottenuti. Queste informazioni sono particolarmente utili per l'ottimizzazione dell'intervallo di deframmentazione in linea.

Conferma della cancellazione remota
Exchange Server 2007 già consente a un amministratore o un account utente di eseguire una cancellazione remota per cancellare tutti i dati degli utenti da un dispositivo mobile, una funzionalità di protezione molto utile in caso di perdita o di furto di un dispositivo. Con il Service Pack 1, quando il dispositivo riconosce una richiesta di cancellazione remota, viene inviato un messaggio di conferma. L'utente che invia la richiesta (tramite Outlook® Web Access o OWA) riceverà un messaggio di posta elettronica di conferma. Se è l'amministratore che invia la richiesta (tramite Exchange Management Console), il messaggio di posta elettronica di conferma verrà ricevuto sia dall'amministratore che dall'utente.

Client OWA più efficiente
Il client di posta elettronica basato sul Web offre numerosi miglioramenti che garantiscono una messaggistica di qualità eccellente per i lavoratori mobili. Con SP1, gli utenti di OWA possono creare e modificare liste di distribuzione personali e regole sul lato server. Gli utenti, inoltre, possono utilizzare le funzionalità Dumpster e Recupera posta eliminata.
All'interfaccia utente sono stati aggiunti i comandi di copia e spostamento, consentendo agli utenti di spostare e copiare le cartelle tramite il menu di scelta rapida nell'elenco delle cartelle. È inoltre possibile spostare e copiare i singoli elementi nelle cartelle dei messaggi e nelle cartelle pubbliche facendo clic con il pulsante destro del mouse sull'elenco degli elementi o su un'icona sulla barra degli strumenti.
Gli utenti di OWA hanno inoltre l'accesso completo alle cartelle pubbliche senza utilizzare la directory virtuale /public (questo supporto non richiede un server back-end di Exchange 2003). In OWA sono supportate le funzionalità di ricerca delle cartelle pubbliche.
Le funzionalità S/MIME ora consentono agli utenti di leggere e comporre messaggi di posta elettronica firmati e crittografati (vedere la Figura 3). Viene fornito persino il supporto per l'API CNG (Cryptography Next Generation) e per la conformità a Suite-B. È inoltre possibile personalizzare l'interfaccia utente di OWA per facilitare l'integrazione di applicazioni personalizzate.
Figura 3 Impostazioni dei messaggi S/MIME
Figura 3 Impostazioni dei messaggi S/MIME

Monitoraggio della composizione in OWA Light
Outlook Web Access Light, una versione meno complessa di OWA progettata per l'impiego con quasi tutti i browser Web, ora consente di monitorare un'attività mentre un utente sta componendo una voce lunga di qualsiasi tipo (ad esempio, un messaggio o una voce del calendario) per impedire il timeout della sessione (causando la perdita dei dati) mentre l'utente sta ancora digitando. Inoltre i messaggi vengono automaticamente salvati nella cartella Bozze in caso di timeout della sessione dovuto a inattività mentre il modulo di composizione del messaggio è aperto.

Miglioramento delle prestazioni di Direct Push
Direct Push stabilisce una connessione HTTPS tra un dispositivo mobile e il server Exchange 2007. In Exchange 2007 SP1, le dimensioni delle intestazioni della richiesta e della risposta HTTPS sono state ridotte, con conseguente riduzione della quantità di dati inviati e ricevuti da un dispositivo mobile.

Gestione delle cartelle pubbliche
La nuova funzionalità Public Folder Management Console, illustrata nella Figura 4, consente agli amministratori di creare, configurare e gestire le cartelle pubbliche da Exchange Management Console. Gli elenchi di indirizzi, i criteri degli indirizzi di posta elettronica, i gruppi di distribuzione dinamici e le liste di distribuzione sono abilitati per le cartelle pubbliche. Durante la visualizzazione in anteprima dei destinatari degli elenchi di indirizzi, dei criteri degli indirizzi di posta elettronica, dei gruppi di distribuzione dinamici e delle liste di distribuzione, è possibile visualizzare le cartelle pubbliche abilitate alla posta incluse nei criteri di appartenenza al gruppo.
Figura 4 Public Folder Management Console
Figura 4 Public Folder Management Console
Public Folder Management Console in Exchange 2007 SP1 consente di configurare i diritti amministrativi per le cartelle pubbliche. A tale scopo, utilizzare il cmdlet Add-ExchangeAdministrator o la procedura guidata Aggiungi amministratore di Exchange per aggiungere un utente al ruolo di amministratore della cartella pubblica oppure utilizzare il cmdlet Add-PublicFolderAdministratorPermission per concedere o negare diritti specifici per le cartelle pubbliche.

Miglioramento del routing e dell'elaborazione dei messaggi
Distribuiti nell'insieme di strutture di Active Directory®, i server Trasporto Hub sono in grado di gestire tutto il flusso di posta all'interno dell'organizzazione, applicare le regole di trasporto, applicare le regole del journal e recapitare i messaggi alle cassette postali dei destinatari. I messaggi inviati a Internet vengono inoltrati dal server Trasporto Hub al server Trasporto Edge nel perimetro di rete. Con SP1 sono stati introdotti dei miglioramenti a questi ruoli del server.
Exchange Server 2007 include una funzionalità di monitoraggio delle risorse di sistema, denominata Congestione, che consente ai server Trasporto Hub e Trasporto Edge di rispondere all'utilizzo eccessivo delle risorse. Con SP1, il requisito di spazio su disco è stato considerevolmente ridotto, da 4 GB a 500 MB.
Exchange Management Console in SP1 offre impostazioni di configurazione del trasporto aggiuntive. Ora, è possibile configurare uno spazio indirizzo X.400 come dominio autorevole (sono supportati anche indirizzi lunghi X.400).
Il server Trasporto Hub supporta l'accodamento con priorità. La priorità dei messaggi assegnata a un messaggio da un utente di Outlook viene considerata dal classificatore, con la garanzia che i messaggi inviati con priorità alta vengano gestiti per primi e recapitati più rapidamente dei messaggi inviati con priorità bassa.
In Exchange 2007 SP1 l'inclusione nell'ambito di un connettore di invio a un singolo sito di Active Directory viene semplificata dall'aggiunta del parametro IsScopedConnector nei cmdlet di Exchange Management Shell e della casella di controllo relativa al connettore di invio dell'ambito in Exchange Management Console. Quando un connettore di invio viene incluso nell'ambito, solo i server Trasporto Hub nello stesso sito Active Directory dei server di origine del connettore di invio prendono in considerazione tale connettore di invio nell'ambito delle decisioni di routing.

Miglioramenti alla sincronizzazione del Server Trasporto Edge
In Exchange Server 2007 SP1 è possibile utilizzare il cmdlet Start-EdgeSynchronization per avviare immediatamente la sincronizzazione dei dati da Active Directory nel servizio directory Active Directory Application Mode (ADAM). In Exchange 2007 SP1 il cmdlet supporta il parametro Server, che consente di eseguire il cmdlet da un computer remoto.
Il cmdlet Test-EdgeSynchronization, un cmdlet di diagnostica che segnala lo stato di sincronizzazione dei server Trasporto Edge, è stato migliorato con un nuovo parametro che consente di verificare i risultati della sincronizzazione per i singoli utenti.

Clonazione dell'oggetto TransportConfig
Gli script di configurazione clonati consentono agli amministratori di applicare con maggiore facilità una configurazione coerente quando nel relativo ambiente vengono distribuiti più server Trasporto Edge. In SP1 l'oggetto TransportConfig, che controlla le impostazioni a livello di server per il ruolo del server Trasporto Edge, viene ora incluso nelle informazioni sulla configurazione clonata. L'inclusione di questo oggetto semplifica di molto le procedure di distribuzione, backup e ripristino dei server.

Miglioramenti della messaggistica unificata
La Messaggistica unificata era una funzionalità molto interessante della versione iniziale di Exchange Server 2007. Il Service Pack 1 si basa su questa funzionalità, introducendo molto nuove funzionalità e alcuni miglioramenti. Alcune delle funzionalità richiedono la distribuzione di Office Communications Server 2007 nello stesso insieme di strutture di Active Directory, ma molte funzionalità non richiedono Office Communications Server. In questo articolo non è possibile illustrare tutte le modifiche apportate alla messaggistica unificata e, pertanto, verranno esaminate solo alcune delle aggiunte più significative. Per ulteriori informazioni sulla messaggistica unificata, vedere l'articolo "Distribuzione della messaggistica unificata con Exchange Server 2007" in questo numero di TechNet Magazine.
Innanzitutto, si descriveranno alcune delle nuove funzionalità che richiedono Office Communications Server 2007. Ora, viene fornito il supporto per l'attraversamento dei firewall da parte dei flussi multimediali e per i messaggi vocali ad alta fedeltà. La notifica dell'inoltro ha luogo quando vengono lasciati messaggi vocali a una destinazione che utilizza l'inoltro delle chiamate. Gli utenti possono accedere ad Outlook Voice Access da Office Communicator 2007 senza immettere alcun codice PIN. È inoltre garantito il supporto per l'integrazione dei messaggi di posta elettronica per la notifica delle chiamate senza risposta e della notifica della posta vocale con Office Communicator 2007 (vedere la Figura 5). Ma le nuove funzionalità non finiscono qui.
Figura 5 Notifica della posta vocale in Office Communicator
Figura 5 Notifica della posta vocale in Office Communicator
Uno dei miglioramenti apportati alla messaggistica unificata che non richiede Office Communications Server, è rappresentato dal supporto per il protocollo Secure Realtime Transport Protocol (SRTP). La versione iniziale di Exchange Server 2007 offre due modalità di protezione: non protetta e protetta. La modalità protetta consente di crittografare solo il traffico SIP (Session Initiation Protocol) mentre il traffico RTP non viene crittografato. In SP1, sono disponibili tre modalità: non protetta, SIP protetta e protetta. In modalità SIP protetta, viene crittografato solo il traffico SIP, non il traffico RTP. In modalità protetta vengono crittografati sia il traffico SIP che il traffico RTP. È inoltre possibile configurare Mutual Transport Layer Security (MTLS) per i dial plan mediante Exchange Management Console.
Tra le altre modifiche figurano la nuova Abilitazione guidata messaggistica unificata, che è possibile utilizzare per aggiungere un indirizzo SIP o E.164 per un utente; la configurazione del tipo di URI per un dial plan mediante Exchange Management Console; al SP1 è stato aggiunto il supporto della qualità del servizio (QoS, Quality of Service) grazie all'utilizzo di DiffServ per la classificazione del traffico multimediale.

Miglioramento della disponibilità elevata
Nel Service Pack 1 sono disponibili nuove funzionalità che consentono di migliorare gli scenari di disponibilità elevata e vengono introdotti alcuni miglioramenti alle funzionalità di disponibilità elevata esistenti. Le funzionalità nuove e migliorate estendono gli scenari in cui è possibile ottenere la disponibilità di dati e servizi per i ruoli del server di Exchange 2007. I nuovi scenari consentono alle organizzazioni di separare gli scenari di disponibilità elevata dagli scenari di resilienza del sito e di distribuire configurazioni personalizzate in base alle esigenze specifiche dell'organizzazione in ciascuna area.
Il supporto aggiunto per Windows Server 2008 abilita il supporto per i cluster di failover di più subnet e per i nuovi modelli di quorum (testimone del disco e di condivisione file). Sono stati inoltre apportati miglioramenti molto utili alle funzioni di monitoraggio e di creazione di rapporti cluster che includono funzionalità aggiuntive progettate per il monitoraggio proattivo degli ambienti di replica continua. I miglioramenti correlati alle prestazioni includono una riduzione delle operazioni di I/O sui dischi che contengono copie passive di gruppi di archiviazione, una maggiore rapidità del processo di copia dei file di registro e miglioramento della rapidità delle operazioni di spostamento dei server cassette postali cluster tra i nodi.
Infine, sono state aggiunte nuove procedure guidate per migliorare le attività di gestione e configurazione (vedere la Figura 6) e sono stati introdotti nuovi controlli dell'interfaccia utente per la gestione dei server cassette postali cluster, tra cui la nuova scheda Server cassette postali cluster e la pagina di configurazione Replica continua cluster (CCR, Cluster Continuous Replication).
Figura 6 Procedura guidata Manage Clustered Mailbox Server
Figura 6 Procedura guidata Manage Clustered Mailbox Server

Replica continua di standby
La replica continua di standby (SCR, Standby Continuous Replication) utilizza la stessa tecnologia di riesecuzione e di distribuzione dei log utilizzata dalla replica continua locale (LCR, Local Continuous Replication) e da CCR per fornire configurazioni e opzioni di distribuzione aggiuntive. SCR è simile a LCR e CCR, ma presenta caratteristiche peculiari. Per informazioni più dettagliate su SCR, vedere l'articolo "Replica continua di standby in Exchange Server 2007 Service Pack 1" di Scott Schnoll in questo numero di TechNet Magazine.

Conclusioni
Exchange Server 2007 Service Pack 1 offre chiaramente molto più di aggiornamenti rapidi e miglioramenti della protezione. Fornisce numerose nuove funzionalità e diversi miglioramenti che saranno disponibili a breve. Per motivi di spazio, non è stato possibile illustrare tutte le nuove funzionalità e i miglioramenti, ma spero che questo articolo sia riuscito a offrire una panoramica valida delle novità introdotte. Per informazioni complete su tutte le modifiche introdotte nel Service Pack 1 e per i download, i webcast e i forum di discussione, visitare il sito di Exchange Server TechCenter all'indirizzo technet.microsoft.com/exchange.

Tony Smith è Lead Technical Writer per il team di formazione utenti di Exchange, specializzato in messaggistica unificata. Prima di lavorare per Microsoft, Tony ha lavorato come tecnico di rete, fornitore per Microsoft e Microsoft Certified Trainer. Ha inoltre portato a termine alcuni progetti per Microsoft Learning, inclusi libri e manuali di esercitazioni pratiche.
© 2007 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.


 Comunicazioni: Replica continua di standby in Exchange Server 2007 Service Pack 1
Comunicazioni Scott Schnoll

Replica continua di standby in Exchange Server 2007 Service Pack 1
Panoramica:
  • Configurazione della replica continua di standby
  • Importanza della ridondanza
  • Riduzione dei tempi di inattività con SCR

Con il Service Pack 1 vengono introdotte molte nuove funzioni e alcuni miglioramenti per Exchange 2007. Una delle nuove funzionalità, la replica continua di standby (SCR, Standby Continuous Replication), è stata progettata per fornire alle organizzazioni ridondanza nel centro dati e resilienza del sito. Come indicato dal nome, la replica SCR è ideata
per scenari che utilizzano o abilitano l'utilizzo dei server di ripristino di standby.
Chi ha già lavorato con la versione RTM (Release To Manufacturing) di Exchange 2007, sa che l'applicazione fornisce ridondanza all'interno del centro dati e resilienza del sito tramite le funzionalità di distribuzione dei log e il supporto per i cluster di failover di Windows®. Nella versione RTM, la distribuzione dei log, nota ufficialmente come replica continua, è disponibile in due forme: replica continua locale (LCR, Local Continuous Replication), come illustrato nella Figura 1 e replica continua cluster (CCR, Cluster Continuous Replication), come illustrato nella Figura 2.
Figura 1 Replica continua locale
Figura 1 Replica continua locale
Figura 2 Distribuzione dei log su un secondo server in un cluster di failover di Windows tramite la replica CCR
Figura 2 Distribuzione dei log su un secondo server in un cluster di failover di Windows tramite la replica CCR
La replica continua fornisce disponibilità e ridondanza dei dati consentendo agli amministratori di attivare e tenere in linea una seconda copia di ciascun database delle cassette postali. Questa copia dei database rappresenta una prima linea di difesa da errori, perdita o danneggiamento di un database di produzione. Invece di sprecare tempo prezioso per recuperare un nastro di backup per il ripristino dei dati, è possibile attivare una copia di database e trasformarla in pochi minuti in un database di produzione.
SCR estende gli scenari in cui è possibile ottenere la disponibilità di dati e servizi per l'organizzazione. I nuovi scenari consentono di separare le topologie per la disponibilità elevata dalle tipologie per la resilienza del sito, nonché di distribuire configurazioni personalizzate in base alle esigenze specifiche dell'organizzazione in ciascuna area.
La versione RTM di Exchange 2007 garantisce ridondanza all'interno del centro dati e resilienza del sito ma, poiché le repliche LCR e CCR forniscono solo una singola copia aggiuntiva di ciascun database, è necessario scegliere tra resilienza e ridondanza. Si considerino, ad esempio, le funzionalità per la disponibilità di dati e servizi fornite dalla replica CCR. La distribuzione dei nodi attivi e passivi in un singolo centro dati garantisce la disponibilità di dati e servizi all'interno del centro dati, ma non la resilienza del sito, poiché entrambi i nodi si trovano nello stesso sito fisico. La distribuzione del nodo attivo in un centro dati e del nodo passivo in un centro dati secondario garantisce la resilienza del sito ma non la disponibilità nel centro dati, poiché il nodo passivo, che fornisce queste funzionalità, si trova in un centro dati secondario.
Grazie alla funzionalità SCR inclusa nel Service Pack 1, la possibilità di creare copie aggiuntive di ogni database implica che la disponibilità elevata e la resilienza del sito non siano reciprocamente esclusive. Come illustrato nella Figura 3, è possibile ad esempio combinare SCR con CCR per realizzare la replica locale dei gruppi di archiviazione in un centro dati principale (utilizzando CCR per la disponibilità elevata) e la replica remota in un centro dati secondario o di backup (utilizzando SCR per la resilienza del sito). Il centro dati secondario contiene un cluster di standby che è possibile attivare e predisporre rapidamente con un server cassette postali cluster sostitutivo in uno scenario di ripristino del sito.
Figura 3 Distribuzione di CCR nel centro dati di Redmond e di SCR nel centro dati di Quincy
Figura 3 Distribuzione di CCR nel centro dati di Redmond e di SCR nel centro dati di Quincy
Nella Figura 3 viene illustrata una distribuzione aziendale con due centri dati, ciascuno con il proprio sito Active Directory®: Redmond e Quincy. Il sito Redmond si trova nel centro dati principale (produzione), mentre il sito Quincy si trova in un centro dati secondario (backup). CCR viene distribuito nel sito Redmond per garantire la ridondanza all'interno del centro dati. Le destinazioni SCR vengono configurate, insieme agli elementi dell'infrastruttura necessari per Exchange 2007, in un cluster di standby nel sito Quincy per ottenere la resilienza del sito. Questi elementi aggiuntivi dell'infrastruttura, che includono i server Accesso client e Trasporto Hub, i server Active Directory e DNS e l'accesso a Internet, possono essere risorse dedicate o non dedicate. Le risorse dedicate sono le risorse progettate per fornire il supporto solo per gli utenti del centro dati in cui risiedono. Le risorse non dedicate sono le risorse che supportano sia gli utenti nel centro dati locale che gli utenti in altre posizioni. La decisione di utilizzare risorse dedicate o non dedicate dipenderà dalle esigenze specifiche della propria organizzazione. Per ulteriori informazioni sulle risorse dedicate e non dedicate, vedere l'argomento della Guida in linea di Exchange Server 2007 "Configurazioni con resilienza del sito" all'indirizzo technet.microsoft.com/bb201662.aspx. Si noti l'utilizzo di un nuovo tipo di quorum di maggioranza dei nodi (MNS, Majority Node Set). In Exchange Server 2007 la replica CCR utilizza il quorum MNS con il testimone di condivisione file (FSW, File Share Witness) al posto del tradizionale nodo voter, come illustrato nella Figura 3.
Nella Figura 4 la combinazione di CCR e un ambiente SCR progettato per la resilienza fornisce diversi livelli di ridondanza per le cassette postali e i servizi ospitati sul server EXCLUS1, garantendo la protezione delle cassette postali da errori irreversibili su ogni scala.
Figura 4 Server cassette postali autonomi che utilizzano SCR per la replica di gruppi di archiviazione da un server a un altro
Figura 4 Server cassette postali autonomi che utilizzano SCR per la replica di gruppi di archiviazione da un server a un altro
Anche le organizzazioni di piccole e medie dimensioni possono trarre vantaggio dalla replica SCR. Come illustrato nella Figura 4, ad esempio, un'organizzazione può distribuire due server cassette postali autonomi (EXMBX1 e EXMBX2) e utilizzare SCR per la replica di alcuni o di tutti i gruppi di archiviazione da un server cassette postali all'altro.
Nell'esempio EXMBX1 ed EXMBX2 sono server di produzione con cinque gruppi di archiviazione attivi. Ciascun gruppo di archiviazione è un'origine SCR per una destinazione SCR corrispondente sull'altro server. In caso di errore di archiviazione o nel caso in cui un gruppo di archiviazione attivo configurato come origine SCR non sia disponibile, la copia di destinazione SCR può essere rapidamente attivata utilizzando alcune attività amministrative in Exchange Management Shell. L'utilizzo di Microsoft® Office Outlook® 2007 e delle funzionalità di individuazione automatica e portabilità del database di Exchange 2007 consente di ridurre, in modo significativo, i tempi di inattività in caso di perdita di uno o più gruppi di archiviazione attivi.

Origini e destinazioni SCR
Analogamente a quanto avviene con LCR e CCR, anche per la replica SCR vengono utilizzati i concetti di copia attiva e copia passiva di un gruppo di archiviazione, definiti rispettivamente origini e destinazioni SCR. Tuttavia, le origini e le destinazioni SCR sono copie di gruppi di archiviazione (non è possibile abilitare i gruppi di archiviazione di ripristino per la replica SCR).
Il punto di partenza per SCR (origine SCR) è rappresentato da un qualsiasi gruppo di archiviazione su un server cassette postali autonomo o su un server cassette postali cluster in un cluster a copia singola o in un ambiente CCR. È importante notare che, sebbene l'origine SCR possa essere rappresentata da un server cassette postali cluster, la replica SCR non costituisce una soluzione cluster e pertanto non richiede il servizio cluster di Windows. L'endpoint per la replica SCR (destinazione SCR) può essere rappresentato da un server cassette postali autonomo o da un nodo in un cluster di failover nel quale sia installato il ruolo Cassette postali, ma nel cui cluster non sia stato configurato alcun server cassette postali cluster.

Relazioni tra origini e destinazioni
Per ogni gruppo di archiviazione di origine SCR può esistere un numero illimitato di destinazioni SCR. Per un'origine, ad esempio, può esistere una destinazione che risiede nello stesso centro dati e un'altra residente in un centro dati diverso. Tuttavia, Microsoft consiglia di utilizzare non più di quattro destinazioni per ogni origine. Qualora si decida di utilizzare più di quattro destinazioni, è necessario valutarne il potenziale impatto sul server di origine SCR in termini di memoria, CPU e risorse del disco ed effettuare una pianificazione adeguata. Per ogni computer di destinazione SCR possono esistere più server di origine. È necessario che il Service Pack 1 per Exchange 2007 sia installato nel computer di origine e in quello di destinazione e che il sistema operativo sia supportato dal Service Pack 1 per Exchange 2007, ad esempio Windows Server® 2008 o Windows Server 2003 SP2. Tuttavia, indipendentemente dal sistema operativo utilizzato, SCR non fornisce il supporto per più sistemi operativi e richiede che il sistema operativo nell'origine SCR corrisponda al sistema operativo utilizzato in tutte le destinazioni SCR per l'origine in questione. Pertanto, se nell'origine SCR è installato Windows Server 2003, è necessario che Windows Server 2003 venga eseguito anche in tutte le destinazioni SCR per tale origine.
SCR è disponibile in Exchange 2007 Standard Edition. Se un server cassette postali cluster in un ambiente SCC o CCR viene utilizzato come origine SCR, è necessario utilizzare Exchange 2007 Enterprise Edition. In Exchange 2007 Enterprise Edition ciascuna destinazione SCR supporta un massimo di 50 istanze, ossia 50 gruppi di archiviazione replicati, mentre in Exchange 2007 Standard Edition viene supportato un massimo di cinque istanze
È necessario inoltre soddisfare i requisiti delle destinazioni SCR descritti di seguito. Innanzitutto, è necessario che i computer di origine e di destinazione risiedano nello stesso dominio di Active Directory, anche se possono risiedere nello stesso sito o in siti diversi di Active Directory. Inoltre, è necessario che per ciascun gruppo di archiviazione replicato con la funzionalità SCR i percorsi del file di registro e del database nell'origine e in tutte le rispettive destinazioni siano uguali. Infine, quando un nodo o un server viene configurato come destinazione SCR, non è possibile abilitare la replica LCR per alcun gruppo di archiviazione nel computer di destinazione SCR e non è possibile aggiungere alcun server cassette postali cluster al cluster di failover di standby.

Confronto della replica SCR con CCR e LCR
La replica SCR (come illustrato nella Figura 5) utilizza la stessa tecnologia di riesecuzione e di distribuzione dei log utilizzata da LCR e CCR per fornire nuove configurazioni e opzioni di distribuzione. Analogamente a LCR e CCR, i gruppi di archiviazione abilitati per SCR non possono contenere più di un database. Inoltre, non è possibile utilizzare SCR per un database di cartelle pubbliche se nell'organizzazione di Exchange sono presenti più database di cartelle pubbliche.
Figura 5 Utilizzo di SCR per la distribuzione dei log su un altro server o un nodo passivo in un cluster di failover
Figura 5 Utilizzo di SCR per la distribuzione dei log su un altro server o un nodo passivo in un cluster di failover
La differenza principale rispetto alla replica SCR è rappresentata dal fatto che quest'ultima supporta più destinazioni per ogni gruppo di archiviazione, mentre le repliche LCR e CCR supportano una sola destinazione, ossia la copia passiva. Inoltre, a differenza di CCR e LCR, non è possibile eseguire il backup di alcuna copia SCR. In caso di utilizzo di SCR, le intestazioni del database per le destinazioni SCR vengono aggiornate e i file di registro vengono troncati quando per il gruppo di archiviazione dell'origine SCR vengono eseguiti backup supportati (o nel caso di CCR e LCR, quando si eseguono backup delle copie attive o passive del gruppo di archiviazione dell'origine SCR).
Analogamente a LCR e CCR, la distribuzione dei log con SCR è continua e prevede l'utilizzo di un modello di estrazione. Dopo che un nuovo file di registro è stato chiuso e denominato con il numero di sequenza di generazione del file di registro, il servizio di replica di Microsoft Exchange eseguito sul computer di destinazione SCR estrae i file di registro delle transazioni chiusi dal computer di origine SCR e, dopo averli controllati e convalidati, li sposta nella cartella dei file di registro per i gruppi di archiviazione corrispondente sul computer di destinazione SCR.

Ritardo dell'attività di riesecuzione
Dopo che i file di registro sono stati copiati nel computer di destinazione SCR, SCR consente di effettuare un'operazione non eseguibile con LCR e CCR. Anziché rieseguire immediatamente i file di registro nella copia del database, la replica SCR prevede un ritardo incorporato per l'attività di riesecuzione pari a 50 file di registro e impostato su 24 ore. SCR consente inoltre di specificare un ritardo aggiuntivo oltre ai ritardi incorporati. L'impostazione del ritardo per l'attività di riesecuzione si rivela utile in un'ampia gamma di scenari. Ad esempio, in caso di danneggiamento logico di un database attivo, il ritardo può impedire il danneggiamento logico del database di destinazione SCR.
Il ritardo dell'attività di riesecuzione configurato dall'amministratore viene impostato mediante il parametro ReplayLagTime, che stabilisce il periodo di tempo in cui il servizio di replica di Exchange rimane in attesa prima della riesecuzione dei file di registro che sono stati copiati nel computer di destinazione SCR. Il formato del parametro è Giorni.Ore:Minuti:Secondi e l'impostazione predefinita è 24 ore L'impostazione massima consentita per questo valore è sette giorni. L'impostazione minima consentita è 0 secondi, valore con cui si eliminano i ritardi nell'attività di riesecuzione dei registri al di sopra del ritardo predefinito relativo a 50 file di registro.
Oltre a ReplayLagTime, in Exchange esiste un ritardo incorporato specificato a livello di codice di 50 file di registro, indipendentemente dal valore di ReplayLagTime. Per determinare quando deve essere rieseguito un file di registro, in Exchange viene utilizzato il valore più elevato di ReplayLagTime o x file di registro, dove x = 50. Questa caratteristica rappresenta un'ulteriore salvaguardia rispetto all'esigenza di eseguire nuovamente il seeding di un gruppo di archiviazione nei casi in cui in un'origine SCR che utilizza la replica continua, ad esempio un server cassette postali cluster in un ambiente CCR, si verifichi un failover e sia necessario riportare in linea uno o più gruppi di archiviazione mediante il cmdlet Restore-StorageGroupCopy. Il seeding è un processo che prevede l'utilizzo delle API di backup di flusso ESE (Extensible Storage Engine) per la creazione di una copia in linea del database di origine SCR nel computer di destinazione SCR. Grazie al ritardo dell'attività di riesecuzione nelle destinazioni SCR, quando si verifica un failover con perdita di dati in un'origine SCR la necessità di un reseeding delle copie SCR viene ridotta al minimo, poiché la natura della perdita dei dati nell'origine SCR determina un riavvicinamento temporale delle due copie.

Ritardo del troncamento
Nella versione RTM di Exchange 2007 le regole vengono applicate in modo che, in un ambiente di replica continua, un file di registro non venga eliminato se non già inserito in un backup e rieseguito nella copia del database. Quando si utilizza la replica SCR, questa regola viene modificata. Nella replica SCR, che introduce il concetto di copie multiple del database, i file di registro nel computer di origine SCR possono essere troncati non appena ispezionati da tutti i computer di destinazione SCR. Il troncamento dei file di registro sul server di origine SCR non attende la riesecuzione di tutti i registri in tutte le destinazioni SCR, poiché è possibile configurare le copie delle destinazioni SCR definendo un significativo ritardo di riesecuzione dei registri.
È inoltre possibile specificare un ritardo aggiuntivo per il troncamento dei file di registro utilizzando un nuovo parametro denominato TruncationLagTime, che indica il periodo di tempo per cui il servizio di replica di Microsoft Exchange resta in attesa (nel formato Giorni.Ore:Minuti:Secondi) prima di troncare i file di registro copiati nel computer di destinazione SCR e rieseguiti nella copia del database. Il periodo di tempo viene considerato a partire dalla riesecuzione dei file di registro nella copia del database. L'impostazione massima consentita per il valore è sette giorni, mentre l'impostazione minima consentita è 0 secondi, sebbene questa impostazione elimini tutti i ritardi nell'attività di troncamento dei registri.
Per determinare l'eventuale necessità di troncamento dei file di registro, in un ambiente SCR viene eseguito ogni tre minuti un thread in background. Se la sequenza di generazione dei file di registro è al di sotto del punto di arresto dei file di registro del gruppo di archiviazione e il file di registro è precedente a ReplayLagTime + TruncationLagTime, verrà troncato un file di registro nella destinazione SCR.
In un ambiente LCR o CCR esteso con SCR, un file di registro nella destinazione SCR viene troncato quando sono soddisfatti i seguenti criteri: il backup del file di registro è stato eseguito, la sequenza di generazione dei file di registro è al di sotto del punto di arresto dei file di registro per il gruppo di archiviazione, la copia passiva del gruppo di archiviazione è in uno stato che consente il troncamento del file di registro e il file di registro è stato ispezionato da tutte le destinazioni SCR.

Attivazione e gestione della replica SCR
La replica SCR viene attivata mediante il cmdlet Enable-StorageGroupCopy in Exchange Management Shell, che è stato aggiornato in SP1 con nuovi parametri. Come descritto in precedenza, ReplayLagTime e TruncationLagTime consentono di controllare alcuni comportamenti delle destinazioni SCR. Un altro parametro, SeedingPostponed, può essere utilizzato per ignorare il seeding iniziale della destinazione SCR. Il rinvio del seeding può risultare utile in numerose situazioni. Si supponga, ad esempio, che il database nel gruppo di archiviazione abilitato per la replica SCR sia pari a 100 GB. È opportuno evitare che 100 GB di dati attraversino la rete durante i periodi di produzione di picco. Il parametro SeedingPostponed consente di abilitare la replica SCR immediatamente e di eseguire un'attività di seeding in un momento successivo Quando tutto è pronto, eseguire manualmente il seeding della destinazione SCR mediante il cmdlet Update-StorageGroupCopy.
Mentre i parametri sopra riportati sono facoltativi, un parametro di Enable-StorageGroupCopy è obbligatorio per la replica SCR: StandbyMachine. Questo parametro consente di specificare il nome del computer che conterrà la destinazione SCR. Il valore del parametro viene impostato come parte del valore per l'attributo msExchStandbyCopyMachines del gruppo di archiviazione abilitato per SCR. L'attributo msExchStandbyCopyMachines è una stringa Unicode multivalore che viene aggiunta allo schema di Active Directory quando Exchange 2007 SP1 viene introdotto nell'organizzazione di Exchange. Questo è uno dei motivi per cui SP1 richiede un aggiornamento dello schema per Active Directory.
Il parametro StandbyMachine è fondamentale per la replica SCR e in SP1 alcuni cmdlet sono stati aggiornati in modo da utilizzare questo parametro per l'attivazione e la gestione delle destinazioni SCR. I cmdlet aggiornati sono descritti nella Figura 6.
Figure 6 Cmdlet che utilizzano il parametro StandbyMachine (Close Figure 6)

Cmdlet | Descrizione
Disable-StorageGroupCopy | Consente di disattivare una destinazione SCR per un gruppo di archiviazione.
Get-StorageGroupCopyStatus | Consente di determinare lo stato corrente della destinazione SCR.
New-StorageGroup | Consente di creare un nuovo gruppo di archiviazione abilitato per SCR senza dover attivare SCR separatamente mediante il cmdlet Enable-StorageGroupCopy.
Restore-StorageGroupCopy | Consente di disattivare SCR e rendere un database di destinazione SCR disponibile per il montaggio mediante l'esecuzione di un'operazione Mount-Database durante il processo di ripristino.
Resume-StorageGroupCopy | Consente di riprendere la replica continua per un gruppo di archiviazione per il quale la replica SCR è stata sospesa.
Suspend-StorageGroupCopy | Consente di sospendere l'attività di replica continua per un gruppo di archiviazione abilitato per SCR.
Update-StorageGroupCopy | Consente di eseguire il seeding o il reseeding di un gruppo di archiviazione per la destinazione SCR.

Attivazione delle destinazioni SCR
SCR fornisce una o più copie aggiornate dei dati, che possono essere utilizzate nel caso in cui i dati originali vadano persi o diventino inutilizzabili. Il processo che prevede l'utilizzo di una copia di destinazione SCR e la riconfigurazione di tale copia come database di produzione è noto come attivazione. L'attivazione viene eseguita nel corso del processo di ripristino, che prevede l'utilizzo della portabilità del database o di una delle due opzioni di ripristino del programma di installazione (/m:RecoverServer per ripristinare un server autonomo o /RecoverCMS per ripristinare un server cassette postali cluster).

Possibili utilizzi della replica SCR
Verrà ora illustrato come un'azienda fittizia può utilizzare la replica SCR e la portabilità del database per eseguire il ripristino in seguito a un errore di un database delle cassette postali. Dopo aver rilevato che il database di produzione è stato danneggiato, l'amministratore attiva il database di destinazione SCR utilizzando la portabilità del database.
L'organizzazione ha distribuito Exchange 2007 con SP1 e ha deciso di utilizzare la replica SCR per fornire una copia di un gruppo di archiviazione su un server cassette postali remoto. I server cassette postali di origine e di destinazione risiedono entrambi nello stesso sito Active Directory e sono configurati per l'utilizzo dei server DNS integrati in Active Directory. L'intervallo di replica di Active Directory è configurato per 15 minuti.

Attivazione della replica SCR e ripristino per la gestione temporanea
La replica SCR è configurata in modo che i file di registro delle transazioni vengano replicati per un singolo gruppo di archiviazione, SG1, che contiene un solo database, MBX1. I percorsi per i file del gruppo di archiviazione e del database sono C:\SG1 e C:\SG1\MBX1.EDB In questo caso, EXMBX1 rappresenta l'origine SCR e EXMBX2 rappresenta la destinazione SCR. Questa configurazione è illustrata di seguito:
Enable-StorageGroupCopy EXMBX1\SG1
-StandbyMachine EXMBX2
Una volta attivata la replica SCR, lo stato di SCR per SG1 viene verificato mediante il cmdlet Get-StorageGroupCopyStatus:
Get-StorageGroupCopyStatus EXMBX1\SG1
-StandbyMachine EXMBX2
Per risparmiare tempo durante il processo di attivazione della destinazione SCR, EXMBX2 viene preconfigurato con un gruppo di archiviazione, SG1PORT, e un database, MBX1PORT, che verrà utilizzato come parte delle operazioni di portabilità del database. SG1PORT e MBX1PORT sono separati dai file del database e del gruppo di archiviazione della destinazione SCR. Pertanto, i percorsi per SG1PORT e MBX1PORT vengono configurati con un percorso temporaneo che non sia in conflitto con i percorsi della destinazione SCR. SG1PORT e MBX1PORT verranno utilizzati solo come oggetti di portabilità del database; i file del gruppo di archiviazione e del database effettivi per SG1PORT non sono necessari. Per questo motivo, l'amministratore smonta il database MBX1PORT ed elimina tutti i file all'interno del gruppo di archiviazione. Gli oggetti gruppo di archiviazione e database restano in Active Directory in quanto verranno utilizzati in seguito per la portabilità del database durante il processo di ripristino.

Attivazione e ripristino
Una voce del registro eventi applicazioni indica che il database di origine SCR è fisicamente danneggiato. Poiché la replica SCR è stata attivata per SG1, verrà eseguita l'attivazione manuale del database di destinazione SCR per SG1 e si utilizzerà la portabilità del database per ripristinare la disponibilità dei dati. L'attivazione della copia di destinazione SCR inizia con lo smontaggio di MBX1 in SG1 mediante il seguente cmdlet:
Dismount-Database EXMBX1\SG1\MBX1
Il database di destinazione SCR viene quindi reso disponibile per il montaggio e le cassette postali originariamente presenti in MBX1 verranno spostate in MBX1PORT.
Il processo per disattivare SCR e rendere il database di destinazione SCR disponibile per il montaggio prevede l'esecuzione del cmdlet Restore-StorageGroupCopy. Questa attività contrassegna il database del gruppo di archiviazione come montabile e fornisce un report sull'eventuale perdita dei dati in seguito al montaggio del database nel gruppo di archiviazione. Consente inoltre di verificare che tutti i file di registro generati dalla copia attiva del gruppo di archiviazione siano presenti nel percorso dei file del gruppo di archiviazione della copia passiva. L'operazione tenterà di copiare anche i file di registro eventualmente mancanti. Per rendere il database di destinazione SCR disponibile per il montaggio viene utilizzato il seguente cmdlet:
Restore-StorageGroupCopy EXMBX1\SG1
-StandbyMachine EXMBX2
In questo esempio, i file di registro del gruppo di archiviazione dell'origine SCR sono disponibili per la copia. Se questi file non sono disponibili, ad esempio perché il computer di origine SCR è inattivo, sarà necessario aggiungere all'attività Restore-StorageGroupCopy il parametro Force. In caso contrario, Restore-StorageGroupCopy tenterà di connettersi continuamente all'origine SCR per copiare tutti i file mancanti e, se l'origine SCR non è disponibile, l'attività Restore-StorageGroupCopy avrà esito negativo e il database non verrà reso disponibile per il montaggio. L'aggiunta del parametro Force indica all'attività Restore-StorageGroupCopy che i file di origine non sono disponibili e, in tal caso, l'attività ignora il tentativo di connessione e procede per rendere il database di destinazione SCR disponibile per il montaggio.
Dopo aver completato il comando Restore-StorageGroupCopy, l'amministratore dovrà verificare che il database sia in uno stato di chiusura normale. Se il database è nello stato di chiusura anomala (visitare il sito all'indirizzo technet.microsoft.com/aa996757.aspx), è necessario riportarlo allo stato di chiusura normale. Se il prefisso del file di registro per il gruppo di archiviazione, ad esempio E00 o E01, è lo stesso per l'origine SCR (EXMBX1\SG1) e il gruppo di archiviazione nella destinazione SCR (SG1PORT) che verrà utilizzato per la portabilità del database (EXMBX2\SG1PORT), non sarà necessario eseguire Eseutil in modalità di ripristino e l'operazione finale per il montaggio del database riporterà il database nello stato di chiusura normale dopo la riesecuzione di tutti i file di registro replicati. Se il database non è in uno stato di chiusura normale, sarà necessario eseguire sul database Utilità database di Exchange Server (Eseutil) in modalità di ripristino (Eseutil /r).
Quando il database è in uno stato di chiusura normale, è possibile eseguire due comandi che consentono di aggiornare Active Directory con i nuovi percorsi dei file del gruppo di archiviazione e del file del database. Questi comandi consentono di modificare i percorsi originali per SG1PORT e MBX1nei percorsi per il gruppo di archiviazione e il database gestiti (SG1PORT e MBX1PORT):
Move-StorageGroupPath EXMBX2\SG1PORT
-SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT
-EdbFilePath C:\SG1\MBX1PORT.EDB
–ConfigurationOnly
È necessario includere nei comandi sopra riportati il parametro –ConfigurationOnly in modo che solo le impostazioni di configurazione per questi oggetti vengano aggiornate in Active Directory. Non è necessario spostare dati o file in quanto SCR ha già replicato i dati in C:\SG1 nella destinazione EXMBX2.
Il passaggio successivo prevede la configurazione del database (MBX1PORT) in modo da consentirne la sovrascrittura durante un'operazione di ripristino. Questa operazione può essere eseguita selezionando la casella di controllo per l'impostazione "Database riscrivibile da un ripristino" nelle proprietà dell'oggetto database in Exchange Management Console o utilizzando il seguente comando in Exchange Management Shell:
Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT
-AllowFileRestore:$true
Una volta configurato il database per la sovrascrittura, il passaggio successivo prevede il montaggio del database mediante il seguente comando:
Mount-Database EXMBX2\SG1PORT\MBX1PORT
Dopo aver montato il database, le cassette postali presenti nel database di origine SCR (SG1\MBX1) devono essere spostate nel database MBX1PORT in EXMBX2. È sufficiente eseguire il cmdlet Get-Mailbox e inviare l'output al cmdlet Move-Mailbox. Durante questo processo, è importante che il Supervisore sistema di Exchange e che le cassette postali di sistema non vengano inclusi nell'output inviato dal cmdlet Get-Mailbox al cmdlet Move-Mailbox. Non è necessario né consigliabile spostare gli oggetti cassetta postale. Per spostare tutte le cassette postali degli utenti ed escludere le cassette postali di sistema, utilizzare il seguente comando:
Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|
ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly
-TargetDatabase EXMBX2\SG1PORT\MBX1PORT
A questo punto, l'accesso client a MBX1PORT è possibile. Tuttavia, la capacità degli utenti di accedere alle relative cassette postali dopo che sono state spostate da EXMBX1\SG1\MBX1 in EXMBX2\SG1PORT\MBX1PORT dipende dalla latenza di replica di Active Directory; in altre parole, a seconda del numero di server di elenchi in linea, la propagazione dell'aggiornamento all'interno dell'ambiente potrebbe richiedere molto tempo. È inoltre importante considerare i metodi di accesso client. I client di messaggistica che eseguono Outlook 2007 e i client non Outlook possono accedere alla cassetta postale dell'utente dopo che i server di elenchi in linea utilizzati dal server Accesso client dell'utente sono stati aggiornati con i nuovi percorsi. I client di messaggistica che eseguono Outlook 2003 e versioni precedenti richiedono che il profilo di messaggistica desktop dell'utente venga aggiornato con il nuovo nome del server.

Passaggi finali
Dopo che i client hanno eseguito l'accesso alle relative cassette postali e ai dati delle cassette postali, è necessario determinare il livello di ridondanza riattivando la replica SCR. A tale scopo, rimuovere tutti i file del database e del gruppo di archiviazione rimanenti da EXMBX1. Una volta rimossi i file, è possibile spostare i percorsi per EXMBX1\SG1\MBX1 in una posizione temporanea e configurare EXMBX1 come destinazione SCR di EXMBX2.

Scott Schnoll è Principal Technical Writer nel team di Exchange Server in Microsoft e scrive articoli correlati a Exchange Server 2007. Prima di unirsi a Microsoft, Scott ha scritto il libro Exchange Server 2003 Distilled (Addison-Wesley Professional, 2004) ed è stato l'autore principale di Exchange 2000 Server: The Complete Reference (McGraw-Hill/OsborneMedia, 2001).


 Comunicazioni: Utilizzo di Exchange in Windows Server 2008
Comunicazioni Paul Bowden

Utilizzo di Exchange in Windows Server 2008
Panoramica:
  • Configurazione di Exchange in Windows Server 2008
  • Suggerimenti e idee per la configurazione
  • Informazioni sull'ambiente Exchange

Nel team di sviluppo di Microsoft Exchange in Microsoft, il mio compito consiste nel definire la pianificazione, il ritmo e la priorità per le attività del team. In Microsoft il ruolo che ricopro è noto come Release Manager, una posizione che in altre aziende corrisponde approssimativamente al ruolo di Technical Project Manager. Chiunque abbia ricoperto
questa posizione sarà consapevole del fatto che il rilascio di un buon prodotto nei tempi previsti richiede un certo bagaglio di conoscenze e competenze, un impegno notevole e il rispetto del team. Ritengo che l'acquisizione di credibilità agli occhi di un team così altamente qualificato non avviene da un giorno all'atro. La mia opinione è che tale credibilità vada guadagnata.
Uno dei modi per dimostrare il meglio di se stessi consiste nell'eseguire la propria cassetta postale su un server in fase "dogfood", ossia un server di produzione che esegue una versione non definitiva di Exchange. Si tratta di un ambiente fluido in cui ogni due o tre settimane viene eseguito l'aggiornamento alle nuove build di Exchange. Una configurazione di questo tipo consente di testare il software in un ambiente reale con una reale interazione umana e di eseguire le cassette postali sulle build di test più recenti. Io c'ero e vi racconto pertanto la mia esperienza.

Preparazione per il rilascio di "Longhorn"
Alla fine del 2006, immediatamente dopo il rilascio di Exchange Server 2007, un nuovo sistema operativo era già all'orizzonte: Windows Server®, nome in codice "Longhorn". Non appena iniziammo a integrare i piani per il primo Service Pack per la nuova piattaforma Exchange, fu evidente che le pianificazioni di Exchange e di Windows® seguivano percorsi simili e che "Longhorn" (ora denominato Windows Server 2008) sarebbe diventato un progetto piuttosto complesso. È stato in quel frangente che abbiamo deciso di progettare Exchange Server 2007 SP1 sia per Windows Server 2003 che per Windows Server 2008. Il supporto di un'applicazione aziendale su più versioni di Windows richiede un lavoro notevole in termini di coordinamento e pianificazione. Ad esempio, Exchange opera in stretta collaborazione con IIS e Windows Server 2008 include una nuova versione, IIS 7.0.
Ricordo la prima volta in cui Windows Server 2008 è stato installato nel mio laboratorio verso la fine di dicembre 2006. Due cose sono rimaste impresse nella mia mente riguardo a quel giorno: primo, l'estrema rapidità dell'installazione e secondo l'estrema facilità di utilizzo degli strumenti di gestione, sebbene fossero molto differenti da Windows Server 2003.
Nei nostri laboratori principali, l'installazione di Windows Server 2008 richiede un terzo del tempo necessario per un'installazione di Windows Server 2003. Uno dei motivi è il fatto che i componenti facoltativi, non necessari per l'esecuzione del sistema operativo, non vengono configurati in modo automatico. Questo comportamento è particolarmente efficace nel ridurre la superficie di attacco del computer e nel semplificare la gestione del sistema. A nessuno piace che il sistema operativo sia invaso da componenti inutili. Lo svantaggio tipico di un'installazione di questo tipo è rappresentato dalla necessità di inserire il disco ogni volta che si desidera aggiungere ulteriori componenti. Tuttavia, con Windows Server 2008, tutti i file vengono copiati in una cartella SxS (side-by-side). Utilizzando quindi lo strumento Server Manager, è possibile configurare i componenti necessari e il sistema operativo provvederà automaticamente alla copia dei file.
A questo punto, è importante menzionare un'altra funzionalità: Server Core. Si tratta di una modalità di Windows Server 2008 che fornisce la possibilità di eseguire un'installazione minima del sistema operativo. In questa modalità si interagisce in genere con la console del server tramite un prompt dei comandi; non è prevista neppure l'installazione di Esplora risorse. Questa modalità è particolarmente adatta per i server di infrastruttura come controller di dominio e server DNS. Tuttavia, in questa modalità non è possibile eseguire alcun tipo di applicazione. Dato l'ampio utilizzo di codice gestito, Exchange non è in grado di supportare le installazioni Server Core.

Configurazione di Exchange
Apprezzo molto la possibilità di utilizzare i supporti fisici di Windows Server 2008 ed Exchange Server 2007 SP1 per installare un sistema da zero, senza ulteriori download o prerequisiti. Il metodo migliore per configurare un'installazione di Windows Server 2008 per Exchange consiste nell'utilizzare lo strumento ServerManagerCmd. Ho messo a punto un file di risposte XML, illustrato nella Figura 1, che consente di installare il numero di componenti del sistema operativo sufficiente per l'installazione e l'esecuzione di Exchange su Windows Server 2008. Una volta installato il nuovo sistema operativo, per avviare la configurazione del sistema è sufficiente il seguente comando:
Figure 1 File di risposta ServerManagerCmd per Exchange (Close Figure 1)
<!-- ServerManagerCmd Answer File compatible with Windows Server 2008        -->
<!-- Usage: ServerManagerCmd -ip Exchange.xml                                -->

<ServerManagerConfiguration
    Action="Install"
    xmlns="http://schemas.microsoft.com/sdm/Windows/ServerManager/Configuration/2007/1">

    <!-- BASE: Install PowerShell 1.0 feature -->
    <Feature Id="PowerShell"/>

    <!-- PREPARESCHEMA: Install LDIFDE and other directory tools like LDP and ADSIEdit -->
    <Feature Id="RSAT-ADDS"/>

    <!-- CAS/MBX: Install the Web Server role with additional child components -->
    <Role Id="Web-Server"/>
    <RoleService Id="Web-Metabase"/>
    <RoleService Id="Web-Lgcy-Mgmt-Console"/>
    <RoleService Id="Web-Basic-Auth"/>
    <RoleService Id="Web-Windows-Auth"/>

    <!-- CAS: Install the three authentication types for OWA, GZip compression, plus Outlook Anywhere support -->
    <RoleService Id="Web-ISAPI-Ext"/>
    <RoleService Id="Web-Digest-Auth"/>
    <RoleService Id="Web-Dyn-Compression"/>
    <Feature Id="RPC-over-HTTP-proxy"/>

    <!-- EDGE: Install Active Directory Lightweight Directory Services (previously known as ADAM) -->
    <Role Id="ADLDS"/>

    <!-- UM: Install the Windows Media Player components -->
    <Feature Id="Desktop-Experience"/>

</ServerManagerConfiguration>

ServerManagerCmd –ip Exchange.xml
Dopo la configurazione e il riavvio del sistema, si avrà a disposizione tutto il necessario per installare i ruoli di Exchange, come Cassette postali, Accesso client, Trasporto Hub, Trasporto Edge e Messaggistica unificata.
Un'altra utile soluzione consiste nell'utilizzare ServerManagerCmd con l'opzione –query. Consente infatti di enumerare l'elenco completo dei ruoli e dei servizi e di verificare quali ruoli e servizi sono effettivamente configurati (come indicato dal testo in verde nella Figura 2).
Figura 2 Enumerazione dei ruoli e dei servizi di Exchange
Figura 2 Enumerazione dei ruoli e dei servizi di Exchange
Ora però continuerò a raccontare la mia esperienza. Abbiamo trascorso i primi mesi del 2007 in laboratorio, per individuare le modifiche necessarie per ottenere prestazioni ottimali su Windows Server 2008. Da questa esperienza ho appreso una lezione molto importante: si possono eseguire in laboratorio installazioni continue e sottoporre il software a ripetuti test di stress, tentando e ritentando fino allo sfinimento, ma la vera misura del livello di qualità risiede solo nelle distribuzioni reali con utenti reali. Questo è esattamente il motivo per cui i prodotti Microsoft prima di essere rilasciati ai clienti entrano in fase "dogfood", ovvero vengono testati in scenari reali di utilizzo. Il rilascio di Windows Server 2008 Beta 3 nel mese di aprile 2007 ha rappresentato il punto di svolta: era giunto il momento di distribuire questo sistema operativo in un ambiente di produzione.
Quando avviammo il processo di distribuzione della prima serie di server Exchange su Windows Server 2008, ricordo che rimasi seduto a guardare, alle spalle di un membro del team operativo. L'installazione di Exchange venne eseguita senza problemi e i servizi si avviarono tutti. A questo punto, l'unica operazione da eseguire era spostare una cassetta postale e verificare se funzionava in modo corretto. Mi offrii volontario per l'esecuzione di questo controllo. La cassetta postale aveva una dimensione di 2 GB e, 26 minuti dopo, ricordo che era già operativa ed ero in grado di inviare messaggi di posta elettronica con Exchange su Windows Server 2008. Un vero successo!

Esperienza acquisita
Da quella prima installazione in Windows Server 2008, abbiamo compreso quanto sia importante provvedere all'ottimizzazione del sistema e verificare che tutto sia effettivamente pronto per affrontare la prima reale distribuzione. Nel corso di questo processo ci siamo trovati di fronte alla necessità di prendere alcune importanti decisioni di distribuzione.
Installazione È possibile utilizzare Exchange Server 2007 SP1 come aggiornamento dell'installazione originale di Exchange Server 2007, che può essere definita come versione RTM (Release To Manufacturing) di Exchange 2007, oppure è possibile utilizzare un computer nuovo ed eseguire l'installazione direttamente dal supporto di Exchange Server 2007 SP1. Questo è importante, perché non è possibile installare la versione RTM di Exchange Server 2007 in un computer su cui è in esecuzione Windows Server 2008.
Aggiornamenti Sebbene sia possibile eseguire un aggiornamento diretto del sistema operativo da Windows Server 2003 SP2 a Windows Server 2008, è necessario prima disinstallare alcuni componenti. Uno di questi componenti è Windows PowerShell™. Si tratta di un componente base della gestione di Exchange; persino l'installazione di Exchange è basata su Windows PowerShell. Per questa ragione, non è possibile supportare gli aggiornamenti diretti del sistema operativo quando Exchange è già installato. Per molti, il mancato supporto per gli aggiornamenti diretti implica la necessità di installare Windows Server 2008 in un nuovo computer e successivamente installare Exchange Server 2007 SP1.
IPv6 Exchange è progettato per sfruttare le nuove funzionalità introdotte in Windows Server 2008. IPv6, ad esempio, viene installato per impostazione predefinita e due server Exchange in esecuzione sul nuovo sistema operativo utilizzeranno automaticamente IPv6 per comunicare tra loro. Anche le interfacce in Exchange Management Console supportano gli intervalli di indirizzi IPv6. È importante tuttavia sottolineare un aspetto: Exchange richiede comunque che a ciascuna interfaccia di rete sia associato un indirizzo IPv4.
Controller di dominio di sola lettura Una modifica radicale nell'ambito delle distribuzioni di Active Directory® è rappresentata dalla nozione di controller di dominio di sola lettura (o server del catalogo globale). Questo consente alle aziende di distribuire un server Active Directory che riceve la replica unidirezionale e non è in grado di annullare la replica delle modifiche. Il concetto può rivelarsi utile nell'ambito di filiali o uffici remoti, in cui non è possibile garantire la protezione fisica. Purtroppo, Exchange Server 2007 SP1 non supporta l'utilizzo dei controller di dominio di sola lettura e richiede l'accesso a una normale partizione scrivibile di Active Directory.

Ambiente Exchange
Risorse di Exchange e Windows Server
  • Windows Server 2008 TechCenter
  • Exchange Server TechCenter
  • Centro di valutazione TechNet
  • Laboratori virtuali di Windows Server 2008

Quando occorre scegliere il livello del sistema operativo per la distribuzione, è possibile eseguire diverse configurazioni, come illustrato nella Figura 3.
Figure 3 Matrice dell'ambiente Exchange (Close Figure 3)

Versione di Exchange | Sistema operativo server | Controller di dominio
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2003
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2003
Un'altra considerazione riguarda le distribuzioni di versioni miste. È possibile infatti utilizzare un mix di versioni Exchange e Windows che interagiscono tra loro. È possibile, ad esempio, distribuire Exchange Server 2007 SP1 su Windows Server 2008 per i server Accesso client che, a propria volta, possono accedere a Exchange Server 2007 RTM sui server cassette postali di Windows Server 2003.
Occorre tuttavia prendere in considerazione alcuni aspetti correlati alle versioni precedenti di Exchange e Windows Server 2008 Active Directory. Se si dispone di Exchange Server 2003 SP2 e versioni successive, è possibile distribuire e utilizzare i controller di dominio di Windows Server 2008 nell'ambiente in uso. Tuttavia, se si dispone di Exchange 2000, è consigliabile evitare di distribuire i controller di dominio di Windows Server 2008 nel sito di Active Directory in cui risiedono i server Exchange o specificare a livello di codice le impostazioni DSAccess (Directory Service Access) in modo da impedire a Exchange 2000 di tentare di utilizzare i controller di dominio di Windows Server 2008.

Considerazioni finali
È stato dedicato un impegno notevole per garantire il corretto funzionamento di Exchange 2007 SP1 sulle piattaforme Windows Server 2003 e Windows Server 2008. Il team di Exchange è costantemente impegnato nel fornire scenari volti a garantire un'integrazione ottimale tra le applicazioni e una maggiore flessibilità di distribuzione. Penso che si resterà piacevolmente sorpresi nello scoprire la facilità e la rapidità con cui è possibile distribuire Exchange su Windows Server 2008. Sono stati inoltre apportati alcuni sottili miglioramenti in termini di prestazioni e scalabilità, come si può dedurre dall'elevato livello di scalabilità offerto dai server Accesso client per i client Outlook via Internet.
Windows Server 2008 è la piattaforma per l'innovazione futura nell'ambito della messaggistica. Nessuno resterà deluso.

Paul Bowden è Lead Program Manager del team Exchange Server. Dedica gran parte del suo tempo libero a riconfermare i dati del suo conto PayPal su richiesta.


 Comunicazioni: Distribuzione della messaggistica unificata con Exchange Server 2007
Comunicazioni Jeff Goodwin

Distribuzione della messaggistica unificata con Exchange Server 2007
Panoramica:
  • Elementi di base di telefonia
  • Considerazioni sulla progettazione di soluzioni di messaggistica unificata
  • Migrazione degli utenti

Dunque si è deciso di distribuire Exchange Server 2007 Unified Messaging nell'ambiente dell'organizzazione. Si è installato un ruolo del server Messaggistica unificata, lo si è integrato con il PBX esistente e ora i messaggi di posta vocale, i messaggi di posta elettronica e i messaggi fax dell'amministratore e di altri 10 dipendenti vengono memorizzati in Exchange. Solo poco tempo fa, tutto questo
sembrava un risultato lontano e difficile da raggiungere. Ma come è possibile distribuire le stesse funzionalità a migliaia di abbonati, distribuiti tra siti diversi, senza influire negativamente sulle normali attività commerciali?
L'intento dell'articolo è illustrare proprio uno scenario di questo tipo. Ho deciso di scriverlo per aiutare i lettori a distribuire la messaggistica unificata nel proprio ambiente e a demistificare i concetti di telefonia associati a distribuzioni del genere. Per ulteriori informazioni sull'installazione, la configurazione o le funzionalità di Exchange Server 2007 Unified Messaging, leggere "Risorse di messaggistica unificata" nella barra laterale alla fine dell'articolo. Inoltre, Microsoft ha certificato come Unified Messaging Specialist alcune aziende in grado di assistere i clienti con consulenze, progetti e distribuzioni per Exchange Server 2007 Unified Messaging. Per ottenere assistenza su installazione, configurazione o distribuzione, rivolgersi a una delle aziende elencate nella barra laterale.

Introduzione
Le tecnologie di messaggistica unificata non sono una novità per Exchange; molte organizzazioni offrono prodotti di messaggistica unificata che si integrano con Exchange. Tuttavia, questa è la prima versione di Exchange che supporta la messaggistica unificata in modo nativo. Fin dal primo rilascio, molti clienti hanno distribuito Exchange Server 2007 Unified Messaging a piccoli gruppi all'interno delle proprie organizzazioni. Tuttavia, per varie ragioni, non hanno sempre distribuito la messaggistica unificata a tutti gli utenti. Uno dei problemi è che molti amministratori di Exchange ancora non conoscono i concetti e le tecnologie di telefonia necessarie per implementare i servizi di messaggistica unificati e hanno incontrato delle difficoltà durante la progettazione e distribuzione di queste soluzioni nelle organizzazioni.
Come in tutti i progetti di distribuzione, un approccio in più fasi consente in genere di ottenere i risultati migliori. Le cinque fasi (progettazione dell'architettura, verifica della soluzione, costituzione di una prima community di utenti, formazione e migrazione degli utenti verso il nuovo sistema) sono tutti aspetti da prendere in considerazione per un progetto di messaggistica unificata. È fondamentale coinvolgere nella pianificazione del progetto sia i gruppi IT che di telecomunicazione dell'organizzazione.
Molte funzionalità che gli utenti danno per scontate sulle piattaforme di posta vocale tradizionali devono essere duplicate oppure, se ciò non è possibile, è necessario progettare una soluzione alternativa che riduca al minimo l'impatto del nuovo sistema implementato sulle community degli utenti. Questa è un'area chiave in cui è essenziale ottenere l'assistenza del team delle telecomunicazioni. Allo stesso tempo, il team delle telecomunicazioni dovrà apprendere dal team IT ad amministrare, risolvere i problemi e supportare durante la distribuzione una nuova piattaforma di posta vocale.

Elementi di base di telefonia
La pianificazione risulta molto più semplice quando si comprendono l'architettura di base, il flusso delle chiamate e le terminologie correlate alla messaggistica unificata. Nella Figura 1 è illustrato un esempio di soluzione di messaggistica unificata integrata con un sistema di telefonia aziendale esistente. Nelle prossime sezioni si esamineranno in maggior dettaglio alcuni dei concetti e alcune delle tecnologie più comuni che è probabile incontrare durante una distribuzione.
Figura 1 Una soluzione da PBX a messaggistica unificata
Figura 1 Una soluzione da PBX a messaggistica unificata
Un sistema PBX (Private Branch Exchange) è una rete telefonica privata utilizzata all'interno di un'organizzazione. In un sistema di questo tipo, ciascun utente dispone in genere di un telefono connesso al PBX, da cui è possibile chiamare gli altri utenti dell'organizzazione componendo un numero di interno (quattro o cinque cifre di solito) e i telefoni esterni.
Quando dispongono di varie sedi dotate di PBX, i clienti aziendali a volte decidono di interconnettere i sistemi tramite tecnologie specifiche del produttore del PBX. In tal modo si consente a tutti gli utenti dei PBX connessi in rete di chiamare i colleghi digitando il solo numero di interno.
La messaggistica unificata prevede l'integrazione di due sistemi diversi: la messaggistica Exchange e il sistema di telefonia fisico. Le comunicazioni tra il server Messaggistica unificata e l'architettura di telefonia si ottengono utilizzando la tecnologia SIP (Session Initiation Protocol). Alcune tecnologie PBX possono comunicare direttamente con il server Messaggistica unificata tramite SIP, mentre per altre tecnologie è necessario l'impiego di un gateway SIP. Nella Figura 1 il PBX è connesso a un gateway SIP mediante una linea T1. Quando una chiamata viene inoltrata alla messaggistica unificata, il PBX invia delle informazioni (numero di telefono del chiamante, numero di telefono del destinatario della chiamata e alcuni tipi di codici motivo) al gateway SIP, in modo che il server Messaggistica unificata comprenda chi è il destinatario della chiamata.
Alcuni PBX possono essere interconnessi sulla rete IP. Con la telefonia in rete è possibile reindirizzare le chiamate sulla rete IP a una soluzione di posta vocale centralizzata. Se, ad esempio, si esamina la Figura 2, si noterà come Zurigo sia connette in rete con Londra.
Figura 2 Una distribuzione di messaggistica unificata più complessa
Figura 2 Una distribuzione di messaggistica unificata più complessa

Flusso delle chiamate
Risorse di messaggistica unificata
  • Elenco degli Unified Messaging Specialist
  • TechCenter per la messaggistica unificata di Exchange
  • Gateway SIP supportati
  • Sistema di telefonia
  • Note sulla configurazione PBX

Si supponga che un chiamante esterno chiami il telefono di un abbonato al servizio di messaggistica unificata. In questo caso l'abbonato di messaggistica unificata non è in ufficio e il telefono squilla senza risposta. È possibile seguire il percorso del messaggio nella Figura 1.
Il PBX invia la chiamata al gateway SIP, che negozia la chiamata tramite SIP su TCP con il server Messaggistica unificata. Il server riceve i dati di integrazione dal gateway SIP, che fornisce informazioni sul destinatario della chiamata. Il server Messaggistica unificata riproduce quindi il messaggio di saluto dell'abbonato e consente al chiamante esterno di registrare un messaggio vocale. Tale messaggio viene quindi recapitato nella cassetta postale Exchange dell'abbonato al servizio di messaggistica unificata.
Questo flusso della chiamata è una descrizione molto semplificata di ciò che accade realmente. È importante comprendere che, quando viene registrato un messaggio, il server Messaggistica unificata inoltra il messaggio al server Trasporto Hub tramite SMTP perché venga recapitato al server Cassette postali.
In qualità di abbonati al servizio di messaggistica unificata, ora gli utenti possono accedere alla propria cassetta postale Exchange con un telefono (utilizzando Outlook® Voice Access) o un computer (utilizzando Outlook 2007 o Outlook Web Access). Ma gli abbonati possono accedere ai messaggi anche tramite telefono utilizzando Outlook 2007 o Outlook Web Access con una funzionalità denominata Ascolta al telefono, che consente all'abbonato al servizio di messaggistica unificata di riprodurre il messaggio prescelto chiamando un telefono specificato invece di utilizzare il computer. Quando si utilizza questo metodo, il server Messaggistica unificata interagisce con entrambi i server Accesso client e Cassette postali. Questo è un aspetto importante da comprendere perché, se si posiziona un server Messaggistica unificata in un ufficio remoto che non dispone di un server Accesso client locale, il server Messaggistica unificata dovrà attraversare la WAN per contattare il server Accesso client, con conseguente calo delle prestazioni.

Progettazione del sistema
I progetti architettonici Exchange utilizzati dai clienti ricadono essenzialmente in due categorie: centralizzato o decentralizzato. Come regola generale, l'architettura della messaggistica unificata segue l'architettura di Exchange, vale a dire che ovunque si distribuisca un server Cassette postali, viene distribuito anche un server Messaggistica unificata. Come per ogni regola, esistono delle eccezioni.
Quando si progetta un'architettura di messaggistica unificata, è necessario analizzare cinque aree di intervento fondamentali.
  • Posizionamento del server
  • Numero di server Messaggistica unificata
  • Gateway SIP
  • Archivio delle cassette postali
  • Configurazione del sito di messaggistica unificata
Senza trascurare la continuità delle attività aziendali. In generale, per determinare gli elementi che attengono alla messaggistica unificata, è possibile utilizzare il piano di ripristino di emergenza relativo a Exchange.
Gli scenari di distribuzione di esempio possono aiutare a comprendere i ruoli del server Messaggistica unificata. Nella Figura 2 viene illustrata chiaramente la distribuzione di Exchange Server 2007 con la messaggistica unificata in una grande azienda.
In questo complesso progetto i datacenter principali sono a Seattle e Londra. I server Messaggistica unificata in queste sedi servono le rispettive community di utenti, poiché i server Cassette postali e Trasporto Hub sono locali. Entrambi i siti dispongono di PBX IP che forniscono la copertura delle chiamate al server Messaggistica unificata locale per la risposta alle chiamate.
I siti di medie dimensioni si trovano a New York e Glasgow. I server Messaggistica unificata in queste sedi servono le rispettive community di utenti, poiché i server Cassette postali e Trasporto Hub sono locali. Come accade per i datacenter principali, entrambi i siti dispongono di PBX IP che forniscono la copertura delle chiamate al server Messaggistica unificata locale per la risposta alle chiamate.
I siti più piccoli non dispongono di server Cassette postali o Trasporto Hub, ma forniscono funzionalità di messaggistica unificata garantiti dai datacenter principali. Ad Austin è disponibile un PBX NEC che utilizza la connettività analogica a un gateway SIP locale. Le chiamate agli utenti finali locali vengono inoltrate al gateway SIP, che negozia con il server Messaggistica unificata di Seattle per garantire la risposta alle chiamate con il servizio di messaggistica unificata.
A Zurigo è disponibile un Avaya Communication Manager connesso in rete tramite IP all'Avaya Communication Manager di Londra. Le chiamate agli utenti locali vengono inoltrate tramite la rete di Avaya Communication Manager, che negozia con il server Messaggistica unificata di Londra per garantire la risposta alle chiamate con il servizio di messaggistica unificata.
Nell'esempio presso il sito di Seattle i server Cassette postali e Messaggistica unificata si trovano nella stessa ubicazione fisica. Quando si progetta un'architettura a sito singolo, tutti i server (Cassette postali, Messaggistica unificata, Accesso client e così via) e il dispositivo PBX si trovano nello stesso sito. Le grandi aziende con più sedi aggiungono complessità al progetto. Questa complessità può sembrare eccessiva, ma con la comprensione di alcuni principi di base di messaggistica unificata tutto diventa più semplice e gestibile.
Come illustrato nella Figura 2, se in un sito è presente un server Cassette Postali, è consigliabile posizionare nello stesso sito anche un server Messaggistica unificata. A Seattle, Londra, New York e Glasgow è già così. Ad Austin e Zurigo invece non esiste un server Cassette postali locale, ma i servizi di messaggistica unificata possono essere garantiti utilizzando la rete IP. Ad Austin è presente un PBX analogico locale. In questo caso deve essere utilizzato un gateway SIP per fornire la connettività di rete IP al server Messaggistica unificata di Seattle. A Zurigo è presente un PBX IP locale connesso in rete con il PBX di Londra. Di conseguenza, le chiamate a un utente di Zurigo attraversano la rete telefonica fino al PBX di Londra e al server Messaggistica unificata.
Poiché le chiamate indirizzate agli abbonati di Zurigo attraversano la rete e sono gestite da un sistema di messaggistica unificata centralizzato a Londra, se si verifica un''interruzione sulla rete, le chiamate a tutti gli abbonati di Zurigo non otterranno risposta fino alla riparazione della rete. Per garantire il servizio anche in caso di interruzioni o guasti della rete, è possibile posizionare un server Messaggistica unificata a Zurigo. Quando si verifica l'interruzione di rete, il server Messaggistica unificata continua a rispondere alle chiamate, provvedendo a recapitarle una volta riparata la rete.
Il posizionamento dei server è probabilmente il fattore più importante da considerare durante la progettazione di un'architettura che soddisfi le esigenze dell'ambiente. Il diagramma di flusso nella Figura 3 può facilitare un corretto posizionamento dei server.
Figura 3 Posizionamento dei server
Figura 3 Posizionamento dei server

Valutazione dei server necessari
L'area successiva da prendere in esame è il numero di server Messaggistica unificata necessari per supportare la community di utenti. Il dimensionamento del sistema dipende da diversi fattori che sono specifici dei siti.
La scalabilità della messaggistica unificata è determinata dalla quantità di chiamate contemporanee (porte chiamate nei termini della telefonia) che il server può supportare. Ciascuna chiamata nel sistema richiede al server Messaggistica unificata di dedicare risorse di rete, CPU, memoria e disco. Quando si aggiungono ulteriori risorse, un server Messaggistica unificata è in grado di supportare più chiamate contemporanee. Poiché le risorse sono sempre limitate, il server Messaggistica unificata può gestire solo un determinato numero di chiamate simultanee prima che le risorse si esauriscano.
È possibile determinare quante porte sono necessarie per supportare il numero di abbonati esistenti utilizzando i calcoli di analisi del traffico di Erlang, che non vengono però analizzati in questo articolo. Un metodo più semplice per determinare quante porte sono necessarie consiste nel chiedere agli amministratori del sistema di telefonia quante porte di posta vocale vengono utilizzate nel sistema esistente. In base all'esperienza sul campo, i requisiti in termini di porte di un sistema di posta vocale tradizionale e di un sistema di posta vocale unificato sono molto simili.
In generale, è consigliabile implementare un massimo di 60 porte per server. Il suggerimento non deriva da limitazioni software o hardware, ma si basa piuttosto sul fatto che un singolo server con 60 porte può supportare circa 5.000 utenti. Quando si verifica un guasto sul singolo server utilizzato, si infligge un'interruzione del servizio all'intera (e molto estesa) base di abbonati.
Quando si implementano dei server Messaggistica unificata, è preferibile inserire nel progetto una ridondanza N + 1 nell'architettura. Nella Figura 4 viene illustrato un progetto con gateway SIP e server completamente ridondanti. Quando si adotta un progetto con queste caratteristiche, in caso di guasto di Unified Messaging Server 1, SIP Gateway 1 negozierà automaticamente le chiamate con Unified Messaging Server 2. È inoltre possibile programmare il PBX in modo da distribuire uniformemente il carico di chiamata fra i gateway SIP. È possibile, ad esempio, instradare la prima chiamata nel sistema a SIP Gateway 1 e la chiamata successiva a SIP Gateway 2. Le chiamate che si alternano tra i gateway consentono di distribuire in modo uniforme chiamate e carico fra i server Messaggistica unificata.
Figura 4 Distribuzione delle chiamate tra i server per ridondanza
Figura 4 Distribuzione delle chiamate tra i server per ridondanza
Esistono due fornitori di gateway SIP supportati da soluzioni Exchange Server 2007 Unified Messaging: AudioCodes e Dialogic. Se in un progetto è necessario un gateway SIP, acquistarne uno che supporti il numero di sessioni (porte) previste dal progetto. Se, ad esempio, il progetto prevede 32 porte, sarà necessario un gateway che supporti almeno tale numero di sessioni.
Se si nutrono dubbi sulla compatibilità del PBX con la messaggistica unificata o con il gateway che si intende utilizzare, sarà utile leggere il testo nella barra laterale "Risorse di messaggistica unificata". I collegamenti riportati nella barra laterale indirizzano verso una guida specifica di Microsoft e verso un elenco delle aziende certificate come Unified Messaging Specialists, in grado di aiutare i clienti a valutare le esigenze specifiche dell'organizzazione. Per esperienza personale, posso dire che i PBX in commercio non compatibili con i gateway SIP e la messaggistica unificata di Exchange sono pochi, mentre alcuni PBX possono comunicare con il server Messaggistica unificata utilizzando il protocollo SIP su TCP in modalità nativa.
La messaggistica unificata di Exchange supporta tre codec audio per l'archiviazione dei messaggi di posta vocale: G.711 PCM Linear, GSM 06.10 e Windows Media® Audio (WMA). Ciascun file WAV PCM Linear occupa circa 16 KB per secondo di audio. WMA è il codec audio predefinito per la messaggistica unificata e comprime l'audio a 1,1 kilobit (kb) per secondo di audio con un'intestazione di 7 KB. GSM 06.10 comprime l'audio a 1,6 kb per secondo di audio, ma l'intestazione è meno voluminosa rispetto alla codifica WMA.
La qualità dei messaggi vocali per entrambi i file WMA e GSM 06.10 è accettabile. L'esperienza acquisita sul campo utilizzando i codec WMA o GSM suggerisce che è possibile ipotizzare un aumento tra il 10% e il 20% delle dimensioni dell'archivio delle cassette postali, in base alla frequenza di utilizzo della posta vocale nell'organizzazione.
Quando è il momento di decidere quale codec audio adottare per l'ambiente, è opportuno tenere conto dei dispositivi mobili e degli altri sistemi operativi utilizzati dagli utenti finali. Le domande su questo argomento sono soprattutto correlate alla possibilità da parte degli utenti di ascoltare la posta vocale con i dispositivi Windows Mobile®. Anche gli altri sistemi operativi rappresentano un'area da investigare: magari si dispone di un'ampia distribuzione di computer Linux che potrebbero non riuscire a riprodurre file WMA. In tutti i casi è importante comprendere che questi fattori devono essere inclusi nei requisiti di formazione del personale del supporto tecnico.

Configurazione e test
Che l'architettura di messaggistica unificata sia centralizzata o distribuita, è necessario considerare con attenzione molti requisiti di posta vocale prima di distribuire la messaggistica unificata nell'organizzazione. Un elenco dettagliato degli argomenti che il team responsabile del progetto deve considerare è riportato nella barra laterale "Elenco di controllo per la messaggistica unificata". Le informazioni su tutti gli argomenti devono essere raccolte presso ciascun sito in cui si intende implementare la messaggistica unificata. I team dell'IT e delle telecomunicazioni, come già suggerito, devono collaborare all'analisi di questi argomenti.
Dopo aver progettato il sistema e finalizzato la configurazione, è necessario creare un sistema di test per convalidare il progetto. In un progetto multisito è consigliabile eseguire i test su almeno due siti, per dimostrare la validità del concetto di fondo e delle funzioni comprese nel progetto.
Il piano di test di una funzionalità deve essere sviluppato a partire dai requisiti di configurazione e quindi portato a termine. Il piano deve inoltre comprendere i metodi di accesso degli abbonati (telefono, Outlook 2007 e Outlook Web Access), i metodi di amministrazione e i guasti di hardware e rete.
Al termine dei test e dopo aver verificato e concordato che la messaggistica unificata duplicherà le funzionalità del sistema di posta vocale precedente o che è stata progettata una soluzione alternativa per supportare le eventuali configurazioni o funzionalità che non sarà possibile duplicare, si può procedere alla selezione di un gruppo di utenti pilota per i test sul sistema. La creazione di un gruppo pilota consentirà di individuare le operazioni da eseguire nell'ambiente per spostare (o tagliare in gergo telefonico) gli abbonati dal sistema di posta vocale precedente alla messaggistica unificata. Per tagliare un abbonato, in genere è necessaria la seguente procedura:
  1. Disattivare l'abbonato dal sistema di posta vocale esistente.
  2. Attivare l'abbonato in Active Directory per la messaggistica unificata tramite Exchange Management Console.
  3. Modificare il percorso di copertura del telefono a un numero pilota messaggistica unificata.
È importante disattivare l'abbonato dal sistema di posta vocale esistente, in modo che non venga inviato alcun messaggio alla cassetta postale precedente.
Durante la fase pilota, è necessario raccogliere gli eventuali dubbi e domande che gli abbonati desiderano porre a proposito del funzionamento del sistema. La documentazione di questi dettagli consentirà di risolvere i problemi più comuni durante la fase di formazione.
La formazione è fondamentale per un passaggio senza problemi al nuovo sistema. Gli utenti dell'organizzazione sono abituati ad accedere alla posta vocale dal telefono con un'interfaccia utente specifica. Per alcuni sistemi di posta vocale, ad esempio, è necessario che gli utenti premano 5 per ascoltare i messaggi. Con la messaggistica unificata di Exchange gli utenti devono premere 1 o pronunciare il nome della funzione di posta vocale (oppure utilizzare Outlook 2007 o Outlook Web Access per riprodurre i messaggi vocali). La formazione degli abbonati alla messaggistica unificata deve riguardare l'interfaccia utente della telefonia, l'utilizzo di Outlook Voice Access e l'utilizzo di Outlook e Outlook Web Access.
Con la messaggistica unificata di Exchange 2007, la possibilità di pronunciare a voce i comandi è incorporata in Outlook Voice Access. Alcuni utenti tendono ad accogliere con entusiasmo le nuove funzionalità del sistema e tale entusiasmo può facilitare la transizione da un'interfaccia utente all'altra.
La messaggistica unificata di Exchange consente di inviare a ciascun utente un messaggio di testo personalizzato tramite posta elettronica al momento dell'attivazione. I messaggi personalizzati possono essere utilizzati per fornire utili collegamenti Web verso domande frequenti (FAQ), documentazione per gli abbonati, numeri di telefono del supporto tecnico e così via. Possono anche contenere informazioni sull'accesso al sistema di posta elettronica con la password unica dell'abbonato. Questa è una delle funzionalità più potenti che è possibile utilizzare quando si attivano gli utenti finali.

Migrazione degli utenti
Elenco di controllo per la messaggistica unificata
Nelle sezioni che seguono vengono definiti alcuni elementi fondamentali di un sistema di messaggistica unificata e vengono suggerite le domande a cui è necessario rispondere in vista della distribuzione e configurazione di Exchange Server 2007 Unified Messaging. Il seguente vuole essere un elenco di controllo utile per sviluppare un piano di distribuzione.
Dial plan Un dial plan di messaggistica unificata corrisponde logicamente a un PBX e agli interni associati. Alcuni aspetti del dial plan da considerare in anticipo sono:
  • Di quante cifre sono costituiti i numeri degli interni?
  • Qual è il numero pilota del sistema di messaggistica unificata?
  • Quale numero devono comporre gli utenti per accedere a una linea esterna?
  • Quale codec audio si utilizzerà per i messaggi?
  • Qual è il numero di interno del centralino?
Gruppi di risposta e numeri pilota Un gruppo di risposta è una serie di interni telefonici configurati per ricevere le chiamate in un determinato ordine. Il numero pilota è l'interno principale che viene chiamato per accedere al gruppo di risposta. Nel progetto è necessario prevedere un numero di interni membri del gruppo di risposta che equivale al numero di porte di posta vocale.
Criteri cassetta postale I criteri cassetta postale per la posta vocale non sono molto diversi dai criteri cassetta postale di Exchange. Di seguito alcuni criteri da prendere in considerazione:
  • Per quanti giorni viene conservata la posta vocale prima della cancellazione?
  • Con quale frequenza vengono reimpostate le password della posta vocale?
  • Quali sono i criteri applicati per il backup della posta vocale?
  • Qual è la lunghezza minima della password?
  • Qual è il numero massimo di tentativi di accesso che si possono eseguire prima che la cassetta postale venga bloccata?
Operatori automatici. Gli operatori automatici rispondono alle chiamate in arrivo che non sono destinate a un abbonato specifico. Possono fornire informazioni e indirizzare i chiamanti verso altre ubicazioni dell'organizzazione. La messaggistica unificata di Exchange consente di sfruttare le funzionalità di segnale multifrequenza (DTMF) e vocali per l'esplorazione dell'operatore automatico. I fattori da considerare sono:
  • Sono previste istruzioni dell'operatore automatico diverse per il giorno, la notte e le festività (le istruzioni devono essere documentate e registrate)?
  • Chi è possibile chiamare dal menu dell'operatore automatico?
  • L'esplorazione vocale è possibile quando si utilizza l'operatore automatico?
  • Sono necessarie più lingue per utilizzare l'operatore automatico?
Cassetta postale generale o notturna Alcune organizzazioni dispongono di una cassetta di posta vocale generale o notturna che consente ai chiamanti di lasciare dei messaggi generici. Se l'azienda ne utilizza una, sarà necessario creare e attivare per la messaggistica unificata un'apposita cassetta postale Exchange.
Indicatore di messaggio in attesa (MWI) Per indicatore di messaggio in attesa si intende la spia del telefono che avvisa della presenza nella cassetta postale di messaggi non letti. La presenza dell'indicatore di messaggio in attesa sui ricevitori dei telefoni è un requisito per la distribuzione?
Supporto di interni multipli In molte organizzazioni ad alcuni dei dipendenti sono associati più telefoni. Quando si attiva l'accesso di questi abbonati alla messaggistica unificata, è necessario associare tutti i numeri di interno. Prima di iniziare, sviluppare un elenco dei dipendenti con estensioni multiple.
Supporto di IVR (risposta voce interattiva) Alcuni sistemi di posta vocale tradizionali supportano applicazioni IVR che la messaggistica unificata non può duplicare. Determinare se nel sistema da sostituire vengono utilizzate applicazioni di questo tipo. Tali applicazioni possono restare sul sistema esistente o essere sostituite da applicazioni IVR alternative.
Posta vocale in rete La posta vocale in rete consente di inviare un messaggio da un sistema a un altro sistema diverso. Nelle grandi aziende, ad esempio, il direttore generale può inviare un messaggio vocale all'intera organizzazione oppure l'amministratore può inviare annunci di carattere generale relativi, ad esempio, alle esercitazioni antincendio. Con la posta vocale in rete, il direttore generale può inoltre registrare un messaggio vocale e inviarlo a tutti i dipendenti dell'azienda, indipendentemente dal sistema di posta vocale che questi utilizzano. Al momento non è ancora possibile connettere in rete la messaggistica unificata di Exchange con altri sistemi di posta vocale tradizionali.
Supporto fax Alcune piattaforme di posta vocale tradizionali supportano la ricezione di fax e consentono di utilizzare un singolo numero di telefono per la ricezione di messaggi vocali e fax. Exchange Server 2007 Unified Messaging supporta la ricezione dei fax e può essere utilizzato per sostituire questa funzionalità. Questa è una funzionalità unidirezionale, poiché il sistema non supporta la funzionalità di invio di fax. Se l'invio dei fax è un requisito, sarà necessario ricorrere a un prodotto di terze parti che lo supporti.

Esistono molti punti di vista diversi sui metodi di migrazione verso il sistema di produzione. Le due metodologie principali sono una migrazione graduale e un passaggio immediato. Qualunque sia il metodo scelto, è fondamentale somministrare al personale del supporto tecnico dei corsi su come rispondere alle domande più comuni poste dal gruppo pilota. Gli addetti dovranno inoltre essere in grado di attivare un utente, verificare che un utente è stato attivato e modificare una password.
La migrazione degli utenti dal sistema di posta vocale precedente alla messaggistica unificata è abbastanza semplice, ma esiste un problema importante da affrontare: la connessione in rete della posta vocale. Proprio come un sistema di posta elettronica consente di inviare, inoltrare e rispondere agli altri utenti e sistemi di posta elettronica, anche un sistema di posta vocale consente di inviare, inoltrare e rispondere agli altri utenti e sistemi di posta vocale.
Si consideri uno scenario in cui Alice e Davide siano due utenti del sistema di posta vocale esistente. Davide diventa quindi utente della messaggistica unificata e vuole inviare un messaggio ad Alice sul sistema di posta vocale esistente. Poiché sono utenti di sistemi diversi, i due non possono più scambiarsi messaggi di posta vocale; purtroppo, è stata creata un'isola di posta vocale.
Il problema nei sistemi di posta vocale tradizionali viene risolto utilizzando dei convertitori di protocolli di rete, che consentono di connettere in rete sistemi diversi. Attualmente, tuttavia, non esistono convertitori di protocolli di rete che consentano di connettere Exchange Server 2007 Unified Messaging con altri sistemi diversi. Il problema potrebbe non essere rilevante per la propria organizzazione, ma è bene esserne consapevoli quando si decide di eseguire la migrazione di piccoli gruppi di utenti.
Io trovo preferibili le migrazioni immediate di tutti gli utenti di ciascun sito. Questa scelta crea le premesse di un passaggio netto da un sistema all'altro. Di solito l'operazione viene eseguita in un fine settimana; gli utenti vanno a casa il venerdì e tornano a lavorare il lunedì con un nuovo sistema posta vocale. Alcuni amministratori sostengono che il passaggio immediato dovrebbe essere adottato solo per piccole imprese o siti remoti. Non sono d'accordo. Ho collaborato a dei passaggi immediati in aziende con oltre 7.000 utenti in un singolo sito in cui meno dell'1% dei dipendenti ha dovuto ricorrere al supporto tecnico. Se tutte le fasi precedenti del progetto sono state pianificate ed eseguite in modo corretto, il passaggio da un sistema all'altro avviene senza intoppi.
Quando, tuttavia, è necessario eseguire il passaggio al nuovo sistema di più siti in produzione, è opportuno iniziare dai siti remoti più piccoli, proseguendo uno alla volta fino al sito principale. Elaborare le informazioni che si raccolgono durante la migrazione dei siti più piccoli e implementare le eventuali modifiche necessarie nel piano del progetto.
In genere, al momento della migrazione tutti gli utenti hanno già seguito un corso di formazione e sono stati attivati nel sistema di messaggistica unificata. Di seguito è illustrata una procedura per preparare il passaggio immediato da un sistema di posta vocale alla messaggistica unificata.
La prima operazione da eseguire è la verifica che il sistema di messaggistica unificata sia completamente installato, configurato e testato.
Somministrare i corsi di formazione a piccoli gruppi. Spiegare agli utenti che partecipano ai corsi che la cassetta postale viene attivata prima dell'effettiva migrazione al nuovo sistema ed esortarli ad accedere alla propria cassetta postale per inizializzarla modificando la password e registrando il messaggio di saluto. Non appena terminato il corso, attivare gli utenti in modo che possano inizializzare la propria cassetta postale prima della migrazione.
Infine, al termine dell'intero ciclo di corsi di formazione, scegliere un fine settimana in cui disattivare tutti gli utenti dal sistema di posta vocale precedente e passare i numeri telefonici alla messaggistica unificata di Exchange. Il lunedì mattina successivo, il sistema sarà pronto e disponibile per tutti gli utenti dell'organizzazione.

La migrazione
Che si tratti di supportare un unico sito o una grande organizzazione con più siti, le informazioni riportate nell'articolo dovrebbero risultare utili. Le organizzazioni costituite da più siti possono aggiungere complessità al progetto, ma i requisiti di base restano gli stessi con 50 o 5.000 utenti.
Non si sottolinea mai abbastanza la necessità che i team dell'IT e delle telecomunicazioni collaborino alla distribuzione di una soluzione di messaggistica unificata. Nella mia esperienza, tra i molti imprevisti che possono far deragliare un progetto di messaggistica unificata, l'assenza di coordinamento tra i team di IT e delle telecomunicazioni e la mancanza di un accordo sulla soluzione da adottare sono le principali cause di problemi. La convergenza delle tecnologie non è complessa come sembra, ma potrebbe richiedere l'impiego di una figura esterna all'organizzazione che comprenda le istanze sia del reparto IT che delle telecomunicazioni e che faciliti la collaborazione tra i team o pianifichi una corretta distribuzione del progetto.

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


 Protezione: Una guida introduttiva alle indagini forensi sui computer
Protezione Tom Cloward and Frank Simorjay

Una guida introduttiva alle indagini forensi sui computer
Panoramica:
  • Guida di base alle indagini sui computer per Windows
  • Starter Kit Rimozione malware
  • Creazione di un kit di strumenti di indagine con Windows PE
  • Conservazione delle informazioni per l'analisi forense

Esistono numerosi modi in cui un computer può essere utilizzato da utenti malintenzionati per eseguire attività illegali: intrusione nei sistemi, divulgazione di segreti industriali, diffusione di nuovi virus, utilizzo di messaggi di phishing per rubare informazioni personali e così via. Accade inoltre sempre più frequentemente di sentir parlare di nuovi exploit
e tecniche. Non si sente invece parlare altrettanto frequentemente di tutti i modi in cui è possibile utilizzare i computer per avviare delle indagini su questi tipi di attività.
Sebbene alcune indagini facciano affidamento su professionisti altamente qualificati che utilizzano strumenti costosi e tecniche complesse, esistono alcuni metodi più semplici ed economici per le analisi e le indagini di base. In questo articolo verranno esaminate le tecniche di analisi forense immediatamente accessibili a tutti gli amministratori.
In particolare, l'attenzione è incentrata su due acceleratori di soluzioni che è possibile scaricare gratuitamente: "Guida di base alle indagini sui computer per Windows" (go.microsoft.com/fwlink/?LinkId=80344) e lo Starter Kit Rimozione malware (go.microsoft.com/fwlink/?LinkId=93103). In questo articolo verrà illustrato come combinare le due soluzioni per creare un ambiente Windows® PE di avvio in cui è possibile condurre un'indagine efficace e preservare le proprie scoperte per la creazione di report e le analisi. Non è tuttavia possibile utilizzare il metodo illustrato in questo articolo per condurre indagini su un disco rigido che sia stato crittografato o faccia parte di un volume RAID. Inoltre, se il disco rigido è danneggiato, prima di avviare un'indagine sarà necessario eseguire ulteriori operazioni per ripristinarne lo stato precedente.
Sebbene la soluzione illustrata costituisca un metodo semplice per raccogliere prove da un computer basato su Windows, si tratta comunque di un approccio ad hoc di base. Sul mercato sono disponibili diverse soluzioni più sofisticate in grado di eseguire il lavoro illustrato nell'articolo in modo molto più efficace.
Inoltre, la tecnica descritta nell'articolo non è una soluzione prescrittiva garantita né certificata dall'International Society of Forensic Computer Examiners. Prima di iniziare un'indagine, è opportuno valutare se la prova rilevata sul disco rigido possa essere utilizzata nell'ambito di un'azione legale. Se tale possibilità esiste, è opportuno reclutare un esperto di informatica forense (Computer Examiner) professionalmente certificato a cui affidare la conduzione dell'indagine. A seconda della natura delle potenziali azioni legali, è necessario inoltre considerare se passare le indagini direttamente alle autorità giudiziarie competenti. Ulteriori informazioni su questo argomento sono disponibili in "Guida di base alle indagini sui computer per Windows".

Informazioni sugli acceleratori di soluzioni
In "Guida di base alle indagini sui computer per Windows" vengono illustrati processi e strumenti che è possibile utilizzare nell'ambito di un'indagine interna sui computer. Nella guida vengono illustrate quattro fasi del modello di indagine sui computer: valutazione, acquisizione, analisi e report. Si tratta di un modello molto utile che offre ai professionisti IT la possibilità di condurre le indagini in maniera tale da preservare le scoperte più importanti.
In questa guida vengono inoltre prese in esame le situazioni in cui è necessario rivolgersi alle autorità giudiziarie competenti, una decisione che prevede il coinvolgimento dei propri consulenti legali. Vengono inoltre fornite informazioni su come gestire i crimini correlati ai sistemi informatici, su come contattare le autorità giudiziarie competenti appropriate, sugli strumenti di Windows Sysinternals e su altri strumenti Windows utili per l'esecuzione di indagini.
L'altro acceleratore di soluzione cui si fa riferimento in questo articolo, Starter Kit Rimozione malware, fornisce indicazioni su come creare e utilizzare un CD-ROM di Windows PE di avvio per rimuovere eventuali infezioni malware da un computer. Questa guida contiene un elenco di minacce e di alcune soluzioni di attenuazione che consentono di ridurne il potenziale impatto su un'organizzazione. Nella guida viene inoltre messa in rilievo l'importanza dello sviluppo di un piano di risposta ai problemi di protezione da utilizzare in caso di un possibile attacco malware. Lo Starter Kit Rimozione malware include, inoltre, un approccio basato su quattro fasi per consentire ai professionisti IT di determinare la natura del malware rilevato, limitarne la diffusione, rimuoverlo, se possibile, verificare che sia stato rimosso e procedere con tutti i passaggi successivi eventualmente necessari.

CD-ROM di Windows PE
Per eseguire un'indagine di questo tipo sono necessari due prerequisiti: un CD-ROM di Windows PE e un dispositivo di archiviazione esterna, come un'unità memoria flash USB.
Come si può apprendere da alcuni programmi televisivi dedicati alla cronaca, è comunemente noto che gli ufficiali di polizia hanno la responsabilità di garantire l'integrità della scena del crimine. Per lo stesso motivo, è opportuno preservare i dati contenuti nel disco rigido su cui viene condotta l'indagine. A differenza del CD dello Starter Kit Rimozione malware, il CD di Windows PE di avvio che si sta creando eseguirà gli strumenti in maniera da impedire qualsiasi alterazione dei dati del disco rigido.
Il CD di Windows PE consente di avviare il sistema in un ambiente Windows limitato. Quando si crea questo CD di avvio, è possibile includere strumenti, come quelli riportati nello Starter Kit Rimozione malware, configurati per uno scopo specifico. È tuttavia necessario che il computer disponga di almeno 512 MB di RAM, un requisito di Windows PE.
Il processo di creazione del CD-ROM di Windows PE, descritto nei dettagli nello Starter Kit Rimozione malware, è molto semplice. Prima di creare il CD di avvio, è necessario installare Windows Automated Installation Kit (AIK), la famiglia di prodotti Sysinternals (disponibile all'indirizzo microsoft.com/technet/sysinternals/utilities/sysinternalssuite.mspx), inserire gli strumenti Sysinternals nell'elenco degli strumenti riportato nell'attività 2 dello Starter Kit Rimozione malware e installare qualsiasi altro strumento e utilità di analisi del malware. Per istruzioni dettagliate su come creare il CD, seguire la procedura descritta nel documento Starter Kit Rimozione malware.

Unità USB esterna
Poiché questo processo non determina l'alterazione dell'unità sottoposta a indagine, è necessario utilizzare anche un'unità USB o un altro tipo di unità disco esterna in modo da poter archiviare i file di output che verranno generati. È consigliabile tuttavia utilizzare un'unità USB in quanto Windows PE è in grado di installare i dispositivi USB automaticamente. È opportuno inoltre utilizzare un'unità disco esterna per archiviare un'immagine dell'unità disco originale. Con tutti questi requisiti e opzioni, è importante eseguire una pianificazione preliminare che tenga conto dello spazio su disco totale necessario per l'indagine.
Poiché occorre che il kit sia pulito quando si avvia un'indagine, tutti i dati precedenti dovranno essere completamente rimossi dall'unità disco esterna che si utilizzerà per salvare i file dell'indagine. A tale scopo, utilizzare un'utilità di pulizia del disco che sovrascriva l'intera superficie scrivibile dell'unità. Il disco esterno può essere quindi formattato ed etichettato, se necessario, per l'utilizzo nel processo di indagine. Questa precauzione assicura che il dispositivo non contenga file che possano contaminare la prova raccolta durante l'indagine.
Occorre inoltre includere un modulo di catena di custodia (chain of custody) in modo che vi sia una documentazione ufficiale relativa alla persona che ha gestito il computer nel corso dell'indagine. Nel documento "Guida di base alle indagini sui computer per Windows" viene fornito un modulo di catena di custodia di esempio. Una volta incluso il kit in un pacchetto, che contiene il CD di Windows PE di avvio necessario, il dispositivo di archiviazione esterna e un modulo di catena di custodia, è possibile procedere con l'indagine.

Esecuzione di un'indagine
A questo punto è possibile procedere con l'esecuzione di un'indagine. Innanzitutto, avviare il sistema sospetto dal CD di Windows PE verificando che durante la sequenza di avvio del computer il CD-ROM venga identificato come dispositivo di avvio principale. Quando richiesto, premere un tasto per completare l'avvio dal CD-ROM. In tal modo, sarà possibile accedere agli strumenti installati sul disco.
Il kit verrà utilizzato su un computer di esempio per illustrare come raccogliere informazioni da un computer (che verrà chiamato Testbox1). La lettera dell'unità CD assegnata a Testbox1 è X:\ e il percorso predefinito fornito per gli strumenti nello Starter Kit Rimozione malware è X:\tools. Per accedere agli strumenti inclusi nel kit, digitare semplicemente: cd \tools.
Esistono diversi strumenti in grado di identificare le unità di destinazione installate in un computer. Bginfo.exe, situato nella directory degli strumenti Sysinternals, è in grado di fornire queste informazioni e di inserirle in una finestra in background sul desktop in modo da consentirne una rapida consultazione. Drive Manager inoltre è in grado di identificare tutte le unità presenti nel computer, compresi il dispositivo USB esterno e le unità disco rigido di destinazione. Nella Figura 1 vengono riportate le informazioni sulle unità disco per Testbox1. L'unità di avvio è X:\, l'unità disco di destinazione è C:\ e l'unità USB esterna è F:\.
Figura 1 Visualizzazione delle informazioni sulle unità disco con Drive Manager
Figura 1 Visualizzazione delle informazioni sulle unità disco con Drive Manager

Verifica della presenza di malware
Prima di avviare un'indagine, è importante eseguire strumenti anti-malware in modo da assicurare che l'indagine non venga contaminata da un virus o altro codice dannoso. Il report che lo strumento anti-malware genera può essere utilizzato come prova, se necessario. La mancata esecuzione di un controllo nel computer per verificare la presenza di malware può ostacolare l'indagine nonché mettere a rischio la credibilità dell'esperto di informatica forense in termini di precisione e accuratezza. È consigliabile eseguire gli strumenti anti-malware forniti in modalità sola lettura o di report.
Nello Starter Kit Rimozione malware vengono trattati numerosi strumenti consigliati, compresi lo Strumento di rimozione malware e McAfee AVERT Stinger. Quando si esegue lo Strumento di rimozione malware, accertarsi di includere l'opzione da riga di comando /N per indicare allo strumento di segnalare solo la presenza di malware e di non tentare di rimuoverlo:
x:\tools\windows-KB890830-v1.29.exe /N
Il file di report risultante si trova in %windir%\debug\mrt.log.
Analogamente, quando si esegue McAfee AVERT Stinger, impostare la preferenza solo su Report, come illustrato nella Figura 2, in modo che venga eseguita l'analisi del computer ma non venga apportata alcuna modifica all'unità disco rigido. Una volta completata l'analisi, assicurarsi di salvare un report fornito dallo strumento.
Figura 2 Utilizzo della sola modalità Report in McAfee AVERT Stinger
Figura 2 Utilizzo della sola modalità Report in McAfee AVERT Stinger

Salvataggio di file critici
Se, prima di avviare l'indagine, non si è eseguito il backup completo del disco, è consigliabile sottoporre a backup almeno i file più importanti degli utenti. Le informazioni di configurazione possono essere utilizzate per un'analisi futura, se necessario. Raccogliere innanzitutto le impostazioni e i file del Registro di sistema che contengono tutte le informazioni rilevanti sulla modalità di utilizzo del computer e sul software installato nel sistema.
Per salvare l'hive del Registro di sistema per Testbox1, creare prima una cartella nell'unità F:\ rimovibile, quindi registrare l'ora e la data in cui l'indagine è stata avviata utilizzando i seguenti comandi:
f:
Mkdir f:\evidence_files
Date /t >> f:\evidence_files\Evidence_start.txt
Time /t >> f:\evidence_files\Evidence_start.txt
Salvare l'hive del Registro di sistema utilizzando il comando xcopy per copiare l'intera directory di configurazione e il relativo contenuto. I file del Registro di sistema a cui si è interessati sono situati in %windows%\system32\config. In questo caso, verrà eseguito il seguente comando:
xcopy c:\windows\system32\config\*.* f:\registrybkup /s /e /k /v
Questo comando consente di copiare tutte le informazioni di configurazione presenti nella cartella config. Textbox1 contiene circa 95 MB di informazioni nella cartella config.
Successivamente, concentrare l'attenzione sui dati degli utenti, che possono essere situati in qualsiasi punto del disco rigido. Ai fini dell'esempio riportato in questo articolo, vengono copiati solo i dati presenti nella directory c:\HR. Per assicurare che i dati vengano raccolti completamente, copiare tutti i dati nella directory e nelle rispettive sottodirectory utilizzando il seguente comando xcopy:
Mkdir f:\evidence_files\HR_Evidence
Mkdir f:\evidence_files\documents_and_settings
Mkdir f:\evidence_files\users
xcopy c:\HR\*.* f:\evidence_files\HR_Evidence /s /e /k /v
A questo punto, è possibile focalizzare l'attenzione sulle informazioni delle cartelle personali. Copiare di nuovo tutti i dati da queste directory e dalle relative sottodirectory. A tal fine, utilizzare i seguenti comandi:
Xcopy c:\documents and settings\*.* f:\evidence_files\documents_and_settings /s /e /k /v

Xcopy c:\users\*.* f:\evidence_files\users /s /e /k /v
Questo esempio ha consentito di raccogliere circa 500 MB di dati, che è possibile analizzare se necessario. Come è possibile osservare, la quantità di dati raccolti può raggiungere dimensioni estremamente elevate, in particolare se sono presenti file audio, video e foto. Tuttavia, è importante preservare il maggior numero possibile di dati originali in quanto un'indagine potrebbe richiedere non solo l'a prova raccolta fisicamente ma anche la sicurezza che queste informazioni non siano state alterate durante il processo di raccolta. L'ideale sarebbe creare un'immagine disco completa per l'indagine, ma questa operazione può rivelarsi difficoltosa a causa delle limitazioni di dimensione. Inutile a dirsi, la valutazione preliminare della quantità di spazio di archiviazione eventualmente necessaria per l'indagine riveste un'importanza fondamentale.

Raccolta di ulteriori informazioni
Anche i file di sistema possono essere una risorsa utile nel processo di raccolta delle prove, ma la raccolta di questi dati potrebbe richiedere l'esplorazione del computer di destinazione in quanto è possibile che tali file non risiedano sempre nella stessa posizione. Tuttavia, vale comunque la pena analizzare determinati tipi di file in quando possono fornire informazioni molto utili. I file di scambio, ad esempio, contengono informazioni sui tipi di file utilizzati dalla memoria. Inoltre, i file di scambio possono fornire anche attività di utilizzo dettagliate. Allo stesso modo, i dati e i cookie del browser Web offrono informazioni sul comportamento e sui modelli di esplorazione.
Il rilevamento di questi dati può richiedere un po' di lavoro da detective, soprattutto se un utente ha modificato la configurazione del sistema in modo da archiviare i dati in posizioni diverse da quelle predefinite. Sono disponibili diversi strumenti di Sysinternals che consentono di identificare i file critici. Nella Figura 3 vengono elencate cinque utili applicazioni e viene descritto come tali applicazioni possono semplificare le indagini.
Figure 3 Strumenti per l'individuazione dei file e dei dati di interesse (Close Figure 3)

Applicazione | Descrizione
AccessChk | Consente di visualizzare l'accesso a file, chiavi del Registro di sistema e servizi di Windows da parte dell'utente o del gruppo specificato.
AccessEnum | Consente di visualizzare l'utente che ha accesso a determinati file, directory e chiavi del Registro di sistema su un computer. È possibile utilizzare questo strumento per individuare le posizioni in cui le autorizzazioni non sono applicate in modo corretto.
Du | Consente di visualizzare l'utilizzo del disco in base alla directory.
PsInfo | Consente di visualizzare le informazioni su un computer.
Strings | Consente di cercare le stringhe ANSI e UNICODE nelle immagini binarie.

Tom Cloward, CCE, CISSP, è Program Manager presso Microsoft e la sua attività è incentrata sulla fornitura ai professionisti IT di acceleratori di soluzioni per la protezione e la conformità. Ha lavorato nei settori software e IT per oltre 15 anni e ha una spiccata passione per la protezione IT, le indagini forensi e la conformità. Frank Simorjay, CISSP, CET, è Technical Program Manager e un esperto nell'area della protezione per il gruppo Microsoft Solution Accelerator - Security and Compliance. È responsabile della progettazione di soluzioni di protezione per i clienti Microsoft. La sua creazione più recente è Starter Kit Rimozione malware, disponibile su Microsoft TechNet.
Frank Simorjay, CISSP, CET, è Technical Program Manager e un esperto nell'area della protezione per il gruppo Microsoft Solution Accelerator - Security and Compliance. È responsabile della progettazione di soluzioni di protezione per i clienti Microsoft. La sua creazione più recente è Starter Kit Rimozione malware, disponibile su Microsoft TechNet.


 Rete: Report Microsoft sullo stato della protezione
Rete Tim Rains

Report Microsoft sullo stato della protezione
Panoramica:
  • Le tendenze di divulgazione e sfruttamento delle vulnerabilità del software
  • L'impatto delle minacce sulle diverse versioni di Windows
  • Le aree più e meno colpite del mondo

I dati di centinaia di milioni di sistemi connessi a Internet e di alcuni dei servizi online più trafficati del mondo consentono a Microsoft di godere di un punto di vista privilegiato sui rischi di protezione che gli utenti di Internet devono affrontare ogni giorno.
Microsoft pubblica questi dati due volte l'anno nel Report Microsoft sullo stato della protezione (SIR). Alla stesura del report collaborano Microsoft® Malware Protection Center (MMPC), Microsoft Security Response Center (MSRC), il gruppo Trustworthy Computing (TwC) e alcuni gruppi che lavorano ad altri prodotti. Il SIR costituisce un'analisi approfondita delle tendenze più recenti nella divulgazione di vulnerabilità del software e nella diffusione di software dannoso e potenzialmente indesiderato, come spyware e adware. Il report contiene, inoltre, informazioni sul comportamento delle diverse versioni del sistema operativo Windows nell'ambito dei rischi di protezione e sulle aree del mondo più colpite da malware e altro software intrusivo. La versione più recente del report, che riguarda le tendenze osservate nella prima metà del 2007, contiene una nuova sezione sugli exploit delle vulnerabilità del software. Chiunque sia responsabile o interessato alla protezione dei computer troverà il SIR una lettura estremamente utile, poiché il rapporto è stato progettato per informare gli utenti sui rischi di protezione correlati all'utilizzo di Internet.
Il SIR più recente rivela che i professionisti della protezione informatica hanno trovato più vulnerabilità nel software di tutti i produttori. Infatti, solo nella prima metà del 2007 sono state scoperte 3.400 nuove vulnerabilità del software. Tuttavia, nonostante questa considerevole cifra, la percentuale complessiva di vulnerabilità scoperte nel sistema operativo è in calo.
Qual è il significato di questi dati? Una possibilità è che i ricercatori e i professionisti della protezione si siano concentrati di più sulle applicazioni, perché la protezione del sistema operativo ha continuato a migliorare. Inoltre, poiché il numero di nuove applicazioni è molto superiore al numero di nuovi sistemi operativi, la proliferazione di applicazioni è probabilmente una forza trainante per le tendenze di divulgazione delle vulnerabilità più recenti.
Nel 2006, il 29,3% delle vulnerabilità note dei prodotti Microsoft aveva del codice di sfruttamento pubblicamente disponibile mentre, a tutto il 1 agosto 2007, solo il 20,9% delle vulnerabilità note aveva del codice di sfruttamento pubblicamente disponibile. Sebbene il numero di vulnerabilità continui ad aumentare, il rapporto con il codice di sfruttamento disponibile resta stabile con una lieve tendenza al ribasso. È più difficile trovare del codice per sfruttare le vulnerabilità dei prodotti più recenti. È stata condotta una comparazione prodotto per prodotto, che suggerisce che le versioni più recenti dei prodotti sono meno esposte al rischio delle versioni che sono sul mercato da maggior tempo. In media, la sfruttabilità tende a diminuire lungo il ciclo di vita di un prodotto, vale a dire che per una maggioranza di prodotti le versioni più recenti sono meno sfruttabili. Questo è particolarmente evidente per Windows e per i prodotti Microsoft Office System. Con le ultime versioni di entrambi (Windows Server® 2003, Windows Vista®, Office 2003 e Office System 2007) si è osservata una netta riduzione nel numero di vulnerabilità durante il ciclo di vita del prodotto.
Il SIR offre preziose informazioni sulle tendenze del software dannoso (noto come malware). Queste tendenze sono indicative delle tattiche utilizzate per attaccare gli utenti. L'analisi dei dati raccolti da alcune fonti significative, tra cui Microsoft Exchange Hosted Services (EHS), Windows Live® OneCare e Windows Live OneCare Safety scanner, Strumento di rimozione malware per Microsoft Windows (MSRT) e Windows Defender, offre una panoramica sui rischi di protezione da alcuni punti di vista privilegiati.
L'ingegneria sociale assume un ruolo sempre crescente nella distribuzione del malware. Con attacchi di questo tipo si riesce spesso a convincere gli utenti a eseguire delle azioni che possono ridurre l'efficacia dei meccanismi di protezione. I dati EHS indicano che, durante la prima metà del 2006, i worm diffusi tramite posta elettronica classici hanno rappresentato la maggiore minaccia diffusa tramite posta elettronica, raggiungendo il 95% del malware rilevato nei messaggi di posta elettronica. All'inizio della seconda metà del 2006, la percentuale è scesa al 49% restando invariata per tutta la prima metà del 2007 (vedere la Figura 1). Gli attacchi tramite phishing e i messaggi di posta elettronica con attacchi IFrame dannosi assommavano al 27% dei rilevamenti di malware diffuso tramite posta elettronica nella seconda metà del 2006, raggiungendo il 37% nella prima metà del 2007. I trojan downloader trasportati da messaggi di posta elettronica hanno raggiunto un picco del 20% nella seconda metà del 2006, scendendo quindi al 7% nella prima metà del 2007.
Figura 1 Composizione dei messaggi di posta elettronica infetti nella prima metà del 2007
Figura 1 Composizione dei messaggi di posta elettronica infetti nella prima metà del 2007
I dati di telemetria raccolti da Windows Live OneCare e Windows Live OneCare Safety scanner (safety.live.com) indicano che nella prima metà del 2007 sono aumentati i tassi di infezione da virus, backdoor, programmi di intercettazione password e trojan progettati per il furto di dati.
MSRT è progettato per facilitare l'individuazione e rimozione del malware dai computer dei clienti. Viene rilasciato principalmente come aggiornamento critico tramite Windows Update (WU), Microsoft Update (MU) e Aggiornamenti automatici (AU). Negli ultimi due anni MSRT ha rimosso 50,3 milioni di infezioni da 20,5 milioni di computer nel mondo. Il numero totale delle sessioni di esecuzione di MSRT alla data del report è pari a oltre 7,4 miliardi, di cui 1,9 miliardi nella prima metà del 2007.
MSRT è un'ottima fonte di dati per Microsoft e i suoi clienti. I tassi di infezione osservati da MSRT sono molto più bassi nei sistemi Windows Vista e Windows XP SP2 rispetto ai sistemi operativi Windows meno recenti, come illustrato nella Figura 2. MSRT ha eliminato malware da computer che utilizzano Windows Vista con una frequenza inferiore del 60% rispetto ai computer che utilizzano Windows XP SP2 e inferiore del 91,5% rispetto ai computer che utilizzano Windows XP senza alcun Service Pack installato. È interessante notare che il numero di disinfezioni per computer è rimasto invariato nel tempo, con una media di 2,2 disinfezioni per computer infettato.
Figura 2 Versioni di sistema operativo pulite da MSRT nella prima metà del 2007
Figura 2 Versioni di sistema operativo pulite da MSRT nella prima metà del 2007
In generale, la maggiore quantità di malware viene rilevato da MSRT, in proporzione, nei paesi in via di sviluppo. Ad esempio, i paesi con il maggior numero di infezioni in Europa sono Albania e Turchia, mentre le infezioni sono meno frequenti in Italia e Finlandia. Nell'area Asia-Pacifico, i paesi con più infezioni sono Mongolia e Tailandia, mentre il numero minimo di infezioni si rileva in Nuova Zelanda e Giappone. Negli Stati Uniti si registrano, in proporzione, meno infezioni che nella maggior parte degli altri paesi delle Americhe e il tasso di infezione USA equivale per grandi linee alla media mondiale. In media MSRT ha pulito infezioni da un computer ogni 216 durante la prima metà del 2007.
Windows Defender viene eseguito su Windows Vista, Windows XP e Windows Server 2003. In totale, nella prima metà del 2007 sono stati rilevati 50,7 milioni di software potenzialmente indesiderati. Sui computer che utilizzano Windows Vista i rilevamenti sono stati inferiori di 2,8 volte rispetto ai computer che utilizzano Windows XP SP2. Allo stesso modo, il numero di rilevamenti di software potenzialmente indesiderato sui computer che utilizzano Windows Vista è risultato essere pari alla metà dei rilevamenti analoghi sui computer con Windows Server 2003.
Per quanto possano sembrare interessanti, è naturale chiedersi in che modo queste statistiche possono aiutare a migliorare la protezione del proprio ambiente informatico? Nell'ultimo SIR ciascuna sezione è preceduta da un riepilogo con i dati principali della sezione e una serie di strategie, attenuazioni e contromisure. È possibile utilizzare questi elenchi per apprendere rapidamente le informazioni sui risultati di ciascuna sezione del report.
I dati, i dettagli e i consigli proposti dal SIR possono inoltre essere impiegati per valutare e migliorare le condizioni di protezione correnti, dato il paesaggio in continua evoluzione. È possibile scaricare il report completo, che propone anche strategie, attenuazioni e contromisure sulla base dei dati più importanti, dall'indirizzo microsoft.com/sir.

Tim Rains è un Product Manager del Microsoft Malware Protection Center (MMPC). Gestisce la produzione del Report Microsoft sullo stato della protezione (SIR). Gli autori del SIR sono Jeff Jones (Direttore, gruppo Microsoft Trustworthy Computing), Jeff Williams (Direttore per il MMPC), Mike Reavey (Group Manager, Microsoft Security Response Center) e Ziv Mador (Senior Program Manager e Response Coordinator, MMPC).


 Rete: Individuazione dei problemi di rete pi&#249; elusivi
Rete Christopher Stoneff

Individuazione dei problemi di rete più elusivi
Panoramica:
  • Cause comuni dei problemi di rete
  • Oltre l'ovvio
  • Quando gli strumenti per la risoluzione dei problemi sono inefficaci
  • Perché è necessario configurare i limiti di connessione

Capita di frequente di trovarsi in una situazione in cui un computer non riesce a comunicare con gli altri computer della rete senza alcun motivo apparente. Il sistema di gestione risiede su un segmento di una rete di routing connessa ad altri segmenti di rete tramite un router, ad esempio Microsoft Internet
Security and Acceleration (ISA) Server o un altro dispositivo di rete. In uno scenario che prevede la gestione di 10, 20 o persino 100 sistemi, esistono buone probabilità che non si verifichi alcun problema. Tuttavia, quando si tenta di gestire 500 sistemi, il computer non sarà in grado di comunicare con tutti i computer della rete, ma solo con quelli con cui ha già aperto delle connessioni. Non si riesce a comunicare con nessun altro sistema, né a connettersi a Internet, anche se nessun altro computer sul proprio segmento di rete presenta lo stesso problema. Come procedere in una situazione di questo tipo?

Diagnosi del problema
In questo tipo di situazione si parte, in genere, dal presupposto che il software di gestione sia difettoso. Molti strumenti di gestione proattiva si connettono ai sistemi e li gestiscono, ma a volte gli stessi strumenti possono causare il problema che si sta tentando di individuare. Il motivo è che uno strumento di gestione proattiva a volte genera migliaia di connessioni ai dispositivi, in nome di una migliore gestione. Per impostazione predefinita, in Windows® le connessioni vengono tenute aperte per due minuti anche quando sono inattive, a meno che lo strumento, l'applicazione o il servizio non preveda una maggiore durata del periodo di attività delle connessioni aperte. Ne consegue che, sebbene il sistema di gestione non abbia comunicato con altri computer nel corso del periodo predefinito di due minuti, potrebbero essere ancora presenti più di 1.000 connessioni aperte. Per visualizzare le connessioni aperte, è possibile eseguire NETSTAT in un prompt dei comandi. Il comando NETSTAT consente di visualizzare tutte le connessioni aperte, in sospeso e chiuse da e verso il proprio sistema e di fornirne lo stato. Descrizioni dei messaggi di stato sono disponibili nella specifica RFC 793 all'indirizzo tools.ietf.org/html/rfc793.
Per escludere il software di gestione malfunzionante, è possibile creare un file batch che consenta di stabilire connessioni ai sistemi remoti. Se lo stesso problema si verifica durante l'esecuzione del file batch, la causa non va ricercata nel malfunzionamento del software di gestione e dei relativi thread. Di seguito viene riportato un esempio del contenuto del file batch necessario:
Net use \\system01\ipc$
Net use \\system02\ipc$
Net use ...
Se il programma di gestione in questione ha implementato il proprio stack di rete e di autenticazione, è probabile che la causa del problema sia lo strumento stesso; tuttavia, nelle soluzioni senza agente, come la maggior parte di questi pacchetti di gestione, per eseguire le operazioni di rete, lo strumento utilizza gli stack di rete e di autenticazione del sistema operativo. L'utilizzo di un file batch che avvia esattamente lo stesso numero di connessioni senza causare l'errore dimostrerà che il problema non è il risultato dell'utilizzo degli stack di rete e di autenticazione del sistema operativo da parte del programma di gestione, poiché gli stack vengono utilizzati anche dal file batch.

Registri e messaggi di errore non risolutivi
Quando si sono manifestati i problemi di connessione, è possibile che si siano ricevuti informazioni erronee sull'errore: errore 53 - Impossibile trovare il percorso di rete, errore 64 - Nome di rete cancellato ed errore 1203 - Nessun provider di rete ha accettato il percorso di rete specificato. Tutti questi messaggi in genere indicano problemi di risoluzione dei nomi, anche se tutti gli altri computer non presentano affatto problemi di risoluzione dei nomi e di connessione agli stessi sistemi. Per verificare che le impostazioni del computer siano corrette, è sufficiente eseguire ipconfig.
Successivamente, poiché il problema sembra essere circoscritto al proprio sistema di gestione, è opportuno esaminare i registri eventi. Anche se una ricerca nei registri applicazioni non porta alcun frutto, tuttavia nel registro eventi di sistema è possibile rilevare l'evento di avviso 4226 generato dall'origine eventi TCP/IP che indica che è stato raggiunto il numero massimo di connessioni consentite (vedere la Figura 1).
Figura 1 Il limite di connessione TCP è stato raggiunto
Figura 1 Il limite di connessione TCP è stato raggiunto
Se si esegue una ricerca completa all'interno della Microsoft® Knowledge Base per verificare i limiti di connessione, si scoprirà che esistono limitazioni di connessione per le connessioni non completate, ma non per le connessioni completate. Per controllare i fattori sopra menzionati è possibile modificare le seguenti voci del Registro di sistema in HKLM\System\CurrentControlSet\Services\TCPIP: TcpNumConnections viene utilizzato per impostare il numero massimo di connessioni aperte disponibili per TCP contemporaneamente (il valore predefinito è 10). TCPTimedWaitDelay imposta il periodo di tempo in cui una connessione resta nello stato TIME_WAIT durante la chiusura. Il valore predefinito è 120 secondi, che indica che una connessione è sostanzialmente in uso per 4 minuti. Infine, anche MaxFreeTcbs gioca un ruolo nel numero massimo di connessioni. Se tutti i blocchi di controllo TCP sono in uso, TCP deve rilasciare le connessioni nello stato TIME_WAIT per creare ulteriori connessioni anche se il parametro TCPTimedWaitDelay non è ancora scaduto. TCPTimedWaitDelay prevede un intervallo di valori compreso tra 30 e 300 secondi (0x1E - 0x12C).
A seconda dello scenario specifico, queste modifiche al Registro di sistema potrebbero determinare un lieve miglioramento delle prestazioni globali. Un'altra operazione che è possibile tentare consiste nell'applicazione di patch al file TCPIP.sys per rimuovere questi limiti, ma questo tentativo garantisce dei miglioramenti solo nelle applicazioni P2P.

Acquisizioni di rete
Dopo altri tentativi di risoluzione dei problemi di connessione non riusciti, un'acquisizione di rete dai computer coinvolti potrebbe consentire di ottenere risultati positivi. Quando si è eseguito Microsoft Network Monitor (Netmon), sono state create delle acquisizioni che mostravano gli stessi risultati visualizzati negli strumenti di gestione e negli script di test: dopo i primi risultati positivi, si registra una serie di problemi, senza alcuna ulteriore indicazione di errore.
Nella Figura 2 viene illustrato il risultato dell'esecuzione di Netmon, che indicava la corretta comunicazione tra i primi n sistemi. È possibile osservare inoltre che si sono ottenuti acknowledgment relativi alle richieste RPC. Ecco il risultato che si desidera ottenere: comunicazione bidirezionale senza errori.
Figura 2 Corretta comunicazione in Netmon
Figura 2 Corretta comunicazione in Netmon
A questo punto, è necessario esaminare le acquisizioni dal sistema di gestione e dai computer remoti su cui sembra si sia verificato l'errore 53/1203. Come ci si può aspettare, non viene visualizzato nulla, in quanto i computer non stanno comunicando. Nell'acquisizione di rete nella Figura 3, il sistema di gestione ha risolto l'indirizzo IP e tenta di connettersi al sistema tramite la porta 445 (la porta Microsoft SMB) ma non riceve alcuna risposta.
Figura 3 I tentativi di connessione al sistema tramite la porta 445 non producono alcuna risposta
Figura 3 I tentativi di connessione al sistema tramite la porta 445 non producono alcuna risposta
L'errore che si riceve quando si utilizza un numero di thread superiore a quello a cui il computer è attualmente in grado di connettersi non è sempre coerente. In alcuni casi, è possibile che nel sistema di origine venga visualizzato l'errore 53, che indica che si è ricevuta la risoluzione dei nomi ma che l'indirizzo IP non è stato trovato. Un errore di questo tipo indica che DNS ha fornito un indirizzo a cui non si è in grado di connettersi. È possibile che si riceva l'errore 1203, che indica che nessun computer ha risposto al nome o all'indirizzo IP richiesto. L'errore 1203, in questo caso, indica che DNS non è disponibile. A conferma di ciò è possibile eseguire nslookup.
A questo punto, non lasciarsi prendere dalla frustrazione, in quanto sono disponibili altre opzioni da prendere in considerazione. Data la modalità in cui questo problema si manifesta, la maggior parte degli utenti non pensa affatto di esaminare l'infrastruttura di connessione: il proprio computer è l'unico computer che non è in grado di connettersi al resto della rete e i registri eventi mostrano che è stato raggiunto il numero massimo di connessioni consentite, pertanto il problema non sembra essere correlato all'architettura del sistema.
Sebbene le migliaia di connessioni generate dalla soluzione di gestione non vengano avviate contemporaneamente, i keep-alive di trasmissione e i timeout di connessione possono indicare che sono presenti più connessioni simultanee aperte di quanto si possa pensare. Pertanto, è necessario esaminare anche i sistemi che connettono il resto della rete.
In altre parole, come si è affermato in precedenza, poiché il traffico di rete passa attraverso la rete, passerà anche attraverso switch, router e probabilmente firewall. In ognuno di questi punti, in genere il router o il firewall, è possibile che siano presenti sistemi di rilevamento delle intrusioni. È possibile inoltre che i router e gli switch gestiti utilizzino i filtri di traffico. Chiunque gestisca questi dispositivi dovrà controllare i registri per verificare se siano presenti errori o avvisi. Il problema di comunicazione potrebbe con molta probabilità risiedere in questi sistemi.
Poiché si sta eseguendo una connessione da un sistema interno ad altri sistemi interni, è possibile che non venga generato alcun messaggio di avviso, in quanto la funzionalità di avviso non è configurata nel dispositivo o perché il problema non sembra essere il risultato di un attacco di intrusione o Denial of Service (DoS). Ancora una volta, è consigliabile esaminare prima i registri. Utilizzando ISA Server come esempio, è possibile trovare questi registri nella console di gestione di ISA Server in Arrays\<NomeArray>\Monitoring\Logging.
Se il blocco è causato da un criterio, è possibile (nel caso di ISA Server) cercare i seguenti codici dei risultati dove l'IP di origine rappresenta il computer di gestione:
  • 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
  • 0xc004000d FWX_E_POLICY_RULES_DENIED
  • 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED
Se si trovano questi risultati, questo significa che si è identificata la causa dei problemi di connettività.

Implementazione della soluzione
Una volta identificato il problema, la soluzione può essere semplice, ma la politica di reparto potrebbe renderne difficoltosa l'implementazione. Prima di apportare eventuali modifiche, assicurarsi di disporre delle autorizzazioni appropriate, in quanto la creazione di esclusioni nelle configurazioni di protezione nei propri firewall, router e/o sistemi di rilevamento delle intrusioni non è sempre consentita.
Utilizzando di nuovo ISA Server come esempio, nella procedura riportata di seguito viene illustrato come aumentare il numero massimo di connessioni per un determinato host o per tutti i computer della rete (come riportato nella Figura 4). Aprire la console di gestione di ISA Server e accedere alla directory Arrays\<NomeArray>\Configuration\General\Configure Flood Mitigation Settings.
Figura 4 Aumento del numero massimo di connessioni per un host o tutti i computer utilizzando ISA Server
Figura 4 Aumento del numero massimo di connessioni per un host o tutti i computer utilizzando ISA Server
Le due impostazioni di interesse sono relative al numero massimo di connessioni TCP simultanee per ciascun indirizzo IP e al numero massimo di richieste di connessione TCP al minuto per ogni indirizzo IP. Il numero massimo di connessioni TCP simultanee per ciascun indirizzo IP viene in genere impostato su un valore che risulta sufficiente quando non viene eseguita una gestione attiva, ovvero quando nessun computer è attivamente connesso a migliaia di altri computer. In ISA Server, il limite predefinito per il numero massimo di connessioni TCP simultanee è 160. Il numero massimo di richieste di connessione TCP al minuto per ogni indirizzo IP ha lo scopo di limitare i danni e la visibilità delle scansioni di rete. Il limite predefinito per il numero massimo di richieste di connessione TCP al minuto per ogni indirizzo IP è 600.
Come affermato in precedenza, in Windows una connessione viene mantenuta attiva per un periodo predefinito di due minuti, purché nessun altro dispositivo tenti di mantenere attiva la connessione, anche se la connessione non è in uso. Ne consegue che, anche se si è già gestito un computer e non è più necessario comunicare con tale computer, la connessione rimarrà attiva. Questa connessione aperta viene conteggiata nel numero totale delle connessioni consentite. Se si ripete questo processo più di 160 volte senza rimuovere le connessioni si rileverà che tutti i tentativi di connessione verranno negati dal router. Anche se il programma di gestione termina attivamente una sessione, è possibile che in Windows la connessione venga lasciata nello stato time_wait in attesa che il computer di destinazione accetti di disconnettere la sessione.
Il primo passaggio da eseguire è apportare modifiche al colpevole più probabile: il numero massimo di connessioni TCP simultanee per ciascun indirizzo IP. È consigliabile impostare questo numero in modo che il computer di gestione sia in grado di creare tutte le connessioni necessarie per gestire i sistemi senza che l'accesso venga negato. Fare clic sul pulsante Edit accanto all'impostazione e modificare i valori.
Il prompt successivo (vedere la Figura 5) include una casella Limit che rappresenta il limite predefinito, applicabile a tutti i client. Il limite Custom si applica a tutti i computer, le reti e altri sistemi definiti nella scheda IP Exceptions della finestra di dialogo Flood Mitigation. Se si desidera consentire a ogni computer di creare più connessioni, modificare il valore della casella Limit. Per configurare l'eccezione solo per il computer di gestione in uso, modificare il limite Custom e aggiungere il computer alla scheda IP Exceptions. In generabile, è preferibile consentire l'eccezione solo per il computer in uso.
Figura 5 Limite di connessione predefinito e limite di connessione personalizzato
Figura 5 Limite di connessione predefinito e limite di connessione personalizzato
Se si desidera utilizzare il limite personalizzato per modificare questo valore solo per specifici sistemi, modificare il valore nel campo Custom limit e fare clic su OK. Aggiungere quindi il computer alla scheda IP Exceptions nella finestra di dialogo Flood Mitigation. Per aggiungere il computer in uso all'elenco delle eccezioni, in IP Exceptions fare clic su Add per visualizzare la finestra di dialogo Computer Sets. Fare clic su New per creare un nuovo gruppo di reti che contenga il sistema in uso, se un gruppo di reti contenente questi computer non esiste già. Selezionare questo gruppo di reti e fare clic su Add per aggiungere il gruppo di reti Internal Networks, quindi scegliere Close. Selezionare di nuovo il gruppo di reti Internal Networks e fare clic su Edit. Verranno visualizzate le proprietà per Internal Networks (vedere la Figura 6). In questa finestra di dialogo fare clic su Add per visualizzare un sottomenu in cui è possibile scegliere di aggiungere un computer, un intervallo di indirizzi o una subnet; scegliere di aggiungere il computer. Immettere un nome per identificare la voce, l'indirizzo IP del computer e una descrizione in modo da impedire a chiunque visualizzi questa voce in futuro di rimuovere il sistema (vedere la Figura 7). Fare clic su OK per aggiungere il sistema, quindi fare di nuovo clic per aggiungere l'eccezione. Una volta apportate queste modifiche, è necessario applicare le impostazioni.
Figura 6 Impostazioni della finestra di dialogo Internal networks properties
Figura 6 Impostazioni della finestra di dialogo Internal networks properties
Figura 7 Inserire il nome del computer, l'indirizzo IP e la descrizione per assicurare che il sistema non venga rimosso
Figura 7 Inserire il nome del computer, l'indirizzo IP e la descrizione per assicurare che il sistema non venga rimosso
Se si esegue di nuovo lo strumento di gestione proattiva si rileverà che le prestazioni sono notevolmente migliorate e che non si verificano problemi di connessione, almeno non in conseguenza del traffico di rete. Alla fine, si è scoperto che la causa del problema non risiedeva nel numero di connessioni avviate dal software, ma nella mancanza di una corretta pianificazione delle connessioni.

Esperienza acquisita
Uno dei grattacapi principali nel settore IT è sperimentare e successivamente risolvere problemi caratterizzati da elevata ambiguità. Si tratta di problemi non creati dall'utente finale, non causati dal team del server, della cui esistenza il supporto tecnico è inconsapevole e la cui correzione è, fortunatamente, responsabilità dell'utente. Sono disponibili diversi strumenti che consentono di isolare e risolvere specifici problemi, ma talvolta gli strumenti non sono sufficienti. Gli strumenti a volte possono essere suscettibili di errore. E a volte è necessario adottare un approccio più intelligente rispetto a quello fornito dagli strumenti.
Qualora capiti di trovarsi in una situazione in cui non si è in grado di stabilire connessioni tra diversi computer della rete senza alcuna ragione apparente, provare e eseguire la procedura descritta in questo articolo. Vi sono buone possibilità che seguendo questa procedura, esaminando attentamente il software di gestione e impostando le connessioni consentite in modo appropriato si sarà in grado di risolvere il problema nel modo corretto.

Christopher Stoneff è Product Manager presso Lieberman Software (liebsoft.com), nonché uno sviluppatore di software per la gestione della protezione e dei sistemi. In questi anni Chris ha ottenuto moltissime certificazioni. Il suo obiettivo principale sul lavoro consiste nel comprendere non solo il "come" ma soprattutto il "perché" ogni cosa funziona in un certo modo.


 Dal redattore: Che la conversazione inizi
Dal redattore
Che la conversazione inizi
Joshua Hoffman

Quasi tutte le cose che vale la pena ricordare sono iniziate con una conversazione.
"Non credo affatto che il mondo sia piatto. Dovremmo andare a controllare di persona, non credi"?
"Perché non mandiamo qualcuno sulla luna"?
"Posso parlarti di un'idea che mi è venuta per questi nuovi computer"?
"Vediamoci per un caffè"
(quest'ultimo non è l'evento importante a cui mi riferisco... Il caffè mi piace troppo. E poi, diamine, se ci si incontra per un caffè, magari una grande idea ci viene davvero).
In ogni caso l'affermazione che ogni evento importante inizi di solito con una conversazione mi appare vera su due livelli questo mese. Il primo si riferisce a una conversazione reale in corso in questo periodo sui blog, nei corridoi e anche in questo numero di TechNet Magazine (vedere l'articolo della rubrica Taccuino di Romi Mahajan a pag. 91). Riguarda il progressivo scivolamento dell'informatica verso il mercato di consumo. La discussione si incentra sul fatto che l'IT non è più una riserva dei professionisti in ambito lavorativo. La realtà è che ciò che si fa nella vita quotidiana (il volontariato, il karaoke, i giochi su Xbox, qualunque cosa) influisce sul lavoro e sulle decisioni che si prendono in ambito professionale. È una conversazione che Romi e io, con alcuni ospiti speciali, sosterremo anche in un dibattito intitolato "Il futuro intercambiabile" alla prossima conferenza Windows Connections che si terrà a Las Vegas. Spero che molti lettori possano unirsi a noi di persona o visitando il sito Web all'indirizzo WeWantToKnow.net. Anche la conversazione sul blog blogs.technet.com/tnmag è aperta ai contributi dei lettori.
Il secondo aspetto da discutere è la tecnologia utilizzata per rendere possibili le conversazioni. Nel numero di questo mese di TechNet Magazine si analizzano i principali miglioramenti apportati a Exchange Server che semplificano lo scambio di informazioni, da un corridoio all'altro o da continenti diversi. Vengono illustrate le nuove funzionalità di Exchange Server 2007 SP1, si descrive in che modo la replica continua di standby può rafforzare in modo considerevole i piani di ripristino di emergenza, si espongono le opportunità offerte alla piattaforma Exchange da Windows Server 2008 e si dimostra che la messaggistica unificata rende le conversazioni ancora più fruttuose. Come bonus questo mese, l'edizione stampata di TechNet Magazine contiene il più recente della famosa serie di poster di Astrid McClean e Martin McClean. In passato sono già stati pubblicati il poster Active Directory Component Jigsaw e i poster di Windows Server 2008. Questo mese si confrontano con Exchange. Che la conversazione inizi Joshua Hoffman

Si ringraziano i seguenti esperti tecnici di Microsoft: Ed Banti, Anah Cameron, Chun Yong Chua, Cliff Didcock, Jeremy Kelly, Michael Murgolo, Jon Orton, Jeff Ressler, Kevin Sullivan, Jim Truher, Scot Vidican e Michael Wilson.


 Lettere: La parola ai lettori
Lettere
La parola ai lettori

Utilità PageDefrag
Ho tentato di eseguire l'utilità PageDefrag di SysInternals di cui avevo letto nel numero di settembre 2007. Tuttavia, sotto Windows Vista® x64 l'esecuzione non è riuscita ed è stato visualizzato un messaggio d'errore con cui si richiede di verificare se l'utente è un amministratore e si notifica che non è possibile caricare il driver di PageDefrag".
—Alex D.

L'utilità PageDefrag non è ancora supportata in Windows Vista. Funziona solo con Windows NT® 4.0, Windows® 2000, Windows XP, e Windows Server® 2003. Ci scusiamo se questa circostanza non è stata precisata nell'articolo di settembre.

Pianificazione dei backup
Ho letto l'articolo "Una guida alle tecnologie di backup di Windows Vista" del numero di settembre 2007 con grande interesse, ma vorrei porre qualche domanda in merito.Nella Figura 2 dell'articolo vengono visualizzate una data e un'ora per il backup successivo. Come è possibile se lo strumento di backup non contiene una funzione di pianificazione?
Poiché le modifiche dei blocchi del disco sono la base per determinare quali dati inserire nel backup, cosa accade dopo una deframmentazione del disco? Nel backup viene archiviata una grande quantità di dati a causa del massiccio spostamento dei blocchi e delle relative modifiche? Inoltre, in che modo il ripristino dei dati nella posizione di origine interagisce con le modifiche conseguenti alla deframmentazione del disco?
—Bruce G.

Abbiamo girato le domande all'autrice dell'articolo Christine Fok, che ci ha fornito le seguenti risposte:
Nella Figura 2 viene visualizzata una data e un'ora per il backup successivo di file e cartelle, ma solo l'ora del Backup Complete PC più recente. È possibile pianificare un backup a livello di file/cartella ma, come notato dal lettore, Backup Complete PC non è dotato di una propria funzionalità di pianificazione.
È corretto pensare che l'esecuzione della deframmentazione tra due backup Complete PC può rendere il secondo più voluminoso. Allo stesso modo anche i dubbi sul ripristino dopo la deframmentazione sono giustificati. Complete PC opera a livello di volume, al di sotto del file system. Ciascun blocco viene ripristinato esattamente nella stessa posizione su disco in cui si trovava al momento del backup, senza tenere conto delle eventuali deframmentazioni eseguite dal momento del backup. Ne consegue che dopo il ripristino potrebbe essere necessario eseguire di nuovo la deframmentazione del volume.

Strumento BGInfo
Ho letto con molto interesse l'articolo della rubrica Utilità in primo piano del numero di agosto 2007. Lo strumento BGInfo di SysInternals che consente di raccogliere informazioni cruciali su CPU e rete si è rivelato eccezionale. Leggo sempre con piacere le informazioni sulle persone che sviluppano un prodotto, un'utilità, un programma o un'applicazione nuova. Il signor Cogswell ha sviluppato altri prodotti software per Microsoft?
—Daryl B.

Ci fa piacere sapere che i nostri lettori abbiano trovato utile BGInfo. Bryce Cogswell ha scritto molte utilità particolarmente riuscite, in genere in collaborazione con Mark Russinovich come parte di Sysinternals. Microsoft ha acquisito Sysinternals nel 2006, e sia Cogswell che Russinovich ora lavorano presso di noi. Le altre utilità cono disponibili sul sito Web di Sysinternals all'indirizzo microsoft.com/technet/sysinternals.

RPC e firewall
L'articolo "Risoluzione degli errori RPC" del numero di luglio 2007 si è rivelato molto utile, ma a mio parere ha mancato un punto essenziale: Windows Firewall può provocare errori RPC. Se Windows Firewall viene configurato in modo da consentire le richieste di PING ma non i messaggi in ingresso non richiesti, tutti i tentativi di gestire un computer in modalità remota sono destinati a fallire. Se si esegue RPCPING.exe da Windows Resource Kit, viene restituito l'errore 1722 (il server RPC non è disponibile).
In questo caso il firewall assolve esattamente al proprio compito: blocca l'accesso degli estranei a un determinato sistema. Purtroppo ciò accade anche nel caso di amministratori che tentano di gestire i computer su una rete aziendale.
—Aaron M.

Grazie per aver messo in luce un'altra potenziale origine di problemi RPC. Speriamo che gli strumenti menzionati nell'articolo possano aiutare a risolvere i problemi.

Licenze di Windows XP
Nella rubrica Taccuino di ottobre 2007 si cita la possibilità di acquistare licenze per Windows XP per soli 5,00 Dollari USA. Io rappresento una casa editrice senza scopo di lucro e vorremmo acquistare alcune di queste licenze. È possibile acquistarle tramite telefono o posta elettronica? Dispongo di un indirizzo di posta elettronica ma non ho accesso al Web.
—Ernest B.

È possibile contattare il partner amministrativo MAR, TechSoup, all'indirizzo communitymar@techsoup.org o chiamando il numero 800-659-3579 x350. È inoltre possibile scrivere a: Community MAR Administrator, TechSoup Stock, 435 Brannan Street 100, San Francisco, CA 94107.


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

Monitoraggio dei sistemi di rete
Network Monitor di ActiveXperts
activexperts.com
Quando si verifica un evento insolito, per gli amministratori di sistema è importante esserne informati prima che gli utenti inizino a chiedere insistentemente spiegazioni. Il monitoraggio dei servizi è uno strumento chiave per la gestione proattiva dell'infrastruttura. ActiveXperts Network Monitor è una soluzione efficace, con molti controlli che è possibile estendere sia alle reti LAN/WAN che ai server Windows®, Novell e *NIX in modo da ottenere notifiche relative agli eventuali problemi insorti prima che le notifiche arrivino dagli utenti.
ActiveXperts Network Monitor è un'applicazione basata su Windows che viene eseguita come servizio sul computer designato come stazione di monitoraggio; è possibile utilizzare come sistema operativo di base di tale computer Windows 2000, Windows Server® 2003, Windows XP o Windows Vista®. Una volta eseguita l'installazione, la Configurazione guidata offrirà una guida rapida per l'impostazione delle notifiche tramite posta elettronica, delle notifiche SMS e della soglia di errore e di frequenza dell'analisi predefinita. È inoltre possibile aggiungere un insieme di controlli da utilizzare come esempio nel corso del processo di configurazione. I controlli possono risultare molto utili per iniziare e apprendere le nozioni di base su come configurare le diverse funzionalità dell'applicazione in base ai requisiti dell'ambiente.
L'applicazione è suddivisa in tre componenti diversi: Network Monitor Engine è il servizio Windows che esegue continuamente le attività di monitoraggio. Network Monitor Manager è un'applicazione Windows che consente di visualizzare l'attività di monitoraggio corrente e i relativi risultati nonché di apportare modifiche alla configurazione. Un'interfaccia Web fornisce accesso in sola lettura alle attività e ai risultati delle attività.
Oltre a eseguire i controlli di monitoraggio, Network Monitor Engine è responsabile della gestione delle notifiche, delle azioni basate sui risultati e delle attività di registrazione per l'applicazione. Il motore di monitoraggio è uno strumento multithreading che garantisce la scalabilità necessaria a soddisfare le specifiche esigenze dell'ambiente. Poiché il servizio non richiede alcun agente di endpoint per eseguire i controlli di monitoraggio, sarà necessario fornire credenziali amministrative per il monitoraggio dei server o delle workstation Windows remote. Per fortuna, è possibile specificare più set di credenziali in modo che, in caso di monitoraggio in diversi domini e contesti di protezione, non sia necessario utilizzare un singolo account per l'esecuzione della soluzione di monitoraggio.
È probabile che gli utenti dedichino la maggior parte del tempo all'utilizzo dell'applicazione Network Monitor Manager, che fornisce un controllo granulare su tutte le funzionalità e le impostazioni di configurazione. In questa applicazione è possibile organizzare le attività di monitoraggio in una struttura di cartelle ad albero, consentendo di individuare e identificare in modo più rapido gli elementi in ambienti di grandi dimensioni e di filtrare la visualizzazione corrente dell'interfaccia utente per ottenere una rapida analisi di un insieme di attività di monitoraggio.
L'aggiunta di un nuovo controllo di monitoraggio è piuttosto semplice. In Network Monitor sono compresi quasi 40 controlli incorporati, tra cui controlli IP e di protocollo (come ICMP, LDAP, SMTP e HTTP), controlli Windows (come controlli a livello di CPU, processi, memoria e Terminal Server), controlli di connettività ODBC, controlli Oracle TnsPing, controlli di database basati su query OLEDB, controlli di appartenenze Novell e controlli RSH *NIX. Inoltre, è possibile monitorare i dettagli dell'ambiente, come temperatura e umidità, utilizzando in rete un dispositivo di monitoraggio ambientale SensaTronics.
L'applicazione supporta script VBScript e Remote Shell personalizzati e consente di personalizzare le attività di monitoraggio. Nell'applicazione è incluso un insieme di modelli VBScript per il monitoraggio di diversi servizi, come antivirus, Microsoft® ISA Server e query XML, quindi non è necessario riavviare il processo dall'inizio quando si creano attività di monitoraggio personalizzate.
È possibile impostare per ciascuna attività la soglia di errore e di frequenza dell'analisi, nonché pianificare l'esecuzione dei controlli a una data e un'ora specificate, ad esempio per verificare i risultati di un altro processo in esecuzione come un'attività di archiviazione dei registri o la reimpostazione di un pool di applicazioni IIS. È inoltre possibile configurare processi batch, eseguibili e script in modo che vengano eseguiti in caso di errore o ripristino di un controllo, nonché causare un riavvio o riavviare un servizio specificato. Infine, l'interfaccia Web offre una visualizzazione basata su fogli di stile XSL dei dati dei risultati XML. I fogli di stile possono essere facilmente personalizzati per la creazione di una visualizzazione personalizzata del Network Operations Center (NOC) o dei dispositivi portatili e, poiché i dati sono in formato XML, è possibile recuperarli con facilità e utilizzarli in un'altra applicazione o in un sistema di aggregazione.

Prezzo: si parte da 395 Dollari USA con acquisto diretto per una licenza che consente l'utilizzo di cinque server.
ActiveXperts Network Monitor include controlli di esempio utili per iniziare
ActiveXperts Network Monitor include controlli di esempio utili per iniziare

Recensione
Windows Vista Resource Kit
microsoft.com/mspress/books/9536.aspx
Poiché un numero sempre crescente di organizzazioni sta iniziando a integrare i client Windows Vista nelle infrastrutture, è necessario che i professionisti IT apprendano rapidamente l'utilizzo degli strumenti disponibili nel nuovo sistema operativo. Nel manuale Windows Vista Resource Kit (Microsoft Press®, 2007) pubblicato di recente, vengono descritti molti degli strumenti necessari per implementare in modo corretto i client Windows Vista nell'ambiente aziendale, con informazioni che spaziano dall'automazione dell'installazione e dell'attivazione del volume, alla gestione e manutenzione del desktop e all'utilizzo della rete IPv6 e dell'assistenza remota. Oltre alle 1.568 pagine da cui è composto, il manuale include un DVD di supporto che contiene più di 100 script per l'amministrazione e la distribuzione, un insieme di strumenti di debug, Solution Accelerator for Business Desktop Deployment (BDD) e altri elementi utili.
Dopo una panoramica delle nuove funzionalità disponibili in Windows Vista, nel manuale particolare attenzione viene posta sui miglioramenti alla protezione, come il controllo dell'account utente, Crittografia unità BitLocker e Protezione esecuzione programmi. Viene inoltre trattato il concetto di protezione avanzata e protezione contro l'applicazione di patch al kernel. Il manuale procede quindi con l'illustrazione del processo di distribuzione di Windows, esplorando i numerosi strumenti disponibili per rendere più semplice e automatico il processo. Nel libro viene, ad esempio, esaminata la configurazione di un ambiente di ripristino e preinstallazione Windows PE 2.0 e vengono forniti dettagli su BDD 2007, offrendo indicazioni su come pianificare e distribuire Windows Vista nell'ambiente aziendale. Inoltre, nel manuale vengono fornite procedure consigliate per la creazione e la configurazione di immagini disco nonché informazioni su come eseguire la migrazione dei dati degli utenti mediante Trasferimento dati Windows e Utilità di migrazione stato utente.
Viene quindi descritta nei dettagli la gestione dell'ambiente desktop tramite Criteri di gruppo, esaminando i nuovi file del modello amministrativo basati su XML (ADMX). Anche la gestione di dischi e file system è illustrata e vengono esaminati i nuovi miglioramenti ReadyBoost e BitLocker inclusi in Windows Vista. Viene inoltre descritto il funzionamento della funzionalità Versioni precedenti, delle copie shadow e delle quote disco e viene esplorato come distribuire e gestire l'Area riunioni virtuali Windows in gruppi di lavoro, domini e ambienti wireless ad-hoc.
Nella sezione relativa alla manutenzione dell'ambiente desktop vengono trattati le attività, lo strumento Segnalazioni errori Windows, il monitoraggio delle prestazioni e gli eventi di Windows. Particolare attenzione viene anche dedicata all'utilizzo di Assistenza remota da parte degli addetti al supporto tecnico. Si passa quindi alla descrizione degli aggiornamenti software, di Servizio trasferimento intelligente in background (BITS, Background Intelligent Transfer Service), di Windows Update e di altri strumenti di controllo.
Nella sezione relativa ai servizi di rete viene descritto nei dettagli il funzionamento di Windows Firewall e vengono illustrati i nuovi miglioramenti apportati allo stack di rete. L'esame dell'utilizzo di Desktop remoto e delle connessioni VPN per la configurazione di reti e utenti remoti trova uno spazio adeguato nel volume.
Infine, nel manuale viene illustrata nei dettagli la procedura per la risoluzione dei problemi, dall'avvio dalla rete agli errori dei driver e ai problemi dei dispositivi. È possibile cogliere, a volte, una certa tendenza al ricorso a termini gergali del marketing, ma il libro si segnala per l'estrema praticità con 1.500 pagine di analisi e suggerimenti utilissimi. Il manuale offre infatti un esame approfondito e completo di Windows Vista, dei relativi strumenti e della gestione del sistema operativo.

Prezzo: 59,99 Dollari USA con acquisto diretto.

Analisi del traffico HTTP
Charles Web Debugging Proxy
xk72.com/charles
Considerata la grande quantità di comunicazioni basate su HTTP tra le applicazioni e tra le workstation, i server e Internet, un analizzatore del traffico HTTP efficace rappresenta uno strumento estremamente utile per gli amministratori di sistema. Questo strumento può semplificare l'individuazione dei problemi correlati al proxy, dei rischi per la protezione, degli errori di connettività e di configurazione e dei problemi relativi alla comunicazione tra le applicazioni. Uno strumento piuttosto interessante è l'applicazione basata su Java di Karl von Randow: Charles Web Debugging Proxy.
Analogamente ad altri proxy per il debug, l'applicazione si configura come una sorta di "mediatore", poiché risiede tra le applicazioni endpoint, intercettando e interpretando il traffico che rileva. Grazie a questa configurazione, l'applicazione consente inoltre di visualizzare il traffico HTTPS crittografato in formato testo normale decrittografato. L'interfaccia utente presenta una visualizzazione ben organizzata della sessione registrata, fornendo un'ampia gamma di informazioni, che spaziano dalle richieste di base per pagine, immagini, script e fogli di stile ai dettagli specifici relativi a dimensioni, latenza e temporizzazione. È inoltre possibile verificare quali cookie vengono inviati e ricevuti in ciascuna richiesta e controllare gli elementi che questi contengono; è possibile persino scegliere di bloccare tutti i cookie contemporaneamente.
Con lo strumento Charles Web Debugging Proxy è possibile risolvere i problemi relativi alla memorizzazione delle richieste nella cache, verificando le date dell'ultima modifica nelle risposte 304 Not Modified o scegliendo di disabilitare la memorizzazione nella cache mediante la rimozione delle intestazioni correlate alla cache dalle richieste e dalle risposte pertinenti man mano che queste procedono all'interno dell'applicazione. Infatti, le impostazioni di riscrittura dell'applicazione consentono di definire un insieme di regole per la riscrittura di una serie di intestazioni HTTP o del contenuto del corpo man mano che le richieste e le risposte procedono all'interno dell'applicazione. In alternativa, è possibile utilizzare le impostazioni di spoofing DNS dell'applicazione per sovrascrivere l'indirizzo IP di un host, consentendo di testare le richieste inviate agli elementi che potrebbero non essere registrati in DNS. Questa caratteristica è particolarmente utile per il test, ad esempio, di un nuovo server Web per verificare se è in ascolto e risponde in modo corretto all'intestazione host prima di attivarlo.
È possibile inoltre utilizzare lo strumento per eseguire il debug delle richieste e delle risposte AJAX e per esaminare i dati XML non elaborati all'interno della risposta. Nell'interfaccia utente è possibile persino visualizzare all'interno del testo i dati di richieste e risposte non elaborati per semplificare l'individuazione di eventuali intestazioni insolite.
Lo strumento è dotato di due layout di dati molto interessanti, che forniscono informazioni importanti sulla transazione dei dati: la tabella Summary e la tabella Chart. La tabella Summary consente di analizzare rapidamente i dati di richieste/risposte, mostrando le dimensioni delle intestazioni, le dimensioni del corpo, il tempo di risposta, il codice della risposta, il tipo MIME e la risorsa. Nella tabella Chart viene invece fornita una rappresentazione grafica della sequenza temporale del ciclo di vita che mostra il punto della sequenza in cui si trovavano i dati di richieste/risposte e il tempo necessario per la transazione.
È possibile salvare le sessioni di registrazione per consentirne la riesecuzione e l'analisi in un momento successivo. Questo può risultare utile per acquisire il complesso flusso di richieste/risposte che causa errori sporadici di comunicazione; una volta acquisito il flusso, è possibile riprodurlo. È possibile inoltre importare file di traccia HTTP in una nuova sessione ed esportare la sessione corrente nel formato di file di traccia CSV o HTTP.
Per simulazioni di richieste in contesti con larghezza di banda limitata, ad esempio, per determinare il motivo per cui una richiesta ha esito negativo in una linea modem a 56 K ma non nella rete aziendale, l'applicazione prevede una funzionalità di regolazione della larghezza di banda che consente di scegliere tra un insieme di impostazioni predefinite comuni o di definire una nuova impostazione predefinita in base a quattro livelli di regolazione: larghezza di banda, utilizzo in percentuale, latenza di andata e ritorno e unità massima di transizione. È inoltre possibile configurare il proxy di debug come proxy inverso o come server di inoltro alla porta, associando una porta locale a un endpoint (e una porta) remoti in modo che tutto il traffico inviato a tale porta venga reindirizzato all'indirizzo remoto.

Prezzo: si parte da 50 Dollari USA con acquisto diretto per licenza di un singolo utente.
Analisi del traffico di rete tramite Charles Web Debugging Proxy
Analisi del traffico di rete tramite Charles Web Debugging Proxy

Eliminazione dei file non necessari
Wise Disk Cleaner 2
wisecleaner.com
Un disco rigido può essere paragonato a una casa, in cui nel corso del tempo si accumulano tanti oggetti, spesso del tutto inutili. Ogni tanto, è opportuno dedicare un po' di tempo alle pulizie. Sono disponibili alcuni metodi standard per la pulizia di un disco rigido tra gli strumenti Windows incorporati, come l'utilità di sistema, Pulizia disco, e la funzionalità di ricerca. Tuttavia, talvolta un'utilità rapida e di facile utilizzo rappresenta il metodo ideale, in particolare quando è possibile ottenerla gratuitamente. Uno strumento di questo tipo è Wise Disk Cleaner 2, che consente di eseguire una ricerca nei dischi rigidi per individuare tutti i file non necessari che possono essere rimossi in tutta sicurezza dal sistema.
Un aspetto molto interessante di questo strumento è rappresentato dalla capacità di visualizzare in tempo reale tutti i file individuati nell'interfaccia utente, semplificando il rilevamento di potenziali problemi. Un'altra funzionalità utile è rappresentata dalla possibilità di aggiungere ulteriori criteri di file da controllare e rimuovere. Wise Disk Cleaner consente inoltre di cancellare, se necessario, i file Internet temporanei ed è possibile scegliere di conservare i cookie in modo da non perdere le preferenze del sito memorizzate in tali file. È inoltre possibile rimuovere i file di disinstallazione di Windows Update e cancellare il codice sorgente di Windows Update, l'elenco degli ultimi file utilizzati e le cartelle temporanee degli utenti e di Windows. È possibile persino eseguire automaticamente l'applicazione, con la possibilità di scegliere di eliminare gli elementi in modo permanente o semplicemente di spostarli nel Cestino. L'applicazione è in grado inoltre di registrare le relative attività in modo da consentirne la revisione: niente male per uno strumento gratuito.

Prezzo:gratuito.
Rilevamento dei file che è possibile eliminare in sicurezza tramite Wise Disk Cleaner 2
Rilevamento dei file che è possibile eliminare in sicurezza tramite Wise Disk Cleaner 2

Gestione dei dispositivi di rete
iReasoning Networks MIB Browser Personal Edition
ireasoning.com/mibbrowser.shtml
Se nell'infrastruttura sono presenti dispositivi di rete, applicazioni o sistemi abilitati per SNMP (Simple Network Management Protocol), iReasoning Networks MIB Browser consente di caricare un insieme di file MIB (Management Information Base) e di esplorare la struttura gerarchica tramite una visualizzazione molto simile alla visualizzazione di Esplora risorse. Nella struttura gerarchica è possibile visualizzare i dettagli dell'oggetto selezionato, compresi l'identificatore di oggetto (OID), la sintassi, l'accesso in lettura/scrittura e la descrizione.
È possibile inviare facilmente una richiesta SNMP per recuperare i dati da un dispositivo di rete tramite l'interfaccia utente. È sufficiente immettere l'indirizzo IP del dispositivo, selezionare l'oggetto MIB e fare clic su Go. Se necessario, è inoltre possibile impostare la porta, la versione della richiesta SNMP e le stringhe di community di lettura e scrittura. La modifica di un agente è un'operazione altrettanto semplice (supponendo che il dispositivo in uso consenta tale modifica). Selezionare l'identificatore di oggetto, il tipo di dati e il valore, quindi fare clic su OK. È disponibile inoltre un'utilità incorporata Trap Sender e Trap Receiver che consente di creare trap e analizzare le operazioni di trap (a cui è possibile applicare filtri per semplificare la visualizzazione del dispositivo in questione).
iReasoning Networks MIB Browser Personal Edition è uno strumento gratuito ma non fornisce il supporto per SNMPv3 ed è limitato al caricamento simultaneo di cinque MIB. Se possibile, prendere in considerazione l'acquisto della Professional Edition (con un costo di 269 Dollari USA con acquisto diretto per licenza) che include funzionalità aggiuntive e fornisce il supporto per SNMPv3, l'individuazione rete e il confronto tra dispositivi.

Prezzo:gratuito.
iReasoning Networks MIB Browser
iReasoning Networks MIB Browser

Greg Steen è un professionista IT oltre a essere un appassionato costantemente alla ricerca di nuovi strumenti e metodi che consentano di semplificare le operazioni e il processo di sviluppo per i professionisti IT.


 Domande e risposte su SQL: Configurazione della memoria, profiling delle prestazioni, impostazione del fattore di riempimento e altro
Domande e risposte su SQL
Configurazione della memoria, profiling delle prestazioni, impostazione del fattore di riempimento e altro
A cura di Nancy Michell

Configurazione della memoria
Suggerimento: profiling più semplice
Ora è possibile mettere in correlazione PerfMon con SQL Server 2005 Profiler.
Durante l'esecuzione di Performance Monitor sul computer SQL Server è probabile che si siano notati picchi di utilizzo della CPU, un consumo eccessivo della memoria o una riduzione delle prestazioni globali e che non si sia riusciti a capire la causa di queste anomalie. Prima del rilascio di SQL Server 2005, una situazione di questo tipo prevedeva l'utilizzo di Profiler per acquisire una traccia, l'analisi dei sysprocesses in Enterprise Manager e infine acquisizione dei registri di Performance Monitor, che richiedeva ovviamente l'avvio di PerfMon. Dopo aver utilizzato tutti questi strumenti, era comunque necessario riconciliare manualmente gli eventi tra gli strumenti per individuare la causa della riduzione delle prestazioni. Il processo richiedeva l'analisi di ogni singolo registro. Non era un'operazione divertente, ma era necessaria per individuare l'origine dei problemi di prestazioni.
Con SQL Server 2005, è ancora necessario acquisire una traccia ed esaminare i registri PerfMon, ma Profiler ora consente di correlare i registri. È possibile scorrere le istruzioni T-SQL e in Profiler verrà automaticamente visualizzata una rappresentazione grafica degli eventi che si sono verificati. Se si fa clic sull'interfaccia utente di Performance Monitor in Profiler, sarà possibile accedere all'istruzione correlata al timestamp. Questo consente di ridurre notevolmente i tempi per la risoluzione dei problemi correlati all'ambiente SQL Server.
Di seguito è riportata la procedura per correlare i registri PerfMon a Profiler:
  1. Avviare Performance Monitor e iniziare ad acquisire informazioni dal server di database.
  2. Creare un nuovo registro contatori in Avvisi e registri di prestazioni, quindi immettere un nome per il nuovo registro.
  3. Aggiungere i nuovi contatori, ad esempio % Tempo processore. È possibile impostare la registrazione in modo che venga avviata manualmente o automaticamente in base a una pianificazione utilizzando la scheda Pianificazione.
  4. Fare clic su OK e, se si è scelto di impostare l'opzione manuale, avviare la registrazione.
  5. Configurare una traccia in SQL Server tramite Profiler. A tal fine, scegliere Nuova traccia dal menu File. Includere StartTime ed EndTime nella traccia, quindi assegnare un nome alla traccia e salvarla in un file. Infine, è necessario avviare il server per simulare alcune attività di transazione, quindi interrompere l'acquisizione dei dati di Performance Monitor e Profiler.
  6. In Profiler, scegliere Importa dati prestazioni dal menu File. Selezionare il percorso in cui si è memorizzato il registro PerfMon e selezionare File | Apri | Traccia. Infine, selezionare il percorso in cui si è memorizzata la traccia di Profiler.
Al termine, si scoprirà quanto sia semplice determinare l'impatto che istruzioni SQL specifiche hanno avuto sui tempi di elaborazione.

D Sto cercando di scoprire quale sia la migliore configurazione della memoria per i miei computer SQL Server™. L'amministratore che mi ha preceduto ha impostato il file Boot.ini per ciascun computer con 12 GB di RAM su un cluster a due nodi SQL Server 2000, come descritto di seguito: Yes /PAE NO /3GB (No AWE set for SQL Server). Con 12 GB di RAM disponibili, è necessario rimuovere l'opzione /3GB in Boot.ini, attivare AWE e dedicare a SQL Server circa 10 GB dei 12 GB? Nei computer che eseguono SQL Server non sono disponibili altre applicazioni e pertanto non è necessario aggiungere ulteriore memoria.
R Sì, è consigliabile attivare la funzionalità AWE (Address Windowing Extensions) e preallocare un limite superiore di RAM per SQL Server; 10 GB sembrano sufficienti su un computer SQL Server dedicato con 12 GB di RAM. La preallocazione è valida solo per SQL Server 2000. A partire da SQL Server 2005, l'utilizzo di AWE non è più statico e può essere modificato in tempo reale. È da sempre vivo un forte dibattito tra gli esperti del settore circa la necessità di utilizzare contemporaneamente le opzioni /3GB e /PAE o solo l'opzione /PAE obbligatoria. Sebbene in realtà sia necessario solo impostare l'opzione /PAE e attivare la funzionalità AWE, è consigliabile utilizzare entrambe le opzioni; in tal caso, tuttavia, è necessario prendere in considerazione alcuni fattori.
Se si prevede di utilizzare l'opzione /3GB, occorre determinare soprattutto se l'opzione è necessaria nella situazione specifica. La memoria nell'area MemToLeave compresa nei primi 2 o 3 GB dello spazio degli indirizzi virtuali è esaurita? Se si attiva l'opzione, la memoria destinata al sistema operativo non è sufficiente? Per ulteriori informazioni , visitare il sito support.microsoft.com/kb/316739. Se si utilizza un cluster, è possibile impostare /3GB su un solo nodo e non sull'altro. In tal modo, quando si esegue il processo di test con l'opzione /3GB e si verificano dei problemi, è possibile eseguire rapidamente il failover dell'istanza sull'altro nodo. È bene ricordare che, se si dispone di più di 16 GB di RAM, l'opzione /3GB non è supportata.
L'utilizzo dell'opzione /3GB determina un incremento del 50% dello spazio degli indirizzi virtuali (VAS, Virtual Address Space) e questo rappresenta un enorme vantaggio, non solo per la cache dati, ma anche per le applicazioni che fanno un uso estensivo della memoria disponibile nello spazio di indirizzi virtuali. Per fortuna, i server a 64 bit, IA64 e x64, eliminano questo fattore di confusione. Le considerazioni relative all'insufficienza della memoria destinata al sistema operativo non sono applicabili se il computer è dedicato a SQL Server. Anche una base di 2 GB per il sistema operativo deve essere considerata eccessiva; se questo server è dedicato a SQL Server ed esegue solo i servizi standard minimi del sistema operativo, sul server saranno disponibili circa 1,3 GB di memoria e si potrà pertanto destinare anche questa quantità aggiuntiva a SQL Server. Iniziando con 10 GB, utilizzare PerfMon per monitorare la memoria disponibile per un lungo periodo di tempo in modo da controllare per quanto tempo resta inattiva, quindi modificarla di conseguenza. Se si esegue l'overcommit della memoria in SQL Server 2000, si verificherà uno swapping, dal momento che la funzionalità AWE non è tanto dinamica quanto in SQL Server 2005. Pertanto la chiave per decidere se utilizzare o meno /3GB consiste nel testare l'opzione nello specifico ambiente in uso.

Nomi di istanza per la replica
D Ora è possibile utilizzare l'indirizzo IP del server in uso in Replica di SQL Server 2005 per indicare quale istanza replicare? In SQL Server 2000, in base all'articolo "Come eseguire la replica tra computer che eseguono SQL Server in domini non trusted o su Internet" (support.microsoft.com/kb/321822), l'esecuzione di questa operazione può causare la generazione di errori, ma non so se questo accade ancora.
R Quando si specificano istanze del server da includere nel processo di replica, è necessario fornire il nome dell'istanza registrato di SQL Server. Ad esempio, è necessario utilizzare il nome dell'istanza di SQL Server quando si specifica il parametro Publisher o Subscriber per le stored procedure di replica o le impostazioni di connessione per gli agenti di replica nella riga di comando. Se il nome di rete per l'istanza di SQL Server differisce dal nome dell'istanza registrato, le connessioni di replica in base agli agenti non riusciranno.
Se il nome di rete dell'istanza e il nome dell'istanza di SQL Server differiscono, valutare l'opportunità di aggiungere il nome dell'istanza di SQL Server come nome di rete valido. Un metodo per impostare un nome di rete alternativo consiste nell'aggiungerlo al file degli host locale. Il file degli host locale risiede per impostazione predefinita in WINDOWS\system32\drivers\etc o WINNT\system32\drivers\etc. Se, ad esempio, il nome del computer è comp1, l'indirizzo IP del computer è 10.193.17.129 e il nome dell'istanza è inst1/instname, aggiungere la seguente voce al file degli host:
10.193.17.129 inst1

SQL Server Integration Services
D Sto installando un cluster attivo/attivo per SQL Server 2005 (Enterprise Edition a 64 bit con due server) e dispongo di un numero totale di quattro istanze di SQL Server 2005. È necessario utilizzare SQL Server Integration Services (SSIS) per tutte le istanze. Come si esegue il clustering di SSIS e qual è l'effetto di questa operazione sui piani di manutenzione?
R Sebbene sia possibile eseguire il clustering del servizio SSIS, questa operazione non è necessaria e la relativa esecuzione può determinare l'insorgenza di una serie di problemi, tra cui la mancanza di supporto per la delega (visitare il sito msdn2.microsoft.com/aa337083) e per le istanze multiple, ovvero sarà possibile eseguire su un nodo una sola istanza per volta.
In precedenza, per eseguire la Creazione guidata piano di manutenzione non era necessario che il servizio SSIS fosse in esecuzione ma solo che venisse installato. Tuttavia, questo non avviene in SQL Server 2005 SP1. Se il servizio SSIS non è in esecuzione, i piani di manutenzione possono essere eseguiti da SQL Server Agent.
Anziché eseguire il clustering di SSIS, eseguire questa applicazione come servizio autonomo e modificare il file MsDtsSrvr.ini.xml in modo che faccia riferimento a tutte le istanze in esecuzione. In tal modo, sarà possibile gestire i pacchetti da qualsiasi nodo e fornire la disponibilità elevata richiesta dalla maggior parte dei clienti senza dover far fronte a tutti i problemi associati al clustering del servizio.
Per ulteriori informazioni sulla creazione non riuscita dei piani di manutenzione, consultare l'articolo della Knowledge Base all'indirizzo support.microsoft.com/kb/909036.

Tempi di esecuzione anomali
D Durante l'esecuzione del test del carico sul computer SQL Server 2005 SP1, SQL Server Profiler ha registrato molti valori negativi relativi al tempo di esecuzione delle stored procedure (SP, Stored Procedure) e in alcuni casi non esisteva alcuna corrispondenza tra il tempo di esecuzione SP e il risultato derivante dalla sottrazione dell'ora di inizio dall'ora di fine.
D Molti fattori possono influire sui report relativi al tempo di esecuzione SP e ad altri tempi di prestazioni in SQL Server Profiler. In SQL Server 2005 vengono utilizzati i millisecondi per conteggiare il tempo di esecuzione e, se si utilizzano tecnologie che modificano l'unità di misura, si otterranno report incoerenti e tempi di esecuzione piuttosto anomali.
Se, ad esempio, si utilizzano combinazioni per il risparmio energia, stepping di CPU o la tecnologia AMD Cool 'n Quiet si ottiene una modifica delle frequenze della CPU che, quindi, non corrisponderanno al risultato previsto in SQL Server Profiler durante il calcolo del tempo di esecuzione.
È disponibile un articolo della Knowledge Base all'indirizzo support.microsoft.com/kb/931279 in cui vengono illustrati i sintomi, una serie di cause e alcuni rimedi.
Suggerimento: controllare il fattore di riempimento
Si supponga di versare dell'acqua in un bicchiere completamento pieno. Cosa succede? L'acqua fuoriesce.
Lo stesso accade in SQL Server. Ogni volta che una nuova riga viene aggiunta a una pagina di indice completa, in SQL Server circa metà delle righe viene spostata in una nuova pagina per fare posto alle nuove. Questo processo è noto come divisione di pagina. Le divisioni di pagina consentono di creare spazio per nuovi record, ma sono notevolmente dispendiose in termini di tempo e risorse. Possono inoltre causare la frammentazione che influisce negativamente sulle operazioni di I/O. Come è possibile evitarle?
Per evitare situazioni di questo tipo, è necessario determinare in modo proattivo il valore del fattore di riempimento. Quando un indice viene creato o ricreato, il valore del fattore di riempimento determina la percentuale di spazio in ciascuna pagina al livello foglia che deve essere occupata dai dati, riservando lo spazio rimanente all'espansione futura. Se, ad esempio, si configura un valore del fattore di riempimento pari a 60, il 40% di ciascuna pagina al livello foglia verrà lasciato vuoto per consentire l'espansione dell'indice man mano che si aggiungono dati alla tabella sottostante.
Il fattore di riempimento predefinito è sempre impostato su 0, un valore appropriato per la maggior parte delle situazioni. In sostanza, un fattore di riempimento pari a 0 indica che la capacità del livello foglia è quasi esaurita, ma parte dello spazio viene riservato per l'inserimento di almeno una riga di indice aggiuntiva (i valori del fattore di riempimento 0 e 100 sono simili).
È possibile impostare il valore del fattore di riempimento per singoli indici durante un'istruzione CREATE INDEX o ALTER INDEX o è possibile configurare questo valore direttamente a livello di server in modo che tutti i nuovi indici creati utilizzino il valore predefinito.
Nell'esempio riportato di seguito il valore del fattore di riempimento viene impostato a livello di server su 70%, il che indica che all'espansione futura viene riservato il 30% dello spazio disponibile. Ovviamente, è necessario testare con attenzione questa opzione prima di implementarla in un ambiente di produzione.
USE Master;
GO
SP_Configure 'show advanced options',1;
GO
SP_Configure 'Fill Factor', 70;
GO
--You must restart SQL Server Engine for changes to take effect.
Se invece si desidera configurare il fattore di riempimento a livello di singolo indice? Si supponga di creare la tabella riportata di seguito e che si desideri creare un indice univoco nella colonna Col_A con un valore del fattore di riempimento pari a 70. In tal caso, si utilizzerà un comando simile al seguente:
--Create an Item table
USE Item_DB;
GO
CREATE TABLE ITEM (Col_A Varchar(100),Col_b Varchar(200));
GO;

--Create a unique index on colum Col_A of Item table with a Fill Factor value of 70
CREATE UNIQUE INDEX AK_Index ON Item (Col_A)
WITH (FillFactor = 70);
GO
Come è possibile identificare il fattore di riempimento per ciascun indice? È possibile eseguire una query in sys.Indexes per ottenere il valore del fattore di riempimento per tutti gli indici di un database, come illustrato di seguito:
USE Item_DB;
GO
SELECT Fill_Factor FROM Sys.Indexes WHERE Object_id=object_id('item') AND name IS NOT NULL;
GO


 Utilit&#224; in primo piano: Microsoft Security Assessment Tool
Utilità in primo piano
Microsoft Security Assessment Tool
Lance Whitney
Scarica il codice per questo articolo: Microsoft Security Assessment Tool 3.0 (solo in inglese) (10547.2KB)

Individuare i problemi di protezione in rete può essere difficile e costoso. Uno strumento che può aiutare a individuare e risolvere i rischi di protezione è Microsoft® Security Assessment Tool (MSAT), un'utilità gratuita con un questionario elettronico in cui descrivere il proprio ambiente di protezione. Progettato per le medie imprese con un numero di computer compreso tra 50 e 500, MSAT pone 172 domande organizzate in categorie diverse, fornisce quindi un'analisi della situazione e alcuni consigli su come migliorarla.
MSAT inizia ponendo una serie di domande sul modello aziendale, che vengono quindi utilizzate per creare un Business Risk Profile (BRP) che valuta il rischio di protezione rispetto alla media del settore in cui si opera. Per completare l'intero questionario sono in genere necessarie due ore ed è possibile interrompere la compilazione per riprenderla in qualsiasi momento in seguito. Di seguito sono illustrate le categorie con domande di esempio:
Informazioni di base Quanti client e server sono presenti nell'organizzazione?
Protezione dell'infrastruttura Alcuni dei dipendenti lavorano in modalità remota? Alla rete accedono anche consulenti esterni e terzisti?
Protezione delle applicazioni L'azienda sviluppa applicazioni? Vengono archiviati dei dati riservati elaborati dalle applicazioni?
Protezione delle operazioni La rete aziendale è connessa a reti esterne? L'organizzazione riceve dati da parti esterne?
Protezione dalle persone L'azienda ha assegnato la manutenzione dei computer a collaboratori esterni? Ai dipendenti è consentito scaricare dati riservati dell'azienda sulle proprie workstation?
Ambiente Quanti sono i dipendenti dell'organizzazione? Il tasso di ricambio degli addetti al reparto IT è molto alto?
Quindi il MSAT genera una valutazione in cui si utilizza un'unità di misura denominata Defense-in-Depth Index (DiDI), che si riferisce in particolare ai processi di protezione adottati. Utilizzando le medesime categorie, le domande tipiche sono: nell''organizzazione è installato un firewall su ciascuna postazione? Si utilizzano delle macro personalizzate nelle applicazioni di Microsoft Office? Gli utenti godono di diritti amministrativi sulle proprie workstation? È stato stabilito un criterio per la distribuzione di patch e aggiornamenti sui computer dell'organizzazione?
Dopo aver raccolto le risposte, MSAT produce tre report. Il Summary Report in cui è riportato un grafico a barre con i risultati. Un punteggio alto nel BRP indica un rischio maggiore, mentre un punteggio alto nel DiDI rappresenta una migliore protezione. Nei risultati di MSAT, se punteggi bassi di BRP e alti di DiDI sono senza dubbio da preferire, è molto più importante esaminare le singole aree. Così, per ciascuna area, in Complete Report viene specificato se sono rispettate le procedure consigliate, se è necessario apportare dei correttivi o se mancano del tutto le procedure necessarie (vedere la Figura 1).
Figura 1 Il report completo
Figura 1 Il report completo
Infine, con il Comparison Report si chiede di caricare i risultati in modo anonimo su un sito Web MSAT protetto, dove è possibile paragonare i propri risultati a quelli di altre organizzazioni.
È possibile scaricare lo strumento dal sito Web Microsoft Security Guidance all'indirizzo securityguidance.com o dal sito Web di TechNet Magazine all'indirizzo technetmagazine.com/code07.aspx.

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


 The Cable Guy: Server dei criteri di rete (Network Policy Server)
The Cable Guy
Server dei criteri di rete (Network Policy Server)
Joseph Davies
Questo articolo si basa su una versione provvisoria di Windows Server 2008. Tutte le informazioni riportate sono soggette a modifica.

Il servizio Server dei criteri di rete (NPS, Network Policy Server) in Windows Server 2008 sostituisce Servizio autenticazione Internet (IAS, Internet Authentication Service) utilizzato in Windows Server 2003. NPS consente a un computer che utilizza Windows Server 2008 di agire da server e proxy di Remote Authentication Dial-in User Service (RADIUS). RADIUS è un protocollo Internet Engineering Task
Force (IETF) specificato nelle RFC 2865 e 2866 che garantisce autenticazione, autorizzazione e accounting (AAA) centralizzati per i dispositivi di accesso alla rete, come i punti di accesso wireless. I server RADIUS eseguono le operazioni di AAA per i dispositivi di accesso alla rete. I proxy RADIUS inoltrano messaggi RADIUS tra i client RADIUS (i dispositivi di accesso alla rete) e i server RADIUS.
I miglioramenti di NPS per facilitare la distribuzione dell'accesso autenticato alla rete, garantire l'estendibilità per i componenti di terze parti e supportare le tecnologie e le piattaforme di rete più recenti sono molteplici. Il nuovo snap-in NPS è illustrato nella Figura 1.
Figura 1 Il nuovo snap-in NPS
Figura 1 Il nuovo snap-in NPS

Funzionalità di Server dei criteri di rete
In questo articolo verranno illustrate le funzionalità di NPS che non erano disponibili nelle versioni precedenti di Windows®. La prima è Protezione accesso alla rete che consente di applicare dei requisiti di integrità alla rete, quindi si passerà alla gestione, alla configurazione, al supporto di IPv6 e agli altri argomenti. Verranno inoltre descritte le funzionalità del nuovo snap-in NPS.
Protezione accesso alla rete Protezione accesso alla rete, introdotto con Windows Server® 2008, consiste in una serie di nuove tecnologie che consentono di applicare dei requisiti di conformità per l'integrità dei computer, al fine di ottenere una migliore protezione dell'intranet. I criteri di integrità possono prevedere, ad esempio, che deve essere installato e attivato un firewall e che su tutti i client che si connettono alla rete devono essere installati gli aggiornamenti più recenti del sistema operativo. Con Protezione accesso alla rete è possibile creare criteri personalizzati per la certificazione dell'integrità dei computer prima di consentire l'accesso alla rete o la comunicazione, aggiornare automaticamente i computer per garantire una conformità costante e confinare i computer non conformi su una rete limitata fino a che non tornano conformi. Per ulteriori informazioni, vedere microsoft.com/nap.
In una distribuzione di Protezione accesso alla rete, il server NPS è un server criteri di integrità Protezione accesso alla rete che valuta l'integrità dei client di Protezione accesso alla rete per conto dei punti di imposizione Protezione accesso alla rete, come le Autorità registrazione integrità (HRA), i punti di accesso 802.1X, i server della rete privata virtuale (VPN) e i server del protocollo DHCP. Il server NPS determina inoltre se ai client deve essere concesso un accesso pieno o limitato all'intranet. I criteri di rete, i criteri di integrità e le impostazioni di Protezione accesso alla rete determinano il comportamento di valutazione dell'integrità per NPS.
Supporto dei criteri EAPHost ed EAP NPS supporta EAPHost, la nuova architettura per i metodi di autenticazione dell'Extensible Authentication Protocol (EAP). La nuova architettura consente ai fornitori di metodi EAP di sviluppare e installare facilmente nuovi metodi EAP per 802.1X o autenticazioni basate sul protocollo point-to-point (PPP) su server NPS e computer client.
EAPHost supporterà l'installazione e l'uso di tutti i metodi EAP riportati nel Registro di sistema EAP all'indirizzo www.iana.org/assignments/eap-numbers, oltre agli altri metodi di autenticazione più diffusi come il Lightweight EAP (LEAP) di Cisco Systems. EAPHost consente di utilizzare contemporaneamente più implementazioni del metodo EAP. Ad esempio, è possibile installare e scegliere la versione Microsoft e la versione di Cisco Systems di Protected EAP (PEAP).
Per i fornitori di metodi EAP, EAPHost supporta i metodi EAP già sviluppati per Windows XP e Windows Server 2003, oltre a modalità semplificate di sviluppo di nuovi metodi EAP per Windows Vista® e il Windows Server 2008. Dopo l'installazione, è possibile configurare i metodi EAP necessari per un determinato scenario di accesso alla rete in un criterio di rete. Un criterio di rete per NPS equivale a un criterio di accesso remoto per IAS.
Per ulteriori informazioni sull'architettura EAPHost, vedere technetmagazine.com/issues/2007/05/CableGuy.
Configurazione memorizzata in formato XML IAS memorizzava le informazioni di configurazione in un database Jet. Ora NPS memorizza le informazioni di configurazione in formato XML, facilitando l'esportazione della configurazione di un server NPS e l'importazione in un altro server. L'importazione ed esportazione dei file di configurazione è uno dei metodi utilizzabili per la sincronizzazione delle impostazioni di più server NPS in una configurazione a tolleranza d'errore. È possibile esportare la configurazione NPS con il comando netsh nps export e importarla con il comando netsh nps import.
Conformità ai Common Engineering Criteria NPS è stato aggiornato in modo da supportare la distribuzione in ambienti che devono soddisfare i criteri Microsoft® Common Engineering Criteria (CEC). Per ulteriori informazioni, vedere microsoft.com/windowsserversystem/cer/allcriteria.mspx.
DLL di estensione NPS solide Il servizio NPS può essere esteso con DLL di estensione e autorizzazione. Al contrario di IAS, questi componenti di terze parti vengono gestiti in sandbox di NPS in modo che gli eventuali problemi che si verificano non influiscano sul funzionamento o sull'esecuzione del servizio NPS.
Supporto di IPv6 NPS supporta IPv6 e la distribuzione in ambienti IPv6 nativi o con tunnel. È possibile configurare gli indirizzi IPv6 per i client RADIUS o i server RADIUS remoti e il servizio NPS può comunicare tramite IPv6 per le operazioni di autenticazione e autorizzazione degli account dei servizi di dominio Active Directory®.
IAS a confronto con NPS
Se si conosce già bene lo snap-in IAS per Windows Server 2003, si apprezzeranno le seguenti modifiche apportate allo snap-in NPS:
  • I criteri di accesso remoto sono diventati criteri di rete e sono stati spostati sotto il nodo Criteri.
  • Il nodo Client RADIUS è stato spostato sotto il nodo Client e server RADIUS.
  • Non esiste più un nodo Elaborazione richiesta di connessione. Il nodo Criteri richiesta di connessione è stato spostato sotto Criteri e il nodo Gruppi di server RADIUS remoti è stato spostato sotto Client e server RADIUS.
  • Le impostazioni delle condizioni dei criteri di accesso remoto e del profilo sono state riorganizzate sulle schede Panoramica, Condizioni, Vincoli e Impostazioni per le proprietà di un criterio di rete.
  • Le impostazioni delle condizioni dei criteri di richiesta di connessione e del profilo sono state riorganizzate sulle schede Panoramica, Condizioni e Impostazioni per le proprietà di un criterio di richiesta di connessione.
  • Nella cartella Registrazione Accesso remoto è stato rinominato il nodo Accounting e non esistono più i nodi File locale o SQL ServerTM.

Generazione automatica di segreti condivisi RADIUS complessi I segreti condivisi RADIUS vengono utilizzati per verificare che i messaggi RADIUS vengano inviati da un client, server o proxy RADIUS configurato con il medesimo segreto condiviso. I segreti condivisi vengono inoltre utilizzati per crittografare alcuni attributi RADIUS riservati, come password e chiavi di crittografia. I segreti condivisi RADIUS complessi sono una lunga (più di 22 caratteri) sequenza di lettere, numeri e simboli di punteggiatura casuali.
Con lo snap-in NPS, è possibile generare automaticamente un segreto condiviso RADIUS complesso quando si aggiunge o si modifica un client RADIUS. Il segreto condiviso RADIUS complesso può essere copiato in un editor di testo, come Blocco Note, quindi è possibile configurare il dispositivo di accesso alla rete o il punto di imposizione Protezione accesso alla rete con lo stesso segreto condiviso.
Integrazione con Server Manager È possibile installare NPS con gli strumenti Attività di configurazione iniziale o di Server Manager. In entrambi i casi si installa NPS con il ruolo Servizi di accesso e criteri di rete. Per iniziare, sotto Personalizzazione del server nello strumento Attività di configurazione iniziali, fare clic sull'opzione l'opzione Aggiungi ruoli. Nello strumento Server Manager aprire Riepilogo ruoli e fare clic su Aggiungi ruoli.
Dopo aver installato NPS, è possibile fare clic su Servizi di accesso e criteri di rete sotto il nodo Ruoli nella struttura console di Server Manager per verificare lo stato del servizio NPS e visualizzare gli eventi di errore che si sono verificati nelle ultime 24 ore. Quando si espande il nodo Servizi di accesso e criteri di rete nella console, è possibile configurare NPS con lo snap-in NPS.
Supporto di netsh migliorato La serie di comandi di Windows Server 2003 nel contesto netsh aaaa per la configurazione di IAS era limitata. In Windows Server 2008 il nuovo contesto netsh nps prevede una serie estesa di comandi per la configurazione di NPS da riga di comando o tramite uno script. Con i comandi netsh nps è possibile configurare i client RADIUS e i server RADIUS remoti, i criteri di rete, la registrazione e, per Protezione accesso alla rete, i criteri di integrità, le convalide dell'integrità del sistema e i gruppi server di monitoraggio e aggiornamento. Gli script costituiti da comandi nel contesto netsh nps rappresentano un metodo alternativo per sincronizzare le impostazioni di più server NPS in una configurazione a tolleranza di errore.
Tag origine per l'isolamento dei criteri di rete I criteri di rete possono essere configurati per un tipo specifico di server di accesso alla rete o di punto di imposizione Protezione accesso alla rete, come un server DHCP o un HRA, che diventa un tag origine che classifica i criteri di rete. I server di accesso basati su Windows Server 2008 e i punti di imposizione Protezione accesso alla rete contengono questo tag origine nei rispettivi messaggi RADIUS. Quando viene ricevuto un messaggio RADIUS che richiede l'accesso, il servizio NPS tenta di trovare un criterio di rete corrispondente con il medesimo tag origine del messaggio in arrivo. Se non viene rilevato alcun criterio corrispondente, NPS tenta di trovare un criterio di rete corrispondente per i criteri senza alcun tag origine specificato.
L'utilizzo del tag origine in criteri di rete e messaggi RADIUS in entrata consente di isolare i diversi tipi di criteri di rete uno dall'altro. I criteri di rete per i server DHCP, ad esempio, non vengono utilizzati per le connessioni VPN.
Integrazione con il controllo di accesso alla rete di Cisco NPS supporta alcune funzionalità per facilitare l'integrazione in un ambiente che utilizza hardware Cisco e il Network Access Control (NAC). Tali funzionalità prevedono il supporto per Host Credential Authorization Protocol (HCAP) e le condizioni HCAP, la condizione di scadenza dei criteri e l'impostazione di stato esteso di Protezione accesso alla rete nei criteri di rete.
Nuove condizioni dei criteri di rete Esistono nuove condizioni per i criteri di rete in NPS, progettate per specificare gruppi di computer, gruppi di utenti, tipi di EAP consentiti e indirizzi IPv6 di client e server di accesso. Per il supporto di HCAP, NPS è dotato di nuove condizioni per i gruppi di posizioni e i gruppi di utenti. Per il supporto di Protezione accesso alla rete, NPS è dotato di nuove condizioni dei criteri per tipo di identità, criteri di integrità, computer compatibili con Protezione accesso alla rete, sistema operativo e scadenza dei criteri.
Snap-in NPS Il nuovo snap-in NPS è stato molto migliorato, in modo che si possano creare e gestire facilmente i client RADIUS e i server RADIUS remoti, i criteri di rete per gli scenari di accesso alla rete comuni, le impostazioni di criteri di integrità e Protezione accesso alla rete per gli scenari di Protezione accesso alla rete e le impostazioni di registrazione.
Nel nodo Client e server RADIUS è possibile configurare i client RADIUS (server di accesso alla rete, punti di imposizione Protezione accesso alla rete o altri proxy RADIUS quando NPS agisce da server RADIUS) e i gruppi di server RADIUS remoti (altri server RADIUS quando NPS agisce da proxy RADIUS).
Nel nodo Criteri è possibile configurare i criteri di richiesta di connessione (se il servizio di NPS agirà da server o proxy RADIUS), i criteri di rete (impostazioni e vincoli di autorizzazione e connessione quando il servizio NPS agisce da server RADIUS) e i criteri di integrità (conformità di integrità del sistema per i client di Protezione accesso alla rete). Quando si sceglie un criterio di richiesta di connessione o un criterio di rete nel riquadro dei dettagli, nello snap-in NPS vengono visualizzate le condizioni e le impostazioni del criterio. Nella Figura 2 è illustrato un esempio.
Figura 2 Lo snap-in NPS migliorato
Figura 2 Lo snap-in NPS migliorato
Nel nodo Protezione accesso alla rete il nodo Convalida integrità sistema consente di configurare i requisiti di integrità di Protezione accesso alla rete. Il nodo Gruppi server di monitoraggio e aggiornamento consente di configurare la serie di server a cui possono accedere i client limitati di Protezione accesso alla rete per i metodi di imposizione di Protezione accesso alla rete di VPN e DHCP. Infine, nel nodo Accounting, è possibile configurare le modalità di memorizzazione delle informazioni di accounting di NPS.
Lo snap-in NPS è dotato di una serie completa di procedure guidate per automatizzare la configurazione iniziale dei client RADIUS e dei criteri necessari per i metodi di imposizione di Protezione accesso alla rete, le connessioni di accesso remoto o basate su VPN e le connessioni autenticate tramite 802.1X wireless o cablate. Per i metodi di imposizione di Protezione accesso alla rete, la procedura guidata configura automaticamente tutti i criteri di richiesta di connessione, i criteri di rete e i criteri di integrità.
È possibile accedere alle nuove procedure guidate facendo clic sul nodo NPS dello snap-in NPS. Per configurare criteri e impostazioni per i metodi di imposizione di Protezione accesso alla rete, scegliere Protezione accesso alla rete nella casella a discesa Configurazione standard e fare clic su Configurazione Protezione accesso alla rete. Per configurare criteri e impostazioni per l'accesso alla rete VPN o in remoto, scegliere Server RADIUS per connessioni remote o VPN nella casella a discesa Configurazione standard, quindi fare clic su Configurazione VPN o connessioni remote. Per configurare criteri e impostazioni per l'accesso autenticato con 802.1X wireless o cablato, scegliere Server RADIUS per connessioni wireless 802.1X o cablate nella casella a discesa Configurazione standard, quindi fare clic su Configurazione 802.1X.
Ciascuna di queste procedure guidate consente di accedere agli elementi di configurazione più comuni per gli scenari scelti. Le procedure guidate per i metodi di imposizione di Protezione accesso alla rete sono molto utili: la procedura guidata di Protezione accesso alla rete per l'imposizione di VPN crea un criterio di richiesta di connessione, tre criteri di rete (per i client di Protezione accesso alla rete conformi, per i client di Protezione accesso alla rete non conformi e per i client non compatibili con Protezione accesso alla rete) e due criteri di integrità (per i client di Protezione accesso alla rete conformi e non conformi).
Le nuove procedure guidate di Protezione accesso alla rete e le altre procedure guidate per la creazione di client RADIUS, di gruppi di server RADIUS remoti, di criteri di richiesta di connessione e di criteri di rete semplificano di molto la configurazione di NPS per gli scenari di accesso alla rete più comuni.

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


 Windows PowerShell: Approfondimenti
Windows PowerShell
Approfondimenti
Don Jones

In Windows PowerShell è disponibile una gamma completa di funzionalità, che vengono spesso trascurate dalla maggior parte degli amministratori. Tuttavia, a un'analisi più approfondita, risulterà chiaro come alcune funzionalità siano davvero interessanti. Infatti, mi è capitato spesso di scoprire nuove funzionalità associate a uno specifico cmdlet che pensavo di conoscere già.
Quando tengo i miei corsi su Windows PowerShellTM, consiglio sempre agli amministratori di creare un calendario con il cmdlet del giorno, simile al calendario con la parola del giorno. In tal modo, ogni mattina (esclusi i weekend naturalmente), possono dedicare alcuni minuti ad approfondire la conoscenza delle funzionalità complete di un cmdlet. Windows PowerShell comprende circa 130 cmdlet, il che implica che, seguendo pedissequamente il calendario, sarà possibile arrivare a conoscere praticamente tutte le funzionalità di Windows PowerShell in soli sei mesi. A quel punto, si sarà pronti per utilizzare tutti i cmdlet di Exchange Server 2007.
Nell'articolo di questo mese verranno forniti alcuni esempi delle potenzialità che è possibile scoprire e dei risultati che si possono ottenere dedicando alcuni minuti all'esplorazione delle funzionalità più nascoste di diversi cmdlet.

Report HTML dall'aspetto più accattivante
Un cmdlet non utilizzato di frequente è ConvertTo-HTML. Questo cmdlet è in grado di accettare un insieme di oggetti di input, ovvero servizi, processi, oggetti di Windows® Management Instrumentation (WMI) e così via, e di convertirli in una tabella HTML. È possibile quindi inviare la tabella HTML a Out-File ottenendo, in tal modo, una pagina HTML adatta per la pubblicazione su un server Web Intranet. È possibile, ad esempio, configurare la semplice riga di codice riportata di seguito in modo che venga eseguita ogni mattina:
Gwmi Win32_Service | Where { $_.StartMode
–eq "Auto" –and $_.State –ne "Running" } |
ConvertTo-HTML | Out-File C:\ServiceAlert.html
Si creerà così un report HTML, come quello illustrato nella Figura 1, dei servizi che devono essere avviati automaticamente ma che non sono in esecuzione.
Figura 1 Report HTML dei servizi non eseguiti
Figura 1 Report HTML dei servizi non eseguiti
È possibile, ovviamente, che si desideri creare un report dall'aspetto più accattivante. Per fortuna, il cmdlet ConvertTo-HTML cmdlet produce un report HTML pulito, ovvero non incorpora alcuna formattazione nel codice HTML creato. In base alle regole HTML, è preferibile evitare di inserire un'eccessiva formattazione nel codice HTML. È consigliabile invece inserire la formattazione in un foglio di stile CSS esterno e collegare CSS al report HTML. Si può creare tale collegamento mediante il cmdlet ConvertTo-HTML.
Il foglio di stile CSS viene collegato alla sezione <HEAD> di un file HTML. Esaminando le informazioni della Guida relative al cmdlet ConvertTo-HTML, si noterà che la sintassi include alcuni parametri che potrebbero essere stati trascurati:
ConvertTo-Html [[-property] <Object[]>]
[-inputObject <psobject>] [-body <string[]>]
[-head <string[]>] [-title <string>] [<CommonParameters>]
Il parametro –head consente di specificare codice HTML aggiuntivo da inserire nella sezione <HEAD> dello script. A questo punto, è possibile modificare facilmente la singola riga di codice sopra illustrata, in modo che venga collegata a un file CSS esistente che contiene la formattazione da applicare alla tabella HTML:
Gwmi Win32_Service | Where { $_.StartMode
–eq "Auto" –and $_.State –ne "Running" } |
ConvertTo-HTML -title "Services" -head "<link
rel='stylesheet' href='styles.css' type='text/
css' />" | Out-File C:\ServiceAlert.html
In questo caso il parametro –head viene utilizzato per inserire un collegamento a un file CSS che si trova nella stessa cartella del file HTML di output. Viene inoltre utilizzato il parametro –title per impostare il titolo della pagina Web. Il risultato è illustrato nella Figura 2. Il testo del file Style.CSS utilizzato è simile al seguente:
Figura 2 Report HTML formattato con un file CSS
Figura 2 Report HTML formattato con un file CSS
body { background-color:#EEEEEE; }
body,table,td,th { font-family:Tahoma; color:Black; Font-Size:10pt }
th { font-weight:bold; background-color:#CCCCCC; }
td { background-color:white; }

Filtraggio semplificato
Cmdlet del mese
Questo mese si esamineranno due cmdlet: Start-Transcript e Stop-Transcript. Entrambi i cmdlet vengono utilizzati per controllare la registrazione delle trascrizioni di Windows PowerShell, che prevede la scrittura in un file di testo specificato di tutte le informazioni presenti nella finestra della console. Si tratta di un'operazione piuttosto semplice. Innanzitutto, eseguire il cmdlet Start-Transcript e assegnargli un nome. Eseguire quindi Stop-Transcript per terminare la registrazione e chiudere il file. Questo è un metodo efficace per passare dall'utilizzo di shell ad-hoc all'esecuzione di script formali: quando si iniziano a utilizzare singole righe di comando nella shell, è possibile copiarle e incollarle dal file delle trascrizioni creato. È possibile ovviamente modificare la trascrizione nello script effettivo. Jeffery Hicks, un Microsoft MVP, ha scritto uno script che consente di analizzare le trascrizioni e di convertirle in file PS1 di Windows PowerShell. Questo script è disponibile all'indirizzo blog.sapien.com/current/2006/11/28/powershell-transcripts.html.

Ecco ora il cmdlet Get-WMIObject. La sintassi di questo cmdlet, riportata nella Guida incorporata di Windows PowerShell, fa riferimento a funzionalità finora ignorate:
Get-WmiObject [-class] <string> [[-property]
<string[]>] [-namespace <string>]
[-computerName <string[]>] [-filter <string>]
[-credential <PSCredential>]
[<CommonParameters>]
Un errore comune che i nuovi utenti di Windows PowerShell commettono, consiste nell'eseguire una riga di comando WMI simile alla seguente:
Gwmi Win32_NTLogEvent –comp Server2
Questo comando consente di recuperare le voci del registro eventi da Server2, ovvero tutte le voci del registro eventi. Tuttavia, se si utilizza questo comando, il processo di elaborazione e trasmissione delle voci del registro eventi da parte di Server2 e l'utilizzo in Windows PowerShell di un numero così elevato di eventi potrebbero richiedere molto tempo.
Un approccio più efficace consiste nel configurare Server2 in modo che vengano individuati e inviati solo gli eventi a cui si è effettivamente interessati. A tal fine, è possibile utilizzare una query WQL (WMI Query Language, linguaggio di query WMI). Alcuni considerano la sintassi di questa query piuttosto difficoltosa, ma Windows PowerShell consente di specificare solo la parte di una query WQL relativa all'applicazione di filtri, utilizzando il parametro –filter:
Gwmi Win32_NTLogEvent –comp Server2 –filter "EventIdentifier=1024"
Questo parametro consente di recuperare tutti gli eventi, da qualsiasi registro, con l'ID evento 1024. Si noti come i criteri di filtro prevedano l'utilizzo dell'operatore di confronto = anziché dell'operatore –eq di Windows PowerShell. questo avviene perché il filtro viene passato al servizio WMI del computer remoto per l'elaborazione e, pertanto, è necessario che i criteri utilizzino la sintassi WMI, non la sintassi di Windows PowerShell.
Un parametro –filter è disponibile anche in altri cmdlet, come Get-ChildItem, il cmdlet a cui sono associati alias come Dir e Ls. Nella maggior parte dei casi il parametro –filter passa i criteri di filtro direttamente alla tecnologia sottostante, dando luogo al cosiddetto filtro all'origine, un'operazione in genere molto più rapida rispetto al processo che prevede la raccolta di tutti gli oggetti e l'esecuzione di tali oggetti tramite il cmdlet Where-Object, in modo da filtrare quelli non ritenuti necessari.

Cmdlet trascurati
Questo approccio all'esplorazione dei cmdlet che prevede l'analisi delle funzionalità di un cmdlet al giorno consentirà senza dubbio di approfondire la conoscenza dei cmdlet con cui si ha già una certa dimestichezza. Tuttavia, un'altra ragione valida per creare un calendario con il cmdlet del giorno è evitare di trascurare completamente cmdlet che non si conoscono affatto. Uno dei miei preferiti è il cmdlet Resolve-Path. Dato un percorso con caratteri jolly, questo cmdlet restituisce un insieme di nomi di file e cartelle che corrispondono al percorso. È simile al cmdlet Get-ChildItem (meglio noto con l'alias Dir o Ls) ma, anziché restituire tutti gli oggetti di un file o una cartella, restituisce semplici stringhe che possono essere trasmesse ad altri cmdlet per un ulteriore filtraggio o elaborazione. L'utilizzo di questo cmdlet è piuttosto semplice:
Resolve-Path C:\P*
In questa semplice riga vengono restituiti percorsi come C:\Program Files, C:\Processes.txt e così via. Nella Figura 3 vengono illustrati due esempi di utilizzo di questo cmdlet.
Figura 3 Utilizzo di Resolve-Path, un cmdlet utile ma trascurato
Figura 3 Utilizzo di Resolve-Path, un cmdlet utile ma trascurato

Punto di partenza
Una volta individuato il cmdlet del giorno da esplorare, eseguire Gcm, un alias per Get-Command. Verrà restituito un elenco di tutti i cmdlet disponibili in Windows PowerShell, inclusi quelli aggiunti tramite gli snap-in, come Exchange Server 2007 Management Shell, PowerShell Community Extensions e così via. Selezionare il primo cmdlet dell'elenco, nel caso dell'esempio Add-Content, e accedere alle informazioni della Guida disponibili per il cmdlet in questione:
Help Add-Content –full
È opportuno leggere la Guida completa, anziché quella predefinita, che è molto più sintetica, in modo da ottenere una descrizione dettagliata delle funzioni di ciascun parametro, visualizzare alcuni esempi di utilizzo dei cmdlet e individuare altre utili informazioni. Dedicare un po' di tempo all'utilizzo del cmdlet. È consigliabile evitare di esercitarsi nell'ambiente di produzione e utilizzare magari un computer virtuale. È opportuno riservare all'esplorazione dei cmdlet 10 minuti al giorno, preferibilmente alla stessa ora ogni giorno in modo che diventi un'abitudine. Nel giro di pochissimo tempo, si acquisirà una conoscenza approfondita di tutte le funzionalità offerte da Windows PowerShell.

Don Jones è il guru degli script di SAPIEN Technologies e coautore di Windows PowerShell: TFM (SAPIEN Press, 2007). È possibile contattarlo all'indirizzo www.ScriptingAnswers.com.


 Hey, Scripting Guy!: Il ritorno di WinRM
Hey, Scripting Guy!
Il ritorno di WinRM
Gli Scripting Guy di Microsoft

Quando gli Scripting Guy hanno deciso di creare una serie in due parti su Gestione remota Windows® (WinRM), si sono subito imbattuti in un problema importante: la protezione. Dopotutto, noi Scripting Guy eravamo ben consapevoli dei problemi che hanno afflitto l'uscita dell'ultima puntata della saga di Harry Potter: le copie dei libri ordinate in anticipo sono state spedite e consegnate inavvertitamente prima della data ufficiale di uscita del libro (ma si è poi trattato di un vero problema? No di certo; la casa editrice si è limitata a chiedere ai clienti di non di leggere il libro fino alla data di uscita).
Ma il bello deve ancora venire. Il finale di libro e serie è stato rivelato prima ancora che i libri fossero distribuiti alle librerie (se non l'hai ancora letto, ecco come va a finire: pare che Harry Potter sia diventato una specie di mago o qualcosa del genere). Allo stesso modo, le copie di tutte le pagine digitalizzate sono state immediatamente rese disponibili su Internet, in alcuni casi addirittura prima che l'autore J. K. Rowling le scrivesse. Insomma, una bella falla nei sistemi di protezione: gli Scripting Guy erano quindi determinati a impedire che ciò accadesse anche a loro. D'altra parte, se tante persone si sono dimostrate così determinate a svelare il finale della saga di Harry Potter, è facile immaginare ciò che sarebbero capaci di fare per mettere le mani sul finale della serie in due parti su WinRM degli Scripting Guy.
Per fortuna, gli Scripting Guy sono riusciti a tenere i segreti, per l'appunto, segreti. È vero, il motivo principale di tale notevole successo è che gli Scripting Guy hanno scritto effettivamente la seconda parte della serie molto dopo la scadenza prevista per la presentazione dell'articolo. Ma diamine, lo Scripting Guy che scrive questo articolo è andato in vacanza ad agosto e, a differenza di una percentuale sorprendentemente grande di dipendenti Microsoft, non guarda mai un computer mentre è in vacanza e di usarlo nemmeno se ne parla.
Ecco, a dire il vero guarda raramente, e usa ancora meno, un computer anche quando non è in vacanza. Ma questa è un'altra storia.
In ogni caso sappiamo che molti degli utenti hanno dormito poco e male nelle ultime quattro settimane, preoccupati e impazienti di sapere come sarebbe terminata la saga di WinRM. Bene, le settimane dolorosamente lunghe di attesa insonne sono terminate. Qui, per la prima volta nella storia, è raccontata la fine della strabiliante serie in due parti su WinRM degli Scripting Guy. Bene, in effetti, finisce alla Figura 1.
Figure 1 Epilogo (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strDialect = "http://schemas.microsoft.com/wbem/wsman/1/WQL"
strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*"
strFilter = "Select Name, DisplayName From Win32_Service Where State = 'Running'"

Set objResponse = objSession.Enumerate(strResource, strFilter, strDialect)

Do Until objResponse.AtEndOfStream
    strXML = objResponse.ReadItem

    Set objXMLDoc = CreateObject("Microsoft.XMLDom")
    objXMLDoc.async=False
    objXMLDoc.loadXML(strXML)

    Set objElement = objXMLDoc.documentElement
    Wscript.Echo "Name: " & objElement.ChildNodes(0).ChildNodes(0).NodeValue
    Wscript.Echo "Display Name: " &  objElement.ChildNodes(1).ChildNodes(0).NodeValue
    Wscript.Echo
Loop
Sì, è vero: anche l'imprevedibile stravolgimento della trama ha impressionato e fatto correre lunghi brividi sulla schiena dei lettori. objElement.ChildNodes(0).ChildNodes(0).NodeValue! Chi poteva aspettarselo? In verità, data l'efficacia del dispositivo di protezione, nemmeno gli Scripting Guy avevano idea di come si sarebbe conclusa la serie. Ma ora il segreto è svelato.
Prima di procedere oltre, è il caso di riassumere rapidamente l'intera serie, per tutti quelli che per qualche misterioso motivo non hanno letto la Parte 1 (disponibile all'indirizzo technetmagazine.com/issues/2007/11/HeyScriptingGuy). Nella Parte 1 è stata presentata la nuova tecnologia WinRM, disponibile in Windows Server® 2003 R2, Windows Vista® e Windows Server 2008, che semplifica la gestione di computer su Internet, anche in presenza di firewall. Se è vero che Strumentazione gestione Windows (WMI) ha sempre consentito di gestire i computer in modalità remota, tuttavia la tecnologia di gestione remota su cui si fonda WMI è DCOM. Ottima scelta se non fosse per il fatto che la maggior parte dei firewall, per impostazione predefinita, blocca il traffico DCOM. È comunque possibile aprire le porte necessarie e consentire il traffico DCOM, ma molti amministratori di rete non sono entusiasti di questa soluzione, preoccupati come sono di evitare che l'apertura di una porta per DCOM possa rappresentare l'apertura di una breccia per ogni sorta di codice dannoso.
Da queste considerazioni è nato WinRM, "l'implementazione Microsoft del protocollo WS-Management, un protocollo standard, basato su SOAP, di facile integrazione con i firewall, che consente all'hardware e ai sistemi operativi di diversi fornitori di interoperare". Un modo piuttosto elaborato per dire che ora si può eseguire la gestione remota con i protocolli Internet standard, come HTTP e HTTPS.
Come già sottolineato il mese scorso, WinRM semplifica la connessione a computer remoti e il recupero delle informazioni WMI presenti in tali computer. Questo significa che si tratta di una tecnologia assolutamente perfetta? Non è esattamente così. Come già evidenziato, quando WinRM invia di nuovo i dati allo script che ha eseguito la chiamata, i dati vengono restituiti in formato XML. Inutile dire che il formato XML può risultare un po' complesso da analizzare e utilizzare, soprattutto per gli amministratori di sistema con esperienza limitata in questa area specifica. È per questo che WinRM viene fornito con una trasformazione XSL che converte i dati restituiti in un formato più leggibile.
Anche questa è un'ottima idea, peccato che però l'output tenda sempre a somigliare al seguente:
Win32_Service
    AcceptPause = false
    AcceptStop = true
    Caption = User Profile Service
    CheckPoint = 0
    CreationClassName = Win32_Service
Questo non è necessariamente uno svantaggio, ma significa anche che l'output verrà sempre scritto nella finestra di comando; per impostazione predefinita, non è possibile salvare direttamente i dati in un file di testo, scrivere i dati in una database o in un foglio di calcolo di Microsoft® Excel® oppure eseguire qualsiasi altra operazione con i dati, oltre a visualizza le informazioni sullo schermo. Ma questo raramente basta.
Per di più, il problema si aggrava quando si decide di restituire solo un certo numero di proprietà per una classe WMI (per ridurre, ad esempio, il traffico in rete). Quando si lavora con un numero ridotto di proprietà di una classe, invece che con tutte le proprietà di una classe, si ottiene un output simile al seguente:
XmlFragment
    DisplayName = Windows Event Log
    Name = EventLog

XmlFragment
    DisplayName = COM+ Event System
    Name = EventSystem
Interessare, ma non è certo la migliore schermata di dati che si sia mai vista (soprattutto per l'intestazione XmlFragment che compare in tutto il report).
Cosa si può fare per renderla migliore? Scrivere del codice personalizzato per analizzare e formattare i dati XML? Non sembra un'operazione particolarmente adatta a un amministratore di sistema. O forse lo è?

Chi fa da se, fa per tre
Utilizzare i dati XML non formattati restituiti da WinRM non è difficile come sembra. Di seguito verrà illustrato un modo semplice di analizzare e formattare i dati XML. L'approccio utilizzato nell'esempio non è certo l'unico possibile per operare sui dati in formato XML, ma è un buon metodo; lo scopo principale consiste nel dimostrare che non è necessario fare affidamento sulla trasformazione XSLT. Una volta afferrato il concetto di base, non vi saranno limiti alle possibilità di manipolazione dei dati di WinRM.
Piccola avvertenza: per motivi di spazio, non verrà illustrata la maggior parte dello script riportato nella Figura 1. Ciò non dovrebbe costituire un problema, tuttavia, dal momento che i primi due-terzi dello script sono stati descritti in dettaglio nell'articolo del mese scorso. L'attenzione si concentrerà, invece, sull'ultimo terzo dello script, ovvero sulla parte in cui si lavora effettivamente con i dati restituiti.
Come si può notare, questo episodio delle Cronache di WinRM iniziano dalla creazione di un'istanza dell'oggetto WSMan.Automation, dalla query a un computer remoto (in questo caso, atl-fs-01.fabrikam.com) e dalle informazioni ricevute relative a tutti i servizi in esecuzione su tale computer. Questo ci riporta alla riga dello script in cui si imposta un loop Do Until per leggere ed elaborare i dati XML restituiti. Il loop continua fino a che non resta più niente da leggere ed elaborare (oppure, tanto per dare l'impressione che sappiamo quel che diciamo, il loop continua fino a quando la proprietà AtEndOfStream del file XML non diventa True).
Ecco la riga di codice e questo è l'inizio della storia di questo mese:
Do Until objResponse.AtEndOfStream
All'interno del loop, la prima operazione eseguita è l'utilizzo del metodo ReadItem per la lettura della prima sezione dei dati XML restituiti. Poiché si utilizza WinRM e poiché vengono recuperate le informazioni del servizio, questa prima sezione consisterà in tutti i dati restituiti per il primo servizio dell'insieme. Dopo la memorizzazione dei dati (ancora una volta, in formato XML) in una variabile denominata strXML, si crea un'istanza dell'oggetto Microsoft.XMLDom. In tal modo si ottiene un documento XML vuoto con cui lavorare:
Set objXMLDoc = _
    CreateObject("Microsoft.XMLDom")
Una volta approntato il documento vuoto, si imposta il valore della proprietà Async su False, quindi si chiama il metodo loadXML.
A questo punto... come dici? Perché si imposta il valore della proprietà Async su False? E perché si denomina il metodo loadXML? Ottime domande! Avremmo dovuto pensarci noi.
Per i principianti, la proprietà Async indica se lo script consente un download asincrono di informazioni XML. Se il valore della proprietà è True, il download viene avviato e il controllo viene restituito immediatamente allo script, anche se il download non è ancora terminato. Una funzionalità davvero utile. Purtroppo, in questo caso, lo script procederebbe come se disponesse già di tutte le informazioni necessarie. Quando uno script rileva che le informazioni necessarie non sono tutte disponibili, cominciano guai seri. Ecco perché nell'esempio proprietà Async è impostata su False.
Nota: si potrebbe scrivere del codice per monitorare periodicamente lo stato del download, garantendo che lo script non proceda in modo prematuro. È una soluzione praticabile, ma impostare il valore della proprietà Async su False è un approccio molto più semplice. Infatti lo script si blocca fino a che il download non è completo; in pratica, una volta iniziato il download, lo script resta pazientemente in attesa della fine del download prima di procedere.
Quanto al metodo loadXML, l'operazione che esegue è quella suggerita dal nome: carica un documento XML (o un frammento di documento) ben formattato nel documento vuoto. A tale scopo, è sufficiente richiamare il metodo loadXML, passando la variabile strXML quale unico parametro del metodo:
objXMLDoc.loadXML(strXML)
Il risultato finale? I dati WinRM sono stati trasformati in un documento XML virtuale. Ne consegue che è possibile iniziare a utilizzare i metodi XML standard per analizzare il documento virtuale.
A questo punto, è necessario utilizzare la riga di codice seguente per creare un riferimento oggetto all'elemento radice del file XML:
Set objElement = objXMLDoc.documentElement
Ora tutto è pronto per iniziare a divertirsi (sempre che si condivida la stessa idea di divertimento degli Scripting Guy, che corrisponde a eseguire l'analisi di un file XML).
Come si ricorderà, la query WQL (o, utilizzando la terminologia WinRM, il filtro) ha l'aspetto seguente:
strFilter = "Select Name, DisplayName " & _
  "From Win32_Service Where State = 'Running'"
Come si può vedere, si sono richieste due proprietà dalla classe Win32_Service: Name e DisplayName. È presente anche una clausola Where che limita i dati restituiti ai servizi in esecuzione, ma non è il caso di occuparsene qui. È importante che siano state richieste due proprietà? L'ordine della richiesta è importante? Forse. Come forse?
L'obiezione è lecita. Forse, in qualità di autori dell'articolo, dovremmo avere una risposta a queste domande. Va bene. Per quanto ne sappiamo, la risposta a entrambe le domande è sì. È importante che siano state richieste due proprietà nella query WQL? Sì lo è; dopotutto, saranno questi i soli valori della proprietà restituiti (al contrario di quanto accade con una query Select * From, che restituisce i valori per tutte le proprietà di una classe).
L'ordine delle due proprietà è importante? Certo che lo è. L'ordine in cui si specificano i nomi di proprietà corrisponde all'ordine in cui vengono restituiti i valori della proprietà. È importante perché ciascun valore della proprietà viene restituito come nodo figlio (o sezione) dell'elemento radice. Quale valore della proprietà viene restituito come primo nodo figlio? La risposta è facile. In questo caso il primo nodo figlio sarà la proprietà Name, perché si tratta della prima proprietà riportata nella query WQL. Quale proprietà viene restituita come secondo nodo figlio? Esatto, la proprietà DisplayName, perché è la seconda voce riportata nella query.
Un momento. L'hai indovinato da solo o qualcuno ti ha passato una copia non autorizzata dell'articolo? Hmmmm...
In ogni caso, questo facilita la restituzione del valore della proprietà Name. Non resta che impostare un riferimento a NodeValue del primo elemento (elemento 0) nel primo insieme ChildNodes (elemento 0), come segue:
Wscript.Echo "Name: " & _
objElement.ChildNodes(0).ChildNodes(0).NodeValue
Come si imposta il riferimento al valore della proprietà DisplayName? In questo caso il riferimento a NodeValue del primo elemento viene impostato nel secondo insieme ChildNodes (elemento 1):
Wscript.Echo "Display Name: " & _
objElement.ChildNodes(1).ChildNodes(0).NodeValue
E se nella query WQL fosse disponibile una terza proprietà (ad esempio, Status)? In tal caso il riferimento a NodeValue del primo elemento verrebbe impostato nel terzo insieme ChildNodes (elemento 2):
Wscript.Echo "Status: " & _
objElement.ChildNodes(2).ChildNodes(0).NodeValue
E così via fino all'ultima proprietà.
A questo punto che aspetto ha assunto l'output dello script? Qualcosa di simile a quanto segue:
Display Name: Windows Event Log
Name: EventLog

Display Name: COM+ Event System
Name: EventSystem
È vero che non sembra essere molto diverso dall'output WinRM predefinito (anche se quell'inutile intestazione XmlFragment ora non compare più). Una differenza esiste ed è questa: quando si lavora con singoli valori di proprietà, non è necessario limitarsi alla formattazione predefinita (si noti l'utilizzo dell'etichetta Display Name al posto di DisplayName) o alla sola visualizzazione delle informazioni nella finestra di comando.
È necessario scrivere i dati in un foglio di calcolo Excel? L'operazione è relativamente semplice. Per iniziare, inserire il blocco di codice seguente (che crea e configura un nuovo foglio di calcolo Excel) subito dopo la riga dello script WinRM che chiama il metodo Enumerate:
Set objExcel = _
  CreateObject("Excel.Application")
objExcel.Visible = True
Set objWorkbook = objExcel.Workbooks.Add()
Set objWorksheet = objWorkbook.Worksheets(1)

i = 2
objWorksheet.Cells(1,1) = "Name"
objWorksheet.Cells(1,2) = "Display Name"
Quindi sostituire il loop originale Do Until con quello illustrato nella Figura 2. Provare e verificare il risultato.
Figure 2 Nuovo loop Do Until (Close Figure 2)
Do Until objResponse.AtEndOfStream
  strXML = objResponse.ReadItem

  Set objXMLDoc = CreateObject("Microsoft.XMLDom")
  objXMLDoc.async=False
  objXMLDoc.loadXML(strXML)

  Set objElement = objXMLDoc.documentElement
  objExcel.Cells(i, 1) = objElement.ChildNodes(0).ChildNodes(0).NodeValue
  objExcel.Cells(i, 2) = objElement.ChildNodes(1).ChildNodes(0).NodeValue
  i = i + 1
Loop

WinRM Parte 3?
Le informazioni fornite con questo articolo e con il precedente dovrebbero consentire di iniziare a utilizzare WinRM con profitto. Almeno si spera; WinRM è una nuova tecnologia molto interessante che promette di semplificare la gestione remota dei computer (senza compromettere sicurezza e protezione). Considerazione che fa nascere spontanea una domanda: questo significa che ci sarà una terza puntata della saga di WinRM?
L'informazione è riservata e non può essere rivelata. Non tanto per i rischi di protezione, ma più semplicemente perché a causa del solito processo di pianificazione e decisione, gli Scripting Guy non hanno la più pallida idea di come si concluderà davvero la saga di WinRM. Come si suol dire, resta sintonizzato!
Il rompicapo di script del Dottor Scripto.
Il Dottor Scripto ha avuto un piccolo incidente. Ha lasciato uno dei suoi script sul pavimento (invece di archiviarlo con cura, come fanno tutti i bravi autori di script) ed è inciampato sparpagliando accidentalmente i pezzi dello script in ogni dove. È riuscito a trovare tutte le variabili, le parole chiave, i simboli e così via e li ha disposti in ordine alfabetico, ma adesso deve riassemblarli di nuovo per ricostruire lo script. L'operazione gli costerà del tempo, ma conta di avere la risposta pronta per l'uscita del prossimo numero di TechNet Magazine. Nel frattempo, prova ad aiutarlo cercando di assemblare in uno script completo questa serie apparentemente casuale di pezzi di script. Buona fortuna!
Suggerimento: OK, ecco un piccolo aiuto. Lo script finale elimina dal computer locale tutti i file con una data precedente a quella specificata.

Il rompicapo di script del Dottor Scripto.
Risposta: Il goffo Dottor Scripto, dicembre 2007
Sì, il Dott. Scripto è riuscito a rimettere insieme il suo script. Ecco lo script ricostruito e funzionante, che elimina dal computer locale tutti i file con una data precedente a quella specificata:
strDate = "20060102000000.000000+000"

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colFiles = objWMIService.ExecQuery("Select * From CIM_DataFile Where CreationDate < '" & strDate & "'")
For Each objFile in colFiles
    Wscript.Echo objFile.Name
Next

Gli Scripting Guy di Microsoft lavorano o, per meglio dire, sono stipendiati da Microsoft. Quando non si dedicano al baseball (o ad altre attività) come giocatori, allenatori o semplici spettatori, gestiscono il TechNet Script Center. Consultare la pagina www.scriptingguys.com.


 Controllo della protezione: Criteri password del dominio Windows
Controllo della protezione
Criteri password del dominio Windows
Derek Melber

Un amministratore di un dominio Windows è senza dubbio consapevole dei limiti relativi ai criteri password per gli account utente di dominio. Con l'introduzione di Windows Server 2008, tuttavia, alcune di queste limitazioni svaniranno. In questo articolo verrà esaminato innanzitutto uno dei problemi che il nuovo sistema operativo è in grado di risolvere: l'impossibilità di implementare più criteri password.
Chi oggi esegue una versione del sistema operativo Windows® (Windows NT®, Windows 2000 Active Directory® o Windows Server® 2003 Active Directory), è costretto a utilizzare un singolo criterio password per ciascun dominio. In realtà, la limitazione effettiva non è rappresentata dai criteri password, quanto dalla più ampia gamma delle impostazioni comprese in Criteri account. Criteri e impostazioni sono illustrati nella Figura 1.
Figure 1 Criteri account (Close Figure 1)

Criteri password
Imponi cronologia delle password
Validità massima password
Validità minima password
Lunghezza minima password
Le password devono essere conformi ai requisiti di complessità
Archivia password mediante crittografia reversibile
Criterio di blocco account
Blocca account per minuti
Limite di blocchi dell'account tentativi di accesso non validi
Reimposta blocco account dopo ...
Criterio Kerberos
Imporre le restrizioni di accesso degli utenti
Durata massima ticket di servizio minuti
Durata massima ticket utente ore
Durata massima rinnovo ticket utente giorni
Tolleranza massima per la sincronizzazione dell'orologio del computer minuti
Per impostazione predefinita, queste impostazioni dei criteri si applicano a tutti gli account utente e di dominio associati al dominio. Il motivo è il tipo di ereditarietà di Criteri di gruppo all'interno della struttura di Active Directory. Per comprendere meglio il modo in cui i criteri influiscono sugli account utente locali e di dominio, è importante comprendere dove vengono impostati tali criteri e in che modo l'ereditarietà di Criteri di gruppo influisce su tutti i diversi account utente. Le impostazioni dei criteri Kerberos sono applicabili solo agli account utente di dominio, poiché solo questi ultimi utilizzano il protocollo Kerberos per l'autenticazione. Gli account utente locali invece utilizzano NTLMv2, NTLM o LM per l'autenticazione.

Impostazione dei criteri di account
In Active Directory Criteri di gruppo stabilisce e controlla i criteri di account per l'intero dominio. L'operazione viene eseguita durante l'installazione iniziale del dominio di Active Directory, purché si disponga di un oggetto Criteri di gruppo predefinito collegato al nodo di dominio in Active Directory. Questo oggetto Criteri di gruppo, denominato Criterio dominio predefinito, prevede configurazioni predefinite per tutte le tre sezioni di Criteri account. Nella Figura 2 è riportato un elenco completo delle impostazioni iniziali per gli elementi dei criteri password in un dominio Windows Server 2003.
Figura 2 Criteri password predefiniti per il dominio Windows Server 2003
Figura 2 Criteri password predefiniti per il dominio Windows Server 2003
Le impostazioni in questo oggetto Criteri di gruppo controllano i criteri di account per tutti gli account utente di dominio e per tutti i computer del dominio. Tutti i computer del dominio (desktop e server) dispongono di un sistema Gestione account di protezione (SAM) locale, che viene controllato dalle impostazioni presenti nell'oggetto Criteri di gruppo predefinito. Ovviamente i SAM locali contengono anche gli account utente locali per il rispettivo computer.
Le impostazioni in Criterio dominio predefinito hanno effetto su tutti i computer del dominio attraverso la normale ereditarietà degli oggetti Criteri di gruppo all'interno della struttura di Active Directory. Poiché è collegato al nodo del dominio, questo oggetto Criteri di gruppo avrà effetto su tutti gli account computer all'interno del dominio.

Operazioni non eseguibili con i criteri password correnti
All'implementazione corrente di Active Directory (in Windows Server 2003) è associata una serie di convinzioni erronee relative ai controlli delle password, malgrado anni di test rigorosi, senza tuttavia ottenere finora alcuna prova della veridicità di tali convinzioni diffuse. È ovvio che i criteri non funzionano per scopi diversi da quelli per cui sono stati progettati.
Ciò premesso, molti amministratori pensano che sia possibile disporre di più criteri password per gli utenti nello stesso dominio. Ritengono inoltre che sia possibile creare un oggetto Criteri di gruppo e collegarlo a un'unità organizzativa. L'idea è spostare gli account utente nell'unità organizzativa in modo che l'oggetto Criteri di gruppo influisca sugli oggetti. All'interno dell'oggetto Criteri di gruppo, i criteri di account vengono modificati per creare un criterio password più sicuro, impostando magari la lunghezza massima della password su 14 caratteri. Tuttavia, per diverse ragioni, con questa configurazione non si otterrà mai il risultato desiderato. Innanzitutto, le impostazioni dei criteri password sono criteri basati sui computer e non sugli utenti e, in quanto tali, queste impostazioni non potranno mai influire su un account utente. Secondo, le impostazioni dei criteri di account per un account utente di dominio possono essere modificate solo all'interno di un oggetto Criteri di gruppo collegato al dominio. Gli oggetti Criteri di gruppo collegati all'unità organizzativa e configurati per la modifica delle impostazioni dei criteri di account modificheranno il sistema SAM locale dei computer che risiedono nell'unità organizzativa o nelle unità organizzative secondarie dell'unità organizzativa collegata.
Una seconda convinzione erronea è che le impostazioni dei criteri di account stabilite nel dominio principale (il dominio iniziale dell'insieme di strutture di Active Directory) vengono ereditate nell'ambito dei domini figlio nell'insieme di strutture. Anche questo è errato e non è possibile configurare le impostazioni per questo tipo di comportamento. Gli oggetti Criteri di gruppo collegati al dominio e le unità organizzative all'interno di un dominio non avranno effetto sugli oggetti di un altro dominio, anche se il dominio a cui l'oggetto Criteri di gruppo è collegato è il dominio principale. L'unico metodo per estendere le impostazioni degli oggetti Criteri di gruppo agli oggetti all'interno di diversi domini, consiste nel collegare gli oggetti Criteri di gruppo ai siti di Active Directory.

Novità relative alle password
Come è stato illustrato, nelle versioni correnti di Windows le password degli account utente vengono gestite in modo piuttosto semplice. Questo processo prevede la gestione di una serie di regole di password per tutti gli account dominio e la gestione dei criteri di account tramite un oggetto Criteri di gruppo collegato al nodo del dominio in Active Directory. Lo scenario cambia completamente nel caso di Windows Server 2008.
Windows Server 2008 e l'infrastruttura di Active Directory inclusa in questo sistema operativo, adotta un approccio diverso. Le versioni precedenti prevedevano la presenza delle impostazioni dei criteri di account in un oggetto Criteri di gruppo. Era quindi possibile impostare un singolo criterio per tutti gli account utente di dominio; tali impostazioni sono state ora spostate in una sezione più profonda di Active Directory. Inoltre, i criteri di account non sono più basati sugli account computer. Ora è possibile specificare singoli utenti e gruppi di utenti in modo da controllare le restrizioni per le relative password. Si tratta di un concetto radicalmente nuovo per gli amministratori di Windows che finora hanno sempre gestito i criteri di account per account computer.

Criteri di account in Windows Server 2008
In Windows Server 2008, i criteri di account non vengono stabiliti con l'oggetto Criterio dominio predefinito. Infatti, non è possibile utilizzare gli oggetti Criteri di gruppo per creare criteri di account per account utente di dominio. In Windows Server 2008, gli utenti che desiderano apportare modifiche al sistema verranno indirizzati al database di Active Directory. Più specificamente, per modificare l'oggetto di Active Directory e gli attributi a esso associati, si utilizzerà lo strumento ADSIEdit.
La ragione alla base di questa modifica è che Criteri di gruppo non è progettato per l'utilizzo di più password all'interno dello stesso dominio. L'implementazione della funzionalità per l'utilizzo di più password per ciascun dominio è elegante ma non altrettanto intuitiva. In futuro, tuttavia, si prevede di semplificare maggiormente l'accesso all'interfaccia per la configurazione delle impostazioni. Per ora, per apportare le modifiche desiderate al sistema è necessario "introdursi" nel database di Active Directory.
Se si preferisce, per modificare le impostazioni dei criteri di account è tuttavia possibile utilizzare uno strumento diverso da ADSIEdit. È possibile utilizzare qualsiasi altro strumento di modifica LDAP in grado di interagire con il database di Active Directory o persino script. Quando si implementano i criteri password in Windows Server 2008, è necessario adottare un approccio molto diverso rispetto al passato. Le nuove funzionalità implicano la necessità di considerare quali utenti e gruppi riceveranno determinate impostazioni delle password.
È necessario considerare non solo la lunghezza delle password ma anche le restrizioni aggiuntive relative alle impostazioni dei criteri password, compresi il periodo di validità minimo e massimo, la cronologia e così via. Altri fattori da considerare includono la modalità di controllo delle impostazioni dei criteri di blocco degli utente e delle impostazioni Kerberos. Esiste una relazione uno-a-uno tra le impostazioni correnti dei criteri di account e quelle configurate nel database di Active Directory in Windows Server 2008. Tuttavia, è importante notare che i nomi di ciascuna impostazione dei criteri sono differenti dal momento che ora rappresentano oggetti e attributi di Active Directory.
Per implementare le nuove impostazioni delle password, è necessario creare un oggetto Impostazioni password (PSO, Password Settings Object) denominato msDS-PasswordSettings nel contenitore Impostazioni password, a cui è associato il percorso LDAP "cn=Password Settings,cn=System,dc=domainname,dc=com". Tenere presente che il livello di funzionalità del dominio utilizzato deve essere impostato su Windows Server 2008. In questo nuovo oggetto sono disponibili le informazioni per diversi attributi, come illustrato nella Figura 3.
Figure 3 Attributi delle password in Active Directory (Close Figure 3)

Nome attributo Active Directory | Descrizione attributo
msDS-PasswordSettingsPrecedence | Stabilisce quale impostazione ha la precedenza in situazioni in cui un utente è membro di più gruppi con diversi criteri password.
msDS-PasswordReversibleEncryptionEnabled | Attiva o disattiva la crittografia reversibile.
msDS-PasswordHistoryLength | Determina quante altre password devono essere univoche prima che sia consentito riutilizzarne una.
msDS-PasswordComplexityEnabled | Stabilisce il numero e il tipo di caratteri necessari in una password.
msDS-MinimumPasswordLength | Stabilisce la lunghezza minima di una password.
msDS-MinimumPasswordAge | Determina per quanto tempo un utente deve utilizzare una password prima di modificarla.
msDS-MaximumPasswordAge | Determina per quanto tempo un utente può utilizzare una password prima che sia necessario modificarla.
msDS-LockoutThreshold | Determina quanti tentativi con password errate sono consentiti prima di bloccare l'account utente.
msDS-LockoutObservationWindow | Determina il periodo di tempo trascorso il quale il contatore delle password errate verrà reimpostato.
msDS-LockoutDuration | Determina per quanto tempo l'account verrà bloccato dopo troppi tentativi con password errate.
Come si può vedere, tutte le impostazioni di Criteri di gruppo correlate alle impostazioni dei criteri di account sono duplicate come attributi. Notare che è presente anche un'impostazione della precedenza che risulta essenziale per l'implementazione di più password nello stesso dominio, in quanto si verificheranno sicuramente dei conflitti e sarà necessario disporre di un meccanismo in grado di gestire tali conflitti.

Configurazione delle impostazioni per i criteri di account
Per ogni oggetto creato, è necessario compilare tutti gli attributi per configurare i criteri di account per ciascun utente. È disponibile un nuovo attributo, msDS-PSOAppliesTo, che determina quali oggetti riceveranno l'insieme delle impostazioni dei criteri. Questo attributo consente di applicare specifiche impostazioni a determinati utenti. L'elenco sotto questo attributo può includere utenti o gruppi ma, come in tutte le situazioni in cui si definisce un elenco di controllo di accesso, è consigliabile utilizzare gruppi anziché utenti. I gruppi sono più stabili, più visibili e in genere più semplici da gestire.

Buone notizie
Per anni si è desiderato di avere la possibilità di utilizzare più password all'interno dello stesso dominio di Active Directory e ora questo desiderio è diventato realtà. Ora, nell'ambito delle password, non è più previsto lo stesso livello di protezione per tutti gli utenti dell'intero dominio. È possibile, ad esempio, configurare una password di otto caratteri per gli utenti normali e una password più complessa di 14 caratteri per i professionisti IT (che potrebbero disporre di privilegi di amministratore).
Abituarsi ad accedere al database di Active Directory per stabilire o modificare le impostazioni dei criteri di account potrebbe richiedere un po' di tempo. Fortunatamente, tuttavia, le nuove impostazioni riproducono funzionalità con cui si ha già una certa familiarità. Accertarsi di esplorare queste nuove impostazioni non appena si ha la possibilità di "mettere le mani" su Windows Server 2008, in quanto saranno senza dubbio tra le prime impostazioni che si configureranno.

Derek Melber, MCSE, CISM, MVP, è un consulente e istruttore indipendente. La sua funzione consiste nel promuovere e fornire una formazione adeguata nell'ambito della tecnologia Microsoft, con particolare attenzione ad Active Directory, a Criteri di gruppo, alla protezione e alla gestione dei desktop. Derek è autore di diversi libri IT, tra cui Microsoft Windows Group Policy Guide (Microsoft Press, 2005). È possibile contattarlo all'indirizzo derekm@braincore.net.


 Desktop file: Distribuzione di Windows in un mondo virtuale
Desktop file
Distribuzione di Windows in un mondo virtuale
Wes Miller

L'elaborazione virtuale è ovunque. L'incontro con questa tecnologia è solo questione di tempo. La virtualizzazione riduce la dipendenza dall'hardware creando essenzialmente un proprio Hardware Abstraction Layer (HAL) e consentendo di spostare uno o più sistemi guest, come i sistemi operativi client Windows Server o Windows, fra i sistemi host.
La virtualizzazione è, ovviamente, diversa dall'emulazione per il fatto che non imita il processore del guest. Rappresenta semplicemente le risorse del sistema host in modo che i sistemi guest possano accedervi. Di conseguenza, i sistemi host sono generici per i guest. In genere è possibile spostare un guest virtuale da un sistema creato da un OEM a uno creato da un altro OEM, indipendentemente dall'hardware dell'host. È però opportuno prestare attenzione ad alcuni aspetti. Se, ad esempio, si sposta un guest dall'hardware con un processore di un produttore di CPU, come AMD, a un altro, come Intel, è possibile che si verifichino dei problemi (in base alla tecnologia di virtualizzazione utilizzata). Ciò accade perché la tecnologia di elaborazione virtuale si limita a passare le informazioni dall'host al guest e viceversa; non emula una CPU specifica per il guest (come, ad esempio, Microsoft® Virtual PC su un vecchio Macintosh basato su PowerPC).
Tuttavia, la virtualizzazione emula i componenti hardware principali per l'host. Nella maggior parte dei casi, l'emulazione è limitata alla rete, ai dispositivi video (in genere un dispositivo molto limitato, senza una GPU avanzata) e all'archiviazione di massa. Questi coprono l'intera gamma di funzioni presentando al guest uno o più tipi di dispositivi emulati tramite software. Leggendo l'articolo si sarà già notato che l'elenco comprende tutti i dispositivi utilizzati da Windows® PE. Nella virtualizzazione questi sono gli stessi tipi di dispositivi necessari perché Windows funzioni. Inoltre, tutte le tecnologie di virtualizzazione devono emulare un BIOS. Potrebbero emulare anche l'EFI (Extensible Firmware Interface), ma il numero ridotto di sistemi operativi basati su EFI oggi ne limita di molto l'uso. Le emulazioni consentono di avviare i guest virtuali. Il BIOS e ciascuno dei dispositivi emulano un dispositivo reale nel software e presentano tale dispositivo ai guest. Sono di conseguenza necessari gli stessi driver (non sempre forniti da Windows) che vengono utilizzati dal dispositivo reale. Questo è un concetto importante da assimilare.
Alcune tecnologie di virtualizzazione consentono l'interfacciamento anche dei dispositivi USB (o USB 2.0), ma non verranno analizzate in questo articolo. A parte i dispositivi USB che richiedono dei driver (stampanti, NIC wireless USB e così via) o un supporto DirectX® (insoliti nella maggior parte delle tecnologie di virtualizzazione), non è necessario molto altro per iniziare a utilizzarli. È importante ricordare che il supporto per dispositivi USB o di altro tipo non emulati dipende, come è ovvio, dalla tecnologia di virtualizzazione utilizzata. Verificare di conoscere tutte le limitazioni del prodotto di virtualizzazione che si intende adottare prima di tentare di utilizzare i nuovi dispositivi.
Esistono due produttori di primo piano di tecnologie di virtualizzazione in ambiente Windows: Microsoft e VMware (vmware.com). Altri produttori si stanno affermando in questo campo con tecnologie promettenti, come Parallels (parallels.com).
Ora che inizia a essere chiaro l'ambito di utilizzo della virtualizzazione, nel resto dell'articolo si illustrerà come prepararla, come evitare i problemi più comuni e come eseguirne la distribuzione su alcuni computer presenti nell'ambiente.

Distribuzione virtuale
La distribuzione di sistemi virtuali non differisce dalla distribuzione di sistemi fisici ma, come si vedrà, esistono alcune buone ragioni per renderla diversa.
Per le prime versioni di Windows NT®, la distribuzione doveva avvenire tramite installazione. Si potevano creare degli script, ma era comunque necessario eseguire l'intero processo. Al termine dell'installazione, la funzione di copia dell'immagine su altri sistemi, sebbene fosse in teoria utile, semplicemente non era supportata.
In seguito, tuttavia, in Microsoft si decise di supportare i sistemi "clonati" o copiati da disco di Windows NT. Oggi tutti i metodi disponibili per la distribuzione fisica dei sistemi sono disponibili anche per la distribuzione virtuale. È possibile utilizzare: Winnt32 (o setup.exe nel caso di Windows Vista® e Windows Server® 2008); Windows PE (1.x o 2.x, a seconda del client da distribuire, come spiegato nei miei articoli precedenti); Servizi di installazione remota (RIS) o Servizi di distribuzione Windows (WDS); Sysprep (Utilità preparazione sistema per la distribuzione introdotta con Windows NT 4.0) e la tecnologia di duplicazione dischi preferita (ImageX, ad esempio).
L'operazione è necessaria solo la prima volta che si distribuisce un sistema operativo specifico. In seguito è sufficiente eseguire una copia. Esiste tuttavia un problema correlato ai metodi di duplicazione basati su disco come quelli appena menzionati.

Utilizzo di Sysprep
La decisione iniziale di Microsoft di non supportare la duplicazione basata su disco dipendeva in larga parte dal dall'identificatore di protezione (SID) di Windows NT. Per fortuna, Sysprep fornisce una soluzione. È però opportuno analizzare prima il problema da risolvere. Come illustrato all'indirizzo support.microsoft.com/kb/314828, il SID consiste in un numero revisione della struttura SID (di solito un identificatore univoco globale o GUID) che identifica un singolo computer basato su Windows. L''ID viene quindi utilizzato come parte principale dell'identificatore per tutti gli account locali. Gli account locali dispongono di un proprio identificatore univoco, denominato identificatore relativo (RID). Il RID è costituito da un ID di account concatenato in coda al SID. La combinazione dei due diventa l'identificatore per gli account locali.
Perché è un problema utilizzare, ad esempio, il SID del gruppo Administrators S-1-5-21-191058668-193157475-1542849698-500? S-1-5 è il descrittore che definisce che definisce questo codice come SID, la S è onnipresente nella rappresentazione testuale di un SID, mentre 1 e 5 rappresentano rispettivamente il numero revisione e il valore dell'identificatore dell'autorità del SID di Windows NT (in questo caso Protezione di Windows). Il resto è il SID vero e proprio, compreso 500 che identifica un SID ben noto, ovvero l'account del gruppo Administrators di Windows. All'account del gruppo Administrators creato per impostazione predefinita (e impossibile da eliminare) su tutte le installazioni di Windows viene attribuito un SID che termina con 500. Agli account degli utenti locali aggiunti a Windows dopo l'installazione viene attribuito un numero a partire da 1000.
PSGetSID, disponibile da Windows Sysinternals (menzionato nel mio articolo su PSTools consultabile all'indirizzo technetmagazine.com/issues/2007/03/DesktopFiles), consente di enumerare un SID per un determinato utente su un sistema o il SID del sistema. L'output di PSGetSID per il SID del sistema virtuale e dell'account utente di esempio, 1003, è visibile nella Figura 1.
Figura 1 L'output di PSGetSID per il SID di un sistema virtuale e per il SID dell'account utente 1003
Figura 1 L'output di PSGetSID per il SID di un sistema virtuale e per il SID dell'account utente 1003
Poiché i RID degli account locali sono basati su questo SID, il problema che si verifica quando si duplica un sistema tramite disco o si copia semplicemente un'immagine di computer virtuale è abbastanza chiaro. Se il SID non viene modificato (funzionalità prevalente ma non unica di Sysprep), si ottiene una copia del principale componente che rende unico un sistema Windows. Se il sistema A e il sistema B hanno un SID del gruppo Administrators identico, gli utenti di entrambi i sistemi verrebbero legittimamente identificati come lo stesso utente. Lo stesso accade per tutti gli account locali del sistema B che si autenticano sul sistema A e viceversa. Ancora peggio, i due sistemi presentano lo stesso SID ad Active Directory®. Se quindi si consente l'autenticazione del sistema A per una risorsa di dominio, ma si impedisce tale autenticazione al sistema B, si verifica un conflitto. Quando si impedisce l'autenticazione del sistema B, l'accesso viene impedito anche al sistema A.
Diventa quindi fondamentale rigenerare i SID sui sistemi utilizzando Sysprep, soprattutto in scenari di sistemi virtuali perché le immagini di sistema si possono propagare molto facilmente. Non è inoltre consigliabile utilizzare uno strumento di modifica del SID di terze parti, ma solo Sysprep. Sysprep è progettato, testato e supportato da Microsoft per la preparazione della duplicazione dei sistemi (anche di sistemi virtuali). Nella Figura 2 è riportato un esempio di schermata di Sysprep prima della modifica del SID di un sistema. Quando si prepara il sistema alla duplicazione, verificare che l'opzione "Don't regenerate security identifiers" sia sempre deselezionata.
Figura 2 L'opzione "Don't regenerate security identifiers" deve essere deselezionata quando si prepara la duplicazione
Figura 2 L'opzione "Don't regenerate security identifiers" deve essere deselezionata quando si prepara la duplicazione
Oltre ad aggiornare il SID in un nuovo ID, Sysprep modifica gli eventuali archivi dati privati rilevati in modo che riportino il SID e il nome del computer oppure in modo che la crittografia utilizzata funzioni con il nuovo SID. Alcuni esempi sono l'archivio dati Attività pianificate e i valori nella metabase IIS (se IIS è installato).
Sysprep inoltre elimina forzatamente tutte le schede NIC del sistema, con i dati di configurazione di rete per la scheda NIC. Poiché la configurazione di rete resta priva di NIC nel Registro di sistema e la relazione di tale NIC si basa sull'ID hardware della NIC (relazione che, al di fuori di uno spostamento da virtuale a virtuale, viene spesso interrotta), Sysprep elimina questi dati che in genere venivano abbandonati.
Sysprep elimina inoltre dal sistema tutte le informazioni di appartenenza di Active Directory. Di conseguenza, deve necessariamente rimuovere anche il sistema dal dominio. In tal modo si garantisce che al dominio possano essere aggiunti senza problemi i sistemi a cui sono stati appena attribuiti dei nuovi SID. Alcune utilità di modifica del SID consentono di modificare il SID di un computer senza rimuoverlo dal dominio, ma questo procedimento non è né attendibile né sicuro. Se si deve assolutamente eseguire Sysprep su un computer che è membro di un dominio, è preferibile rimuoverlo dal dominio prima di eseguire Sysprep oppure eseguire Sysprep e lasciare che lo strumento gestisca l'attività.
È inoltre utile notare che, quando si virtualizza un controller di dominio (DC), è necessario duplicare i sistemi che sono semplici server autonomi non promossi a controller di dominio e che non fanno parte del dominio. Fatta eccezione per Windows Server 2003 Small Business Server Edition, non è possibile eseguire una duplicazione sicura dei dischi di un controller di dominio. Per creare nuovi controller di dominio in modo sicuro, è necessario creare un'immagine disco di un server pronto ad essere incluso nel dominio e promosso a controller di dominio. Sysprep (tra l'istanza specifica SBS, che è foresta singola/server singolo) non è in grado di modificare in modo sicuro il SID su un controller di dominio.
Infine, oltre a modificare il SID e rimuovere il computer dal dominio, Sysprep modifica il nome del computer.
Può sembrare scoraggiante dire che è necessario eseguire tutte le attività elencate sopra quando si creano delle immagini (o semplicemente si copiano) dei sistemi virtuali. Ma è fondamentale, soprattutto se si utilizzano questi sistemi su una rete con altri sistemi fisici o virtuali, in un dominio o con qualsiasi altra copia di se stessi sulla rete.
Se non si utilizza Sysprep per la duplicazione di sistemi virtuali, è quasi certo che si verificheranno molti problemi (conflitti in Active Directory o altre connessioni di rete), alcuni dei quali imprevisti. Le immagini virtuali, ad esempio, sono particolarmente soggette ad attacchi dal momento che un attacco ben assestato a un'immagine può consentire di accedere concedere a tutte le altre.

Driver e Hardware Abstraction Layer (HAL)
Si è già menzionata la possibilità che i dispositivi virtuali inclusi in un'immagine virtuale non dispongano dei driver di "posta in arrivo" per Windows. Durante la distribuzione (o la distribuzione delle immagini disco con Sysprep), verificare di avere a portata di mano i driver dei dispositivi, poiché il famigerato errore del driver 0x0000007B può verificarsi con grande facilità quando si sposta un'immagine virtuale da un driver del bus di memorizzazione a un altro, esattamente come accade quando si opera con l'hardware fisico. Lo stesso vale per le schede NIC. Molti dei prodotti di virtualizzazione offrono un dispositivo virtuale piuttosto universale, ma potrebbe essere comunque necessario un driver aggiuntivo.
Nemmeno si possono ignorare i potenziali problemi provocati dall'Hardware Abstraction Layer (HAL). Teoricamente, è preferibile creare dei computer virtuali che supportano i multiprocessori ACPI (Advanced Configuration and Power Interface) (vedere intel.com/technology/iapc/acpi), se la tecnologia di virtualizzazione utilizzata lo consente. La conversione tra HAL non è generalmente supportata (per ulteriori informazioni sulle specifiche, vedere support.microsoft.com/kb/309283). Tuttavia, alcune tecnologie di virtualizzazione (e, ciò che conta di più, molte tecnologie di migrazione) promettono di poter spostare in modo sicuro un'installazione di Windows non ACPI in un'installazione ACPI o viceversa. L'affermazione è falsa e, per iniziare, l'installazione di Windows che ne risulta non è supportata da Microsoft quando e se si verificano dei problemi. Si confermano per i sistemi virtualizzati le stesse limitazioni esposte nella pagina Web di supporto appena citata. L'HAL di uno dei computer virtuali di esempio è illustrato nella Figura 3 (in questo caso in esecuzione utilizzando l'HAL monoprocessore ACPI). L'esempio non deve essere confuso con il processore singolo; questo è intercambiabile con il multiprocessore dello stesso tipo.
Figura 3 HAL di un computer virtuale
Figura 3 HAL di un computer virtuale

Modifiche varie
Modificare gli elementi modificabili e accettare ciò che non si può modificare
Quando si intende eseguire la migrazione da fisico a virtuale o viceversa, è necessario ricordare che è possibile modificare alcuni elementi, mentre altri aspetti non sono modificabili. È possibile modificare tutti i seguenti aspetti di un'installazione Windows:
  • HAL (ma solo da multiprocessore a monoprocessore o viceversa, purché siano basati sulla stessa configurazione di alimentazione).
  • Controller di archiviazione di massa (non è facile, ma la maggior parte delle soluzioni di migrazione da fisico a virtuale tentano di eseguire questa operazione di propria iniziativa). La maggior parte dei produttori fornisce una soluzione di archiviazione IDE e una SCSI. La scelta durante la distribuzione deve essere oculata, poiché il passaggio da uno all'altro non è molto semplice. In generale, quando si sceglie la soluzione SCSI si ottiene un dispositivo più affidabile (questo è il caso con le implementazioni di emulazione di dispositivi SCSI della maggior parte dei produttori).
  • Controller di rete (anche se in uno scenario di migrazione da virtuale a virtuale questo sarà probabilmente identico all'interno delle tecnologie proposte da un singolo produttore).
Non è possibile modificare tutti i seguenti aspetti di un'installazione Windows:
  • HAL (tranne che nel caso menzionato prima, quando si utilizza la medesima configurazione di alimentazione). Non è affatto detto che una soluzione di migrazione in grado di garantire questo tipo di modifiche possa garantire un'installazione di Windows stabile o affidabile (un'installazione di questo tipo, inoltre, non è supportata da Microsoft).

Oltre a modificare il SID e il nome del computer, è necessario modificare anche alcuni valori specifici per la tecnologia di elaborazione virtuale che si utilizza. In particolare, si deve modificare l'indirizzo MAC (l'ID univoco per i dispositivi di rete). Molte applicazioni virtuali, inoltre, dispongono di un proprio identificatore univoco. Nella maggior parte dei casi l'identificatore viene memorizzato nei file di configurazione del computer di origine, dunque è necessario avere dimestichezza con la manipolazione di queste voci (garantendone la validità). È opportuno sottolineare che molti prodotti di virtualizzazione che supportano il Pre-Boot Execution Environment (PXE) codificano l'UUID del SMBIOS in base al proprio ID univoco, accentuando la necessità di modificare l'ID (o di lasciare che il software di virtualizzazione esegua la modifica, se possibile) quando si partecipa a un dominio. In caso contrario può risultare impossibile gestire sistemi WDS o RIS (quando si evidenziano conflitti tra GUID). Nella maggior parte delle soluzioni di virtualizzazione provate si possono verificare gravi problemi di rete nel caso di indirizzi MAC duplicati; quindi, se non si intende semplicemente spostare un computer virtuale, è molto importante modificare l'indirizzo MAC se il software di virtualizzazione non esegue già questa operazione.
Gli altri componenti da ricordare durante la preparazione della distribuzione di un sistema virtuale sono gli eventuali dischi collegati o istantanee. In base alla soluzione di virtualizzazione che si utilizza, questi potrebbero essere anche definiti dischi differenziali o con un altro nome. Ma se si esegue Sysprep per preparare un sistema e si dispone di istantanee (o di un altro stato ripristinabile) da includere nel sistema virtuale, queste devono essere distrutte affinché l'immagine resti sicura, affidabile e protetta quando viene duplicata. Nel caso di un'istantanea o di un'altra tecnologia di tipo "annulla le modifiche apportate sul disco", il ripristino di un'istantanea può significare il ritorno a una condizione in cui i sistemi che avevano come origine il computer virtuale precedente ora sono in conflitto con un altro sistema (o addirittura con il sistema di origine, se ripristinato). Dunque sulle eventuali relazioni tra dischi differenziali o istantanee deve essere già stato eseguito Sysprep.

Ottimizzazione
La maggior parte delle tecnologie di virtualizzazione prevede l'aggiunta di strumenti per i computer virtuali che consentono di migliorare le prestazioni e l'interazione con il guest dall'host. In genere, tra i miglioramenti delle prestazioni offerti, si apprezzano l'ottimizzazione dell'input da mouse e da tastiera, oltre a funzionalità migliorate di copia e incolla o di altra interazione tra host e guest. Prima della distribuzione, installare la versione più recente di questi strumenti nei sistemi virtuali.
È inoltre necessario verificare che la memoria del client sia configurata in modo ottimale per il sistema operativo guest, ma anche nel contesto degli host su cui sarà distribuito. È inutile e pericoloso distribuire un'immagine di Windows XP impostata in modo da utilizzare 1 GB di RAM su sistemi host che non dispongono di tanta RAM neanche per eseguire il sistema operativo di origine.
È necessario inoltre ricordare le limitazioni a cui sono sottoposte la maggior parte delle tecnologie virtuali odierne. È importante che gli utenti sappiano come interagire con i dispositivi collegati al sistema virtuale oppure quali applicazioni è possibile o meno utilizzare sul sistema operativo guest (la maggior parte non supporta DirectX 9 o 10, ad esempio, o supportano le versioni meno recenti in modo limitato). Gli utenti potrebbero non conoscere le limitazioni e il modo in cui queste si manifestano (alcune applicazioni non gestiscono neanche questo tipo di errori).

Considerazioni sull'host
In generale non sono molti gli aspetti da considerare relativi al computer host quando si esegue una tecnologia di virtualizzazione, indipendentemente dal fatto che sotto si utilizzi un sistema operativo completo o un hypervisor di tipo 1 eseguito direttamente sull'hardware. La maggior parte delle tecnologie di virtualizzazione sono progettate in modo da garantire che il sistema operativo guest non sia coinvolto per nulla (o solo in minima parte) nelle operazioni dell'host. Tuttavia, quando un guest spostato da un host a un altro provoca dei problemi, verificare quali host sono in uso. Informarsi inoltre sulle limitazioni imposte al prodotto di virtualizzazione su piattaforme specifiche. Può essere possibile passare da uno all'altro, ma nel processo si possono perdere o guadagnare determinate funzionalità dell'hypervisor di tipo 2 del sistema operativo (l'applicazione di virtualizzazione).

Altri meccanismi di distribuzione
Collegamenti correlati a Sysprep
I documenti seguenti sono molto utili per apprendere l'utilizzo di Sysprep:
  • Progettazione di installazioni basate su immagini con Sysprep
  • Utilizzo dello strumento Sysprep per automatizzare la corretta distribuzione di Windows XP
  • Utilizzo dell'Utilità preparazione sistema (Sysprep.exe) per effettuare la duplicazione dei dischi
  • Utilizzo dell'Utilità preparazione sistema su computer diversi

L'utilizzo di Sysprep o della duplicazione del disco (o semplicemente l'esecuzione di Sysprep seguita dalla copia della macchina virtuale) è una scelta ovvia per la distribuzione di sistemi virtuali, ma ne esistono altre. Infatti, che si utilizzi l'imaging o l'installazione, l'impiego di Windows PE può risultare più semplice con la virtualizzazione che con i computer fisici, poiché si utilizzano file ISO invece di CD reali. Alcune tecnologie di virtualizzazione, tuttavia, non sono in grado di gestire in modo corretto i supporti DVD, quindi è opportuno rivolgersi al produttore per informazioni in merito. È possibile utilizzare winnt32 o setup.exe (nel caso di Windows Vista o Windows Server 2008), ma non si notano particolari vantaggi. Se si utilizzano altre tecnologie di distribuzione Microsoft, come gli Automated Deployment Services, la tecnologia di virtualizzazione utilizzata supporta PXE per l'avvio di una distribuzione basata sulla rete, come se si utilizzasse RIS o WDS.

Migrazione
Infine, a parte l'effettiva migrazione di un intero computer, ricordarsi non dell'Utilità di migrazione stato utente (USMT). USMT consente di spostare facilmente le impostazioni dell'utente da un client fisico a un nuovo sistema virtuale. Se gli utenti vogliono eseguire la migrazione dei propri vecchi dati e impostazioni verso un nuovo computer virtuale, sarà possibile, ad esempio, recuperare i file e le impostazioni da Windows XP, memorizzarli su un UNC e inviarli al nuovo computer virtuale.

Wes Miller vive ad Austin, nel Texas. In precedenza, ha lavorato per Winternals Software ad Austin e in Microsoft come Program Manager e Product Manager di Windows. È possibile contattarlo all'indirizzo technet@getwired.com.


 Taccuino: Il futuro intercambiabile
Taccuino
Il futuro intercambiabile
Romi Mahajan

Il filosofo ed economista Karl Marx ha scritto in uno dei suoi saggi che "tutto ciò che è solido si dissolve nell'aria", per sintetizzare la natura delle relazioni in continua mutazione fra le categorie sociali nate con l'industrializzazione e il capitalismo nell'Europa del XIX secolo. Questa potente nozione, che le divisioni e le categorie non si rinsaldano mai in modo completo, può essere coniugata in molti contesti e forme, non ultimo nel mondo della tecnologia, ovvero in un mondo in cui la sola costante è il cambiamento.
In questo settore in rapida trasformazione, non c'è esempio migliore della velocità con cui si verificano i cambiamenti (e le sfide che è necessario affrontare di conseguenza) della nascita delle tecnologie dirette al mercato dei consumatori. Infatti, l'informatica è sempre più rivolta al consumatore e gli indicatori principali del cambiamento ricadono ampiamente nel campo del personale, con effetti enormi su lavoro e vita privata. Il fenomeno si esprime con dei numeri:
  1. Il mondo Web 2.0 riguarda la lettura/scrittura su Internet; per scrittura su Internet si intende soprattutto il ruolo dello scrittore come consumatore.
  2. Le applicazioni e le tecnologie di consumo creano un effetto "aura" sul lavoro.
  3. L'intera struttura di Internet è in fase di riprogettazione proprio a causa dell'influsso dell'informatica di consumo.
  4. Le strutture di riferimento per l'informatica, come i supporti tecnici, devono pianificare e gestire i confini sempre più labili tra tecnologie di uso domestico e di uso aziendale.
  5. Le persone decidono e queste persone sono sia consumatori che lavoratori o professionisti.
  6. La tecnologia "preferita" di una persona è quasi sempre un prodotto di consumo, non un prodotto destinato al mercato aziendale.
Le implicazioni sono profonde e le categorie sono intercambiabili, come è facile notare dalla breve serie di esempi riportata di seguito. Un mio amico che lavora in una società ad alto tasso tecnologico mi ha confidato che l'8% di tutte le chiamate al supporto tecnico in azienda riguardavano gli aggiornamenti di iTunes. Il white paper di Cisco "The Exabyte Era" (in inglese) inizia con due punti: Internet non sta crollando sotto il peso dello streaming video e YouTube è solo l'inizio. Apple Corporation ha raggiunto circa il 10 percento del mercato dei computer portatili venduti al dettaglio nel marzo 2007, secondo uno studio di NDP Group: ecco l'effetto aura dell'iPod al lavoro. Microsoft sta investendo capitali ingenti in aree quali giochi, musica, fotografia digitale e host video. Infine, oggi le aziende fissano le riunioni su Second Life.
I marchi tecnologici, per di più, sono stati elevati e genericizzati nell'aria rarefatta della permanenza. Le persone "Googlano" le cose, tutti parlano di iPod, si fanno vedere su "myspace" e giocano con "Xbox®". Si è costituita una connessione emotiva tra le tecnologie e le persone che le utilizzano. L'effetto di questa connessione funziona transitivamente dall'ufficio a casa e viceversa, per approdare infine sulla considerazione che le persone nutrono per le aziende che producono i dispositivi, le applicazioni, i siti Web e le community. Le percezioni create (buone, cattive o neutre che siano) vivono con i consumatori in entrambe le incarnazioni personale e professionale.
Ciò che attiene a un individuo è, quindi, una questione complessa. È di certo fondamentale un cambiamento culturale se le aziende vogliono rispondere alle sfide simultanee di scalare i messaggi proposti, mostrarsi personalmente vicini ai consumatori e occuparsi dei clienti. In un'era precedente, prima dell'iperspecializzazione dei ruoli, i messaggi generici erano la sostanza del marketing. Negli ultimi anni, invece, si è imposto il messaggio specifico che consente una precisione chirurgica su categorie quali il ruolo aziendale, il segmento di pubblico, le dimensioni dell'azienda e le tecnologie specifiche. Ciò che si è perso, tuttavia, è il fatto che davvero "tutto ciò che è solido si dissolve nell'aria" e l'unico modo per creare una connessione e anticipare le mutazioni consiste nel fare riferimento alle persone nelle incarnazioni personali/di consumatore.
Essere intercambiabili significa essere fungibili ed evitare le distinzioni nette fra le categorie. In altre parole non è più possibile erigere barriere tra le nozioni di tecnologie di consumo e aziendali. L'informatica di consumo è già qui e il futuro è davvero intercambiabile.

Romi Mahajan è direttore del marketing del team Technical Audience and Platform Marketing in Microsoft. Romi ha pubblicato saggi in molti campi, tra cui politica, ambiente, tecnologia e sociologia.


 Windows Confidential: Un joystick non deve essere un microonde
Windows Confidential
Un joystick non deve essere un microonde
Raymond Chen

Di recente ho letto un post in un blog di un collega, Audio Fool, che mi ha ricordato di un errore fatto molti anni fa e che ha continuato a perseguitarmi. Quando l'interfaccia del joystick force feedback DirectInput® era in fase di progettazione e sviluppo, i produttori di joystick furono invitati presso la sede Microsoft di Redmond, WA per discutere i dettagli dell'interfaccia proposta e fornire suggerimenti e idee originali (detto senza ironie).
Nel corso delle riunioni furono affrontati molti problemi, ma quello che non riesco a dimenticare è la divergenza di opinioni sulla necessità di esprimere le forze periodiche come un periodo o come una frequenza. Uno dei rappresentanti dei produttori fece animatamente rilevare che la sua azienda aveva già scritto un driver in cui le forze periodiche venivano espresse in termini di frequenza e non avevano alcuna intenzione di modificarlo. Se la riunione era stata organizzata proprio per discutere dei dettagli di un'interfaccia nuova di zecca, come poteva mai pensare un produttore di uscire dalla sala senza dover apportare qualche modifica al proprio driver?
Il rappresentante di questo produttore si lamentò talmente tanto da indurci a rinunciare e a convenire sull'utilizzo della frequenza invece della periodicità per specificare le forze periodiche. La questione sembrava trascurabile. Una forza con una frequenza di 10 oscillazioni per secondo equivale a una forza con un periodo di un decimo di secondo. Periodo e frequenza sono semplicemente uno l'inverso dell'altro.
Invece non è esattamente così. Il periodo era espresso in millisecondi, con una gamma dinamica risultante pari a 1 ms per un periodo inferiore ai 50 giorni. Un periodo di 50 giorni è impercettibile su una scala dei tempi umana e un periodo di 1 ms è talmente rapido che non può essere neanche descritto come un fenomeno periodico, ma viene invece percepito come un tono musicale.
D'altra parte, la frequenza era espressa in hertz, con un intervallo dinamico risultante di 1 Hz per 4 miliardi di cicli al secondo. Se può sembrare strana l'idea di produrre musica con un joystick, si pensi alle forze che si generano nella banda di frequenze di un microonde!
Il problema è che il potenziale espressivo praticamente inutile alla sommità della gamma di frequenze veniva ottenuta a scapito della sezione inferiore. Pare però che chi utilizza i simulatori di volo sia un grande consumatore di forze periodiche con periodi relativamente lunghi. Non conosco bene la fisica che c'è dietro, ma mi dicono che uno degli effetti che i piloti devono controllare è una lenta forza periodica sullo joystick misurabile nell'ordine di qualche minuto. L'aereo ha una tendenza naturale a viaggiare in un'onda sinusoidale verticale molto lenta, che i piloti devono contrastare per mantenere un volo orizzontale. Se si esprimesse la forza in base al periodo, il programma di simulazione di volo potrebbe specificare un periodo di 120.000 millesimi di secondo. Espresso in frequenza, tuttavia, il valore è di 0,0083 Hz, che è molto più lento della frequenza più lenta che può essere espressa nell'interfaccia del driver, ovvero 1 Hz. Quindi, la forza più lenta che un simulatore di volo può richiedere è una forza che si ripete ogni secondo, che è ancora troppo veloce rispetto all'effetto fisico che si desidera ottenere con il simulatore di volo.
Poiché questo problema continua ad assillarmi dopo tutti questi anni, ho ripassato di recente la documentazione dell'interfaccia force feedback. Con sorpresa mi sono reso conto che, per esprimere gli effetti periodici, la struttura DIPERIODIC utilizza il periodo invece della frequenza (e in buona parte utilizza i microsecondi, consentendo quindi di suonare musica o pilotare un aereo). L'errore deve essere stato corretto, oppure sto invecchiando e la memoria inizia a giocarmi brutti scherzi. In ogni caso non dovrò più preoccuparmi di questo errore. Sempre ammesso che sia mai esistito.

Raymond Chen, The Old New Thing, così come nel suo libro che porta lo stesso titolo (Addison-Wesley, 2007), vengono illustrate la storia di Windows e la programmazione in Win32. Quel colore ti sta benissimo.