 TechNet Magazine May 2008

TechNet Magazine May 2008

Amministrazione di Windows: Backup e ripristino per Active Directory in Windows Server 2008

Windows Server 2008 e la nuova utilità Windows Server Backup apportano numerosi cambiamenti e miglioramenti per il backup. In questo articolo vengono fornite informazioni approfondite per eseguire il backup e il ripristino Active Directory nel nuovo sistema operativo server.

Gil Kirkpatrick Amministrazione di Windows: Progettazione di strutture di unità organizzative efficaci

Un numero eccessivo di amministratori sottovaluta l'importanza di disporre di una struttura di unità organizzative ben progettata. Scoprite perché è fondamentale disporre di una strategia efficace per le unità organizzative e individuate la struttura più appropriata per la vostra organizzazione.

Ken St. Cyr Amministrazione di Windows: Estensione dello schema di Active Directory

Molte applicazioni basate su Active Directory definiscono le proprie modifiche nello schema. Ma è importante che tali modifiche non abbiano alcun impatto su altre applicazioni. Scopri una panoramica sull'estensione di Active Directory tramite gli oggetti classSchema e attributeSchema.

Vikas Malhotra System Center: Introduzione a System Center Mobile Device Manager

Il nuovo sistema System Center Mobile Device Manager fornisce un set completo di strumenti per la gestione dei dispositivi Windows Mobile attraverso uno snap-in MMC o Windows PowerShell. Scoprite come utilizzare questo strumento fondamentale per gestire i dispositivi mobili, potenziare la sicurezza e fornire funzionalità Mobile VPN.

Matt Fontaine System Center: Novità di System Center Essentials SP1

Con il Service Pack 1 vengono introdotte delle importanti funzioni avanzate per System Center Essentials 2007. Esplorate alcune delle novità principali che miglioreranno l'esperienza utente e semplificheranno l'amministrazione.

Pete Zerger Dal redattore: Un caloroso benvenuto alla rubrica "Inside SharePoint"

Joshua Hoffman Lettere: La parola ai lettori

Toolbox: Nuovi prodotti per professionisti IT

Greg Steen Exchange Queue & A: Exchange 2007 SP1 Deployment

In questo numero, risponderemo alle vostre domande relative ad Exchange Server 2007 SP1.

Nino Bilic Utility Spotlight: Strumento SharePoint Capacity Planning

Esplorate lo strumento SharePoint Capacity Planning e scoprite come è possibile progettare una topologia per distribuire SharePoint e quindi riesaminarla dopo aver eseguito simulazioni di carico e utilizzo.

Peter Skjøtt Larsen and Satish Mathew Inside SharePoint: Come costruire un'infrastruttura SharePoint

SharePoint è potente, ma la sua complessità può trasformare la sua distribuzione in una vera e propria sfida. A questo proposito, la nostra rubrica dedicata a SharePoint può essere di aiuto. In questo primo numero, forniamo una panoramica dell'architettura di SharePoint e illustriamo come configurare un'infrastruttura SharePoint di base con

Pav Cherny Windows PowerShell: Automatizzare la gestione di Active Directory

La versione 1 di Windows PowerShell offre capacità di gestione di Active Directory poco meno che impressionanti. Scoprite come utilizzare i componenti aggiuntivi per migliorare il vostro modo di lavorare con gli oggetti Active Directory direttamente da Windows PowerShell.

Don Jones Hey, Scripting Guy!: Utilizzo delle espressioni regolari

Gli scripting guy visitano il Louvre, si dedicano alla critica d'arte e mostrano come utilizzare le espressioni regolari in uno script che esegue ricerche e sostituzioni.

The Microsoft Scripting Guys Security Watch: Principi di sicurezza quantistica

Scoprite come il principio di indeterminazione di Heisenberg e altri elementi della fisica quantistica potrebbero frenare l'evoluzione delle strategie di sicurezza. (Nota: durante la stesura di questo articolo non è stato fatto del male ad alcun gatto.)

Jesper M. Johansson File desktop: Come sbarazzarsi del ruolo di amministratore

Perché tutti utilizzano l'esecuzione come amministratori? Wes Miller esamina i rischi dell'esecuzione come amministratori ed esplora i vantaggi dell'esecuzione come utenti.

Wes Miller Taccuino: Più mouse, un solo PC

Come comportarsi quando il numero degli studenti supera il numero di computer disponibili in un'aula? Microsoft Research India ha sviluppato una soluzione, denominata MultiPoint, che consente l'utilizzo simultaneo di più mouse su un unico computer.

Kentaro Toyama Windows Confidential: Le icone a 16 bit sono così fuori moda

Raymond Chen esamina il motivo per cui Windows Vista non supporta le icone a 16 bit e si chiede se qualcuno abbia mai notato tale caratteristica.

Raymond Chen


 Amministrazione di Windows: Backup e ripristino per Active Directory in Windows Server 2008
Amministrazione di Windows Gil Kirkpatrick

Backup e ripristino per Active Directory in Windows Server 2008
Panoramica:
  • Differenze tra NTBACKUP e Windows Server Backup
  • Opzioni e strumenti di backup
  • Opzioni e strumenti di ripristino
  • Suggerimenti per una efficace strategia di backup Active Directory

È oramai noto che Servizi di dominio Active Directory (ADDS) è un componente cruciale nell'infrastruttura Windows. Se Active Directory ha dei problemi, la rete diventa praticamente inutile. Di conseguenza, il piani di backup e ripristino per Active
Directory sono fondamentali per la sicurezza, la continuità operativa e la conformità normativa.
Windows Server® 2008 apporta nuove funzioni ad Active Directory®, due delle quali con un impatto significativo sui piani di backup e ripristino: la nuova utilità Windows Server Backup e la funzione che consente di lavorare con gli snapshot del servizio Copia Shadow del volume di Active Directory. In questo articolo verranno descritte le modifiche apportate da questi miglioramenti e come sfruttarne i vantaggi offerti per semplificare le attività di backup per Active Directory.

Differenze tra NTBACKUP e Windows Server Backup
Impostazioni di Criteri di gruppo
Windows Server Backup fornisce diverse impostazioni di Criteri di gruppo che offrono un controllo limitato sul funzionamento dei processi di backup sui server. Con questi criteri di backup, è possibile attenuare alcuni dei rischi in cui si incorre quando persone prive dell'apposita autorizzazione eseguono il backup per ottenere l'accesso a dati riservati. Le opzioni includono:
Consenti solo backup di sistema Se è impostata questa opzione, Windows Server Backup può eseguire il backup solo dei volumi di sistema critici. Non può eseguire il backup dei volumi standard. Non consentire l'utilizzo di dispositivi di archiviazione collegati localmente come destinazione per il backup Quando è abilitata, questa impostazione non consente di eseguire il backup nelle unità collegate in locale. È possibile eseguire il backup solo in una condivisione di rete.
Non consentire l'utilizzo della rete come destinazione di backup Questa impostazione non consente di eseguire il backup in una condivisione di rete.
Non consentire l'utilizzo di supporti ottici come destinazione di backup Se è impostata questa opzione, Windows Server Backup non può eseguire il backup su un dispositivo ottico, ad esempio un'unità DVD registrabile.
Non consentire backup a esecuzione unica Questa impostazione non consente a Windows Server Backup di eseguire backup ad hoc non pianificati. È consentita l'esecuzione solo dei backup pianificati attraverso lo snap-in MMC di Windows Server Backup.

L'utilità NTBACKUP ben nota e disponibile a partire da Windows NT® 3.5 non è più utilizzabile. È ora possibile sostituirla con Windows Server Backup. Tra l'altro, questo nuovo strumento non è solo una copia di NTBACKUP; è una tecnologia di backup completamente nuova che implicherà il ripensamento della modalità con la quale si esegue il backup dei sistemi.
Sebbene Windows® Server Backup sia solo una soluzione di backup incorporata per Windows Server 2008, non rappresenta una semplice sostituzione di NTBACKUP. La principale differenza consiste nel fatto che Windows Server Backup è una soluzione di backup da disco a disco, che non supporta il backup su nastro. È possibile creare immagini di backup nei volumi di disco collegati direttamente, nelle condivisioni di rete, sui dischi rigidi USB esterni e sui DVD registrabili a più volumi. Tuttavia, non è possibile eseguire il backup su nastro. Per essere chiari, è sempre possibile collegare un'unità nastro su un server Windows Server 2008 e copiare le immagini di backup generate da Windows Server Backup su tale unità, ma si potrà farlo solo utilizzando un software di terze parti.
Se NTBACKUP è uno strumento di ripristino e backup basato su file, Windows Server Backup è un'utilità basata su volumi e blocchi. L'origine di backup di Windows Server Backup è un insieme di volumi, ognuno dei quali con una serie di blocchi del disco. Ciò si rivela estremamente più efficiente dell'eseguire il backup dei file attraverso il file system. Eseguire il backup in base ai blocchi consente anche a Windows Server Backup di utilizzare gli snapshot del servizio Copia Shadow del volume per eseguire backup incrementali a livello di blocco e di creare snapshot sul volume di destinazione per rendere più semplice l'uso di più backup (e ridurre lo spazio utilizzato dagli stessi).
Anche se si eseguono backup completi, Windows Server Backup non utilizza una grande quantità di spazio sui dischi di destinazione. Ad esempio, è possibile eseguire più backup completi dello stesso volume. Dato che Windows Server Backup utilizza gli snapshot del servizio Copia Shadow del volume sui dischi di destinazione dove archivia le immagini di backup, gli snapshot archivieranno solo i blocchi modificati. Ciò riduce sostanzialmente lo spazio utilizzato dai numerosi backup completi. In questo modo, viene eliminata la necessità di eseguire più operazioni di ripristino per recuperare un backup incrementale. Anche se lo snapshot archivia soltanto i delta per ogni backup, il servizio Copia Shadow del volume fa in modo che ogni backup risulti completo.
Tuttavia, bisogna essere consapevoli del fatto che si potrà godere dei vantaggi offerti dagli snapshot del servizio Copia Shadow del volume sulla destinazione solo se il backup viene eseguito su un disco rigido locale; Windows Server Backup non può eseguire operazioni relative al servizio Copia Shadow del volume sui backup archiviati su DVD o in condivisioni di rete.
Come vantaggio aggiuntivo, Windows Server Backup archivia le proprie immagini di backup in formato Microsoft® Virtual Hard Disk (VHD). È possibile prendere un'immagine e montarla come volume in una macchina virtuale su cui è in esecuzione Microsoft Virtual Server 2005. Si può semplicemente montare i file VHD su una macchina virtuale e ricercare uno specifico file anziché eseguire ripristini di prova dei nastri per individuare quello che contiene il file. (Prestare attenzione a quanto segue: non è possibile prendere un'immagine di backup e utilizzarla per avviare una macchina virtuale. Dato che la configurazione dell'hardware di backup non corrisponde a quella della macchina virtuale, non è possibile utilizzare Windows Server Backup come strumento di migrazione da macchina fisica a virtuale.)
Esiste uno svantaggio associato al fatto che l'utilità Windows Server Backup è basata su volumi e blocchi. Dato che questo nuovo strumento considera l'origine di backup come insieme di volumi e blocchi, non consente di eseguire il backup solo dei file selezionati, ma richiede il backup dell'intero volume. Tra l'altro, esiste anche il problema che, per impostazione predefinita, non è possibile archiviare un'immagine di backup in uno dei volumi sottoposti a backup (esistono numerosi modi per risolvere questo problema; vedere support.microsoft.com/kb/944530). Ciò comporta profonde implicazioni per il backup dello stato del sistema, come verrà illustrato più avanti nell'articolo.

Installazione di Windows Server Backup
Windows Server Backup è una "funzione" di Windows Server 2008 e non è installata per impostazione predefinita. Prima di eseguire un backup con Windows Server Backup, è necessario installare la funzione, utilizzando Server Manager o l'utilità della riga di comando SERVERMANAGERCMD:
C:\> servermanagercmd -install Backup-Features
Windows Server Backup è un'utilità costituita da due funzioni secondarie, ovvero Windows Server Backup e Strumenti da riga di comando. Strumenti da riga di comando fa riferimento a una serie di cmdlet Windows PowerShellTM (e non allo strumento da riga di comando WBADMIN .EXE) Pertanto, se si sceglie di installare entrambe le funzioni secondarie, è necessario installare la funzione Windows PowerShell.
Dopo aver installato Windows Server Backup, è possibile individuare lo snap-in Microsoft Management Console (MMC) nel nodo di archiviazione di Server Manager e nel menu Strumenti di amministrazione. Se si installa Windows Server Backup in un'installazione Server Core di Windows Server 2008, utilizzare il comando OCSETUP (ricordare che si tratta di un comando che distingue tra maiuscole e minuscole):
C:\> ocsetup WindowsServerBackup
Una descrizione completa del processo di installazione è disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=113146.
Windows Server Backup non consente di eseguire il backup delle immagini create con NTBACKUP. Per una situazione di questo tipo, Microsoft ha reso disponibile una versione scaricabile di NTBACKUP per Windows Server 2008 (vedere go.microsoft.com/fwlink/?LinkId=113147).

Componenti di Windows Server Backup
L'architettura dell'applicazione Windows Server Backup rappresenta una novità significativa. Questa nuova soluzione di backup è costituita da quattro componenti:
  • Interfaccia utente MMC (WBADMIN.MCS)
  • Interfaccia della riga di comando
(WBADMIN EXE)
  • Servizio di backup (WBENGINE.EXE)
  • Insieme di cmdlet di Windows PowerShell
Ripartire l'applicazione in un client e in un servizio distinti genera numerosi vantaggi, compresa una maggiore affidabilità. Sia che si avvii un backup dal client MMC che dall'interfaccia della riga di comando, il servizio WBENGINE svolge sempre il lavoro più difficile. I programmi client si limitano a segnalare lo stato del backup. Pertanto, se si arresta l'esecuzione del client, il backup verrà comunque completato. Il client verrà arrestato e l'esecuzione del servizio continuerà fino al normale completamento. È ovviamente possibile interrompere realmente il backup, ma è necessario farlo in modo esplicito.
L'altro vantaggio di questa architettura ripartita è che consente di utilizzare il client per gestire i backup sui computer remoti. Ciò si rivela particolarmente utile per eseguire il backup dei computer core Windows Server 2008.
Windows Server Backup supporta ripristini bare metal utilizzando Ambiente ripristino Windows, o WinRE, fornito sul supporto di installazione di Windows Server 2008. WinRE consente di eseguire il ripristino di un server in modo estremamente semplice. Più avanti nell'articolo verrà illustrato come eseguire ripristini bare metal. È opportuno ricordare che Windows Server Backup supporta numerose impostazioni di Criteri di gruppo per la gestione dei backup, illustrati nel riquadro laterale "Impostazioni di Criteri di gruppo".

Servizio Copia Shadow del volume
Windows Server Backup utilizza il servizio Copia Shadow del volume in tre diversi modi. Quando si avvia un backup completo su Windows Server 2008, l'applicazione crea in primo luogo una copia shadow di tutti i volumi di origine. In questo modo, si ottiene una visione coerente del file system con cui potrà lavorare il software di backup. (I risultati sono simili a quelli che si ottenevano con NTBACKUP.) Windows Server Backup quindi copia i blocchi (uno a uno) dal volume di origine alla destinazione di backup, creando un'immagine VHD per ogni volume di backup nel processo.
Se non viene specificato diversamente, Windows Server Backup crea anche uno snapshot del volume di origine per consentire al servizio Copia Shadow del volume di tenere traccia di tutti i blocchi modificati nel volume. Ciò consente a Windows Server Backup di creare backup incrementali a livello di blocco che richiedono solo la lettura dei blocchi modificati del volume di origine. Anziché dover leggere e scrivere un intero file a seguito della modifica di un unico bit nello stesso, Windows Server Backup può leggere e scrivere solo il blocco modificato.
Ciò consente backup incrementali molto efficaci, ma con un aumento dell'I/O su disco per le operazioni di scrittura nel volume di origine. Se si esegue il backup di un volume particolarmente occupato o critico dal punto di vista delle prestazioni, è necessario disabilitare lo snapshot del servizio Copia Shadow del volume nel volume di origine selezionando il collegamento Configure Performance Settings e disabilitando i backup incrementali in tale volume (come mostrato nella figura 1).
Figura 1 Disabilitare i backup incrementali nei volumi occupati
Figura 1 Disabilitare i backup incrementali nei volumi occupati
Quando il backup è completato, Windows Server Backup acquisisce uno snapshot del volume di destinazione (sempre che si esegua il backup su un disco rigido collegato in locale). Al momento del successivo backup, i file VHD di destinazione vengono sovrascritti. Tuttavia, dato che il servizio Copia Shadow del volume mantiene copie shadow del volume di destinazione, esistono più versioni di ogni file VHP corrispondente a ciascuno dei backup completi. In tal modo, si ottengono più backup completi eseguendo un'unica operazione e modificando i blocchi.

Backup nelle condivisioni di rete
Eseguire il backup in una condivisione di rete si rivela semplice come eseguirlo in un volume locale. La principale differenza sta nel fatto che non è possibile creare uno snapshot del servizio Copia Shadow del volume remoto. Pertanto, ogni backup completo sovrascriverà quello precedente e ciò permette di mantenere in una condivisione di rete solo l'ultima immagine del backup completo di ogni server. A causa di questo limite, non è possibile utilizzare l'utilità di pianificazione di Windows Server Backup per pianificare i backup in una condivisione di rete. Tuttavia, è possibile utilizzare l'Utilità di pianificazione di Windows per eseguire il programma della riga di comando WBADMIN per l'esecuzione di backup completi in una condivisione di rete. Se si decide di pianificare backup completi in una condivisione di rete in questo modo, modificare la cartella di destinazione per ogni backup per evitare che vengano sovrascritti i backup precedenti.

Backup sui DVD registrabili
Windows Server Backup supporta anche l'esecuzione dei backup su supporti ottici, quali i DVD scrivibili. Inoltre, è possibile creare set di backup che utilizzano più volumi. Windows Server Backup comprime sempre i backup sui DVD e, di conseguenza, è possibile eseguire ripristini di volumi o sistemi completi solo da DVD. Windows Server Backup non supporta backup e ripristini a livello di file o stato del sistema quando si utilizzano i DVD. Inoltre, non è possibile pianificare i backup su DVD.

Backup e ripristini dello stato del sistema
I backup dello stato del sistema, che includono solo i file selezionati e alcuni database delle applicazioni (anziché gli interi volumi), si rivelano semplici e spesso fondamentali. Tuttavia, i build iniziali di Windows Server 2008 non supportavano i backup e i ripristini dello stato del sistema. In effetti, lo strumento di backup eseguiva il backup esclusivamente dei volumi di sistema critici (non si avevano in tal modo i volumi necessari per ripristinare e riavviare il sistema operativo e le applicazioni fondamentali). Tali volumi di sistema critici erano l'equivalente orientato al volume di un backup dello stato del sistema.
Grazie ai suggerimenti forniti dai clienti, Microsoft ha aggiunto a Windows Server Backup delle funzionalità di backup e ripristino dello stato del sistema. L'applicazione crea più file VHD, uno per ogni volume che ospita i dati dello stato del sistema, ma copia nei file VHD esclusivamente i file e i database necessari. Un altro problema consiste nel fatto che, quando si esegue un backup dello stato del sistema, Windows Server Backup non crea uno snapshot del volume di destinazione come in un normale processo di backup. In questo caso, ogni backup dello stato del sistema genera un nuovo insieme di file VHD e, di conseguenza, non si ottengono quei benefici in termini di spazio garantiti dai backup dei volumi basati su snapshot.
È possibile eseguire un backup dello stato del sistema solo utilizzando il programma della riga di comando BADMIN.EXE; lo snap-in MMC non fornisce questa opzione. Per eseguire un backup dello stato del sistema, viene utilizzato questo comando:
C:\> wbadmin start systemstatebackup
–backuptarget:e:
WBADMIN eseguirà quindi il backup dei file di sistema e dei database delle applicazioni critici nel volume di destinazione, in una cartella riservata ai backup dello stato del sistema. Il backup dello stato del sistema su un controller di dominio Windows Server 2008 a 32 bit con un albero di informazioni delle directory utilizza poco più di 6 GB; il processo utilizza 5 GB in più che in Windows Server 2003 perché Windows Server Backup acquisisce i file principali del sistema operativo che non venivano acquisiti da NTBACKUP.
Il tempo richiesto per eseguire il backup dello stato del sistema è anche maggiore, come sicuramente si immaginava. Questi numeri, ovviamente, si basano su una versione non definitiva del sistema operativo. Sarà necessario testarla nell'ambiente in uso, ma è probabile che si dovranno pianificare backup dello stato del sistema di dimensioni maggiori (e con tempi più lunghi) quando si trasferiscono i controller di dominio su Windows Server 2008.

Backup di un server con lo snap-in MMC
Quando si esegue lo snap-in MMC di Windows Server Backup (vedere la figura 2), è possibile configurare una pianificazione del backup oppure eseguire immediatamente un backup ad hoc. In questo caso, è possibile selezionare l'opzione Backup per eseguire un backup immediato.
Figura 2 Snap-in MMC di Windows Server Backup
Figura 2 Snap-in MMC di Windows Server Backup
Come mostrato nella figura 3, è possibile decidere se si desidera eseguire il backup di tutti i volumi sul server oppure solo di specifici volumi prescelti. Se si seleziona Server completo, Windows Server Backup eseguirà il backup di tutti i volumi montati, ma non sarà possibile eseguire il backup di un disco fisso montato (è invece necessario eseguire il backup su un DVD registrabile o in una condivisione di rete).
Figura 3 Uso della finestra di dialogo per la configurazione del backup per specificare tutti i volumi o solo quelli prescelti
Figura 3 Uso della finestra di dialogo per la configurazione del backup per specificare tutti i volumi o solo quelli prescelti
In questo esempio, si desidera eseguire il backup su un disco rigido locale e, quindi, viene selezionata l'opzione Personalizza. Una finestra di dialogo consente di selezionare i volumi di cui eseguire il backup (vedere la figura 4). Per impostazione predefinita, Windows Server Backup seleziona la casella Enable system recovery, che consente di selezionare il volume di avvio, il volume del sistema operativo e tutti gli altri volumi con database delle applicazioni e file di sistema critici. Su un controller di dominio, sono inclusi i volumi che ospitano SYSVOL, l'albero di informazioni delle directory di Active Directory e i registri di Active Directory. Questo processo corrisponde a un backup dello stato del sistema, ma esegue il backup di tutti i volumi critici e non solo dei file critici in tali volumi. In effetti, è anche possibile eseguire un ripristino dello stato del sistema da un set di backup di ripristini di sistema.
Figura 4 Selezione di specifici volumi da sottoporre a backup
Figura 4 Selezione di specifici volumi da sottoporre a backup
Dopo aver selezionato il tipo di destinazione (unità locale o condivisione di rete) e specificato la destinazione desiderata, Windows Server Backup richiede di scegliere un backup "VSS copy" o "VSS full". Ci si potrebbe confondere, dato che entrambe le opzioni consentiranno di eseguire il backup degli interi volumi selezionati. La differenza sta nel modo in cui Windows Server Backup gestisce i file di origine dopo che sono stati sottoposti a backup. Se si seleziona l'opzione "VSS copy", Windows Server Backup consentirà di mantenere solo i file sottoposti a backup. Se si sceglie l'opzione "VSS full", Windows Server Backup reimposterà l'archivio.

Backup di un server dalla riga di comando
Se si desidera creare lo script del processo di backup oppure eseguire il backup di un server su un'installazione Server Core, è possibile utilizzare il programma della riga di comando WBADMIN.EXE. WBADMIN fornisce un insieme di opzioni che eseguono essenzialmente le stesse funzioni dello snap-in MMC, inclusa la gestione delle pianificazioni delle attività di backup.
Si supponga di volere avviare il servizio WBENGINE, che consentirà di eseguire il processo di backup. È sufficiente immettere il seguente comando:
C:\> wbadmin start backup –include:c:,d:
–backuptarget:e:
Oppure, per eseguire il backup di tutti i volumi di sistema critici, è possibile immettere il seguente comando:
C:\> wbadmin start backup -allcritical
–backuptarget:e:
Dopo aver avviato il backup, WBADMIN continua l'esecuzione e mostra l'avanzamento del backup. Se si arresta l'esecuzione di WBADMIN, il backup continuerà come processo in background. È quindi possibile ricollegare WBADMIN a un backup in esecuzione utilizzando il seguente comando:
C:\> wbadmin get status
Se invece si desidera arrestare l'esecuzione di un processo di backup, è sufficiente immettere quanto segue:
C:\> wbadmin stop job

Pianificazione dei backup con lo snap-in MMC
L'utilità di pianificazione dei backup integrata in Windows Server Backup è stata appositamente progettata per il seguente scopo: semplificare la pianificazione di backup di sistema completi giornalieri su un volume del disco locale. È possibile utilizzare l'utilità di pianificazione incorporata per far ruotare automaticamente i backup tra più volumi di destinazione. Se si dispone di dischi rigidi facilmente rimovibili (o si utilizza dischi rigidi USB), è possibile utilizzare questa funzione per configurare uno schema di rotazione in cui il disco di backup viene prima rimosso e quindi reinserito sul server per il successivo backup pianificato.
L'utilità di pianificazione di Windows Server Backup consente di pianificare solo backup giornalieri. In effetti, non è possibile pianificare i backup da eseguire in specifici giorni della settimana. Pertanto, se non si desidera che i backup pianificati vengano eseguiti a cadenza giornaliera, è necessario utilizzare direttamente l'Utilità di pianificazione di Windows.
Quando si configura un backup pianificato su un disco locale, l'Utilità di pianificazione di Windows provvederà a formattare il disco, a configurare una specifica struttura di cartelle e a rendere il disco di destinazione invisibile a Esplora risorse. È necessario che il disco di destinazione sia un volume di base in quanto l'Utilità di pianificazione di Windows non è in grado di eseguire il backup di dischi configurati come volumi dinamici.
La pianificazione dei backup attraverso lo snap-in MMC è un'attività estremamente semplice. In questo esempio, viene prima selezionato il collegamento Pianificazione backup, quindi viene specificato il tipo di backup e i volumi da includere nel processo e, infine, Windows Server Backup visualizzerà la finestra di dialogo "Specify backup time" (vedere la figura 5).
Figura 5 Impostazione dell'ora per i backup giornalieri
Figura 5 Impostazione dell'ora per i backup giornalieri
Dopo aver selezionato l'ora in cui si desidera eseguire i backup, è possibile selezionare i volumi sui quali si desidera eseguire il processo. In questo caso, viene selezionato il volume di backup E:, come mostrato nella figura 6. Windows Server Backup tenta di selezionare un volume di destinazione appropriato, ma se il disco sul quale si desidera eseguire il backup non è disponibile, è possibile utilizzare il pulsante Show All Available Disks per visualizzare tutti i dischi collegati. Dopo aver visualizzato due finestre di conferma, Windows Server Backup formatta i volumi di destinazione e pianifica l'attività di backup utilizzando l'Utilità di pianificazione di Windows.
Figura 6 Definizione del disco di destinazione per un backup pianificato
Figura 6 Definizione del disco di destinazione per un backup pianificato
Dopo il completamento di un backup pianificato, Windows Server Backup acquisisce uno snapshot del volume di destinazione. Quindi, a cadenza settimanale, crea una nuova immagine di base. L'attività viene inserita nel registro Microsoft/Backup/Operational. È possibile esaminare il registro per controllare se i backup sono stati eseguiti correttamente; inoltre, è possibile associare un'attività, ad esempio l'invio di un messaggio di posta elettronica, a eventi riusciti o falliti per potere essere sempre informati sullo stato dei backup pianificati.

Pianificazione dei backup dalla riga di comando
Se si pianificano backup su un'installazione Server Core o si desidera semplicemente creare uno script del processo, è possibile gestire la pianificazione dei backup utilizzando la riga di comando WBADMIN. Per aggiungere un backup pianificato, è possibile utilizzare il comando WBADMIN ENABLE BACKUP, specificando la destinazione, l'origine e l'ora pianificata, come mostrato di seguito:
C:\> wbadmin enable backup –addtarget:e:
-include:c:,d: -schedule:06:00,12:00,18:00
Questo comando consente di eseguire il backup delle unità C: e D: sull'unità E: tre volte al giorno, alle 06.00, alle 12.00 e alle 18.00 (la pianificazione è basata sul formato a 24 ore). Per eseguire il backup dei volumi di sistema critici (dai quali è possibile seguire un ripristino bare metal o un ripristino dello stato del sistema), sostituire il parametro –include con il parametro –allcritical.
È inoltre possibile utilizzare WBADMIN per disabilitare tutti i backup pianificati, come riportato di seguito:
C:\> wbadmin disable backup
Questo comando eliminerà tutti i processi di backup pianificati creati con l'utilità di pianificazione di Windows Server Backup e renderà disponibili tutti i volumi di destinazione di backup per il normale uso. È sempre possibile utilizzare lo snap-in MMC WBADMIN per gestire in remoto le attività di backup e ripristino dei server Server Core.

Ripristino bare metal di un controller di dominio
Uno dei miglioramenti più interessanti per il backup e il ripristino è l'integrazione di WinRE nel processo di installazione. Quando si avvia Windows Server 2008 dal supporto di installazione, è possibile scegliere l'opzione Ripristina il computer, come mostrato nella figura 7. È stato messo in evidenza questo punto perché l'opzione potrebbe sfuggire se non si presta particolare attenzione.
Figura 7 L'opzione Ripristina il computer è disponibile sulla schermata di installazione
Figura 7 L'opzione Ripristina il computer è disponibile sulla schermata di installazione
Dopo la selezione dell'opzione Ripristina il computer sulla schermata di installazione, Windows consente di selezionare un'opzione di ripristino, come mostrato nella figura 8. In questo caso, viene selezionata l'opzione Ripristino completo PC Windows, che attiva Ambiente ripristino Windows.
Figura 8 Impostazione delle opzioni di ripristino del sistema
Figura 8 Impostazione delle opzioni di ripristino del sistema
Dopo la selezione del sistema operativo da ripristinare (generalmente è disponibile un'unica opzione), WinRE consente di selezionare il backup dal quale si desidera eseguire il ripristino. Per impostazione predefinita, WinRE seleziona il backup di sistema completo più recente, ma è anche possibile specificare altri backup archiviati sui dischi locali oppure ricercare nella rete i backup archiviati nelle condivisioni file su altri server.
In questo esempio, è stato selezionato il backup di sistema completo più recente. La finestra di dialogo successiva (mostrata nella figura 9) consente di formattare ed eseguire una ripartizione di tutti i dischi prima del loro ripristino. Si tratta di un'opzione utile se il problema per il quale si esegue il ripristino è stato generato da un errore del disco o se sono state sostituite più unità disco nel server.
Figura 9 È possibile formattare ed eseguire una ripartizione dei dischi prima del loro ripristino
Figura 9 È possibile formattare ed eseguire una ripartizione dei dischi prima del loro ripristino
Dopo aver visualizzato due finestre di conferma, WinRE avvia il processo di ripristino e il server viene riavviato. In tal modo, è possibile eseguire con facilità un ripristino bare metal su un server.

Ripristino dello stato del sistema di un controller di dominio
Se si desidera eseguire un ripristino per un problema relativo ad Active Directory (ad esempio, per ripristinare un'unità organizzativa eliminata dal backup), è necessario ripristinare uno stato precedente per il database Servizi di dominio Active Directory (ADDS) anziché ripristinare l'intero sistema. Anche se è possibile arrestare l'esecuzione di ADDS come un servizio di Windows Server 2008, è comunque necessario avviare il server in modalità ripristino servizi directory (DSRM) per eseguire un ripristino dello stato del sistema su un controller di dominio.
Modificare le opzioni di avvio per avviare Windows Server 2008 in modalità DSRM non è semplice come in passato. L'intero ambiente di avvio Windows è stato riprogettato per supportare la nuova Extensible Firmware Interface (EFI) e il file boot.ini non esiste più. Windows Server 2008 utilizza ora i dati configurazione di avvio per controllare il processo di avvio.
Il modo più semplice per gestire i dati configurazione di avvio consiste nell'utilizzare il programma della riga di comando BCDEDIT. Una trattazione approfondita di tutti i comandi e le opzioni BCDEDIT richiederebbe un articolo a parte e quindi in questa sede verranno forniti solo alcuni esempi.
Per riavviare un controller di dominio Windows Server 2008 in modalità DSRM, utilizzare il seguente comando:
C:\> bcdedit /set safeboot dsrepair
Ciò consente di impostare l'opzione della modalità provvisoria per la voce del caricatore di avvio predefinita. In una nuova installazione di Windows Server 2008 esiste un'unica voce del caricatore di avvio, ovvero WINLOAD.EXE. Per rimuovere l'opzione della modalità provvisoria e riavviare nella modalità normale, utilizzare il seguente comando:
C:\> bcdedit /deletevalue safeboot
Per semplificare le cose, è possibile configurare due voci del caricatore di avvio sui controller di dominio: una per l'avvio normale e l'altra per l'avvio in modalità DSRM. In questo modo, è possibile modificare le opzioni di avvio utilizzando la finestra di dialogo Avvio e ripristino disponibile in Impostazioni di sistema. Per aggiungere una nuova voce del caricatore di avvio, utilizzare il seguente comando:
C:\> bcdedit /copy {default}
/d "Directory Service Repair Mode"
Questa azione consentirà di creare una nuova voce del caricatore di avvio copiando quella predefinita: BCDEDIT visualizzerà quanto segue:
The entry was successfully copied to
{c50d4710-a1f0-11dc-9580-0003ff402ae9}.
La nuova voce viene identificata dal GUID. Utilizzare quindi il seguente comando per impostare l'opzione della modalità provvisoria per la nuova voce del caricatore di avvio nei dati configurazione di avvio:
C:\> bcdedit /set {<GUID for new entry>}
safeboot dsrepair
È ora possibile passare dalla modalità di avvio normale alla modalità di avvio DSRM utilizzando le impostazioni della finestra di dialogo Avvio e ripristino (vedere la figura 10).
Figura 10 Disabilitare i backup incrementali nei volumi occupati
Figura 10 Disabilitare i backup incrementali nei volumi occupati
Prima di utilizzare WBADMIN per avviare un ripristino dello stato del sistema, è necessario identificare il backup dal quale si desidera eseguire il ripristino. WBADMIN può eseguire un ripristino dello stato del sistema da un backup di sistema completo, da un backup contenente solo i volumi di sistema critici o da un backup dello stato del sistema. In ciascuno di questi casi, è necessario specificare la versione del backup che si intende utilizzare. Il modo più semplice per identificare le versioni del backup disponibili consiste nell'utilizzare il seguente comando WBADMIN:
C:\> wbadmin get versions
WBADMIN visualizzerà le versioni del backup in modo simile a quanto mostrato nella figura 11. A ogni backup sono associati un'ora, una destinazione, un identificatore di versione (corrispondente all'ora e al giorno in cui il backup è stato avviato nel formato UMT (Universal Mean Time)) e un elenco dei tipi di operazioni di ripristino supportati dal backup.
Figure 11 Identificare i backup disponibili per il ripristino (Close Figure 11)
wbadmin 1.0 - Backup command-line tool
(C) Copyright 2004 Microsoft Corp.
Backup time: 11/30/2007 3:47 PM
Backup target: Fixed Disk labeled E:
Version identifier: 11/30/2007-22:47
Can Recover: Application(s), System State
Backup time: 12/1/2007 10:46 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/02/2007-05:46
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/2/2007 5:58 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/03/2007-00:58
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/3/2007 11:25 AM
Backup target: Fixed Disk labeled E:
Version identifier: 12/03/2007-18:25
Can Recover: Application(s), System State
In questo caso, viene selezionato il backup più recente e viene avviato il ripristino dello stato del sistema con il seguente comando WBADMIN:
C:\> wbadmin start systemstaterecovery
–version:12/03/2007-18:25
In tal modo, viene eseguito un ripristino non autorevole. Per eseguire un ripristino autorevole di SYSVOL, è possibile contrassegnare semplicemente la replica SYSVOL come autorevole aggiungendo l'opzione authsysvol al comando WBADMIN. Per ulteriori informazioni su questo processo, vedere go.microsoft.com/fwlink/?LinkId=113152.

Acquisizione degli snapshot di Active Directory
Una delle novità più interessanti relativamente al backup per Active Directory non riguarda Windows Server Backup. In Windows Server 2008, Active Directory offre il vantaggio di fornire gli snapshot del servizio Copia Shadow del volume. Tali snapshot sono backup temporizzati ed estremamente leggeri del servizio Active Directory in esecuzione. Inoltre, possono essere creati in pochissimo tempo. Si ha quindi la possibilità di montarli e accedervi utilizzando le normali utilità LDAP, quale lo strumento LDP.
È possibile acquisire snapshot di ADDS o Active Directory Lightweight Directory Services (ADLDS) utilizzando il comando NTDSUTIL, come mostrato di seguito:
ntdsutil: snapshot
snapshot: activate instance ntds
Active instance set to "ntds".
snapshot: create
Creating snapshot...
Snapshot set {42c44414-c099-4f1e-8bd8-4453ef2534a4} generated successfully.
snapshot: quit
ntdsutil: quit
Questa sequenza di comandi NTDSUTIL consente di creare snapshot del servizio Copia Shadow del volume dei volumi contenenti SYSVOL, i registri e l'albero di informazioni delle directory di Active Directory. Anche se Active Directory è ancora in fase di aggiornamento, il servizio Copia Shadow del volume utilizza una strategia copy-on-write per garantire che gli snapshot acquisiti vengano mantenuti correttamente. Gli snapshot non sono copie complete dell'albero di informazioni delle directory. Sono semplicemente una raccolta dei blocchi del disco dell'albero di informazioni delle directory modificati successivamente all'acquisizione dello snapshot. Combinando questi blocchi con la copia corrente dell'albero di informazioni delle directory, il servizio Copia Shadow del volume può presentare l'albero di informazioni delle directory di Active Directory esattamente nel modo in cui appariva al momento dell'acquisizione dello snapshot. Nella figura 12 è mostrato come eliminare gli snapshot vecchi o non necessari.
Figure 12 Eliminare gli snapshot non necessari (Close Figure 12)
C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: delete 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit
C:\>

Montaggio degli snapshot di Active Directory
Per utilizzare uno di questi snapshot, è necessario in primo luogo specificare che il servizio Copia Shadow del volume renda disponibile lo snapshot per il file system. A tale scopo, è possibile utilizzare il comando ntdsutil per elencare gli snapshot disponibili e quindi montare quello a cui si è interessati (vedere la figura 13).
Figure 13 Uso di ntdsutil per montare uno snapshot (Close Figure 13)
C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: mount 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit
C:\>
Il comando "list all" elenca tutti gli snapshot di Active Directory disponibili che al momento vengono mantenuti dal servizio Copia Shadow del volume. Il comando "mount 1" consente di montare gli snapshot selezionati per i volumi del registro e dell'albero di informazioni delle directory di Active Directory e li rende disponibili nel file system. Tali volumi si trovano nelle cartelle C:\$SNAP_200712032318_VOLUMEC$\ e C:\$SNAP_200712032318_VOLUMED$\.
Osservando queste cartelle, si scoprirà che il contenuto dei volumi corrisponde al contenuto esistente al momento dell'acquisizione dello snapshot. Tuttavia, ricordare che gli snapshot montati sono di sola lettura e, di conseguenza, non è possibile modificare nessuno dei file nello snapshot montato.

Ripristino dei dati dagli snapshot di Active Directory
Il montaggio degli snapshot dei volumi contenenti Active Directory potrebbe sembrare un'attività complicata. Come è possibile accedere ai dati Active Directory contenuti in tali snapshot? Il segreto consiste nell'utilizzare il comando DSAMAIN, corrispondente all'eseguibile che consente di eseguire ADLDS. Si tratta essenzialmente di un server LDAP autonomo che condivide quasi tutto il suo codice con ADDS. È possibile utilizzare DSAMAIN per fare in modo che gli snapshot acquisiti abbiano l'aspetto di un server LDAP di sola lettura contenente dati Active Directory corrispondenti a quelli presenti al momento dell'acquisizione dello snapshot.
Prendere in considerazione questo comando:
C:\> dsamain –dbpath
c:\$snap_200712032318_volumed$\ntds\dit
\ntds.dit -ldapport 10000
Questo comando consente di montare il file ntds.dit che si trova nella cartella c:\$snap_200712032318_volumed$\ntds\dit e lo rende disponibile per le operazioni LDAP sulla porta TCP 10000 (o su un'altra porta aperta specificata). DSAMAIN consentirà di aprire: la porta LDAPS (ovvero, la porta utilizzata per LDAP su Secure Sockets Layer) sul numero di porta specificato più uno (in questo caso, 10001); la porta GC (ovvero, la porta utilizzata per le connessioni al catalogo globale) sul numero di porta specificato più due (10002); la porta GCS (ovvero, la porta del catalogo globale su Secure Sockets Layer) sul numero di porta specificato più tre (10003).
È possibile utilizzare qualsiasi programma LDAP (ad esempio, LDP) per accedere all'albero di informazioni delle directory montato sulla porta specificata. Tuttavia, in Windows Server 2008, gli snap-in Utenti e computer di Active Directory (ADUC), Siti e servizi di Active Directory e Domini e trust di Active Directory, oltre che ADSIEDIT, sono stati modificati affinché possano essere connessi a un albero di informazioni delle directory montato utilizzando DSAMAIN. Se si fa clic con il pulsante destro del mouse sul nodo di livello superiore nel riquadro di spostamento di uno snap-in ADUC e si seleziona Cambia controller di dominio, viene visualizzata la finestra di dialogo mostrata nella figura 14. Se si digita semplicemente il nome o l'indirizzo IP del server che ospita lo snapshot montato e si specifica la porta (nell'esempio, localhost:10000), ADUC connetterà lo snapshot montato, consentendo di visualizzare il contenuto della directory corrispondente a quello presente al momento dell'acquisizione dello snapshot. Tutto ciò è sorprendente, non è vero?
Figura 14 Connessione di Utenti e computer di Active Directory a uno snapshot montato
Figura 14 Connessione di Utenti e computer di Active Directory a uno snapshot montato
Avere la possibilità di accedere ai dati Active Directory in questo modo semplifica notevolmente molte delle attività di ripristino dati. Ad esempio, per ripristinare un oggetto eliminato da un backup, in precedenza era necessario eseguire un ripristino non autorevole del backup su un controller di dominio esistente e quindi procedere con un ripristino autorevole dell'oggetto eliminato. Inoltre, se il backup ripristinato non conteneva i dati appropriati, era necessario ripetere tutta la procedura con un altro backup. Ora, utilizzando gli snapshot e il recupero degli oggetti contrassegnati per la rimozione definitiva, è possibile individuare e ripristinare i dati eliminati in modo estremamente rapido senza dover portare offline il controller di dominio.
Tuttavia, ciò presenta anche dei limiti. Ad esempio, ogni snapshot attivo aumenta l'I/O su disco associato alle operazioni di scrittura nella directory e, di conseguenza, non si dovrebbe disporre di più di uno o due snapshot attivi in un determinato momento sul controller di dominio di produzione. Inoltre, maggiore è il tempo per il quale si mantengono attivi gli snapshot, più grande sarà l'archivio dei delta del servizio Copia Shadow del volume, con un probabile impatto negativo sulle prestazioni. Tra l'altro, il ripristino di un oggetto eliminato rappresenta solo la prima fase del processo di ripristino. In effetti, sarà necessario ripristinare anche gli attributi collegati dell'oggetto, ad esempio l'appartenenza a gruppi. Tuttavia, anche in questo caso, gli snapshot consentono di identificare tutti i gruppi di cui l'oggetto eliminato era membro.

Efficace strategia di backup e ripristino per Active Directory
Windows Server 2008 introduce un sistema di backup e ripristino totalmente nuovo. A primo impatto, è possibile che alcune delle novità introdotte sembrino inopportune. Tuttavia, una volta che le organizzazioni IT decidono di accettarle e incorporano la nuova tecnologia di backup nelle loro operazioni giornaliere, il sistema di backup e ripristino risulterà molto più efficace.
Nonostante tutte le modifiche apportate al modo in cui si esegue il backup dei server in Windows Server 2008, la strategia di backup e ripristino per Active Directory resta fondamentalmente invariata. Pertanto, al momento di pianificare tale strategia, prendere in considerazione le seguenti procedure consigliate:
  • Pianificare backup di sistema completi periodici per poter ripristinare un controller di dominio a seguito di un errore hardware. La frequenza con la quale vengono pianificati i backup completi di un controller di dominio dipende da fattori quali la frequenza di aggiornamento dei dati, la tolleranza per il tempo di inattività e/o la perdita dei dati, nonché la quantità di operazioni necessarie per ricreare interamente il controller di dominio.
  • Pianificare backup dello stato del sistema frequenti per eseguire il backup in Active Directory. La frequenza con la quale vengono eseguiti i backup dello stato del sistema dipende dalla tolleranza per i dati Active Directory perduti. Tuttavia, è necessario eseguirli almeno una volta al giorno. Se si dispone di hardware, mantenere almeno uno o due backup dello stato del sistema su un disco locale e copiare le precedenti versioni dello stato del sistema su un DVD o in una condivisione di rete.
  • Eseguire i backup dello stato del sistema su almeno due controller di dominio in ogni dominio. Ciò rappresenterà una garanzia nel caso in cui uno dei backup risulti danneggiato o non disponibile.
Eseguire il backup dei controller di dominio con le repliche delle partizioni applicative, nel caso siano state definite. Inoltre, prendere in considerazione l'idea di creare una partizione Ambiente ripristino Windows sui controller di dominio per potere eseguire rapidamente l'avvio in WinRE in caso di errore di un'unità di sistema critica. 

Gil Kirkpatrick è CTO di NetPro e si occupa dello sviluppo software per Active Directory dal 1996. In collaborazione con Guido Grillenmeier, che lavora presso HP, ha realizzato i noti workshop sul ripristino di emergenza in Active Directory. Gil è anche il fondatore della Directory Experts Conference (www.dec2008.com).
© 2007 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.


 Amministrazione di Windows: Progettazione di strutture di unit&#224; organizzative efficaci
Amministrazione di Windows Ken St. Cyr

Progettazione di strutture di unità organizzative efficaci
Panoramica:
  • Principi fondamentali di una struttura di unità organizzative efficace
  • Modelli di strutture di unità organizzative comuni
  • Documentazione delle strutture di unità organizzative

L'importanza (e la complessità) di progettare una struttura di unità organizzative efficace non dovrebbe essere sottovalutata. I reparti IT non si comportano sempre allo stesso modo: a volte
assegnano un'importanza eccessiva alla struttura di unità organizzative, mentre altre volte la sottovalutano completamente. In entrambi i casi, ciò può provocare problemi con il modello Active Directory® attivo.
Dare un'importanza eccessiva alla struttura di unità organizzative distoglie l'attenzione da altre aree della struttura Active Directory, quali la pianificazione della topologia del sito o il ridimensionamento dei controller di dominio. D'altra parte, quando la pianificazione delle unità organizzative viene sottovalutata, si avranno effetti negativi sulla gestione degli oggetti Criteri di gruppo e delle deleghe.
In questi casi, spesso come scusa viene detto che la struttura di unità organizzative è flessibile e che quindi può sempre essere modificata in seguito se non fosse appropriata. Tuttavia, anche se ciò è vero, gli amministratori scoprono presto che modificare tale struttura in un secondo momento è più difficile di quanto avrebbero potuto immaginare. È sicuramente possibile aggiungere nuove unità organizzative, ma eliminare quelle vecchie non è così semplice.
Una struttura di unità organizzative di scarso livello tende a generare effetti incontrollabili. Se viene creato un nuovo oggetto nella directory e l'amministratore non sa in quale posizione inserirlo nella struttura in uso, sarà costretto a creare una nuova unità organizzativa o a collocare l'oggetto nel posto sbagliato. In entrambi i casi, i pericoli sono molti. Creare una nuova unità organizzativa è un'attività alquanto semplice, ma a lungo andare diventa difficile da gestire. La creazione di un numero eccessivo di unità organizzative contribuisce a dar vita a una struttura caotica e spesso gli oggetti vengono inseriti nella directory non documentati. D'altra parte, se si inserisce un oggetto in un'unità organizzativa esistente a cui non appartiene realmente, l'oggetto potrebbe ricevere criteri non appropriati oppure le autorizzazioni per l'oggetto potrebbero venire delegate agli utenti sbagliati.
Quando si progettano strutture di unità organizzative, è importante ricordare sempre questa semplice equazione: semplicità + adattabilità = sostenibilità. Se la struttura è troppo semplice, è possibile che non si riveli adattabile e che debba essere modificata troppo spesso. Se invece è troppo adattabile, tutto viene compartimentalizzato e alla fine la struttura diventa troppo complessa.
Esistono tre principi fondamentali per l'amministrazione di oggetti, deleghe e Criteri di gruppo che possono costituire un valido aiuto al momento della creazione della struttura. Tali principi possono essere riassunti con tre domande che ci si dovrebbe porre per creare una struttura di unità organizzative in grado di adattarsi ai cambiamenti di carattere organizzativo che si verificheranno nel tempo:
  1. È davvero necessario creare questa unità organizzativa per poterle assegnare un oggetto Criteri di gruppo univoco?
  2. È necessario che vi sia un particolare gruppo di amministratori in possesso delle autorizzazioni per gli oggetti inclusi in questa unità organizzativa?
  3. Questa nuova unità organizzativa renderà più semplice la gestione degli oggetti in essa contenuti?
Se la risposta anche a una sola di queste domande è affermativa, probabilmente è necessario creare l'unità organizzativa. Se la risposta a tutte tre le domande è negativa, si dovrebbe ripensare all'intera struttura e capire se è meglio crearne una completamente diversa. Tuttavia, prima di approfondire ulteriormente la situazione e illustrare come applicare tali principi, è opportuno spiegare prima il motivo della loro importanza.

Principio 1: Criteri di gruppo
Il primo principio importante per la creazione della struttura di unità organizzative consiste nel prendere in considerazione gli oggetti Criteri di gruppo che verranno applicati a una unità organizzativa. Un oggetto Criteri di gruppo consente di configurare impostazioni per utenti e computer in una maniera irrevocabile. È possibile definire più oggetti Criteri di gruppo in Active Directory e applicarli all'intero dominio, a diverse unità organizzative o anche ai siti inclusi nel dominio. Gli oggetti Criteri di gruppo sono suddivisi in due categorie: una per gli utenti e l'altra per i computer.
In uno stesso oggetto Criteri di gruppo possono essere definiti sia i criteri computer che i criteri utente. La sezione Configurazione utente dell'oggetto Criteri di gruppo definisce principalmente l'esperienza che vivrà l'utente una volta connesso all'oggetto. Questi tipi di impostazioni sono disponibili anche nella sezione Configurazione computer, ma questa sezione contiene anche ulteriori impostazioni correlate alla sicurezza del computer, ad esempio quelle relative agli utenti che possono accedere al computer in locale e al modo in cui vengono crittografati i dati.
Verranno ora illustrati alcuni principi fondamentali da prendere in considerazione al momento di definire le unità organizzative per il supporto degli oggetti Criteri di gruppo. Innanzitutto, il fatto che i criteri utente e computer possano essere definiti nello stesso oggetto Criteri di gruppo non vuol dire che sia una buona idea inserire gli oggetti utente e computer nella stessa unità organizzativa. Raggrupparli nello stesso oggetto Criteri di gruppo rende eccessivamente complicata l'eventuale risoluzione dei problemi associati all'oggetto. Ciò diventa particolarmente evidente quando è abilitato un criterio di loopback.
In secondo luogo, molte persone dimenticano che è possibile applicare gli oggetti Criteri di gruppo a livello di sito e quindi progettare le corrispondenti strutture di unità organizzative per creare una struttura del sito adatta a tale scopo. Quello descritto è un modello di struttura di unità organizzative comune, noto come "modello geografico". Soffermiamoci un po' a descrivere questo modello. Sarebbe un errore non riconoscere l'importanza del modello geografico nella progettazione delle unità organizzative, ma, come verrà spiegato più avanti, non ritengo che debba essere implementato solo per potere applicare gli oggetti Criteri di gruppo.
Inoltre, quando si pensa alla struttura di unità organizzative prendendo in considerazione gli oggetti Criteri di gruppo, l'obiettivo dovrebbe essere quello di ridurre la complessità. Accertarsi che l'unità organizzativa si combini con l'ereditarietà degli oggetti Criteri di gruppo. Se la struttura organizzativa contiene server che richiedono gli stessi criteri di altri server, è necessario considerare l'idea di inserire gli oggetti computer sotto un'unità organizzativa dei server più ampia e di creare più unità organizzative per diversi tipi di server sotto l'unità organizzativa dei server (vedere la figura 1). Ciò può semplificare l'applicazione dei criteri, dato che ogni oggetto computer nelle unità organizzative inferiori otterranno i criteri dall'unità organizzativa dei server e qualsiasi altro criterio specifico per il tipo di server di in questione.
Figura 1 Creazione di più unità organizzative per diversi tipi di server
Figura 1 Creazione di più unità organizzative per diversi tipi di server
Un altro principio fondamentale è quello di accertarsi che non vengano creati o collegati inutilmente più oggetti Criteri di gruppo. Con un oggetto Criteri di gruppo, è possibile creare un criterio e applicarlo a più unità organizzative. Ciò a volte si rivela molto utile, ma potrebbe essere anche pericoloso. Se si ha bisogno di modificare un'impostazione degli oggetti Criteri di gruppo e il sistema di oggetti Criteri di gruppo collegati risulta troppo complesso, potrebbe accadere che la modifica venga involontariamente applicata agli oggetti sbagliati. Maggiore è il numero di collegamenti creati, più difficile sarà capire l'ambito di un criterio. Analogamente, si dovrebbe evitare di creare criteri aggiuntivi con le stesse impostazioni di altri criteri. Se la situazione descritta si verifica spesso, prendere in considerazione l'idea di modificare la struttura di unità organizzative per applicare un nuovo modello di ereditarietà degli oggetti Criteri di gruppo.
Infine, si dovrebbe creare quasi sempre una nuova unità organizzativa per gli oggetti utente e computer. Per impostazione predefinita, tali oggetti sono posizionati in contenitori e, di conseguenza, non è possibile collegare loro gli oggetti Criteri di gruppo in modo diretto. Anche se è possibile applicare gli oggetti Criteri di gruppo ai contenitori degli utenti e dei computer dal dominio, l'applicazione sarà per ogni singolo utente e gruppo, a meno che non venga bloccata l'ereditarietà altrove. In Windows Server® 2003, è possibile utilizzare gli strumenti rediruser.exe e redircomp.exe per modificare la posizione predefinita per gli oggetti utente e computer e inserirli nell'unità organizzativa creata appositamente per gli stessi.

Principio 2: Gestione delle deleghe
È importante creare la struttura di unità organizzative in una maniera appropriata al modo in cui le autorizzazioni vengono delegate nel dominio. È opportuno ricordare che quando le autorizzazioni vengono delegate in Active Directory, le loro modifiche vengono apportate solo all'oggetto. Pertanto, se si assegna a un utente un'autorizzazione di controllo completo per un determinato oggetto computer, tale utente ha la possibilità di modificare gli attributi dell'oggetto, pur non disponendo dei privilegi di amministrazione sul computer stesso.
Di seguito vengono indicate alcune procedure consigliate per la gestione delle deleghe quando si progetta una struttura di unità organizzative:
Progettazione della struttura con attenzione all'ereditarietà delle autorizzazioni Si supponga di volere che gli amministratori di livello 1 siano in grado di modificare la password per la maggior parte degli account. Esiste un particolare gruppo di utenti per i quali gli amministratori non dovrebbero essere in grado di reimpostare le password, ma è comunque necessario che abbiano la possibilità di modificare i nomi visualizzati per tali account.
A questo punto, le possibilità sono due. In primo luogo, si potrebbero creare due separate unità organizzative parallele e separare gli utenti speciali dagli utenti normali. Tuttavia, ciò vuol dire che, per modificare le opzioni per le deleghe per tutti gli utenti, sarà necessario modificare tali autorizzazioni in due diverse posizioni. Ciò risulta anche in contraddizione il suggerimento di non collegare inutilmente più criteri (vedere la figura 2).
Figura 2 Uso di due separate unità organizzative parallele
Figura 2 Uso di due separate unità organizzative parallele
L'altra possibilità consiste nel creare un'unità organizzativa nidificata e nel definire un'autorizzazione Deny esplicita per l'unità contenente utenti speciali. Qualsiasi esperto di deleghe direbbe che un tale tipo di autorizzazione non è consigliata, anche se in questo caso è necessario scegliere il male minore (vedere la figura 3). È possibile duplicare e mantenere le impostazioni in due separate unità organizzative oppure inserire un'autorizzazione Deny esplicita in una delle due unità. L'autorizzazione Deny esplicita rappresenta effettivamente la decisione migliore per il lungo termine.
Figura 3 Uso di un'autorizzazione Deny esplicita
Figura 3 Uso di un'autorizzazione Deny esplicita
Attenzione ad AdminSDHolder Questo esempio si rivela appropriato se gli utenti speciali non appartengono tutti a uno dei gruppi amministrativi (Domain Admins, Schema Admins, Enterprise Admins o Administrators), dato che le autorizzazioni per gli account in questi gruppi vengono gestiste in modo differente. L'idea è che non si desidera assegnare involontariamente a un utente le autorizzazioni per un account amministratore.
Se si crea una unità organizzativa separata per gli amministratori, le autorizzazioni a essi delegate continuano a scomparire. Ciò dipende dalla presenza di AdminSDHolder, ovvero uno speciale contenitore che applica il relativo elenco di controllo di accesso a ogni account amministratore in un determinato intervallo di tempo. Di conseguenza, qualsiasi modifica delle deleghe apportata a un account amministratore verrà invertita se non viene apportata anche al contenitore AdminSDHolder. Pertanto, ai fini della gestione delle deleghe, non si dovrebbero separare gli account amministratore da altri account. Tuttavia, è consigliabile separarli ai fini della gestione di Criteri di gruppo (ciò è particolarmente vero in Windows Server 2008, dove è possibile avere più criteri password).

Principio 3: Amministrazione degli oggetti
Le unità organizzative dovrebbero semplificare l'amministratore degli oggetti. Il raggruppamento degli oggetti nella stessa unità organizzativa può spesso rendere più semplice apportare modifiche globali. Lo snap-in Utenti e computer di Active Director consente di modificare determinati attributi in una selezione di più oggetti. Pertanto, se si deve regolarmente modificare un attributo in un gruppo di oggetti, è più semplice riuscirci se si trovano tutti nella stessa unità organizzativa.
Ciò si rivela particolarmente utile anche se si eseguono aggiornamenti con uno script. I linguaggi di scripting semplificano considerevolmente l'enumerazione di tutti gli oggetti di una unità organizzativa e consentono di gestirli uno a uno. L'altra possibilità consiste nel ricercare e modificare ciascun oggetto singolarmente. È sufficiente inserire gli oggetti nella stessa unità organizzativa per poterli amministrare in modo più semplice.
Oppure, sempre per semplificare l'amministrazione degli oggetti, è possibile separarli in diverse unità organizzativa in base al tipo. La creazione di unità organizzative separate per gli oggetti stampante o le condivisioni pubblicate fa in modo che non sia necessario eliminarli quando si esegue l'attività di amministrazione su altri oggetti nell'unità organizzativa. Questa procedura è in linea anche con la procedura che suggerisce di non raggruppare gli account utente e computer nella stessa unità organizzativa.

Scelta di un modello
Dopo aver illustrato i principi alla base della creazione delle strutture di unità organizzative, verranno esaminati alcuni modelli di strutture comune. Per problemi di spazio, in questa sede verrà preso in considerazione solo un numero ristretto di modelli. Inoltre, non si è obbligati ad adottare un unico modello. Si ha la possibilità di prendere in considerazione delle parti di ciascun modello e di crearne uno ibrido per soddisfare le proprie specifiche esigenze.
Qualsiasi modello può rivelarsi appropriato su piccola scala, ma con il crescere dell'azienda, la possibilità di poter gestire correttamente tutto l'ambiente in uso diminuisce. Pertanto, assicurarsi di testare completamente il modello in un ambiente di laboratorio adeguato. Inoltre, ricordare che laddove le strutture di unità organizzative possono essere modificate senza difficoltà in un primo momento, risulterà più difficile modificarle dopo la loro applicazione.

Modello piano
Il modello piano prende il nome dal fatto che viene mantenuto principalmente piatto. In questo modello, alcune unità organizzative di alto livello contengono la maggior parte degli oggetti (vedere la figura 4). Questo modello viene utilizzato principalmente nelle aziende di piccole dimensioni in cui esiste un piccolo reparto IT e un ristretto numero di divisioni o dove le persone tendono a ricoprire ruoli diversi. Si consiglia di non creare più di 10 unità organizzative secondarie, anche se Microsoft indica un limite di 15 unità per non compromettere le prestazioni.
Figura 4 Il modello piano prevede alcune unità organizzative di alto livello che contengono la maggior parte degli oggetti
Figura 4 Il modello piano prevede alcune unità organizzative di alto livello che contengono la maggior parte degli oggetti
Se il responsabile delle risorse umane ricopre anche il ruolo di responsabile delle retribuzioni, non vale la pena creare due unità organizzative rispettivamente per le risorse umane e le retribuzioni. Nel modello piano, tutti gli oggetti utente possono essere raggruppati in una grande unità organizzativa degli account oppure mantenuti nel contenitore degli utenti predefinito. È necessario almeno separare gli oggetti utente dagli oggetti computer.
Per questo modello, si consiglia di separare anche le workstation dai server. In questo modo, sarà almeno possibile applicare diversi Criteri di gruppo senza dover definire un oggetto Criteri di gruppo che utilizza una query Strumentazione gestione Windows® per filtrare le workstation o i server.
Un vantaggio del mantenere una struttura di unità organizzative estesa anziché profonda consiste nella maggiore rapidità delle ricerche Active Directory. Si consiglia di non creare un numero di unità organizzative secondarie superiore a 10. Il controllo sugli oggetti non risulta con granularità molto fine in questo modello; tuttavia, se si gestiscono gli oggetti in un'azienda di piccole dimensioni, tale tipo di controllo non è affatto necessario. Pertanto, è estremamente difficile ottenere risultati positivi con questo modello nelle organizzazioni di grandi dimensioni, ma funziona alla perfezione nelle organizzazioni più piccole.

Modello geografico
Il modello geografico è quello che prevede la creazione di unità organizzative separate per diverse regioni geografiche. Questo modello si rivela adatto per le organizzazioni che si avvalgono di reparti IT dislocati, ma che non desiderano sostenere i costi per l'uso di più domini (vedere la figura 5).
Figura 5 Il modello geografico separa le unità organizzative in base alla regione geografica
Figura 5 Il modello geografico separa le unità organizzative in base alla regione geografica
Si supponga di avere uffici dislocati ad Atlanta, Baltimora e Seattle. Se ogni sito gestisce i propri utenti e computer, questo modello potrebbe rilevarsi la soluzione ideale per ciò che riguarda le deleghe. Eppure, ci si potrebbe chiedere cosa può accadere se un utente di Seattle si trasferisce a Baltimora per un corso di formazione e decide di chiudere il proprio account. Il personale IT a Baltimora potrebbe non essere in grado di aiutarlo se non ha ricevuto in delega le autorizzazioni per l'account dell'utente. Quando a Baltimora sono le 08.00, a Seattle sono le 05.00; questo vuol dire che l'utente potrebbe essere costretto ad attendere per ore prima di riuscire a ottenere assistenza dal personale dell'ufficio di Seattle.
Alcune aziende globali seguono il modello "follow the sun", in cui le chiamate del supporto tecnico vengono instradate a un sito nel normale orario di ufficio di quest'ultimo. Ciò vuol dire che l'azienda non ha bisogno di gestire un supporto tecnico di 24 ore in ogni sito, ma può sempre fornire assistenza ai dipendenti che lavorano nelle ore notturne, ad esempio sbloccando i loro account, quando necessario.
Se si utilizza questo modello, la creazione di unità organizzative separate in base alla posizione geografica non è certamente la scelta ideale per le proprie esigenze. In effetti, si dovrebbero delegare autorizzazioni separate a ogni supporto tecnico regionale per ogni unità organizzativa di utenti. Tuttavia, se i diversi siti dispongono di propri reparti IT, il modello geografico potrebbe rivelarsi adatto per l'organizzazione.
Il modello geografico è difficile da implementare in un dominio singolo, a causa della modalità di funzionamento del dominio stesso. Ciascun dominio tende ad adottare un modello di sicurezza diverso rispetto agli altri domini. Ciò risulta maggiormente evidente se si prende in considerazione un'applicazione a livello di organizzazione come Microsoft® Exchange.
Per il sistema Exchange Server di Atlanta potrebbero essere definiti diversi criteri dei messaggi, ma è probabile che per tutti i sistemi Exchange Server dell'organizzazione siano applicati gli stessi oggetti Criteri di gruppo. Se la situazione è questa, inserire i sistemi Exchange Server in unità organizzative separate in base alla regione potrebbe provocare il collegamento non necessario dello stesso oggetto Criteri di gruppo a più unità organizzative. Per quanto riguarda le deleghe, ci si deve chiedere se gli amministratori Exchange hanno realmente bisogno di autorizzazioni univoche per accedere agli oggetti computer per i sistemi Exchange Server. Nella maggior parte dei casi, gli oggetti computer vengono suddivisi in unità organizzative geografiche ai fini della gestione di Criteri di gruppo e non di quella delle deleghe.

Modello basato sul tipo
Il modello basato sul tipo classifica gli oggetti in base alla loro funzione (vedere la figura 6). L'ultimo oggetto utente creato era destinato a un account utente normale, a un account amministrativo o a un account del servizio? In un modello basato sul tipo, ciascuno di questi oggetti viene gestito in modo differente.
Figura 6 Il modello basato sul tipo raggruppa gli oggetti in base alle loro funzioni
Figura 6 Il modello basato sul tipo raggruppa gli oggetti in base alle loro funzioni
Nella maggior parte dei casi, si dovrebbe fare una distinzione tra diverse classificazioni di oggetti utente per i criteri. È molto probabile che i criteri siano diversi in base al tipo di account utente. Ad esempio, consentire agli utenti di accedere a un computer con un account del servizio è quasi sempre una procedura aziendale sconsigliata. Di norma, le password per gli account del servizio sono condivise da numerosi utenti e, di conseguenza, se qualcuno accede con un account del servizio, la sua identità resta anonima. Se dovesse accadere qualcosa, riuscire a rintracciare l'utente che ha eseguito l'accesso quando si è verificato l'evento di errore potrebbe rivelarsi alquanto difficile. In questo esempio, è necessario impostare un criterio per gli account del servizio per riuscire a impedire l'accesso interattivo. Questa è la soluzione ideale nel modello gerarchico mostrato nella figura 3.
In questo caso, è possibile avvalersi dell'ereditarietà degli oggetti Criteri di gruppo. Ad esempio, è possibile avere un criterio tutti gli utenti che fa riferimento ai criteri applicati per tutti gli oggetti utente. Inoltre, si potrebbe avere un criterio distinto per gli account del servizio, basato sul criterio tutti gli utenti. Questo approccio garantisce che gli account del servizio abbiano lo stesso gruppo di criteri di base di qualsiasi altro account e anche specifiche restrizioni di accesso.
Un approccio di questo tipo si rivela l'ideale anche per la gestione delle deleghe, in cui ci si avvale dell'ereditarietà delle autorizzazioni anziché dell'ereditarietà degli oggetti Criteri di gruppo. Si supponga di volere che gli amministratori di livello 2 siano in grado di reimpostare le password per tutti gli account, ad eccezione degli account amministratore di livello 3. Con una struttura di unità organizzative piana, è necessario delegare le autorizzazioni a ogni unità organizzativa contenente account utente. Tuttavia, in un modello basato sul tipo con una struttura gerarchia, è possibile assegnare autorizzazioni di "reimpostazione delle password" al gruppo di livello 2 nell'unità organizzativa degli account; quindi, nell'unità organizzativa di livello 3, è possibile semplicemente annullare l'ereditarietà delle autorizzazioni o impostare un'autorizzazione Deny esplicita per il livello 2 per potere reimpostare le password.
Questo modello si rivela valido anche per gli oggetti computer. È possibile separare i server e le workstation e applicare loro criteri differenti. I server possono essere quindi ulteriormente suddivisi in funzioni (vedere la figura 1). In questa struttura, è possibile impostare un criterio di alto livello nell'unità organizzativa dei server che abbia un impatto su tutti i server e anche singoli criteri in ciascuna unità organizzativa di livello inferiore.
Ad esempio, si supponga di disporre di un account del servizio Microsoft Operations Manager (MOM). Con questo modello a livelli, è possibile creare un oggetto Criteri di gruppo MOM e applicarlo all'unità organizzativa dei server MOM. Quindi, all'interno dell'oggetto Criteri di gruppo, è possibile assegnare i diritti di account del servizio per accedere come servizio. Ciò è applicabile solo per i server MOM inclusi nell'unità organizzativa in questione. I server MOM continueranno a ottenere l'oggetto Criteri di gruppo dei server dall'unità organizzativa dei server di livello superiore, ma otterranno anche l'oggetto Criteri di gruppo specifico, collegato a livello dell'unità organizzativa MOM.

Documentazione della struttura
Può rivelarsi estremamente gratificante riuscire a progettare una struttura di unità organizzative in grado di adattarsi alle varie modifiche che possono verificarsi un ambiente Active Directory. È però fondamentale tenere traccia delle caratteristiche dinamiche delle unità organizzative. In caso contrario, è molto probabile che non si riuscirà più a gestire nel modo corretto l'ambiente in uso. Quando si devono apportare delle modifiche e a tale scopo aggiungere o eliminare un'unità organizzativa, è necessario sapere cosa fare per riuscire a mantenere una struttura conforme al modello da seguire, nel rispetto dei tre principi fondamentali. Questo è il motivo per il quale una struttura ben documentata è sempre estremamente importante.
Microsoft fornisce guide per la documentazione nel Windows Server Resource Kit. Tali guide si rivelano preziose se la struttura è un framework solido che non si prevede possa cambiare di molto. Tuttavia, quasi tutte le organizzazioni sono dotate di strutture estremamente dinamiche che variano con grande frequenza. Ecco di seguito alcuni importanti suggerimenti per accertarsi che la struttura di unità organizzative sia ben documentata e in grado di supportare un ambiente dinamico.
Accertarsi che tutte le informazioni siano rilevanti Sono un forte sostenitore del fatto che la documentazione debba avere un suo specifico scopo. Un numero eccessivo di documenti rende difficile riuscire a individuare le informazioni davvero importanti. Creare documenti inutilmente non è affatto una buona idea. È davvero necessario includere il numero di oggetti in ogni unità organizzativa o la voce di controllo di accesso (ACE) nell'elenco di controllo di accesso per l'unità organizzativa? Per una corretta documentazione delle unità organizzative, in genere sono sufficienti le seguenti informazioni:
  • Nome dell'unità organizzativa
  • Breve descrizione
  • Autore o persona da contattare per ulteriori informazioni o modifiche
  • Data di creazione
Fare in modo che gli aggiornamenti siano semplici Se l'aggiornamento di un complesso documento Microsoft Word si rivela un'operazione troppo impegnativa, è probabile che si tenda a rimandarla nel tempo. Ovviamente, è consentito posticipare nel tempo delle piccole modifiche se si prevede che presto bisognerà eseguire aggiornamenti di maggiore entità. Sfortunatamente, però, spesso ci si dimentica di queste piccole modifiche o le si rimanda continuamente e, alla fine, il lavoro non verrà rimandato in eterno. Per questo motivo, l'aggiornamento del documento deve essere un'operazione semplice e non scoraggiante. Nella maggior parte dei casi, un semplice foglio di calcolo di Microsoft Excel® con poche colonne è la soluzione ideale.
Inserire i commenti nell'oggetto stesso Gli oggetti unità organizzativa presentano un campo della descrizione in cui è possibile inserire i commenti. Anziché scrivere i commenti nel documento di progettazione, prendere in considerazione l'idea di inserirli nel campo della descrizione, per rendere esplicita la finalità dell'unità organizzativa. Se si devono includere ulteriori dettagli, è possibile immettere una breve descrizione nell'apposito campo e inserire ulteriori dettagli nel documento dell'unità organizzativa.
Automatizzare la documentazione È possibile scrivere uno script per inserire il contenuto della struttura di unità organizzative in un file di testo, in un foglio di calcolo di Excel o in un file HTML. È possibile pianificare l'esecuzione dello script a cadenza giornaliera, nelle ore notturne. Ciò può rivelarsi estremamente utile se si immettono dei commenti nel campo della descrizione della unità organizzativa. Quindi, è sufficiente inserire la descrizione nel file per avere una struttura di unità organizzative completamente documentata e sempre aggiornata. Se si crea un file ogni volta che viene eseguito lo script, anziché sovrascrivere il documento esistente, è possibile mantenere un record cronologico delle modifiche subite dalla struttura di unità organizzative nel tempo.
Sfortunatamente, la maggior parte degli amministratori non si rende conto dell'importanza di una corretta documentazione della struttura di unità organizzative finché non ne ha veramente bisogno. E a quel punto, alle 3 di notte, è praticamente impossibile capire quali altre unità organizzative sono state involontariamente eliminate senza eseguire un ripristino.
Non bisogna aspettare che si verifichi questa situazione. Si consiglia vivamente di agire con prontezza avviando immediatamente un documento per le unità organizzative e designando una persona che abbia la responsabilità di aggiornarlo. E se ci si impegna a rendere semplice l'aggiornamento della documentazione, questa attività sarà un vero gioco da ragazzi. 

Ken St. Cyr lavora come consulente per Microsoft e vanta di dieci anni di esperienza nel settore IT. Si è dedicato alla progettazione e implementazione di soluzioni per le directory basate su Active Directory fin dalla sua ideazione.


 Amministrazione di Windows: Estensione dello schema di Active Directory
Amministrazione di Windows Vikas Malhotra

Estensione dello schema di Active Directory
Panoramica:
  • Informazioni sullo schema predefinito di Active Directory
  • Aggiunta di oggetti classSchema o attributeSchema
  • Acquisizione e utilizzo di identificativi di oggetti
  • Estensione del proprio schema tramite file .ldif
Scarica il codice per questo articolo: Schema2008_05.exe (151KB)

Dall'introduzione di Active Directory con la versione di Windows 2000, Microsoft ha fornito ai clienti la definizione di schema di base per l'implementazione di Active Directory.
La presenza di Active Directory® ha inoltre rappresentato una svolta nella modalità di scrittura e implementazione di molte applicazioni in Windows®. Prima di allora, le applicazioni come Microsoft® Exchange 5.5 venivano create con una struttura di directory integrata. Con l'introduzione di Active Directory, molte applicazioni (sia di Microsoft che di altre aziende) hanno iniziato ad utilizzare la struttura sottostante fornita, anziché creare il proprio schema da zero.
Tali applicazioni hanno iniziato con l'architettura di base fornita da Active Directory e l'hanno estesa in base alle necessità. Microsoft Exchange 2000, ad esempio, utilizzava Active Directory per le implementazioni di messaggistica, definendo in questo modo il futuro dell'architettura di messaggistica di Microsoft.
Attualmente, il funzionamento di molte applicazioni scritte per operare in un ambiente Active Directory si basa sul suo schema sottostante e molte definiscono anche le proprie modifiche allo schema, in base alle necessità. Questo scenario richiede, ovviamente, uno schema che supporti l'estensione, come illustrerò in questo articolo. Inoltre, poiché molte applicazioni dipendono dalle definizioni di base presenti in Active Directory, la stabilità continua dello schema centrale è essenziale. Poiché molte applicazioni devono essere utilizzate l'una accanto all'altro nella stessa Active Directory, le modifiche apportate ad un'applicazione non devono avere alcun impatto sulle altre.

Definizione di uno schema
Per molti, lo schema di Active Directory è una scatola nera e l'idea di modificare tale schema per conto proprio può apparire assurda. Ovviamente, l'estensione del proprio schema di Active Directory non è un'operazione da eseguire tutti i giorni, ma alcune applicazioni o esigenze aziendali potrebbero richiederla. Quindi, è molto importante capire in cosa consiste lo schema e qual è il suo contenuto, poiché Active Directory è una risorsa essenziale in molte organizzazioni e il suo malfunzionamento a causa di un aggiornamento non corretto può avere un impatto estremamente significativo.
Come strategia, molte organizzazioni considerano l'utilizzo di Active Directory Lightweight Directory Service (ADLDS) in Windows Server® 2008 (o di Active Directory Application Mode, ADAM, in Windows Server 2003) come un'alternativa per verificare o implementare direttamente le definizioni di schema personalizzate anziché estendere lo schema di Active Directory.
Uno schema è la struttura sottostante che fornisce il formato per un servizio di directory. Lo schema di Active Directory definisce le classi di oggetto e gli attributi utilizzati in Active Directory Domain Services (ADDS). Lo schema centrale fornisce definizioni per molte classi note (tra cui user, computer e organizationalUnit) e attributi (tra cui telephoneNumber e objectSID). Gli oggetti presenti nella definizione di schema centrale sono noti come oggetti di Categoria 1, mentre gli oggetti aggiunti sono denominati oggetti di Categoria 2.
Uno schema di Active Directory può essere trovato nel contenitore definito nel percorso cn=Schema,cn=Configuration,dc=X in cui X è lo spazio nomi della foresta di Active Directory. Tenere presente che una foresta di Active Directory contiene soltanto un singolo schema, quindi l'esecuzione di modifiche alla definizione di schema in una foresta influisce su tutti i domini presenti in tale foresta. La figura 1 mostra il numero di classi e attributi aggiunti nello schema di Active Directory in differenti versioni di Windows Server.
Figure 1 Numero di classi e attributi (Close Figure 1)

Versione | Numero di attributi aggiunti | Numero di classi aggiunte | File di estensione dello schema
Windows Server 2003 | 208 | 49 | Da sch14.ldf a sch30.ldf
Windows Server 2003 R2 | 81 | 29 | Sch31.ldf
Windows Server 2008 | 136 | 10 | Da sch32.ldf a sch44.ldf
L'aggiornamento dello schema per tali versioni viene eseguito tramite un'utilità denominata Adprep. Con gli aggiornamenti per Windows Server 2003 R2, la versione di schema viene aggiornata a 31 e cambia in 44 con Windows Server 2008.
Tale situazione può essere verificata controllando il valore dell'attributo objectVersion di cn=Schema,cn=Configuration,dc=X nella propria Active Directory tramite uno strumento come ADSIEdit. Tenere presente che alcune applicazioni tra cui Exchange Server, System Management Server (SMS) o altre che dipendono da Active Directory potrebbero modificare lo schema in base alle esigenze dell'applicazione.

Componenti essenziali
Active Directory è composta da due tipi di oggetti: classSchema (classe per short) e attributeSchema (attributo per short). Generalmente, l'estensione dello schema di Active Directory viene presa in considerazione quando un'organizzazione intende memorizzare i dati in attributi non disponibili nello schema esistente. Per creare un attributo in uno schema di Active Directory, specificare prima un oggetto attributeSchema nel contenitore schema e poi definire le proprietà necessarie per il nuovo oggetto.
Per un elenco di proprietà per gli oggetti di attributeSchema con relative informazioni, consultare il collegamento go.microsoft.com/fwlink/?LinkId=110445. Come appare evidente, è possibile definire molte proprietà per gli oggetti attributeSchema e alcune di queste sono obbligatorie.
Oltre agli attributi regolari, esistono anche attributi speciali denominati "attributi collegati all'interno di uno schema", implementati in coppie fornendo un collegamento in avanti e un collegamento a ritroso. Come esempio, si consideri l'appartenenza ai gruppi in Active Directory. L'attributo member di qualunque gruppo (ad esempio, un gruppo denominato ContosoEmployees con un membro denominato John Doe) è il collegamento in avanti, mentre il corrispondente attributo memberOf dell'oggetto member è il collegamento a ritroso (quindi, ad esempio, quando l'attributo memberOf di John Doe viene sottoposto a query, viene calcolato il nome distinto o DN del gruppo ContosoEmployees).
Il collegamento in avanti si comporta in modo molto simile a qualunque altro attributo. I valori possono essere a valore singolo o multiplo (come avviene con l'attributo member,, che può contenere più oggetti come membri di un gruppo) e vengono memorizzati insieme all'oggetto parent nella directory.
I collegamenti a ritroso, invece, sono gestiti dal sistema per garantire integrità referenziale. Quando si esegue una query del valore di un attributo di collegamento a ritroso, i risultati verranno calcolati da tutti i valori del collegamento a ritroso corrispondente. I collegamenti a ritroso sono sempre a più valori.
Ogni classe di oggetti in ADDS è definita da un oggetto classSchema nel contenitore di schema. Per un elenco di attributi critici per la corretta definizione dell'oggetto classSchema, consultare il collegamento go.microsoft.com/fwlink/?LinkId=110445.
È possibile specificare tre tipi di classi: Structural, Abstract e Auxiliary. Tali tipi sono definiti dal valore dell'attributo objectClassCategory. (Una quarta categoria, conosciuta come 88, contiene delle classi definite prima degli standard X. 500 1993. Questo tipo di classe è specificato dal valore 0 nell'attributo objectClassCategory e non dovrebbe più essere definito).

Acquisizione e utilizzo di identificativi
Le identità di ogni oggetto classSchema e attributeSchema nella directory vengono definite utilizzando un identificativo di oggetto obbligatorio (OID), definito rispetto a governsID per oggetti classSchema e rispetto ad attributeID per oggetti attributeSchema. Questi sono dei valori numerici univoci forniti da alcune autorità emittenti per identificare gli oggetti. La numerazione è regolata dalla definizione del protocollo LDAP (RFC 2251). Alcuni degli OID nello schema di Active Directory vengono emessi dalla International Organization for Standardization (ISO) e altri da Microsoft. Un OID deve essere univoco per un oggetto all'interno della directory.
L'OID è una stringa di numeri, ad esempio 1.2.840.113556.1.y.z, come descritto nella Figura 2. Quindi, ad esempio, un OID per un oggetto utente classSchema è 1.2.840.113556.1.5.9.
Figure 2 Identificativo per l'oggetto utente (Close Figure 2)

Valore | Significato | Descrizione
1 | ISO | Identifica l'autorità root.
2 | ANSI | Designazione di gruppo assegnata da ISO.
840 | USA | Codice paese/regione assegnato dall'organizzazione.
113556 | Microsoft | Designazione di organizzazione assegnata dal paese/regione.
1 | Active Directory | Assegnato dall'organizzazione (da Microsoft, in questo caso).
Y | Tipo di oggetto | Numero che definisce il tipo di oggetto diverso (categoria), ad esempio classSchema o attributeSchema. Ad esempio, 5 definisce la classe di oggetto.
Z | Oggetto | Numero che identifica uno specifico oggetto all'interno della categoria. Ad esempio, alla classe utente viene assegnato il numero 9.
Quando un'organizzazione intende estendere lo schema, verifica l'univocità dell'OID acquisendo il relativo numero root di OID, da cui vengono poi ottenuti ID univoci per le nuove classi di oggetto e gli attributi creati dall'organizzazione. La root di OID può essere ottenuta direttamente da una National Registration Authority (NRA) ISO, che negli Stati Uniti è American National Standards Institute (ANSI).
È possibile consultare la procedura e la pianificazione dei costi per ottenere un OID root sul sito ansi.org. Per altre aree, contattare la corrispondente organizzazione membro di ISO; ISO offre un elenco all'indirizzo iso.org/iso/about/iso_members.htm.
In passato, le organizzazioni richiedevano un OID a Microsoft inviando un messaggio e-mail a schemreg@microsoft.com. Tuttavia, attualmente il risultato è una risposta automatica in cui si invita il richiedente a scaricare ed eseguire VBScript dal sito go.microsoft.com/fwlink/?LinkId=110453.
Per gli OID emessi da Microsoft, il numero viene assegnato nello spazio di numeri OID di Microsoft: 1.2.840.113556.1.8000.x, dove x è un numero univoco assegnato all'organizzazione. L'organizzazione può dividere ulteriormente tali OID per specificare gli oggetti, utilizzando ad esempio 1.2.840.113556.1.8000.x.1.y per nuovi oggetti classSchema e 1.2.840.113556.1.8000.x.2.z per oggetti attributeSchema (dove x rappresenta il numero univoco dell'organizzazione e y e z, rispettivamente, sono i numeri assegnati a specifici oggetti classSchema ed attributeSchema). È inoltre consigliato utilizzare un prefisso specifico dell'organizzazione nei nomi di tali oggetti per distinguerli.

Definizione di attributi collegati
È importante che il valore attributeSyntax di un collegamento in avanti sia 2.5.5.1, 2.5.5.7 o 2.5.5.14. Questi valori corrispondono alle sintassi che contiene un nome distinto, ad esempio alla sintassi DS-DN dell'oggetto.
Il valore attributeSyntax di un collegamento a ritroso deve essere 2.5.5.1, ovvero la sintassi DS-DN dell'oggetto. Per convenzione, gli attributi di collegamento a ritroso vengono aggiunti al valore mayContain della classe astratta principale. In questo modo, l'attributo di collegamento a ritroso può essere letto dagli oggetti di qualunque classe poiché gli attributi di collegamento a ritroso non vengono in realtà memorizzati con l'oggetto, ma vengono calcolati in base ai valori di collegamento in avanti.
Windows Server 2003 ha introdotto una funzione che le organizzazioni possono utilizzare per collegare due oggetti in uno schema: la generazione automatica di linkID. Con tale funzione, il sistema genera automaticamente un linkID per un nuovo attributo collegato quando l'attributo linkID dell'attributo è impostato su 1.2.840.113556.1.2.50. Un collegamento a ritroso corrispondente viene creato impostando il linkID sull'attributeId o sull'ldapDisplayName del collegamento in avanti. La cache dello schema deve essere ricaricata dopo la creazione del collegamento in avanti e prima di creare il collegamento a ritroso. Altrimenti, l'attributeId del collegamento in avanti o l'ldapDisplayName non verranno trovati al momento della creazione del collegamento a ritroso. La cache dello schema viene ricaricata su richiesta, pochi minuti dopo l'esecuzione di una modifica dello schema o quando il controller di dominio viene riavviato.
Se Active Directory si trova al livello Windows 2000, è necessario richiedere i linkID a Microsoft inviando un messaggio e-mail all'indirizzo schemreg@microsoft.com. All'interno della risposta automatica, verrà visualizzato un messaggio simile al seguente: "I messaggi e-mail inviati a schemreg@microsoft.com verranno elaborati soltanto se sono correlati a registrazioni linkID per ambienti legacy". Per questo, fornire le informazioni seguenti nel messaggio e-mail: nome azienda, nome contatto, indirizzo e-mail, numero di telefono, prefisso registrato (se applicabile), OID registrato (se applicabile).

Estensione dello schema
Supponiamo di voler estendere lo schema di Active Directory. Questa analisi potrebbe essere condotta scartando l'uso di una directory alternativa implementata tramite ADLDS (o ADAM in Windows Server 2003) dopo avere verificato che non avrebbe soddisfatto i requisiti. Come mossa successiva, si identificano i nuovi oggetti attributeSchema da aggiungere allo schema e, in tal modo, si definiscono tutti i valori richiesti (tra cui cn, ldapDisplayName e altri) che specificano tali oggetti. Nella definizione dei valori di attributo per l'oggetto, si ottiene inoltre l'OID da Microsoft o da un'altra fonte. Le suddette operazioni vengono considerate essenzialmente come requisiti aziendali e specifiche tecniche. Inoltre, si implementa un ambiente di laboratorio che emuli Active Directory e che sia pronto per la verifica.
In realtà, molte organizzazioni formano una commissione per approvare o rifiutare tali modifiche e per impostare il relativo processo di implementazione. La necessità di tali verifiche e bilanci è fondamentale poiché Active Directory viene utilizzata come fonte di informazioni autorevole in molte organizzazioni e l'importanza di restare aggiornati e operativi dopo le modifiche non viene mai sottolineata abbastanza.
Non appena l'organizzazione decide di procedere, è necessario definire i piani di implementazione e di test per questo progetto. È possibile estendere lo schema aggiungendo i nuovi oggetti tramite lo snap-in dello schema di Active Directory all'interno di Microsoft Management Console (MMC) o utilizzando metodi programmatici o semi-programmatici per estendere lo schema (ad esempio, utilizzando script LDIFDE per importare file in formato .ldif; CSVDE per importare file in formato .csv o Active Directory Service Interfaces (ADSI).
Indipendentemente dal metodo utilizzato, questa funzione deve essere eseguita su un server connesso o che disponga del ruolo Flexible Single Master Operations (FSMO) di Master Schema nella foresta di Active Directory. Inoltre, l'account utilizzato per l'aggiornamento dello schema necessita di adeguati privilegi di gestione per eseguire l'aggiornamento, quindi occorre renderlo un membro del gruppo Amministratori di schemi. Infine, è necessario abilitare degli aggiornamenti di schema per la foresta (disabilitati per impostazione predefinita).
A meno che la modifica non sia estremamente semplice, dovrebbe essere eseguita in modo automatico per favorire la standardizzazione tra le fasi di implementazione test e produzione e per ridurre i tipi di errori probabili dovuti all'esecuzione manuale della procedura. Supponiamo di voler implementare la nostra modifica utilizzando LDIFDE. Per applicare gli aggiornamenti durante l'estensione dello schema, è necessario aggiungere i nuovi attributi e classi, aggiungere i nuovi attributi alle classi e quindi attivare un ricaricamento della cache. Esaminiamo un paio di scenari.

Aggiunta di attributi
Si supponga che un'organizzazione denominata Contoso desideri aggiungere nella propria Active Directory un attributo che identifichi il numero di scarpa di ogni dipendente. La foresta di Active Directory ha due domini: contoso.com ed employees.contoso.com. Il requisito è che tutti gli oggetti creati utilizzando la definizione della classe utente devono contenere anche questo nuovo attributo.
È importante tenere a mente che la modifica dello schema interesserà entrambi i domini poiché si trovano nella stessa foresta. Supponiamo di avere ricevuto l'OID 1.2.840.113556.8000.9999 da Microsoft e di avere diviso ulteriormente tale OID in 1.2.840.113556.8000.9999.1 per oggetti classSchema ed in 1.2.840.113556.8000.9999.2 per oggetti attributeSchema per Contoso. A questo punto, si definiranno tutti i valori di attributo per questo nuovo oggetto, come illustrato nella Figura 3.
Figure 3 Definizione dell'attributo contosoEmpShoe (Close Figure 3)

Attributo | Valore | Note
Cn | contosoEmpShoe |
lDAPDisplayName | contosoEmpShoe |
adminDisplayName | contosoEmpShoe |
attributeSyntax | 2.5.5.12 | Specifica una stringa Unicode.
oMSyntax | 64 | Indica una stringa Unicode.
objectClass | top, attributeSchema |
attributeID | 1.2.840.113556.8000.9999.2.1 | Come definito dall'organizzazione.
isSingleValued | TRUE | È possibile memorizzare un solo valore di numero di scarpa.
searchFlags | 1 | L'analisi illustra che si desidera indicizzare questo attributo. Nota: l'analisi del test di stress verrà eseguita nell'ambiente di laboratorio.
isMemberOfPartialAttributeSet | TRUE | Si desidera che questo attributo sia disponibile nel Catalogo globale.
Inoltre, sebbene l'attributo contosoEmpShoe debba essere disponibile per tutti gli oggetti creati come oggetti della classe utente, non è consigliabile modificare la definizione predefinita di tale classe. È preferibile definire una classe ausiliaria denominata contosoUser con il valore mayContain specificato come contosoEmpShoe, come illustrato nella Figura 4. In seguito, aggiungere gli attributi definiti per la classe ausiliaria contosoUser alla classe utente.
Figure 4 Definizione della classe contosoUser (Close Figure 4)

Attributo | Valore
Cn | contosoUser
lDAPDisplayName | contosoUser
adminDisplayName | contosoUser
governsID | 1.2.840.113556.8000.9999.1.1 (come definito dall'organizzazione)
mayContain | contosoEmpShoe
possSuperiors | organizationalUnit, container
objectClassCategory | 3 (definisce una classe ausiliaria)
Dopo avere eseguito l'analisi e definito i valori, è possibile creare il file .ldif, simile al codice riportato nella Figura 5. È possibile copiare il contenuto della Figura 5 nel Blocco note e salvare il file come contosoUser.ldif (una copia è disponibile anche nel download del codice riportato in technetmagazine com).
Figure 5 file .ldif per l'estensione dello schema (Close Figure 5)
#Attribute definition for contosoEmpShoe

dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: contosoEmpShoe
attributeID: 1.2.840.113556.1.8000.9999.2.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
adminDisplayName: contosoEmpShoe
adminDescription: contosoEmpShoe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: contosoEmpShoe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

# Classes

dn: CN=contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: classSchema
cn: contosoUser
governsID: 1.2.840.113556.1.8000.9999.1.1
mayContain: contosoEmpShoe
rDNAttID: cn
adminDisplayName: contosoUser
adminDescription: contosoUser
objectClassCategory: 3
lDAPDisplayName: contosoUser
name: contosoUser
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: auxiliaryClass
auxiliaryClass: contosoUser
-

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
Dopo avere generato il file .ldif, è possibile verificare l'implementazione in un ambiente di laboratorio, verificare la replica end-to-end del proprio dominio e foresta e attivare l'aggiornamento dello schema al suo interno. A questo punto, è necessario accedere con un account che disponga dei privilegi di amministratore dello schema. È possibile disattivare la replica in uscita sul master schema (dove la modifica verrà eseguita) e quindi eseguire il comando seguente per importare il file .ldif:
ldifde –i –f <Path>\contosoUser.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext
Una volta apportata la modifica, attivare la replica in uscita sul master schema e verificare che la replica sia avvenuta per tutti i controller di dominio.
E ora potete tirare un sospiro di sollievo...avete finito! È stato definito un nuovo attributo nello schema che verrà associato agli oggetti creati tramite la classe utente (ovvero, gli account utente).
Per verificare la modifica, aprire Utenti e computer di Active Directory, connettersi al dominio employees.contoso.com, ricercare l'unità organizzativa (OU) Utenti e creare un nuovo account utente denominato ContosoTestUser. Aprire poi la console adsiedit.msc e connettersi alla partizione di dominio dc=employees,dc=contoso,dc=com, espandere l'OU Utenti, fare clic con il pulsante destro del mouse su ContosoTestUser e aprire la pagina Proprietà. Ricercare l'attributo contosoEmpShoe. È possibile modificare tale attributo per inserire un valore e utilizzare l'utilità Ldp.exe per verificare e modificare gli attributi.
Diamo ora un'occhiata ad un esempio che definisce e collega due attributi e immaginiamo uno scenario in cui Contoso considera di elevata importanza il numero di scarpa dei dipendenti e desidera registrare le prestazioni annuali delle persone che si occupano di acquisire tali numeri di scarpa nell'azienda. Sebbene tale scenario possa apparire buffo, supponiamo anche che Contoso intenda tenere traccia non solo delle persone responsabili della misurazione del numero di scarpa dei dipendenti ma anche dei dipendenti di cui viene misurato il numero di scarpa, registrandone anche il numero, il tutto tramite query su un unico attributo. Si potrebbe pensare che sia meglio memorizzare tali dati nelle tabelle del database, ma l'idea in questo caso serve semplicemente a spiegare l'attività dei collegamenti in avanti e a ritroso.
Ovviamente, la prima analisi da eseguire è quella descritta nell'esempio da me riportato all'inizio di questo articolo. Nell'esempio attuale, tuttavia, ci dedicheremo a generare i file .ldif linkids1.ldif e linkids2, come illustrato nella Figura 6. Per importare tali file, immettere il seguente comando:
Figure 6 File .ldif dei collegamenti in avanti e a ritroso (Close Figure 6)

#linkids1.ldif
#Attribute definition for Forward Link Attribute

dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizeTaker
attributeID: 1.2.840.113556.1.8000.9999.2.2
LinkID: 1.2.840.113556.1.2.50
attributeSyntax: 2.5.5.1
isSingleValued: TRUE
adminDisplayName: ContosoShoeSizeTaker
adminDescription: ContosoShoeSizeTaker
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizeTaker
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Reload schema

#linkids2.ldif

#Attribute definition for Backward Link Attribute

dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizesTakenByMe
attributeID: 1.2.840.113556.1.8000.9999.2.3
LinkID: 1.2.840.113556.8000.9999.2.2
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
adminDisplayName: ContosoShoeSizesTakenByMe
adminDescription: ContosoShoeSizesTakenByMe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizesTakenByMe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in
#contosoUser class

dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizeTaker
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add Backward Link Attribute as MayContain in Top

dn: CN=Top,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

ldifde –i –f <Path>\linkedids<>.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext
Non appena viene creato, l'oggetto utente presenterà come attributi anche ContosoShoeSizeTaker e ContosoShoeSizesTakenByMe. Durante la creazione dell'oggetto utente per, ad esempio, John, l'attributo ContosoShoeSizeTaker viene compilato con il DN della persona che ha misurato il numero di scarpa, ad esempio Frank. A questo punto, quando si accede alle proprietà dell'oggetto utente Frank e si esegue una query dell'attributo ContosoShoeSizesTakenByMe, il risultato conterrà il DN di John DN e gli altri DN misurati da Frank. Per completare il nostro scenario, la gestione potrebbe fornire a Frank delle provvigioni in base al numero di DN presenti nell'attributo ContosoShoeSizesTakenByMe del suo account utente.

Controlli e bilanci del sistema
Un aggiornamento essenziale come la modifica di uno schema non può essere eseguito senza controlli rispetto ai requisiti dell'architettura. Active Directory esegue tali controlli di sicurezza e uniformità per verificare che le modifiche non causino incongruenze o altri problemi ogni qualvolta viene eseguita un'aggiunta o una modifica allo schema di Active Directory.
In primo luogo, il valore di governsID per ogni classe deve essere univoco all'interno dello schema. Quando si definisce un oggetto schemaClass, tutti gli attributi definiti negli elenchi systemMayContain, mayContain, systemMustContain e mustContain devono esistere già. Allo stesso tempo, devono esistere già anche tutte le classi definite negli elenchi subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors e possSuperiors.
Inoltre, la objectClassCategory di tutte le classi negli elenchi systemAuxiliaryClass e auxiliaryClass deve essere la classe 88 o la classe Auxiliary. In modo analogo, la objectClassCategory di tutte le classi negli elenchi systemPossSuperiors e possSuperiors deve essere la classe 88 o la classe Structural.
Durante la definizione di varie classi, le classi Abstract possono ereditare soltanto da altre classi Abstract, le classi Auxiliary non possono ereditare dalle classi Structural e le classi Structural non possono ereditare dalle classi Auxiliary. Inoltre, l'attributo specificato nell'attributo rDNAttID deve presentare la stringa Unicode come sintassi ed essere a valore singolo.
Queste sono alcune delle regole correlate agli oggetti classSchema. Quali sono quelle relative agli oggetti attributeSchema? Come avviene con il valore governsID per le classi, il valore di attributeID deve essere univoco, così come deve esserlo il valore di mAPIID, se presente. E se sono presenti rangeLower e rangeUpper, rangeLower deve essere inferiore a rangeUpper. I valori di attributeSyntax e oMSyntax devono corrispondere. Se l'attributo ha come sintassi un oggetto (oMSyntax=127), deve presentare la oMObjectClass corretta. Il valore linkID, se presente, deve essere univoco. In più, un collegamento a ritroso deve disporre di un corrispondente collegamento in avanti.

Come comportarsi in caso di errore?
Una volta esteso lo schema con i nuovi oggetti (classi e attributi), tali oggetti non possono essere eliminati. Tuttavia, è possibile disattivare una classe o un attributo impostando l'attributo su TRUE sull'oggetto schema. Non è possibile disattivare oggetti di schema che fanno parte dello schema predefinito fornito con Active Directory (oggetti della Categoria 1). È possibile disattivare soltanto gli oggetti aggiunti allo schema predefinito, ovvero soltanto gli oggetti di Categoria 2 ed esclusivamente dopo che Active Directory ha verificato che la classe non è utilizzata nell'elenco subClassOf, auxiliaryClass o possSuperiors di alcuna classe attiva esistente.
Con qualunque tentativo di disattivare un attributo, Active Directory controlla che l'attributo non sia utilizzato nell'elenco mustContain o mayContain di alcuna classe attiva esistente. Gli oggetti disattivati possono essere riattivati impostando l'attributo isDefunct su FALSE. Se Active Directory si trova a livello di Windows Server 2003, è possibile riutilizzare i valori ldapDisplayName, schemaIdGuid, OID e mapiID dell'oggetto disattivato.

Conclusioni
L'aggiunta o la modifica di definizioni di attributi o classi nello schema implica l'aggiunta o la modifica del corrispondente oggetto classSchema o attributeSchema. Questo processo è simile all'aggiunta o alla modifica di qualunque oggetto in Active Directory, con l'eccezione che i controlli aggiuntivi vengono eseguiti per garantire che le modifiche non causino incongruenze o problemi successivi nello schema.
Sebbene la modifica dello schema di Active Directory sia semplice, è importante capire la formazione dello schema e il relativo funzionamento per implementare tali modifiche. Qualunque modifica allo schema di Active Directory di produzione richiede una notevole pianificazione e deve essere eseguita con estrema attenzione. È essenziale definire i requisiti aziendali e le specifiche tecniche per i nuovi oggetti ed eseguire una gran quantità di test di laboratorio. Poiché le modifiche possono avere effetti profondi, è consigliabile estendere lo schema di Active Directory soltanto quando è assolutamente necessario.

Vikas Malhotra lavora per i servizi di consulenza Microsoft a New York. Durante i suoi 12 anni nel mondo degli affari, ha lavorato con diverse organizzazioni IT in aziende di medie e grandi dimensioni concentrandosi sulle esigenze dell'architettura della loro infrastruttura, ovvero directory, messaggistica, protezione e rete di dati. Ha un diploma di laurea in Ingegneria Elettronica e delle Telecomunicazioni e una laurea specialistica in Gestione delle telecomunicazioni tecniche. È possibile contattarlo all'indirizzo vikasmal@microsoft.com.


 System Center: Introduzione a System Center Mobile Device Manager
System Center Matt Fontaine

Introduzione a System Center Mobile Device Manager
Panoramica:
  • Tipico sistema Mobile Device Manager
  • Estensione di Active Directory a Windows Mobile
  • Registrazione, provisioning e inventariato dei dispositivi Windows

L'introduzione di Microsoft System Center Mobile Device Manager 2008 rappresenta uno straordinario passo avanti per i professionisti IT che gestiscono i dispositivi Windows Mobile sulle reti aziendali. Fornendo le funzioni per la gestione dei dispositivi, la gestione della sicurezza e le reti private virtuali mobili (VPN)
in un unico prodotto, questa nuova soluzione semplifica notevolmente il compito degli amministratori e garantisce un ritorno sull'investimento (ROI) per i dispositivi mobili.
Mobile Device Manager consente ai professionisti IT di utilizzare Active Directory® e l'infrastruttura di Criteri di gruppo per applicare le impostazioni dei dispositivi. Le funzionalità di gestione dei dispostivi OTA permettono ai professionisti IT di fornire aggiornamenti e applicazioni ai dispositivi in modo estremamente semplice, mentre le funzionalità di provisioning automatico OTA rendono la distribuzione più semplice e scalabile. La funzione Mobile VPN consente agli utenti finali di accedere a dati e applicazioni protetti dal firewall, fornendo al tempo stesso una connessione sempre attiva con la quale gli amministratori possono controllare i dispostivi distribuiti. Con tutte queste funzionalità riunite in un unico prodotto estendibile, personalizzabile e scalabile, Mobile Device Manager è uno strumento fondamentale per i professionisti IT di oggi.

Un'esigenza per la gestione
Si prevede che la forza lavoro mobile continuerà a crescere rapidamente anche nei prossimi anni. I dispositivi mobili sono sempre stati più difficili da gestire rispetto agli altri dispositivi di rete per il fatto stesso di essere mobili. Possono essere connessi alla rete in numerosi modi e molti di loro non sono completamente sicuri (potrebbero non essere protetti dal firewall, non utilizzano gli stessi sistemi operativi dei dispositivi client e potrebbero andare perduti molto facilmente a causa delle dimensioni ridotte).
La funzionalità ampliata dei dispositivi mobili di oggi fornisce grandi vantaggi sia alle aziende che agli utenti finali ma ne rende più difficile il supporto. In effetti, potrebbe esporre le reti e i dati aziendali a rischi di sicurezza aggiuntivi, in particolar modo quando i dispositivi vengono utilizzati per accedere a dati dei clienti e ad applicazioni line-of-business (LOB) sensibili. Se vengono perduti, rubati o utilizzati in modo non corretto, potrebbero creare delle vere e proprie emergenze di sicurezza.
Man mano che il divario della funzionalità tra i dispositivi mobili e i client di rete tradizionali diminuisce, aumenta l'esigenza di gestire tali dispositivi come fossero computer portatili o desktop. Questo è il concetto alla base di Mobile Device Manager. Con la sempre maggiore diffusione della piattaforma Windows Mobile® tra gli utenti aziendali, Mobile Device Manager diventerà un componente cruciale per i sistemi di gestione IT basati su Windows®.
Mobile Device Manager è stato progettato per controllare e ed eseguire la gestione end-to-end dei dispostivi Windows Mobile come fossero portatili o PC collegati in rete. È dotato di tre funzioni fondamentali:
Device Management Funzionalità centralizzata per il provisioning, il monitoraggio e la gestione dei dispositivi Windows Mobile, adattabile a decine di migliaia di utenti per server.
Security Management Migliori meccanismi per proteggere i dati sensibili e tenere traccia dei dispositivi.
Mobile VPN Migliore accesso ad applicazioni e dati protetti dal firewall con funzionalità sempre attiva.
Mobile Device Manager è in linea con l'idea generale seguita da System Center di fornire ai professionisti IT gli strumenti per gestire le risorse aziendali come normali computer portatili e desktop. Fornisce inoltre un'interfaccia utente che sarà familiare per coloro che già utilizzano altri prodotti System Center.
Ciò vuol dire che, per impostazione predefinita, Mobile Device Manager funziona bene con un'infrastruttura basata su Windows preesistente. Per fare alcuni esempi, utilizza Active Directory e Criteri di gruppo; funziona con gli strumenti di analisi e report Microsoft esistenti (quale SQL Server®); è estendibile utilizzando gli snap-in Microsoft® Management Console e i cmdlet Windows PowerShellTM.

Sistema Mobile Device Manager
Mobile Device Manager è altamente scalabile e può supportare decine di migliaia di dispositivi in un'unica istanza, oltre che numerose opzioni di configurazione. In generale, esistono quattro componenti di sistema principali sul lato server di Mobile Device Manager: un server gateway, un server di gestione dei dispositivi, un server di registrazione e i database di SQL Server (vedere la figura 1).
Figura 1 Tipico sistema Mobile Device Manager
Figura 1 Tipico sistema Mobile Device Manager
Generalmente, il server gateway è installato nella rete perimetrale. Funge da terminale per la connessione di rete di un dispositivo, autentica le connessioni dei dispositivi in ingresso, fornisce indirizzi IP stabili per i dispositivi ed esegue altre funzioni correlate alla connettività dei dispostivi o di rete.
Il server di gestione dei dispositivi rappresenta l'hub di amministrazione e gestione dei dispositivi, incluse l'implementazione di Criteri di gruppo, la distribuzione del software OTA e le cancellazioni dei dati nei dispositivi. Funziona con i controller di dominio esistenti. I server di gestione dei dispositivi fungono da client di rete sostitutivi per i dispositivi Windows Mobile, consentendo loro di comunicare con altri di sistemi.
Il server di registrazione crea Servizi di dominio Active Directory che rappresentano i dispositivi mobili nel controller di dominio, consentendo a tali dispositivi di essere gestiti come tutti gli altri membri del dominio. Questo server gestisce anche le richieste e il recupero dei certificati per i dispositivi mobili. Utilizza Active Directory come base per l'autenticazione dei dispositivi prima di accettare o emettere certificati di registrazione. I database di SQL Server forniscono un repository per tutte le informazioni correlate alla configurazione dei dispositivi, alle attività, alle impostazioni relative allo stato e così via.
Una volta che l'infrastruttura è operativa, Mobile Device Manager interagisce con i dispositivi mobili per registrare i dispositivi, definire le connessioni Mobile VPN e gestire i dispositivi. La registrazione dei dispositivi è il processo attraverso il quale un dispositivo si collega al dominio Active Directory. Mobile Device Manager si avvale di un "segreto condiviso" (una password monouso con scadenza) per consentire la registrazione dei dispositivi tramite connessioni non sicure. Una volta registrato, un dispositivo può stabilire una connessione Mobile VPN al server gateway attraverso cui viene instradato il traffico di rete proveniente dal dispositivo. Utilizzando la connessione Mobile VPN, l'amministratore o il sistema può eseguire la gestione dei dispositivi, effettuando il push del software e delle impostazioni sul dispositivo.

Estensione di Active Directory a Windows Mobile
Degli approcci alla sicurezza IT ad hoc o ibridi possono rivelarsi più rischiosi di un approccio completamente integrato. Mobile Device Manager è progettato per ridurre tali rischi fornendo un modo per gestire i dispositivi mobili, quali i PC Windows, tramite l'infrastruttura Servizi di dominio Active Directory esistente. Si ottiene in tal modo una gestione delle identità e degli accessi semplificata, un'assegnazione più coerente dei criteri e la configurazione della sicurezza necessaria.
Proprio come avviene con i PC o i server, gli oggetti Criteri di gruppo correlati ai dispositivi Windows Mobile possono essere assegnati alle unità organizzative, ai gruppi di sicurezza e ai filtri Strumentazione gestione Windows. Gli amministratori possono inoltre impedire a specifici dispositivi di ricevere le impostazioni di Criteri di gruppo.
Esistono oltre 130 impostazioni e criteri per i dispositivi Windows Mobile, che consentono un controllo con granularità fine su una serie di funzioni. Ecco un esempio:
  • Le impostazioni delle password includono il requisito di password; il tipo e la lunghezza minima; la scadenza e la cancellazione locale dei dati nei dispositivi dopo un determinato numero di tentativi non riusciti (inclusa la notifica all'utente del numero di tentativi restante).
  • Le impostazioni di blocco consentono agli amministratori di abilitare o disabilitare selettivamente la funzionalità dei dispositivi, incluse la fotocamera, la LAN wireless, la tecnologia a infrarossi, la tecnologia Bluetooth e gli archivi rimovibili. È possibile disattivare i protocolli Post Office Protocol (POP), Internet Message Access Protocol (IMAP), Short Message Service (SMS) e Multimedia Messaging Service (MMS) e disabilitare Windows Update per Windows Mobile.
  • Mobile Device Manager fornisce un controllo granulare sulle applicazioni. Può impedire ai dispositivi di eseguire applicazioni non firmate e con firme non approvate oppure consentire l'uso di specifiche applicazioni non firmate a discrezione dell'amministratore.
  • Per proteggere i dati, l'amministratore può applicare la crittografia dei file creati su schede di memoria rimovibili (con la chiave di crittografia collegata al dispositivo). È inoltre disponibile la crittografia dei dispositivi per garantire la protezione dei dati sensibili sul dispositivo. Oltre ai file che vengono protetti per impostazione predefinita, l'amministratore può specificare ulteriori file da crittografare.
  • Le impostazioni Mobile VPN determinano il livello di controllo di cui dispongono gli utenti sulle connessioni VPN dei loro dispositivi e consentono anche di impostare i livelli di crittografia dei dati.
  • Le impostazioni ActiveSync® definiscono il formato dei messaggi, i filtri per la validità della posta elettronica, i limiti per le dimensioni, le impostazioni di sincronizzazione e altro ancora.
  • Le impostazioni S/MIME possono richiedere la firma, la crittografia o l'uso di specifici algoritmi per i messaggi.
Tali impostazioni, insieme a molte altre, supportano gli scenari più svariati. Consentono ai professionisti IT di decidere quali tipi di applicazioni possono essere eseguite e su quali dispositivi. È consentita l'abilitazione o la disabilitazione per OTA delle funzionalità hardware; ad esempio, è possibile disabilitare le fotocamere per evitare che vengano compromesse, in modo intenzionale o involontario, le informazioni sensibili. È possibile inoltre applicare la crittografia dei dati sui dispositivi, sulle schede di memoria oppure sia sugli uni che le altre per impedire che, a seguito di perdita o furto, persone non autorizzate accedano ai dati proprietari in essi contenuti.
Mobile Device Manager include anche altri strumenti di gestione della sicurezza. Considerato il grandissimo numero di applicazioni disponibili per i dispositivi Windows Mobile, esiste una chiara esigenza per gli amministratori di controllare quelli che possono essere installati o meno. Mobile Device Manager consente di creare e applicare elenchi Consenti e Blocca esattamente per tale scopo. Fornisce inoltre avanzate funzionalità per la cancellazione remota dei dati nei dispositivi. Grazie alla connessione VPN sempre attiva per i dispositivi, è possibile rimuovere immediatamente i dati nei dispositivi senza dovere attendere che si connettano alla rete e che eseguano la sincronizzazione. Quando si esegue la cancellazione remota dei dati in un dispositivo, quest'ultimo viene rimosso dal controller di dominio e il relativo certificato viene revocato. Se un dispositivo viene recuperato in un secondo momento, è possibile specificare che si ricolleghi al dominio dopo la registrazione con una password monouso.

Controllo dei dispositivi mobili
Mobile Device Manager è appositamente progettato per semplificare la gestione dei dispositivi Windows Mobile sulla rete fornendo una funzionalità di gestione dei dispositivi completa in un'unica soluzione, inclusi il provisioning OTA, la distribuzione degli aggiornamenti e del software OTA e una gestione dell'inventario globale e centralizzata.
La funzionalità di provisioning automatico OTA si rivelerà preziosa sia per i professionisti IT che per gli utenti finali. Un utente immette un indirizzo di posta elettronica su un dispositivo Windows Mobile 6.1, che userà l'indirizzo per tentare di identificare un server di gestione dei dispositivi mobili. Se il server non viene trovato, all'utente viene richiesto di specificare manualmente l'indirizzo del server di gestione. Una volta identificato il server e aver stabilito che è possibile effettuare la registrazione, all'utente viene richiesto di immettere un passcode monouso creato in precedenza dall'amministratore.
L'indirizzo di posta elettronica e il passcode vengono utilizzati per autenticare l'utente e registrare il suo dispositivo nel server di gestione. A questo punto, le impostazioni e i criteri definiti dall'amministratore possono essere applicati sul dispositivo. Il metodo di registrazione automatica è progettato per aumentare la scalabilità delle distribuzioni dei dispositivi Windows Mobile e ridurre i tempi e i costi necessari per renderli operativi.
Le funzionalità di distribuzione del software OTA di Mobile Device Manager si basano su Windows Software Update Services (WSUS) 3.0, il toolkit di aggiornamento del software già utilizzato da numerosi professionisti IT in tutto il mondo. Come mostrato nella figura 2, WSUS 3.0 fornisce la funzionalità di assegnazione e assemblaggio delle applicazioni necessaria per le esigenze IT più complesse. Il software può essere assegnato automaticamente ai dispositivi appropriati in base alle regole e ai criteri impostati dall'amministratore. Analogamente a ciò che avviene per gli aggiornamenti di server e client, è possibile utilizzare WSUS 3.0 per automatizzare anche le patch e gli aggiornamenti dei dispositivi mobili. In modo ugualmente cruciale, gli aggiornamenti automatici possono essere disattivati per la pianificazione e il test delle distribuzioni.
Figura 2 Procedura guidata per la distribuzione del software
Figura 2 Procedura guidata per la distribuzione del software
Una delle maggiori sfide inerenti la gestione dei dispositivi mobili distribuiti su scala è la capacità di tenere traccia di ogni singolo elemento. Mobile Device Manager centralizza le informazioni dell'inventario e fornisce report flessibili e personalizzabili in base a SQL Server 2005 (attraverso il software utilizzato già da numerosi utenti e quindi già familiare). Gli amministratori possono raccogliere centinaia di informazioni presenti nell'inventario, incluse, tra le altre, le voci relative al sistema operativo e alla versione, al modello di dispositivo, alle installazioni applicate e ai criteri di sicurezza. L'inventario può essere esteso e l'amministratore ha la possibilità di aggiungervi voci e impostazioni del Registro di sistema.
Per ottenere una flessibilità ancora maggiore, è possibile controllare Mobile Device Manager utilizzando gli snap-in Microsoft Management Console, se si preferisce un'interfaccia utente grafica (vedere la figura 3), oppure la console Windows PowerShell, se si preferisce una riga di comando. In entrambi i casi, il sistema risulta estendibile e personalizzabile, a tutto vantaggio degli utenti aziendali che desiderano adattare il software alle esigenze della propria organizzazione.
Figura 3 Console Mobile Device Manager
Figura 3 Console Mobile Device Manager

Mobile VPN
Gli Information Worker utilizzano da anni i dispositivi mobili per le comunicazioni di posta elettronica. Attualmente, uno dei maggiori progressi nel campo dei dispositivi mobili è la possibilità di accedere alle applicazioni e ai dati aziendali protetti dal firewall. Con l'aumento degli accessi, aumentano anche i rischi per la sicurezza; di conseguenza, è necessaria una gestione attenta delle nuove funzionalità per prevenire le vulnerabilità. Mobile Device Manager fornisce le avanzate funzionalità Mobile VPN, che consentono agli utenti di accedere a dati su Intranet, che vanno da Microsoft DynamicsTM Customer Relationship Management (CRM) a SAP, fino a Siebel. Il modello è progettato per adattarsi alle strategie di accesso remoto esistenti per PC portatili e desktop (vedere la figura 4).
Figura 4 Impostazioni di Mobile VPN
Figura 4 Impostazioni di Mobile VPN
La funzionalità Mobile VPN consente di connettere il dispositivo al server gateway utilizzando una funzione di sicurezza a doppio envelope, in cui i dati vengono trasmessi in formato crittografato SSL attraverso un tunnel crittografato IPsec. Dopo l'autenticazione del dispositivo, l'utente può accedere alle risorse in base a quanto definito dal criterio specifico delle risorse e dalle sue credenziali.
La tecnologia Mobile VPN utilizzata da Mobile Device Manager consente di stabilire una connessione sempre attiva, che fornisce agli utenti un accesso avanzato e che permette ai professionisti IT di mantenere dispositivi aggiornati con le impostazioni e i criteri correnti. Tra l'altro, tale tecnologia consente anche di cancellare immediatamente i dati in un dispositivo se questo viene perduto o rubato. Anche in caso di interruzione di una sessione, la riconnessione rapida consente di riprendere la sessione senza la necessità di una nuova autenticazione. Mobile Device Manager consente una transizione senza problemi tra le reti Wi-Fi e cellulari, senza interrompere la connettività.
La tecnologia di sicurezza utilizzata in Mobile Device Manager Mobile VPN è basata su standard del settore, tra cui Open Mobile Alliance for Device Management (OMA DM), Internet Key Exchange (IKE) versione 2 e OMA Software Component Management Object (SCOMO). Ciò consente di rendere il sistema più estendibile e personalizzabile per specifiche situazioni a cui devono far fronte i professionisti IT che lavorano in ambienti complessi.

Soluzione completa
Mobile Device Manager fornisce un set completo di strumenti per la gestione dei dispositivi Windows Mobile, a cui è possibile accedere tramite un'unica interfaccia. Utilizza Active Directory e Criteri di gruppo per fornire strumenti di sicurezza che consentono di proteggere i dati, i dispositivi e la rete. La gestione dei dispositivi viene semplificata dalle funzionalità di aggiornamento, provisioning e registrazione OTA, oltre che da potenti strumenti per l'inventario. La tecnologia Mobile VPN è progettata per fornire una preziosa funzionalità alle aziende e agli utenti, senza compromettere la sicurezza.
Tutto ciò permette di semplificare il lavoro dei professionisti IT, che potranno gestire i dispositivi mobili sulla rete in modo assolutamente unico. Mobile Device Manager fornisce ai professionisti IT la possibilità di garantire esperienze utente straordinarie, ridurre l'overhead amministrativo e fornire un ROI maggiore per la gestione.
Si ringraziano Brian Hoskins, Derek Snyder, Prithvi Raj, Lax Madapaty e Katharine Holdsworth per il contributo fornito per questo articolo.

Matt Fontaine è uno scrittore freelance che si occupa di tecnologia e ricopre anche un ruolo di consulente per BuzzBee Company. È impegnato in numerosi campi quali il calcolo ad alte prestazioni, il software aziendale, il campo attuariale, i beni immobili commerciali, l'ingegneria, la costruzione e i beni di consumo confezionati. Matt è laureato al The Evergreen State College.


 System Center: Novit&#224; di System Center Essentials SP1
System Center Pete Zerger

Novità di System Center Essentials SP1
Panoramica:
  • Installazione semplificata con pacchetto di installazione integrato
  • Sostituzioni avanzate per l'ottimizzazione dei Management Pack
  • Supporto per i gruppi di lavoro
  • Nuova attività per il ricalcolo dello stato di integrità

Con il rilascio di System Center Essentials 2007 avvenuto nel luglio scorso, Microsoft ha rafforzato il suo impegno nei confronti delle aziende di medie dimensioni, colmando il divario esistente tra i costosi e complessi strumenti aziendali e le soluzioni shareware
per fornire una soluzione di gestione unificata per le operazioni IT. Essentials 2007 è specificatamente progettato per far fronte alle sfide delle aziende di medie dimensioni, in cui i professionisti IT spesso si trovano a svolgere un vasto numero di attività.
Essentials è facile installare e configurare e offre ai professionisti IT la possibilità di monitorare e gestire attivamente client e server, nonché di tenere traccia degli asset hardware e software. È progettato per semplificare attività tradizionalmente complesse quali il monitoraggio di applicazioni e servizi IT, la distribuzione del software client e server e la risoluzione dei problemi inerenti il desktop.
Dal momento del rilascio iniziale, Microsoft ha raccolto commenti dai clienti nel campo in cui utilizzano già Essentials per gestire la propria infrastruttura IT e tali informazioni sono state incorporate nel primo Service Pack del prodotto. Più che fornire semplicemente correzioni dei bug, SP1 introduce delle importanti funzioni avanzate che rendono il prodotto più flessibile per soddisfare le esigenze dei clienti in una vasta serie di scenari di distribuzione. Inoltre, i miglioramenti apportati alle prestazioni migliorano considerevolmente l'esperienza utente e semplificano l'amministrazione.
In quest'articolo verranno riesaminati i più importanti miglioramenti forniti in Essentials 2007 SP1. Verrà inoltre preso in considerazione in che modo riescono a rendere ancora più semplice la gestione dell'ambiente in uso.

Installazione semplificata
Il pacchetto di installazione integrato di SP1 contiene tutti gli aggiornamenti rapidi di Essentials rilasciati fino a ora, semplificando notevolmente l'attività di installazione. È ora possibile configurare Essentials anche per l'uso di un'istanza di SQL Server® 2005 a 64 bit remota, mentre il server Essentials è basato su un'istanza di Windows Server® 2003 a 32 bit. Ciò garantisce agli amministratori maggiore flessibilità nell'uso dell'infrastruttura server esistente nel proprio ambiente in una topologia di distribuzione di Essentials distribuita. Inoltre, Windows Server 2008 sarà una piattaforma supportata per l'agente, la console e il server Essentials 2007 SP1. Il supporto completo di Windows Server 2008 è previsto per un momento immediatamente successivo al rilascio per la produzione del nuovo sistema operativo.

Migliori prestazioni della console
Se è stata utilizzata la versione RTM di Essentials 2007, verrà sicuramente apprezzata l'interfaccia della console Essentials altamente reattiva inclusa in SP1. Le prestazioni sono state migliorate nelle viste avvisi, eventi, prestazioni, stato e stato attività. Ad esempio, in tutte le viste avvisi, le modifiche apportate al recupero dei dati consentono di selezionare i dati relativi agli avvisi con una velocità tre volte superiore. Le azioni e i report vengono ora portati in background, con un ulteriore miglioramento delle prestazioni dell'interfaccia utente. Analogamente, le attività e i report basati sul contesto (visualizzati nel riquadro Azioni che si trova nella parte destra di Operations Console) vengono caricati in background, consentendo una più rapida reazione delle viste alle selezioni effettuate.
Le informazioni relative agli avvisi visualizzate nel riquadro Dettagli avviso possono essere visualizzate o nascoste a seconda delle preferenze dell'utente facendo clic sul collegamento Show Knowledge o Hide Knowledge (vedere la figura 1). Tale preferenza verrà quindi mantenuta al momento di visualizzare avvisi futuri. Gli amministratori possono ora eseguire anche l'operazione di copia e incolla tradizionale dei dettagli relativi agli avvisi con i tasti di scelta rapida tradizionali (Ctrl+C e Ctrl+V).
Figura 1 Riquadro Dettagli avviso con i collegamenti Show/Hide Knowledge
Figura 1 Riquadro Dettagli avviso con i collegamenti Show/Hide Knowledge

Miglioramenti delle sostituzioni
Le sostituzioni consentono di ottimizzare i Management Pack, disabilitando le regole e i monitoraggi in cui non sono necessarie, oltre che di modificare i diversi valori soglia. Esistono diversi miglioramenti importanti correlati alle sostituzioni che semplificano l'ottimizzazione delle regole e dei monitoraggi dell'ambiente in uso e garantiscono una maggiore visibilità nelle sostituzioni già presenti nell'ambiente Essentials. In tal modo, diventa meno impellente creare regole personalizzate ed è possibile identificare le sostituzioni presenti nell'ambiente in modo più rapido.
Ad esempio, dopo aver creato una sostituzione per un oggetto Management Pack, è possibile esaminare il riepilogo delle sostituzioni per il tipo di oggetto nella finestra Riepilogo sostituzioni. Essentials 2007 SP1 assicura che la descrizione della sostituzione di destinazione sia completa. Ad esempio, se si crea una sostituzione per lo spazio libero sul disco logico per l'unità C:\ di Server1, il riepilogo mostrerà 'server1/c:'. Con un esempio è possibile chiarire l'importanza di questo cambiamento.
Osservare la figura 2 e notare che nella finestra Riepilogo sostituzioni per lo spazio libero sul disco logico di Windows Server 2003 della versione RTM di Essentials 200 non è possibile identificare il computer che ospita l'istanza dell'unità C:\ a cui è destinata la sostituzione. Nella medesima finestra Riepilogo sostituzioni in Essentials SP1, è possibile notare che nella colonna Nome ora vengono visualizzati sia l'istanza dell'unità di destinazione che il computer che ospita tale unità (vedere la figura 3).
Figura 2 Riepilogo sostituzioni in Essentials 2007 RTM
Figura 2 Riepilogo sostituzioni in Essentials 2007 RTM
Figura 3 Stessa finestra Riepilogo sostituzioni in Essentials 2007 SP1
Figura 3 Stessa finestra Riepilogo sostituzioni in Essentials 2007 SP1
La gravità dell'avviso può avere un impatto sostanziale sul volume del traffico degli avvisi raccolto dagli amministratori. Fino a ora, se una regola Essentials in un Management Pack sottoposto a sealing veniva configurata per generare un avviso critico che non si rivelava tale su alcuni server, gli amministratori non potevano modificare tale impostazione, dato che la gravità e la priorità dell'avviso non risultavano esposte nelle sostituzioni delle regole. L'unica soluzione consisteva nello svolgere un lungo lavoro per creare sostituzioni in grado di disabilitare le regole per alcuni computer e quindi si procedeva alla ricreazione delle regole in un Management Pack non sottoposto a sealing in cui i parametri degli avvisi potevano essere modificati. Questa, ovviamente, non si rivelava la situazione ideale per gli amministratori.
Il problema è stato affrontato con decisione in SP1, esponendo sia la gravità che la priorità dell'avviso come parametri degli avvisi in tutte le regole dei Management Pack sottoposti a sealing, come mostrato nella figura 4. In questo modo, gli amministratori possono abbassare e alzare in modo semplice e rapido la gravità e la priorità degli avvisi generati della regole in Essentials 2007 attraverso la creazione di sostituzioni.
Figura 4 Sostituzioni delle regole per la gravità e la priorità degli avvisi
Figura 4 Sostituzioni delle regole per la gravità e la priorità degli avvisi
Osservando la figura 4 è anche possibile notare la casella di controllo Imposto, che non risulta invece disponibile nell'interfaccia della console nella versione RTM di Essentials. Nei casi in cui vengano abilitate più sostituzioni per un oggetto, quella con il flag Applicato selezionato avrà la priorità massima. Ciò può rivelarsi utile nel caso in cui sia stata impostata la stessa priorità per due gruppi di oggetti e alcuni oggetti abbiano l'appartenenza in entrambi i gruppi. Impostando l'opzione Imposto per la sostituzione che si desidera configurare come prioritaria, si potrà essere certi di quale sostituzione verrà applicata.
Per semplificare la creazione di nuovi Management Pack, Essentials 2007 SP1 introduce la possibilità di copiare le viste da un Management Pack esistente ad un altro Management Pack non sottoposto a sealing. L'operazione di copia viene supportata per tutti i tipi di viste (ad esempio viste eventi, avvisi, prestazioni, dashboard e diagramma) e può essere eseguita nell'area di monitoraggio. Ad esempio, se è stato creato un Management Pack per le sostituzioni di Active Directory® e si desidera utilizzare una delle viste dei Management Pack di Active Directory nel Management Pack delle sostituzioni di Active Director, è possibile selezionare semplicemente la vista desiderata e incollarla nella cartella del Management Pack prescelto all'interno del riquadro di spostamento dell'area di monitoraggio.

Nuovo report delle sostituzioni
Vale la pena segnalare anche il nuovo report delle sostituzioni incluso nella Microsoft® Generic Reporting Library, che si trova nel riquadro Report della console Essentials. Questo report consente di descrivere le sostituzioni prendendo in considerazione il Management Pack in cui sono archiviate oppure quello in cui vengono applicate (vedere la figura 5). Gli utenti sono in grado di impostare i parametri del report per escludere dal report le sostituzioni dei Management Pack sottoposti a sealing. Questa si rivela un'importante opzione di filtro in quanto i Management Pack sottoposti a sealing di Microsoft e terze parti contengono numerose sostituzioni che non verranno prese in considerazione quando si creano report per le modifiche apportate nell'ambiente in uso.
Figura 5 Parametri del report delle sostituzioni
Figura 5 Parametri del report delle sostituzioni
Se si segue la procedura consigliata Microsoft per la creazione di un Management Pack separato per ogni Management Pack sottoposto a sealing (uno per il Management Pack di Active Directory, uno per quello di Exchange e così via), sarà possibile limitare in modo più efficace l'ambito del report per visualizzare le sostituzioni che si applicano a uno specifico Management Pack.
Dopo aver selezionato i Management Pack sottoposti a sealing appropriati, è possibile eseguire il report, che visualizza l'output mostrato nella figura 6. Il report mostra chiaramente la regola o il monitoraggio a cui si applica la sostituzione (la colonna Affected element), oltre che l'ora e la data di installazione e rimozione associate al monitoraggio. Ciò dimostra che il report delle sostituzioni non ha solo la funzione di un elenco delle sostituzioni attive, ma rappresenta anche un report della cronologia delle modifiche per la configurazione delle sostituzioni.
Figura 6 Dettagli del report delle sostituzioni
Figura 6 Dettagli del report delle sostituzioni
Infine, nella parte inferiore della vista dettagli per ogni regola o monitoraggio interessato, sarà disponibile un collegamento ipertestuale con etichetta Rule configuration view. Questo collegamento avvia una vista regole o monitoraggi separata con l'ambito già assegnato al tipo di oggetto interessato. Ad esempio, se si fa clic sul collegamento Rule configuration view per la sostituzione mostrata nella figura 6, che è una sostituzione di una regola che punta al ruolo del computer Active Directory Domain Controller Server 2003, la vista regole risultante visualizzerà solo le regole che puntano a tale tipo di oggetto.

Supporto per i computer inclusi in un gruppo di lavoro
Uno dei fattori principali correlati all'esigenza dei clienti di gestire server e workstation nelle configurazioni dei gruppi di lavoro. Numerosi ambienti dispongo di almeno un server situato in una rete perimetrale o in una succursale non collegata al dominio. Dato che Essentials richiede un'autenticazione reciproca tra il server Essentials e i computer gestiti tramite agente, anche i computer dei gruppi di lavoro esterni al limite di attendibilità del server Essentials non rientrano nell'ambito della distribuzione degli agenti Essentials. In molti ambienti, ciò comporta che i componenti principali dell'infrastruttura vengono lasciati non monitorati e al di fuori del processo di gestione delle patch Essentials. Come è possibile gestire in modo sicuro questi computer?
SP1 introduce la certificazione basata sui certificati per gli scenari in cui non sono disponibili le autenticazioni Active Directory e Kerberos. Ciò richiede che sul server Essentials e sul computer gestito tramite agenti sia installato un certificato digitale X.509. Il certificato digitale può essere emesso da un'Autorità di certificazione principale autonoma o Enterprise Windows®. Se al momento non si dispone di un'Autorità di certificazione Windows, è possibile installare questa funzione utilizzando Installazione applicazioni su un controller di dominio o su un server membro dell'ambiente in uso, incluso il server Essentials. Per ulteriori informazioni sui Servizi certificati e sull'infrastruttura a chiave pubblica (PKI) in Windows Server 2003, vedere microsoft.com/windowsserver2003/technologies/pki.
Per configurare l'autenticazione basata sui certificati in Essentials, è necessario che venga richiesto ed emesso un certificato sul server Essentials e sul computer assegnato alla gestione. La richiesta può essere eseguita attraverso un sito Web sul server che funge da Autorità di certificazione.
Una volta emesso e installato, il certificato deve essere "registrato" per l'uso con Essentials utilizzando l'utilità della riga di comando MOMCertImport. Per completare la configurazione del certificato, è necessario semplicemente esportare il certificato in un file (in formato .pfx) ed eseguire MOMCertImport sul computer locale con la seguente sintassi:
MOMCertUtil.exe <cert path \ name>
Dopo aver effettuato tutte queste operazioni sul server Essentials e sul computer assegnato alla gestione, questi sistemi possono eseguire l'autenticazione reciproca e quindi effettuare lo scambio sicuro di dati tramite un canale crittografato. Per completare il processo di distribuzione degli agenti, è necessario semplicemente eseguire un'installazione manuale dell'agente Essentials sul computer di destinazione.

Monitoraggio della rete e dei dispositivi
Essentials 2007 fornisce la funzionalità di monitoraggio dei dispositivi di rete per rilevare gli attributi comuni di numerosi dispositivi di rete abilitati per SNMP. Sebbene SNMP versione 2c (SNMPv2c) sia il protocollo più diffuso oggi, non tutti i dispositivi di rete vengono creati allo stesso modo. Pertanto, SP1 fornisce il supporto per SNMP versione 1 (SNMPv1) per consentire il monitoraggio di una serie di dispositivi di rete, quali alcuni gruppi di continuità, router e server di stampa non abilitati per SNMPv2c. Come mostrato nella figura 7, gli amministratori possono indicare a Essentials quale versione di SNMP deve essere utilizzata attraverso un campo a discesa aggiuntivo disponibile nella Gestione guidata dispositivi e computer.
Figura 7 Interfaccia avanzata per il rilevamento dei dispositivi di rete
Figura 7 Interfaccia avanzata per il rilevamento dei dispositivi di rete

Gestione degli aggiornamenti avanzata
In SP1 sono forniti anche dei significativi miglioramenti per la gestione degli aggiornamenti. Le regole di approvazione automatica di Windows Server Update Services (WSUS) 3.0 consentono di specificare diverse classificazioni di prodotti e aggiornamenti, ad esempio l'approvazione automatica per gli aggiornamenti delle definizioni per Microsoft Word.
In Essentials è stato anche introdotto il supporto delle regole di approvazione automatica, che garantiscono al sistema una funzionalità simile a quella della piattaforma WSUS 3.0 (vedere la figura 8). Ciò consente agli amministratori di creare approvazioni automatiche per più categorie di aggiornamenti, inclusi gli aggiornamenti critici di Windows Vista® e i Service Pack per il sistema 2007 Office. Le regole di approvazione automatica verranno quindi applicate a tutti gli aggiornamenti presenti al momento sul server WSUS. Di conseguenza, facendo clic sull'attività Run Rule(s) Now nella finestra di dialogo Approvazioni automatiche, gli amministratori possono applicare immediatamente le modifiche agli aggiornamenti esistenti che sono inclusi nella console Essentials.
Figura 8 Approvazioni automatiche nella gestione degli aggiornamenti
Figura 8 Approvazioni automatiche nella gestione degli aggiornamenti
Con l'aggiunta del supporto per la distribuzione degli agenti ai computer nelle configurazioni dei gruppi di lavoro, gli amministratori potranno controllare la gestione degli aggiornamenti per l'intero ambiente dalla console Essentials.

Calcolo dello stato di integrità degli oggetti
Nel passato, quando visualizzavano lo stato dei monitoraggi in Esplora stati, gli amministratori erano costretti ad attendere l'aggiornamento periodico dello stato del monitoraggio per determinare se i ripristini o altre azioni correttive erano state eseguite correttamente. Una nuova attività della versione SP1 di Esplora stati è l'attività Recalculate Health, che consente di eseguire il ricalcolo su richiesta dello stato del monitoraggio (vedere la figura 9). Ciò consente di rendere il processo di correzione degli errori estremamente più rapido eliminando l'intervallo di attesa tra un'azione correttiva e l'altra al momento di verificare se lo stato del monitoraggio viene riportato su Integro.
Figura 9 Attività Recalculate Health in Esplora stati
Figura 9 Attività Recalculate Health in Esplora stati
Analogamente, anche l'attività Reimposta stato (disponibile dalla versione RTM) ha subito degli importanti miglioramenti per garantire che ogni monitoraggio risponda alla richiesta per reimpostare Integro per il proprio stato (verde). Ciò avviene anche per le richieste di reimpostazione eseguite sul server Essentials, che nella versione RTM non restituiva sempre delle risposte.

Diagnostica tramite script
La diagnostica è un nuovo tipo di attività in linea speciale introdotto in Essentials 2007, che consente l'esecuzione automatica o su richiesta delle attività di raccolta dati quando viene generato un avviso. La diagnostica automatica è quella diagnostica configurata per essere eseguita ogni volta che un monitoraggio entra in uno stato di errore. I risultati della diagnostica vengono visualizzati nel riquadro Dettagli della scheda Eventi modifica stato di Esplora stati. Nella stessa area viene visualizzata una diagnostica su richiesta come collegamento ipertestuale ed è possibile eseguirla semplicemente facendo clic sul collegamento. I risultati vengono visualizzati in una finestra popup sul computer locale.
Come mostrato nella figura 10, SP1 estende la funzionalità di diagnostica consentendo l'uso degli script nelle attività di diagnostica (diversamente dalle risposte tramite la riga di comando della versione RTM). Ciò fornisce il framework per eseguire risposte di raccolta dati automatizzate più elaborate e diversificate quando si verificano condizioni di errore. Per queste attività di diagnostica sono supportati sia VBScript che JScript®.
Figura 10 Riquadro Dettagli avviso con i collegamenti Show/Hide Knowledge
Figura 10 Riquadro Dettagli avviso con i collegamenti Show/Hide Knowledge

Esportazione in Visio
Un'altra nuova funzione di SP1 è il supporto dell'esportazione di diagrammi nel formato Microsoft Visio® 2007 mediante un pulsante che diventa disponibile sulla barra degli strumenti quando viene selezionata una vista diagramma. Si ottiene in tal modo una funzione di documentazione estremamente utile, poiché i Management Pack Active Directory ed Exchange Server 2003 forniscono diagrammi di topologie dettagliati in modo predefinito, consentendo agli amministratori di risparmiare il tempo altrimenti necessario per la scrittura della documentazione. Inoltre, le preferenze relative al layout dei diagrammi possono essere salvate. Tali preferenze verranno mantenute dalla console Essentials e utilizzate la volta successiva che viene selezionata la vista diagramma.

Miglioramento del backup e del ripristino
Immediatamente dopo l'installazione di Essentials 2007 SP1, l'installazione guidata ora richiede automaticamente all'utente di eseguire il backup delle chiavi di crittografia del server di gestione Essentials (vedere la figura 11). Tale coppia di chiavi viene utilizzata dal server Essentials nell'archiviazione sicura delle credenziali Esegui come nel database Operations Manager. Queste chiavi sono necessarie anche per ripristinare il server Essentials dal backup. Senza di esse, è necessario reinstallare e riconfigurare interamente Essentials.
Figura 11 Backup delle chiavi di crittografia di Essentials
Figura 11 Backup delle chiavi di crittografia di Essentials

Migliore qualità dei Management Pack
Oltre ai numerosi miglioramenti apportati nella versione SP1 di Essentials, il team di prodotto Essentials è impegnato a migliorare la qualità dei Management Pack per la piattaforma Essentials attraverso procedure di test più diversificate e rigorose, nonché attraverso una maggiore interazione con i diversi team di prodotto ed esperti delle applicazioni. I risultati saranno evidenti nel rilascio di un maggior numero di Management Pack che utilizzano le nuove funzioni nella piattaforma di monitoraggio Microsoft, tra cui le soglie di regolazione automatica, il monitoraggio orientato ai servizi con modelli di applicazioni distribuite e il potente motore di gestione dei report.
Microsoft inizierà a rilasciare ulteriori Management Pack che utilizzano le nuove funzioni in Essentials a partire dal 2008. I Management Pack per Essentials 2007 possono essere scaricati dal System Center Management Pack Catalog all'indirizzo go.microsoft.com/fwlink/?LinkId=112399.

Provate la nuova versione
SP1 fornisce miglioramenti delle prestazioni che fanno di System Center Essentials 2007 un saggio investimento per gestire l'infrastruttura IT delle aziende di medie dimensioni. Se si dispone già di Essentials 2007 nell'ambiente in uso, è possibile scaricare una copia di SP1 e provare a utilizzare i miglioramenti delle funzioni e delle prestazioni. Se Essentials 2007 non è ancora stato distribuito e si desidera provare a utilizzare Essentials 2007 con SP1, è possibile scaricare il pacchetto di installazione integrato di SP1. Entrambi i pacchetti, oltre alle informazioni sui prodotti aggiuntivi, sono disponibili nella home page di Essentials 2007 all'indirizzo microsoft.com/systemcenter/essentials. 

Pete Zerger è un Consulting Partner presso AKOS Technology Services e vanta di nove anni di esperienza nel settore IT. È impegnato principalmente nelle attività di progettazione e distribuzione della gestione di operazioni aziendali, dei servizi directory e delle soluzioni di messaggistica. Pete ha conseguito le certificazioni MCSE per la messaggistica e MCTS per SQL Server 2005 e ha ottenuto il riconoscimento MVP di Microsoft per Microsoft Operations Manager. È il fondatore di systemcenterforum.org, un famoso sito di comunità che prende in esame Essentials 2007 e la famiglia di prodotti System Center.


 Dal redattore: Un caloroso benvenuto alla rubrica &quot;Inside SharePoint&quot;
Dal redattore
Un caloroso benvenuto alla rubrica "Inside SharePoint"

Come ricorderete dalla Nota del redattore del mese scorso, dopo aver salutato con affetto l'ultima puntata di The Cable Guy, ho promesso che questo numero di TechNet Magazine avrebbe visto il debutto di una nuova rubrica. Vi prego quindi di accogliere con un caloroso benvenuto "Inside SharePoint", una rubrica mensile che si occuperà di tutto ciò che un professionista dell'IT deve sapere in materia di architettura, distribuzione, protezione, gestione e supporto di un'infrastruttura SharePoint. Come promesso, Pav Cherny ci introdurrà all'argomento con una panoramica sugli elementi chiave di un'infrastruttura SharePoint flessibile. Continueremo il mese prossimo con una descrizione della gestione dei siti SharePoint. E la nostra offerta rimane valida: se desiderate vengano trattati specifici argomenti SharePoint, scriveteci all'indirizzo tnmag@microsoft.com.
Sempre nel numero di questo mese, torna Gil Kirkpatrick il quale ci fornirà una panoramica approfondita ed esauriente sul processo di backup e ripristino di Active Directory in Windows Server 2008. In molte (se non addirittura nella maggior parte) reti orientate a Windows, Active Directory è la fonte autorevole delle informazioni di identità e di accesso, che rappresentano indiscutibilmente dati piuttosto importanti. È inoltre l'infrastruttura chiave di qualsiasi distribuzione di Exchange, SharePoint, Configuration Manager ... e l'elenco continua. Eppure, durante una delle sessioni alla Directory Experts Conference di Chicago del mese scorso alla quale ho partecipato, quando Gil ha chiesto quante persone nell'aula disponevano di un piano di ripristino di emergenza completo per Active Directory, il numero di mani alzate è stato talmente esiguo da poter essere contato sulle dita di una mano. Ciò basta a dimostrare che chiunque dovrebbe leggere l'articolo di Gil.
Nell'ipotesi incredibilmente remota che Active Directory non sia il vostro forte, non preoccupatevi...questo articolo contiene dati sufficienti in merito. Matt Fontaine ci presenterà System Center Mobile Device Manager (una nuova tecnologica indispensabile in caso di gestione di dispositivi Windows Mobile nella propria organizzazione), Pete Zerger ci guiderà attraverso System Center Essentials SP1 e Jesper Johansson applicherà il principio di indeterminazione di Heisenberg alla sicurezza dell'IT. Gli Scripting Guy sono insieme a noi, come sempre, Exchange Queue & Una certezza e molto altro.
Infine, stiamo lavorando ad un progetto per il nuovo meraviglioso sito Web di TechNet Magazine (ancora disponibile sul sito technetmagazine.com). Alcuni dei nostri autori preferiti stanno sviluppando dei video-screencast sulle procedure che accompagneranno i nostri articoli online per guidarvi nella comprensione dettagliata del contenuto. Ci piacerebbe sapere quali sono gli argomenti e le tecnologie su cui vorreste ricevere maggiori informazioni con tali screencast. Ancora una volta, non esitate a contattarci all'indirizzo tnmag@microsoft.com. Grazie! -Joshua Hoffman


 Lettere: La parola ai lettori
Lettere
La parola ai lettori

Cluster di Windows
Quali sono le differenze tra Windows® Compute Cluster Server e un cluster Windows convenzionale?
—from blogs.technet.com/tnmag

È una domanda estremamente comune. Ricevo molte domande relative al clustering di disponibilità (clustering di failover) quando parlo di Windows CCS (Compute Cluster Server). I cluster di calcolo sono diversi dai cluster di disponibilità, che forniscono il failover di servizi tra sistemi.
I cluster di calcolo utilizzano una coda di lavori o un'utilità di pianificazione per assegnare le attività ai vari sistemi presenti nel cluster. La suddetta utilità (in esecuzione sul nodo principale del cluster) riceve richieste di pianificazione lavori e assegna il lavoro ad altri nodi di calcolo nel cluster. In parole povere, CCS consente di dividere il lavoro tra computer, mentre il clustering di disponibilità tenta di fornire un servizio ininterrotto.
—John Kelbley, Senior Technical Product Manager

Robocopy GUI
Grazie per la rubrica su Robocopy GUI (Novembre 2006, technetmagazine.com/issues/2006/11/UtilitySpotlight). Semplifica l'utilizzo di Robocopy e i raggruppamenti di schede mi hanno consentito di comprendere le varie opzioni della riga di comando.
—Biff M.

Grazie mille per i tuoi commenti! Mi fa piacere sapere che ritieni utile questo strumento! Come sempre, se desideri esaminare altri strumenti trattati in TechNet Magazine, non esitare a contattarci! Scrivici all'indirizzo tntools@microsoft.com.

Driver di dispositivo
È possibile creare un elenco di tutti gli specifici file associati a particolari driver di dispositivo?
—T.P.

Se l'obiettivo è la creazione di un elenco di tutti i vari file che supportano una specifica installazione di driver, purtroppo non esiste una soluzione perfetta. La soluzione migliore consiste nell'analisi del file INF incluso con il driver in questione, in particolare nella sezione contrassegnata da *.copyfiles, poiché è correlata al Plug-n-Play ID (PnPID) per tale driver. Tale sezione elencherà i file copiati durante l'installazione del driver.
La situazione è però complicata ulteriormente da alcuni driver che richiamano "CoInstallers" come parte del driver, poiché è possibile che uno di essi estragga o installi in realtà altri file. Ma, analizzando la sezione CopyFiles, generalmente si otterrà la maggioranza dei file; è sufficiente esaminare attentamente il file INF e comprenderne il contenuto.
—Wes Miller, Columnist, The Desktop Files

Autenticazione Windows
Ho cercato di raccogliere articoli o whitepaper che forniscono informazioni sull'autenticazione Windows. In modo specifico, intendo acquisire maggiori informazioni sul concetto di wireless utilizzando IAS (Internet Authentication Service) in un dominio Windows 2000 Active Directory®. Puoi indirizzarmi agli articoli contenenti tali informazioni?
—Brett M.

La migliore fonte di documentazione sull'argomento è probabilmente lo IAS TechCenter in TechNet, che si trova all'indirizzo technet.microsoft.com/network/bb643123. Tale sezione include collegamenti a diversi articoli e whitepaper relativi all'autenticazione con IAS.
Un altro forum online interessante in cui porre tali domande è il Windows 2000 Server Security Newsgroup all'indirizzo microsoft.com/technet/community/newsgroups/dgbrowser/en-us/default.mspx?dg=microsoft.public.win2000.security.

Un lettore riconoscente
Ho letto il tuo interessante articolo "Una guida introduttiva alle indagini forensi sui computer" del dicembre 2007 (disponibile all'indirizzo technetmagazine.com/issues/2007/12/Forensics). Innanzitutto, desidero congratularmi con te per avere pubblicato informazioni così importanti. In secondo luogo, mi congratulo con il coautore Tom Cloward, Program Manager alla Microsoft, per avere utilizzato la sua preziosissima esperienza nel campo della sicurezza. Desidero inoltre congratularmi con il coautore Frank Simorjay, Technical Program Manager ed esperto in materia di sicurezza alla Microsoft. Vi occupate di sicurezza e avete acconsentito a condividere la vostra ampia conoscenza dell'argomento per risolvere i problemi causati dagli attacchi alla sicurezza provenienti da Internet. È encomiabile. Grazie mille.
—Mr. S.

Ti ringraziamo per il tuo commento. Siamo d'accordo con te sull'importanza dell'argomento sicurezza e siamo lieti di informarti che questo stesso soggetto verrà approfondito nei numeri futuri di TechNet Magazine. Grazie ancora!


 Toolbox: Nuovi prodotti per professionisti IT
Toolbox
Nuovi prodotti per professionisti IT
Greg Stee

Analisi dello spazio su disco
FolderSizes
foldersizes.com
Come scoprire cosa sta monopolizzando tutto lo spazio sul computer del cliente Anche se è possibile accorgersi quando sta per essere utilizzato tutto lo spazio del computer semplicemente eseguendo un monitoraggio dello spazio su disco, riuscire a capire come liberare spazio sul disco può rivelarsi un'attività estremamente complessa. Un'utilità che consente di capire cosa sta utilizzando tutto lo spazio su disco è FolderSizes di Key Metric Software.
La prima volta che si avvia questa applicazione, viene fornita una rapida descrizione dettagliata della relativa interfaccia utente (anche se l'applicazione è estremamente semplice). Per analizzare un'unità o una cartella, è possibile fare semplicemente doppio clic nel pannello gerarchico Folder Browser. Dopo che FolderSizes ha analizzato il sistema, il programma fornisce un grafico dello spazio su disco utilizzato e una vista delle cartelle che mostra la quantità di spazio utilizzata da ciascuna delle cartelle padre. Con un semplice clic, è possibile modificare la modalità di visualizzazione delle cartelle trasformando il grafico a torta in un grafico a barre per vedere esattamente dove viene utilizzato lo spazio. Personalmente ritengo che il grafico a barre possa essere più utile quando si a che fare con un grande numero di directory di pari livello.
È possibile fare doppio clic su una barra, una sezione o una cartella per eseguire il drill-down nella sottocartella. Questa navigazione consente di eseguire in modo semplice e rapido lo zoom avanti sui potenziali punti problematici, ad esempio una directory "nascosta" di file mp3 che l'utente ha denominato Sales Presentations. Altrimenti, se l'utente carica una grande quantità di documenti sul computer, è possibile ordinarli in base alla data dell'ultima modifica per capire quali sono i file a cui non si è acceduto per un periodo di tempo prolungato. In questo modo si avrà una motivazione valida per convincere l'utente ad archiviare i file su un CD o a eliminarli definitivamente visto che non sono di grande utilità.
Un'altra funzione preziosa di FolderSizes è quella che consente di personalizzare il numero di livelli che si desidera vengano presentati nel grafico. Ad esempio, è possibile visualizzare un grafico di tutte le cartelle presenti sull'unità, ordinate dalla più grande alla più piccola, per riuscire a individuare i punti problematici. Dopo averne individuato uno, è possibile fare clic con il pulsante destro del mouse per accedere alle azioni "command prompt from here" ed "explore this folder". Ciò consente di eseguire tutti gli altri controlli o utilità di cui si ha bisogno.
FolderSizes include anche un generatore di report incorporato in grado di fornire un altro insieme di viste relative al contenuto del file system da analizzare. Ad esempio, è possibile individuare i file più grandi di un determinato tipo o quelli più vecchi presenti sul sistema, identificare i file temporanei o duplicati oppure localizzare i file di sola lettura e quelli che hanno uno specifico proprietario sul file server. L'elenco di possibilità potrebbe continuare a lungo. Quindi, una volta generato il report, è possibile filtrare la vista, stamparla o esportarla in formato XML, HTML o CSV.
Oltre a ciò, FolderSizes offre anche la possibilità di eseguire il backup in un modo assolutamente straordinario, garantendo che vengano inclusi nell'operazione solo i file che si desidera davvero archiviare. È inoltre possibile utilizzare l'interfaccia della riga di comando dell'applicazione per creare script e automatizzare i controlli dei sistemi client o server. Pertanto, se si è alla ricerca di un modo rapido per individuare ciò che monopolizzando lo spazio su disco dei computer server o client, è consigliabile prendere in considerazione FolderSizes.
Prezzo: Si parte da 50 dollari (per una singola licenza utente).
FolderSizes offre una visualizzazione sotto forma di grafico delle cartelle di sistema
FolderSizes offre una visualizzazione sotto forma di grafico delle cartelle di sistema

Gestione degli account utente
Inactive Users Tracker
netwrix.com/inactive_users_tracker_freeware.html
Nelle organizzazioni di grandi dimensioni sarà maggiore la probabilità di perdere traccia degli account utente inattivi. E, in termini di sicurezza, è sempre un'ottima idea eseguire un processo per tenere traccia con facilità degli account utente inattivi e disabilitarli o rimuoverli, eliminando un potenziale problema di sicurezza. Inactive Users Tracker, un'utilità freeware di NetWrix Corporation, consente di fare ciò in modo estremamente semplice.
Lo strumento analizza periodicamente i domini Active Directory® alla ricerca degli utenti inattivi e invia un messaggio di posta elettronica con l'elenco degli account inattivi all'indirizzo amministrativo prescelto. È possibile specificare il dominio che si desidera gestire e l'account che dispone dell'autorizzazione di analizzare Active Directory per ricercare gli account inattivi. Inoltre, è possibile stabilire il numero di giorni per cui un utente deve essere inattivo affinché possa essere contrassegnato come tale ed essere incluso nella notifica di posta elettronica. Ovviamente, è anche possibile pianificare quando dovrà essere avviato il processo.
A parte ciò, si dovrà semplicemente configurare il server SMTP per l'inoltro della notifica di posta elettronica all'indirizzo amministrativo e specificare se si desidera che l'utilità filtri o meno gli account utente inattivi utilizzando un filtro per i nomi (ad esempio, si può decidere che tutti gli account dei consulenti inizino con "c_").
È disponibile anche una versione commerciale (i preventivi dei prezzi vengono personalizzati in base agli acquirenti). Questa versione consente di personalizzare i messaggi di posta elettronica inviati agli utenti e supporta la disabilitazione automatica degli account utente inattivi. Include anche un supporto tecnico.
Prezzo: Gratuito
Inactive Users Tracker invia notifiche sugli utenti inattivi
Inactive Users Tracker invia notifiche sugli utenti inattivi

Miglioramento delle comunicazioni di posta elettronica
Exclaimer Mail Utilities 2007
exclaimer.com/MailUtilities2007.aspx
In una società regolamentata e in cui tutto può essere oggetto di controversie legali come quella odierna, è estremamente importante che le organizzazioni proteggano le proprie comunicazioni di posta elettronica. Al tempo stesso, una comunicazione costante e il riconoscimento della veste grafica aziendale consentono alle organizzazioni di instaurare rapporti migliori con le parti con cui interagiscono. Exclaimer Mail Utilities 2007, progettata per il funzionamento con le distribuzioni Exchange Server 2007, fornisce aiuto su entrambi i fronti.
L'applicazione dispone di tre funzioni di base, che consentono di unificare e proteggere le comunicazioni di posta elettronica delle organizzazioni: le dichiarazioni di non responsabilità, la veste grafica aziendale e le firme. Inoltre, è possibile aggiungere moduli per una protezione dalla posta indesiderata e dai virus.
Riguardo alle dichiarazioni di non responsabilità, Exclaimer Mail Utilities consente di ridurre il rischio di essere coinvolti in controversie legali e garantisce la conformità alle normative, ad esempio l'Health Insurance Portability and Accountability Act (HIPAA) e la Circular 230, attraverso l'aggiunta di un messaggio personalizzato (prima o dopo il testo del messaggio di posta elettronica) a ogni messaggio in uscita dall'organizzazione. Per ciò che invece riguarda la veste grafica aziendale, è possibile aggiungere in modo estremamente semplice un'immagine e un'etichetta a ogni messaggio inviato per essere certi che il cliente possa riconoscere sempre l'azienda. Infine, relativamente alle firme, è possibile fare in modo che venga applicata una firma automatica a ogni messaggio, sia che venga inviato da uno smart device, Microsoft® Outlook® Web Access, che da un client Outlook standard. La firma viene generata dinamicamente dai dati probabilmente già archiviati nell'albero di Active Directory. Inoltre, è possibile configurare lo strumento per personalizzare tali firme in base a una serie di fattori, incluso il fatto che il messaggio venga inviato a un utente interno o esterno all'azienda oppure in base al destinatario e all'argomento del messaggio.
Il prezzo di Exclaimer Mail Utilities 2007 viene personalizzato in base al numero di utenti e parte da 245 dollari per 25 utenti, per poi scendere man mano che gli utenti aumentano. Inoltre, il modulo di protezione dalla posta indesiderata, il modulo antivirus e il supporto tecnico contribuiscono a far salire il prezzo base. Il supporto è obbligatorio per il primo anno e il prezzo parte da 55 dollari per 25 utenti. Per motivi di prestazioni, è necessario un computer su cui sia installato Windows Server 2008 o Windows Server® 2003 a 64 bit per eseguire Mail Utilities. Se tutto ciò viene ritenuto interessante, ma si utilizza ancora Exchange Server 2003, è disponibile anche un'altra versione.
Prezzo: Si parte da 245 dollari per 25 utenti.

Recensione
How to Cheat at Securing SQL Server 2005
syngress.com
Noi professionisti IT sappiano bene che la sicurezza dovrebbe essere una priorità assoluta per le implementazioni delle infrastrutture. È sufficiente pensare alla stretta interconnessione degli ambienti e alla grande quantità di informazioni sensibili mantenute nei sistemi. Ciò è vero soprattutto per le istanze di SQL Server®, in quanto tendono a essere origini centralizzate di informazioni sensibili. Inoltre, le normative in vigore al momento per la protezione della privacy, quali la Sarbanes-Oxley e l'HIPAA, possono causare significativi problemi di carattere legale e finanziario se dovesse accadere qualcosa e i dati venissero compromessi.
Quando si proteggono le istanze di SQL Server 2005, è possibile fare riferimento al libro How to Cheat at Securing SQL Server 2005. Il titolo potrebbe essere fuorviante, in quanto il libro non fornisce dei "trucchi" ma offre un riferimento dettagliato per proteggere le distribuzioni di SQL Server 2005. La strategia segue il principio del "minimo numero di di accessi", per cui è consentito solo ciò che serve davvero per le esigenze aziendali, mentre tutto il resto deve essere eliminato.
Dopo l'introduzione, il libro presenta un capitolo su come ridurre l'estensione della distribuzione di SQL Server 2005 utilizzando lo strumento Configurazione superficie di attacco. Vengono fornite informazioni utili, quali le descrizioni dei servizi predefiniti con le corrispondenti opzioni di avvio predefinite (Manuale, Automatico o Disattivato) quando si installa SQL Server 2005. Nel capitolo successivo, vengono illustrati i ruoli di SQL Server e come consentono di semplificare considerevolmente le attività amministrative. Ad esempio, viene descritto come collegare un ruolo a un gruppo Windows®. Pertanto, se si aggiunge un nuovo utente al gruppo, riceverà automaticamente il diritto di accesso alle risorse disponibili per il ruolo in questione.
Il capitolo sull'autenticazione e l'accesso granulare descrive gli accessi di Windows e SQL Server, con i vantaggi e gli svantaggi correlati. Illustra inoltre le procedure consigliate Microsoft relative all'autenticazione. A questo punto, il libro inizia a trattare l'autorizzazione, illustrando le opzioni disponibili per ottimizzare le operazioni che gli utenti potranno eseguire sull'istanza (ovvero, le autorizzazioni per le entità a protezione diretta). Vengono descritti elementi quali la connessione amministrativa dedicata (DAC), che fornisce una connessione locale esclusiva per l'amministratore con la quale è possibile connettersi a un'istanza quando una query o un processo consuma tutte le risorse, provocando l'impossibilità di rispondere per il server. Questa è una funzione estremamente utile che non era disponibile prima di SQL Server 2005.
In SQL Server 2005, gli schemi e gli utenti vengono separati in entità distinte. Nel libro esiste anche un capitolo sulla definizione, l'aggiornamento e l'eliminazione degli schemi attraverso T-SQL e SQL Server Management Studio. In questa sezione, verranno forniti anche alcuni suggerimenti preziosi, ad esempio come imparare a non utilizzare la stored procedure sp_adduser per creare nuovi utenti in SQL Server 2005 se non si desidera creare anche un nuovo schema. Viene suggerito di utilizzare l'istruzione CREATE USER T-SQL per creare l'utente, ma niente di più.
Le password sono, naturalmente, un altro elemento importate per proteggere la propria installazione e nel capitolo successivo vengono trattati nel dettaglio i criteri password per ottenere un livello uniforme di sicurezza per gli account. L'autore esplora diversi scenari di implementazione per consentire di scegliere il criterio migliore e più adatto all'ambiente in uso. Quindi si passa ad analizzare i trigger DDL (Data Definition Language), per scoprire come consentono di proteggersi da modifiche strutturali involontarie e come forniscono audit trail per le modifiche agli accessi del server.
Nel capitolo successivo, vengono scoperti i numerosi modi in cui SQL Server 2005 consente di crittografare i dati e gli schemi per proteggere le informazioni sensibili. Infine, il libro fornisce una panoramica di SQL Reporting Services, SQL Analysis Services e SQL Server Integration Services (SSIS), incluse le linee guida consigliate per la sicurezza. Anche le due appendici si rivelano preziose e forniscono informazioni su come proteggere e implementare Criteri di gruppo e Active Directory relativamente a SQL Server 2005.
In ogni parte del libro sono presenti due componenti strutturali particolarmente utili. Il primo luogo, ogni capitolo include una sezione "Solutions Fast Track", che offre un elenco di funzioni, fatti e procedure consigliate per gli elementi descritti nel capitolo. Il secondo componente è una sezione "Frequently Asked Questions", che fornisce risposte veloci alle domande relative all'amministrazione dell'istanza di SQL Server 2005. Se si è alla ricerca di un modo veloce per semplificare l'amministrazione di SQL Server 2005 da un punto di vista della sicurezza, l'acquisto del libro How to Cheat at Securing SQL Server 2005 potrebbe rivelarsi un'ottima idea.
Prezzo: 19,98 dollari per l'e-book, 49,95 dollari per il libro cartaceo

Acquisizione di schermi avanzata
ScreenHunter 5 Pro
wisdom-soft.com/products/screenhunter_pro.htm
Le acquisizioni degli schermi rappresentano un metodo efficace per documentare istruzioni dettagliate per gli utenti, illustrare i messaggi di errore che si verificano nelle applicazioni o creare una presentazione veloce delle funzioni. Ovviamente, Windows dispone della propria funzionalità di acquisizione degli schermi incorporata (PrtScr per acquisire tutti gli schermi, Alt-PrtScr per acquisire solo la finestra attiva). Tuttavia, le funzionalità incorporate nel sistema operativo sono limitate. Per ottenere un controllo più granulare su ciò che viene acquisito e su quando avviene l'acquisizione oppure per acquisire uno schermo da una riproduzione video, sarà necessario estrarre una delle numerose utilità di acquisizione degli schermi di terze parti. Uno di questi strumenti è ScreenHunter Pro di Wisdom Software. Si tratta di un'utilità dal costo contenuto che dispone di una serie di funzioni utili che consentono di personalizzare le acquisizioni degli schermi in base alle proprie esigenze.
L'interfaccia utente è estremamente semplice. È possibile scegliere l'origine dell'acquisizione e quindi indirizzarla verso la destinazione prescelta utilizzando le apposite schede From e To. Relativamente a ciò che è possibile acquisire, l'applicazione consente di catturare un'area rettangolare modificabile o fissa, uno specifico oggetto o finestra, la finestra attiva, una specifica parte della finestra attiva, l'intero schermo, un'origine di screensaver o DirectX®, una riproduzione video o una forma più complessa (un'area di forma libera, ellittica o poligonale definita). È inoltre possibile acquisire contemporaneamente più oggetti finestra o finestre di messaggio (ideale per acquisire solo l'applicazione attiva con la relativa finestra di dialogo o altre interfacce a finestre). È quindi possibile inserire le immagini acquisite negli Appunti, in un editor o visualizzatore specificato, in un file o inviarle a una stampante. È anche possibile decidere di inviarle a un indirizzo di posta elettronica.
Le immagini acquisite possono essere salvate come file di formato BMP, PNG, JPEG o TIFF di diversa qualità visiva. Inoltre, è possibile specificare che le immagini acquisite vengano ridimensionate automaticamente in base a dimensioni specifiche, nonché aggiungere un bordo o una filigrana, riducendo la quantità di operazioni da eseguire successivamente sulle immagini. È anche possibile impostare l'applicazione affinché esegua acquisizioni automatiche degli schermi in base a uno specifico intervallo, registrando le attività sul computer.
Un'altra preziosa funzionalità supportata da ScreenHunter Pro è quella di scorrimento automatico, che consente di acquisire, ad esempio, una lunga pagina Web con una regione visualizzabile che si estende oltre l'area visualizzabile sullo schermo. Al pari di molti altri professionisti IT, anche io ho a che fare con più monitor e, quindi, il supporto dell'acquisizione di più monitor si rivela estremamente utile per acquisire tutte le informazioni con una singola operazione.
Questa utilità include anche un editor di immagini incorporato, che consente di personalizzare le immagini con lo stesso contesto applicativo. Se non si ha bisogno di alcune delle funzionalità più avanzate (ad esempio, l'invio automatico tramite messaggio di posta elettronica, l'acquisizione programmata, le filigrane e le acquisizioni di più monitor), si potrebbe essere interessati a ScreenHunter Plus, una versione dal costo più contenuto. È disponibile anche una versione ridotta gratuita.
Prezzo: 29,95 dollari per ScreenHunter Pro
ScreenHunter Pro consente di specificare quando e cosa acquisire
ScreenHunter Pro consente di specificare quando e cosa acquisire

Greg Stee


 Exchange Queue &amp; A: Exchange 2007 SP1 Deployment
Exchange Queue & A
Exchange 2007 SP1 Deployment
Nino Bilic

D Mi domando se Exchange Server 2007 SP1 è disponibile soltanto nella versione a 64 bit. Se fosse disponibile in una versione a 32 bit, tale versione è supportata per un ambiente di produzione?
R Al riguardo, non vi è alcuna differenza tra l'originale (RTM) e le versioni SP1 di Exchange 2007. SP1 è disponibile in entrambe le versioni: a 32 e a 64 bit. Tuttavia, è importante tenere presente che, come avviene con la versione RTM, soltanto la versione a 64 bit è supportata per ruoli server installati in un ambiente di produzione. È tuttavia possibile utilizzare la versione SP1 a 32 bit per eseguire varie opzioni di installazione /prepare e per gestire i propri server a 64 bit proprio come avverrebbe con RTM.

D È necessario completare prima l'installazione completa della versione RTM Exchange 2007 e poi applicare SP1 per ottenere il server SP1?
R Questa è una caratteristica di Exchange 2007 SP1, nettamente differente rispetto ai service pack per le precedenti versioni di Exchange. Quando si ottengono i bit SP1, essenzialmente si ricevono i bit RTM con SP1 integrato al loro interno, il che significa che non occorre utilizzare il DVD di RTM per nuove installazioni di Exchange 2007 SP1.
Quindi, per installare nuovi server Exchange 2007 SP1, è sufficiente disporre dei bit del SP1. Anche se, ad esempio, si unisce il primo Exchange 2007 nell'organizzazione Exchange Server 2003, sarà possibile usufruire immediatamente del SP1.
D Il mio server dispone di Exchange 2007 RTM in esecuzione su Windows Server® 2003 e vorrei installare Exchange 2007 SP1 sul computer. Dal momento che Microsoft sostiene che Exchange 2007 SP1 è supportato su Windows Server 2008, intendo eseguire un aggiornamento sul posto a Windows Server 2008 in un secondo momento. Gradirei un parere.
R Purtroppo, non è una buona idea. L'aggiornamento del server sul posto da Windows Server 2003 a Windows Server 2008 con Exchange 2007 RTM o SP1 installato non è supportato. Esistono diversi motivi tecnici in tal senso, primo fra tutti il fatto che l'installazione Exchange verrebbe interrotta se si esegue un aggiornamento sul posto.
Per ulteriori informazioni, si rimanda all'articolo "Mission Impossible: In-Place Upgrading Microsoft® Exchange Server 2007 from Windows Server 2003 to Windows Server 2008" disponibile all'indirizzo msexchangeteam.com/archive/2007/10/04/447188.aspx.

D Non ho mai immesso gli ID prodotto per alcuni dei miei server di laboratorio. Di conseguenza, quando avvio Exchange Management Console, ricevo un messaggio di avvertenza che indica il periodo di prova è scaduto ("0 days"). È possibile eseguire un aggiornamento ad Exchange 2007 SP1 senza immettere codici "Product Key" per tali server?
R: Sì. L'installazione di Exchange 2007 SP1 (vedere la schermata) non può verificare la durata del periodo di prova di un server già installato. Per questo scenario, non è previsto un blocco dell'aggiornamento.

D Ho già installato Exchange 2007 SP1 sul mio server di posta. Adesso vorrei aggiungere il ruolo Accesso client a tale server. Devo utilizzare il mio Exchange 2007 RTM o il nuovo Exchange 2007 SP1?
R Per installare ulteriori ruoli server dopo avere già applicato Exchange 2007 SP1, è necessario utilizzare Exchange 2007 SP1. Come indicato in precedenza, Exchange 2007 SP1 è un prodotto completo contenente tutti i file richiesti per eseguire Exchange 2007 e, una volta installato il SP1, Exchange 2007 RTM non è più necessario.
Ovviamente, se si dispone di più ruoli server sul server da aggiornare ad Exchange 2007 SP1, l'applicazione del SP1 aggiornerà automaticamente tali ruoli installati. Non è possibile applicare il SP1 soltanto ad alcuni dei ruoli sullo stesso server fisico.

D La mia organizzazione Exchange dispone di più server Exchange 2007 e i ruoli server sono distribuiti tra vari di tali server. Quali ruoli server è consigliabile aggiornare per primi?
R Prima di tutto, è consigliabile scaricare e leggere le Note sulla versione per Exchange 2007 SP1 (go.microsoft.com/fwlink/?LinkId=112364), poiché contengono informazioni importanti sull'applicazione del SP1 ad un'installazione esistente.
Per rispondere direttamente alla tua domanda, di seguito viene riportato un frammento delle suddette Note che riguardano proprio l'argomento in questione. Di seguito viene fornita una traduzione di tali note:

"Consigliamo di aggiornare i server in esecuzione con il ruolo Server di posta dopo avere aggiornato i server con ruoli Accesso client, Messaggistica unificata, Trasporto Hub o Trasporto Edge. Se si rispetta tale ordine di aggiornamento, è possibile evitare potenziali interruzioni del servizio. Tale ordine garantisce inoltre che i server che guidano la funzionalità per le cassette postali possano comunicare con il server di posta senza interruzioni, anziché incorrere in problemi nel tentativo di comunicare con un server backend con maggiori funzioni. Consigliamo inoltre di aggiornare i server di Accesso client presenti nei siti accessibili da Internet prima di aggiornare i server di Accesso client non accessibili da Internet.
Se si esegue il ruolo Trasporto Edge nella propria organizzazione Exchange ed è stata creata una Sottoscrizione Edge, tutti i server di trasporto che partecipano al processo EdgeSync dovranno eseguire la stessa versione di Exchange 2007. È necessario aggiornare tutti i server Trasporto Edge registrati e tutti i server trasporto Hub nel sito Active Directory® a cui sono registrati i server Trasporto Edge ed è necessario eseguire tale operazione entro 15 giorni dal primo aggiornamento ad Exchange 2007 SP1 di qualsiasi server di trasporto che partecipi al processo di Sottoscrizione Edge".

D Ho installato ForefrontTM Security per Exchange Server sul mio Exchange Server 2007 RTM. Devo eseguire operazioni particolari prima di aggiornare ad Exchange 2007 SP1?
A La versione RTM di Forefront Security per Exchange Server è incompatibile con Exchange 2007 SP1. È necessario rimuovere Forefront Security per Exchange Server o aggiornarlo ad una versione successiva prima di poter eseguire il suddetto aggiornamento. Le Note sulla versione del SP1 forniscono maggiori dettagli in proposito.
E, in ogni caso, l'installazione di Exchange 2007 SP1 dispone di un nuovo controllo prerequisito che avvertirà l'utente nel caso in cui si trovi in questa situazione e tenti l'aggiornamento.

D Dispongo di Exchange 2007 RTM su cui è installato l'aggiornamento cumulativo successivo ad RTM. Devo rimuovere tale aggiornamento prima di applicare Exchange 2007 SP1?
R Non è necessario rimuovere gli aggiornamenti cumulativi prima di installare Exchange 2007 SP1. L'installazione di Exchange 2007 SP1 eliminerà automaticamente gli aggiornamenti da rimuovere prima di applicare il SP1 al computer. 

Nino Bilic è Supportability Program Manager per Exchange Server. Sta accumulando un patrimonio esplorando la galassia e colonizzando i pianeti nel videogioco Mass Effect.


 Utility Spotlight: Strumento SharePoint Capacity Planning
Utility Spotlight
Strumento SharePoint Capacity Planning
Peter Skjøtt Larsen and Satish Mathew

La pianificazione di un grande installazione di Microsoft® Windows® Sharepoint® Services (WSS) e Microsoft Office SharePoint Server (MOSS) può essere un'impresa alquanto complessa. Sono numerosissimi i fattori che contribuiscono a determinare i requisiti di larghezza di banda, hardware e topologia più economicamente vantaggiosi. Inoltre, occorre prendere in configurazione anche tutta una serie di opzioni di configurazione, a seconda del sistema che verrà utilizzato. Spesso gli amministratori e i responsabili della pianificazione non possono fornire molto aiuto per il ridimensionamento di un sistema.
Fortunatamente, Microsoft ha rilasciato la seconda generazione di Microsoft System Center Capacity Planner (SCCP) 2007, uno strumento generico che combina un modello di diverse applicazioni con un simulatore in grado di prevedere il loro funzionamento in una particolare distribuzione. Questa versione introduce il nuovo strumento SharePoint Capacity Planning, che consente di aggiungere a questo motore due ulteriori modelli per WSS 3.0 e MOSS 2007.
Lo strumento SharePoint Capacity Planning Tool e SCCP 2007 sono disponibili gratuitamente dall'Area download Microsoft all'indirizzo microsoft.com/systemcenter/sccp/default.mspx.
Lo strumento SharePoint Capacity Planning raccoglie i requisiti dell'organizzazione compilando le risposte fornite a domande sulle condizioni operative e di utilizzo previste. Per generare un progetto preliminare, una procedura guidata richiede di specificare informazioni rilevanti sulla struttura e sulle esigenze di SharePoint previste, inclusi il numero e il tipo di utenti (autenticati o anonimi), i parametri di rete, la configurazione hardware, i modelli di utilizzo (pubblicazione o collaborazione) e i requisiti di archiviazione, indicizzazione e query.
Risultati di una simulazione nello strumento SharePoint Capacity Planning
Risultati di una simulazione nello strumento SharePoint Capacity Planning
Lo strumento quindi crea una topologia di base utilizzando nomi specifici per l'installazione in uso. Vengono eseguite simulazioni di carico e utilizzo per la topologia suggerita per scoprire come l'installazione proposta potrebbe funzionare in diverse condizioni.
La topologia iniziale può essere modificata con un editor modello ed è possibile eseguire scenari per simulare l'impatto dell'aumento dell'utilizzo, dell'espansione delle succursali aziendali, di hardware aggiuntivo e di una larghezza di banda potenziata. Come è mostrato nella schermata, la simulazione genera carichi dei server previsti e report dell'esperienza utente che consentono di ottimizzare la configurazione in base a parametri quali il costo, le prestazioni e l'hardware disponibile. È possibile esportare un report dettagliato o riepilogativo in un foglio di calcolo di Excel® e il diagramma della topologia in un file Visio®.
Lo strumento SharePoint Capacity Planning semplifica la distribuzione vergine consentendo di provare una serie di circostanze per approdare a una configurazione iniziale appropriata. Dato che è possibile anche modellare una topologia esistente e fare prove con diversi scenari di simulazione, lo strumento si rivela utile anche per esaminare le potenziali modifiche alle distribuzioni esistenti.

Peter Skjøtt Larsen è un Senior Product Manager del team di Microsoft Solution Accelerator. Lavora in Microsoft da quattro anni ed è impegnato nei campi della migrazione UNIX, delle comunicazioni e della collaborazione.
Satish Mathew è un Program Manager del team di Microsoft Solution Accelerator. Lavora in Microsoft da quasi cinque anni e ha dato il suo contributo nel team di Windows PowerShell prima di approdare al team attuale.


 Inside SharePoint: Come costruire un'infrastruttura SharePoint
Inside SharePoint
Come costruire un'infrastruttura SharePoint
Pav Cherny
Scarica il codice per questo articolo: SharePoint2008_05.exe (412KB)

Proprio come i messaggi di posta elettronica hanno trasformato le comunicazioni aziendali, la collaborazione basata sul Web sta cambiando il modo in cui le persone lavorano insieme e condividono le informazioni. Per avere un esempio, basta dare un'occhiata a cosa offre la tecnologia SharePoint. Con Microsoft Windows SharePoint Services (WSS) 3.0 e Microsoft Office SharePoint Server
(MOSS) 2007, è possibile creare siti dedicati a team di lavoro, portali, soluzioni di gestione di contenuti Web, librerie di documenti e centri di ricerca, senza contare l'integrazione del sistema Microsoft® Office 2007, i moduli XML, i flussi di lavoro, il supporto per la mobilità e così via.
Ciononostante, non è sempre semplice iniziare a utilizzare SharePoint®. La terminologia può confondere. L'architettura di sistema può essere complessa e con SharePoint è necessario avere a che fare con più componenti, tra cui IIS, Miscrosoft .NET Framework, SQL Server® e anche altre tecnologie, come Business Intelligence, Infopath® Forms Services, Rights Management Services (RMS), Exchange Server e ForefrontTM Security.
Tra le integrazioni e le personalizzazioni è facile perdersi, considerati i numerosi approcci da scegliere per creare le soluzioni SharePoint, sia attraverso l'interfaccia utente incorporata che in modo programmatico. Senza contare che, quando un'applicazione di SharePoint non funziona, la risoluzione dei problemi può essere complicata. A volte, per capire quali sono i componenti coinvolti e come interagiscono, è necessaria la mentalità di uno sviluppatore di applicazioni Con tutti questi problemi, da dove bisogna cominciare per costruire un'infrastruttura SharePoint robusta, scalabile e gestibile?
In questa rubrica, vi mostrerò come iniziare, creando prima le basi con una discussione sull'architettura in generale, quindi passando ad approfondire la distribuzione di WSS, con alcune personalizzazioni molto semplici. Utilizzando la funzionalità Gestione siti in modalità self-service di WSS 3.0, sarà possibile vedere come delegare ai singoli utenti le autorizzazioni per creare e gestire i siti di SharePoint mantenendo il controllo amministrativo centralizzato sull'infrastruttura SharePoint.
Esaminando, come prima cosa, l'architettura di SharePoint, è facile capire meglio i passaggi di distribuzione e configurazione necessari per implementare un'infrastruttura flessibile e scalabile. Osserviamo, quindi, le dipendenze e passiamo direttamente alla distribuzione di WSS 3.0. Per le istruzioni di distribuzione dettagliate, vedere il materiale di riferimento che accompagna il prodotto. È possibile trovare questo materiale nella sezione dei download del sito Web di TechNet Magazine, all'indirizzo technetmagazine com.

Architettura di SharePoint
Nel caso di SharePoint, è utile pensare alla tecnologia dal punto di vista di un architetto di sistema. Non è necessario conoscere i dettagli di fondo, ma se si ha una certa familiarità con le dipendenze generali che derivano dall'architettura di SharePoint, è possibile arrivare più velocemente alle soluzioni, poiché si può prevedere cosa è necessario configurare e perché.
SharePoint è una tecnologia per il provisioning di siti e applicazioni Web. Si tratta di una soluzione per siti Web basata su IIS, che si integra con IIS tramite ASP.NET e utilizza il back-end di un database SQL Server per archiviare dati di configurazione e contenuti. In breve, SharePoint combina al suo interno tre architetture diverse (IIS, .NET e SQL Server), come mostrato nella figura 1.
Figura 1 Architettura WSS 3.0 basata su IIS 6.0 e ASP.NET 3.0
Figura 1 Architettura WSS 3.0 basata su IIS 6.0 e ASP.NET 3.0
Non fatevi intimorire dal diagramma. Solo per il numero dei componenti, l'architettura potrebbe sembrare troppo imponente a un primo sguardo. Ma tutti questi i componenti sono inseriti in un framework logico che, se osservato in modo sistematico, permette di capire nel dettaglio le dipendenze tra i componenti.
Come illustrato, SharePoint si basa su IIS e ASP.NET per gestire le richieste e le risposte HTTP. I componenti IIS standard, come il driver HTTP in modalità kernel (http.sys) e il processo di lavoro (w3wp.exe), effettuano l'accodamento e il routing iniziali delle richieste fin quando queste non arrivano al filtro ISAPI di ASP.NET (aspnet_isapi.dll). Quando si installa .NET Framework, la routine di installazione registra aspnet_isapi.dll nella metabase IIS (C:\Windows\System32\Inetsrv\metabase.xml), come illustrato di seguito:
InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
Una volta che IIS ha caricato il filtro ISAPI di ASP.NET, tutte le richieste in arrivo per un sito Web possono essere passate ad ASP.NET, che è importante perché SharePoint, alla fine, deve ricevere queste richieste attraverso ASP.NET. A questo scopo, SharePoint estende la configurazione del sito Web scelto aggiungendo una mappa delle applicazioni con caratteri jolly che instrada tutte le richieste in arrivo, indipendentemente dall'estensione del nome file, al filtro ISAPI di ASP.NET.
È possibile verificare questo comportamento in Gestione IIS dopo avere installato WSS 3.0 utilizzando l'opzione di installazione di base. La routine di installazione di WSS disattiva il sito Web IIS predefinito sul server e crea un nuovo sito Web predefinito sulla porta 80, con la mappa delle applicazioni ASP.NET con caratteri jolly definita, come mostrato nella figura 2.
Figura 2 Mappa delle applicazioni con caratteri jolly per il filtro ISAPI di ASP.NET
Figura 2 Mappa delle applicazioni con caratteri jolly per il filtro ISAPI di ASP.NET
Affinché ASP.NET sia in grado di passare a sua volta le richieste a SharePoint, è necessario che SharePoint estenda anche la base delle pipeline delle richieste HTTP tramite un oggetto HttpApplication personalizzato, che viene implementato per mezzo di una classe chiamata SPHttpApplication nell'assembly Microsoft.SharePoint. SharePoint definisce quest'oggetto applicazione personalizzata nel file applicazione di ASP.NET (global.asax), che si trova nel file system nella cartella principale dei siti Web estesi di SharePoint. Il codice che segue elenca il contenuto di questo file global.asax:
<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>
ASP.NET analizza e compila dinamicamente questo file per creare un'istanza dell'oggetto applicazione di SharePoint.
Per ogni richiesta ricevuta, ASP.NET attiva una serie di eventi che l'applicazione Web può elaborare, come BeginRequest, AuthenticateRequest, ProcessRequest ed EndRequest. I dettagli della gestione eventi non rientrano nella distribuzione e nella gestione di SharePoint, ma è importante sapere che, oltre a SPHttpApplication specificato in global.asax, SharePoint implementa dei gestori e dei moduli HTTP personalizzati definiti nel file web.config per il sito. Ad esempio, SharePoint utilizza un modulo HTTP basato sulla classe SPRequestModule, registrata come primo modulo HTTP prima dei moduli standard di ASP.NET. SPRequestModule inizializza l'ambiente runtime di SharePoint, ad esempio registrando un componente SPVirtualPathProvider in ASP.NET. SPRequestModule è per uso interno di SharePoint, ma gli sviluppatori di soluzioni SharePoint possono modificare il file web.config per registrare componenti aggiuntivi, come i gestori e i moduli HTTP personalizzati. Attraverso i moduli HTTP personalizzati e standard, SharePoint utilizza ASP.NET mentre mantiene uno stretto controllo su tutte le richieste alle applicazioni di SharePoint.
Notare che quando si crea un'applicazione Web utilizzando il sito Amministrazione centrale SharePoint 3.0, WSS aggiunge la mappa di applicazioni con caratteri jolly per il sito Web IIS selezionato e crea i file global.asax e web.config nella cartella principale del sito Web. Ogni applicazione Web utilizza il suo insieme di file global.asax e web.config.
Per elaborare le richieste e restituire informazioni significative ai browser, WSS 3.0 e MOSS 2007 si avvalgono del parser di pagine ASP.NET standard, che compila le pagine ASP.NET richieste o le elabora senza modalità di compilazione. Ma le pagine di ASP.NET che SharePoint passa al parser ASP.NET non sono necessariamente localizzate dove sembrano essere. Ad esempio, non sarà possibile trovare un file default.aspx nella cartella principale di un sito Web esteso di SharePoint, come il sito Amministrazione centrale SharePoint 3.0, ma viene comunque aperto il file default.aspx quando si visualizza la home page di questo sito Web. È il componente di SPVirtualPathProvider che virtualizza l'ambiente caricando il contenuto della pagina dal file system locale o da un database del contenuto SQL Server e passandolo come file virtuale al parser di pagine ASP.NET. Per il sito Amministrazione Centrale, SharePoint carica il file di default.aspx dalla cartella C:\Programmi\File comuni\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin.
La home page, come pure la maggior parte delle pagine del sito SharePoint, è collegata a una pagina master di ASP.NET (default.master) che implementa un layout comune per controlli di navigazione e menu. Il file default.master risiede nella cartella C:\Programmi\File comuni\Microsoft Shared\Web Server Extensions\12\Template\Global e contiene dei segnaposti denominati per ulteriori pagine contenuto che possono anche risiedere sul file system locale o in un database del contenuto SQL Server. Il punto principale è che quando si apre un sito di SharePoint in un browser Web, di fatto si visualizzano le informazioni da una raccolta di pagine contenuto che non sono necessariamente ubicate sul server Web locale e sono disposte secondo un layout definito in una pagina master.
La regola generale è che le pagine non modificate (o non personalizzate, secondo la terminologia SharePoint) esistono come modelli di pagina sul file system locale di ogni server SharePoint, e le pagine personalizzate vengono scritte nel database del contenuto in modo che tutti i server SharePoint di una Web farm abbiano accesso allo stesso insieme di pagine (vedere la figura 3). Si presuppone che le pagine non personalizzate siano identiche su tutti i server e i siti della Web farm. Tuttavia, se si personalizza una pagina contenuto o una pagina master in un sito SharePoint, magari utilizzando Office SharePoint Designer 2007, SharePoint archivia automaticamente la pagina personalizzata nel database del contenuto.
Figura 3 Pagine ASP.NET personalizzate e non personalizzate in un'applicazione di SharePoint
Figura 3 Pagine ASP.NET personalizzate e non personalizzate in un'applicazione di SharePoint
Oltre alle pagine personalizzate e ad altro contenuto del sito Web, SharePoint archivia anche i dati di configurazione in un database SQL Server. SharePoint tiene separati i dati di configurazione dal contenuto perché i dati di configurazione sono di natura globale mentre il contenuto è specifico di ogni singola applicazione Web e raccolta siti. In conseguenza, una Web farm può avere soltanto un database di configurazione ma può avere più database del contenuto.
Tutti i server WSS della Web farm utilizzano lo stesso database di configurazione per condividere i metadati, le impostazioni di configurazione e le informazioni su ogni sito Web IIS solo che è stato esteso con SharePoint nella Web farm. Le singole applicazioni Web, d'altra parte, possono essere associate a uno o più database del contenuto (sebbene ogni database del contenuto possa solo essere associato a un'applicazione Web).
La relazione tra i siti Web IIS, le applicazioni Web, le raccolte siti, i siti e i database del contenuto possono confondere. Nella terminologia di SharePoint, per applicazione Web si intende un sito Web IIS esteso di SharePoint. Un'applicazione Web può contenere varie raccolte siti e ogni raccolta siti può includere un sito di livello superiore e altri siti di livello inferiore che condividono le stesse impostazioni di configurazione.
Fra le altre cose, la creazione di più raccolte siti permette di delegare l'amministrazione delle raccolte siti a diversi utenti e gruppi. Una singola raccolta siti non può essere suddivisa in più database del contenuto, ma un'applicazione Web può utilizzare più database del contenuto per più raccolte siti per aumentare la scalabilità e attenuare l'impatto sulle prestazioni di un grande sito che genera una quantità significativa di attività di database su altri siti SharePoint. Tuttavia, non è una buona idea collocare ogni sito SharePoint nella sua raccolta siti perché questa forma di distribuzione limita la funzionalità di interazione tra i vari siti.
WSS 3.0 non supporta ricerche di contenuto in più raccolte siti. Per queste ricerche è necessario MOSS 2007 o Microsoft Search Server 2008. Ad esempio, è possibile creare un'applicazione Web e un sito di livello superiore per http://contoso, mentre un amministratore di raccolte siti può creare i siti di livello inferiore utilizzando l'interfaccia utente di SharePoint, ad esempio http //contoso/info e http://contoso/events. Tutti i siti si trovano nello stesso database del contenuto perché appartengono alla stessa raccolta siti.
L'amministratore della farm può anche utilizzare un percorso gestito, ad esempio /sites, e definire poi le raccolte siti aggiuntive, come http://contoso/sites/IT e http://contoso/sites/HR, in Amministrazione centrale SharePoint 3.0. Queste raccolte siti (http://contoso, http://contoso/sites/IT, e http://contoso/sites/HR) possono avere amministratori di raccolta siti, impostazioni di configurazione e database del contenuto diversi, ma in ogni caso l'accesso a tutte e tre avviene attraverso lo stesso sito Web IIS (http://contoso) e tutte utilizzano la stessa identità di pool di applicazioni dell'applicazione Web.
Dettagli a parte, questa relazione fra IIS, ASP.NET ed SQL Server è molto importante da capire se si desidera avere un rapporto soddisfacente con SharePoint. Se siete interessati a saperne di più sull'architettura di SharePoint, consiglio l'articolo di Ted Pattison pubblicato su MSDN® Magazine, dal titolo "Discover Significant Developer Improvements in SharePoint Services," disponibile all'indirizzo msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview.

Elementi dell'infrastruttura SharePoint
A questo punto, convertiamo la nostra breve discussione sull'architettura in un'infrastruttura SharePoint flessibile. Come avrete certamente notato, sono necessari Windows Server®, IIS, .NET Framework 3.0 (sia per ASP.NET che per Windows® Workflow Foundation), WSS 3.0 o MOSS 2007 e SQL Server. Anche se sarebbe possibile utilizzare IIS 7.0 su Windows Server 2008, utilizzeremo IIS 6.0 su Windows Server 2003 per i nostri scopi, perché al momento è questa la versione più diffusamente distribuita. Resteremo nell'ambito di WSS 3.0 perché non abbiamo bisogno di alcuna funzionalità specifica di MOSS 2007 per un progetto SharePoint pilota.
Per un approccio minimalista, è possibile installare WSS 3.0 con tutti i componenti richiesti su un computer solo (come delineato nel pdf su WSS 3.0 installato su un computer solo, disponibile come materiale di accompagnamento a questa rubrica), una buona soluzione sia per un server di laboratorio che per un piccolo ambiente per gruppo di lavoro. Tuttavia, se si intende concentrarsi sulla flessibilità dell'infrastruttura SharePoint, non si dovrebbe iniziare con una distribuzione autonoma in un ambiente di produzione. Per questioni di disponibilità e scalabilità future, è meglio iniziare con un'infrastruttura multilivello e aggiunge i server nel momento in cui servono.
Nella figura 4 è mostrata l'infrastruttura SharePoint consigliata se si desidera una configurazione di sistema più semplice e flessibile. Questa infrastruttura contiene una Web farm di due server SharePoint e un computer a parte che esegue SQL Server. Questa configurazione elimina l'overhead di elaborazione del database sui server Web, aumenta la disponibilità, la scalabilità e facilita la manutenzione di sistema. Notate che Active Directory® è necessario perché è un requisito software di WSS 3.0 in una distribuzione di Web farm. Per la procedura di distribuzione, è possibile consultare il pdf sull'infrastruttura SharePoint di base nel materiale di accompagnamento.
Figura 4 L'infrastruttura SharePoint di base che agevola la crescita futura
Figura 4 L'infrastruttura SharePoint di base che agevola la crescita futura
L'account di dominio utilizzato per distribuire SharePoint in questa configurazione richiede le autorizzazioni di amministratore locale sui server Web. È anche necessario aggiungere questo account ai ruoli dbcreator e securityadmin di SQL Server come pure al ruolo db_owner per il database master di SQL Server 2005, come illustrato nel pdf sull'infrastruttura SharePoint di base. A questo punto, è possibile utilizzare Configurazione guidata Prodotti e tecnologie SharePoint durante l'installazione di WSS 3.0 per creare il database di configurazione necessario per la Web server farm e un database del contenuto per il sito Amministrazione centrale SharePoint 3.0. In alternativa, è possibile ottenere questi database da un amministratore SQL Server e poi aggiungere gli account di sistema di SWW al ruolo db_owner.
È importante tenere a mente che l'account utente utilizzato per installare SharePoint non è l'account che SharePoint utilizza per accedere al database di configurazione o al database del contenuto del sito Amministrazione Centrale. SharePoint, infatti, utilizza l'account di sistema configurato come identità del pool di applicazioni per il sito Amministrazione centrale SharePoint 3.0.
La Configurazione guidata Prodotti e tecnologie SharePoint richiederà le informazioni sull'account. È buona norma utilizzare un account utente di dominio dedicato a questo scopo, ad esempio CONTOSO\WssConfigAdmin. Personalmente, come prassi generale, utilizzo singoli account utente dedicati per ogni applicazione Web che creo successivamente. Utilizzando un pool di applicazioni separato per ogni applicazione Web aiuta ad assicurare l'isolamento dei processi e utilizzando un account utente diverso per ogni pool di applicazioni aiuta a mantenere l'isolamento di protezione. Questo, però, è solo un approccio, e la facilità di gestione e il potenziale impatto sulle prestazioni che può avere deve essere valutato a fronte dei vari ambienti e requisiti aziendali.
Un altro account di sistema importante che un amministratore del dominio dovrebbe creare per voi è l'account del servizio di ricerca. È possibile utilizzare l'account di Amministrazione centrale ma, per avere una maggiore sicurezza, è meglio utilizzare un account di ricerca dedicato, ad esempio CONTOSO\WssSearch, che non dispone di autorizzazioni amministrative e non può modificare alcun contenuto. L'autorizzazione di scrittura nei database del contenuto non è necessaria perché il servizio di ricerca effettua ricerche nei contenuti solo a scopo di indicizzazione e conserva i dati della ricerca in un database a parte.
Quando si crea un'applicazione Web in una server farm, è possibile associare il database del contenuto a un server di ricerca, che aggiunge implicitamente l'account del servizio di ricerca corrispondente al criterio Lettura completa dell'applicazione Web. I server di ricerca sono server SharePoint che eseguono il servizio di ricerca di Windows SharePoint Services. Se è stata seguita la procedura riportata nel pdf sull'infrastruttura SharePoint di base, entrambi i server Web sono stati configurati come server di ricerca in modo che possa essere distribuito il carico di lavoro di ricerca e indicizzazione di più database del contenuto. Tuttavia, è anche possibile configurare un server di ricerca dedicato in una Web farm, escluso dal bilanciamento del carico di rete e dalle connessioni client, in modo che le connessioni di client non vengano interessate dalle attività di ricerca per indicizzazione.

Gestione dei siti self-service
Una volta preparata l'infrastruttura SharePoint di base, è possibile delegare l'amministrazione di raccolte siti e siti ai singoli reparti e utenti, senza decentralizzare il controllo amministrativo su Active Directory, la Web server farm o i database SQL Server. L'amministratore della farm collabora con gli amministratori di Active Directory e SQL Server per fornire gli account del pool di applicazioni e i database del contenuto per le applicazioni Web. In queste applicazioni Web è possibile creare raccolte siti e designare gli amministratori delle raccolte siti con il diritto di creare siti di livello inferiore. In questo modo, gli amministratori delle raccolte siti dei singoli reparti possono gestire le loro risorse SharePoint con il minimo coinvolgimento del reparto IT, come mostrato nella figura 5.
Figura 5 L'amministrazione decentralizzata dei siti in un'infrastruttura SharePoint centralizzata
Figura 5 L'amministrazione decentralizzata dei siti in un'infrastruttura SharePoint centralizzata
È anche possibile offrire agli utenti la capacità di creare raccolte siti sotto percorsi gestiti (ad esempio, il percorso /sites o altri percorsi gestiti con inclusioni di caratteri jolly creati in Amministrazione centrale SharePoint 3.0). Se si attiva la funzionalità Gestione siti in modalità self-service in un'applicazione Web, gli utenti possono creare le loro raccolte siti e gestire i gruppi di siti e le autorizzazioni nell'interfaccia utente di SharePoint. Diversamente dai siti di livello inferiore, le raccolte siti non ereditano autorizzazioni da un sito padre.
La Gestione siti in modalità self-service non è adatta a ogni ambiente SharePoint ed è disattivata per impostazione predefinita. Se la si attiva, si può causare la presenza di un numero molto elevato di raccolte siti raramente utilizzate nei database del contenuto. Tuttavia, questa funzionalità dimostra molto chiaramente la flessibilità di amministrazione di SharePoint, e io consiglio di provarla nella distribuzione pilota. (In SharePoint sono disponibili alcune opzioni per notificare a utenti e/o amministratori i siti inattivi che, così, possono essere rimossi). È necessario attivare la Gestione siti in modalità self-service per un'applicazione Web, come illustrato nel pdf sull'attivazione della gestione dei siti self-service, disponibile nel materiale di accompagnamento.

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

A questo punto, è naturale voler includere il logo, il nome e i colori aziendali nell'interfaccia utente di SharePoint. L'unica cosa da sapere a proposito è che si sta per portare il progetto SharePoint al livello di sviluppo ASP.NET. Come minimo, si ha bisogno di un sistema di sviluppo, ad esempio un server WSS autonomo con Microsoft Office 2007 SharePoint Designer (è possibile consultare il pdf sull'installazione di SharePoint Designer, disponibile nel materiale di accompagnamento) in modo da poter creare e testare le personalizzazioni senza interessare l'ambiente di produzione. Inoltre, è necessario visitare il Centro per sviluppatori di Windows SharePoint Services all'indirizzo msdn2.microsoft.com/SharePoint per saperne di più sulla ricchezza di opzioni di personalizzazione che SharePoint offre.
Anche se lo sviluppo SharePoint non rientra nell'ambito di questa rubrica, vorrei far notare alcuni aspetti da prendere in considerazione. SharePoint archivia le pagine personalizzate nel database del contenuto della raccolta siti corrispondente. In altre parole, qualunque personalizzazione applicata alle pagine del sito, alle pagine delle applicazioni, alle pagine master, ai fogli di stile, e così via, in un sito SharePoint viene applicata soltanto a livello di raccolta siti o sito. Questo è un vantaggio per gli amministratori delle singole raccolte siti che vogliono regolare l'aspetto dei loro siti con SharePoint Designer 2007, ma non per un amministratore di farm che vuole applicare l'identità aziendale in tutte le applicazioni Web, le raccolte siti e i siti di una Web farm.
È possibile creare temi sito personalizzati o definizioni sito personalizzate partendo dalla copia di un tema o una definizione sito standard di SharePoint. È anche possibile creare pagine master personalizzate e aggiungerle alla Raccolta pagine master. Tuttavia, nessuna di queste opzioni permette di imporre il branding globale se è attiva la Gestione siti in modalità self-service, poiché un utente con le autorizzazioni per creare raccolte siti o siti può selezionare un modello di sito standard che non riporta l'identità aziendale.
Il branding globale richiede di sostituire i componenti SharePoint predefiniti per utilizzare al loro posto i componenti personalizzati. Gli sviluppatori hanno fatto molti progressi per arrivare a effettuare questa attività senza modificare i file originali. Un approccio consiste nel modificare la configurazione delle directory virtuali in Gestione IIS e creare puntamenti tra queste e nuove cartelle con i file personalizzati. Un altro metodo consiste nell'implementare un filtro ISAPI o un modulo HTTP personalizzato che riscrive gli URL per reindirizzare le richieste di specifiche pagine predefinite alle versioni personalizzate.

Conclusioni
Ci siamo concentrati sui punti fondamentali per creare un'infrastruttura SharePoint con WSS 3.0. Non ho coperto altre funzionalità, quali flussi di lavoro, indagini, integrazione della messaggistica e antivirus, né funzionalità specifiche di MOSS 2007, quali portali, directory di siti e cataloghi dati business. Le personalizzazioni per l'amministrazione del sito e il branding aziendale hanno toccato solo in parte le possibilità offerte da SharePoint. È possibile effettuare ulteriori personalizzazioni con WSS 3.0 programmando delle applicazioni personalizzate in Visual Studio®.
L'infrastruttura è abbastanza robusta per gestire la crescita futura, nel caso vengano aggiunti altri server Web o server di database. Con il lancio pilota di alcune personalizzazioni, gli utenti possono creare singoli siti e acquisire familiarità con SharePoint. In questo modo, è possibile stabilire i componenti di base che gli utenti possono adottare, nonché l'hardware e il software, che sono abbastanza flessibili da consentire eventuali modifiche e servire come base per un vero e proprio lancio in produzione.

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


 Windows PowerShell: Automatizzare la gestione di Active Directory
Windows PowerShell
Automatizzare la gestione di Active Directory
Don Jones

Uno dei principali problemi della prima versione di Windows PowerShell è stato il tempo. Il team Windows PowerShell è stato messo sotto pressione per riuscire a completare il prodotto (contemporaneamente ha avuto luogo il lancio di Exchange Server 2007, dipendente da Windows PowerShell) e anche il team Active
Directory ha avuto molto da fare in quel periodo (tra le altre cose, era in lavorazione anche Windows Server® 2008). Ecco perché Windows PowerShell è stato rilasciato con un numero ridotto delle eccellenti capacità di gestione di Active Directory®.
Per essere chiari, Windows PowerShell® non è completamente privo di funzionalità Active Directory. Anzi, a dire il vero, il team Windows PowerShell ha fatto uno sforzo eroico per approntare un supporto decente per Active Directory Services Interface (ADSI), una tecnologia di scripting molto pratica, già nota agli utenti di VBSCRIPT.

Il metodo ADSI
Come funzionamento, ADSI è simile a Windows® Management Instrumentation (WMI). L'utente scrive una query utilizzando una sintassi speciale. La query viene trasmessa a un computer remoto (ad esempio, un controller di dominio) e poi eseguita. Il risultato della query è un oggetto o una raccolta di oggetti Active Directory (ad esempio, un utente o un gruppo), mentre viene generato un riferimento all'oggetto con cui è quindi possibile lavorare. È possibile modificare le proprietà dell'oggetto o eseguire dei metodi per salvare le modifiche, creare nuovi oggetti, cancellare oggetti, e così via. Ad esempio, per creare un utente, è possibile eseguire una query per richiedere l'unità organizzativa (OU) o il contenitore in cui inserire l'utente. L'oggetto restituito ha un metodo Create, che può essere utilizzato per creare l'utente.
A livello di base, l'uso di Windows PowerShell sembra semplice e chiaro. Ad esempio, questo comando può richiamare un utente e visualizzarne l'attributo Company:
$user = [ADSI]"LDAP://cn=Ringo,ou=Singers,dc=company,dc=pri"
$user.Get("Company")
È possibile eseguire il piping dell'utente a Get-Member per poterne vedere le proprietà e i metodi. Sfortunatamente, Windows PowerShell 1.0 non è particolarmente affidabile nell'implementazione di questi oggetti directory. Come mostrato nella figura 1, lo shell non enumera gli attributi directory dell'oggetto, né visualizza i metodi di quest'ultimo, ad esempio il metodo Get utilizzato in precedenza.
Figura 1 Il piping dell'utente a Get-Member per visualizzarne le proprietà
Figura 1 Il piping dell'utente a Get-Member per visualizzarne le proprietà
Questo supporto è leggermente migliorato nella CTP (Community Technology Preview) di Windows PowerShell 2.0, ma soltanto in una certa misura. La conclusione è che il componente Microsoft® .NET Framework sottostante non permette agli amministratori di vedere agevolmente quello che gli serve. Dopo tutto, il framework è stato originariamente progettato per gli sviluppatori. L'altro problema è che il team Windows PowerShell ha competenze specifiche e limitate, mentre, per ottenere un buon supporto Active Directory, è necessario contare su persone esperte di directory. In altre parole, sul team Active Directory. Ma, ne sono sicuro, ciò avverrà presto. Dopo tutto, Windows PowerShell è ancora giovane. Il problema è: cosa fare nel frattempo?
Come ricorderete, ho già illustrato l'uso delle tecnologie ADSI incluse in Windows PowerShell nel numero di giugno 2007 di questa rubrica (technetmagazine.com/issues/2007/06/PowerShell). A chi desidera avere altri dettagli sulla tecnica "nativa", suggerisco di rileggere questa rubrica. In questo numero, invece, voglio illustrare alcuni altri approcci.

Un ecosistema molto ricco
L'architetto di Windows PowerShell Jeffrey Snover cita spesso il ricco ecosistema che circonda Windows PowerShell. Con questo vuole dire semplicemente che il team ha fatto un ottimo lavoro assicurandosi che tutti, non solo i programmatori Microsoft, possano estendere le funzionalità di Windows PowerShell. Alcune importanti aziende hanno già intrapreso questo percorso creando cmdlet Windows PowerShell nativi che permettono di amministrare i loro prodotti dalla riga di comando: VMWare, IBM, Citrix e Foundry sono tra queste.
Uno dei miei esempi preferiti di questo ricco ecosistema è il software di Quest. L'azienda offre una serie di cmdlet gratuiti e non commerciali, appositamente progettati per la gestione di Active Directory. Questi cmdlet possono essere scaricati dal sito quest.com/powershell. Tra i programmi offerti, anche PowerGUI (powergui.org), una GUI gratuita e non commerciale per Windows PowerShell rivolta alle persone non ancora pronte ad affrontare l'esperienza della riga di comando. Con PowerGUI, è più facile imparare a utilizzare i cmdlet di gestione di Active Directory. E, una volta utilizzati questi cmdlet, non sarà più possibile farne a meno. I cmdlet aggiungono alla gestione di Active Directory praticità e potenza senza precedenti. Per saperne di più su PowerGUI, basta leggere il numero di gennaio 2008 della rubrica Toolbox, disponibile all'indirizzo technetmagazine.com/issues/2008/01/Toolbox.)

Il metodo Windows PowerShell
Tutto ciò che implica l'impiego dei cmdlet può essere di fatto definito il metodo Windows PowerShell. Questo metodo significa non avere più a che fare con script tradizionali o strani oggetti di programmazione. In pratica, tutto viene risolto con un'unica riga. Un'unica riga di comando che importa un file di CSV e utilizza le informazioni in esso contenute per creare dozzine o persino centinaia di nuovi utenti Active Directory:
Import-CSV 'C:\provision1.csv' |
ForEach-Object {New-QADUser -organizationalUnit 'company.pri/Singers' -name ($_.'First Name' + '.' + $_.'Last Name')
-samAccountName $_.'Logon name' -city $_.city -title $_.'Job title' -department $_.department}
Certo, il comando è piuttosto lungo, ma è anche sorprendentemente potente. Inizia con Import-CSV, un cmdlet di shell nativo che legge un file CSV e restituisce degli oggetti. Ogni riga del file CSV è un singolo oggetto, mentre le colonne sono le proprietà dell'oggetto. Nel mio file Provision1.csv, i nomi delle colonne sono descrizioni quali "Logon Name" e "First Name", nomi che non hanno una mappatura diretta agli attributi utente di Active Directory. È una prassi comune per i file di questo tipo utilizzare nomi di colonna di tipo familiare al posto di quelli specifici di Active Directory. Dopotutto, un file del genere potrebbe provenire da una persona che lavora nell'ufficio del personale dell'azienda, una persona che molto probabilmente non sa che Last Name è effettivamente un attributo sn di Active Directory.
Una volta che tutti i dati del file di CSV sono stati importati e convertiti in oggetti, tali oggetti vengono inseriti nel cmdlet ForEach-Object, che esegue un blocco di codice - quello tra le parentesi graffe della riga di comando - per ogni oggetto. In pratica, per ogni riga del file CSV, questo script verrà eseguito una volta. Nello script, la variabile speciale $_ è un riferimento all'oggetto corrente, ovvero alla riga corrente del file CSV.
Questo è evidente per ogni oggetto, nell'esecuzione del cmdlet New-QADUser. Si tratta di uno dei quasi dodici cmdlet del componente aggiuntivo Quest. Il nome QADUser richiede un ulteriore commento. La Q, come è facile immaginare, sta per Quest. Questa convenzione di denominazione è stata pensata per evitare conflitti con il cmdlet New-ADUser che verrà prodotto in futuro dal team Microsoft Active Directory. In questo modo, entrambi i cmdlet verranno caricati nello shell contemporaneamente, ma resteranno sempre facilmente distinguibili, sia per lo shell che per gli utenti.
Il resto della riga di comando consiste di parametri per il cmdlet New-QADUser. Si inizia con la specifica di organizationalUnit, che è l'unità in cui vanno creati tutti i nuovi utenti. Segue l'attributo del nome, impostato come contenuto della colonna First Name, il punto e il contenuto della colonna Last Name.
Qui vale la pena notare una cosa interessante: Il parametro city modificherà di fatto l'attributo I (o Locality-Name) in Active Directory. Il cmdlet può accettare anche un parametro denominato l, che fa la stessa cosa. Nella maggior parte dei casi, i parametri che fanno riferimento agli attributi di Active Directory possono utilizzare sia il nome dell'attributo che l'etichetta di testo dello strumento Utenti e computer di Active Directory.

L'altro metodo Windows PowerShell
Active Directory è un archivio gerarchico, e uno dei punti di forza di Windows PowerShell è la sua capacità di esporre ogni archivio gerarchico come un'unità disco, consentendo l'uso di gruppi di comandi molto conosciuti come Dir, Del, Ren, Copy, e così, per gestire una varietà di archivi. Sfortunatamente, Windows PowerShell 1.0 non viene fornito con un provider PSDrive per Active Directory, il che significa che lo shell non ha modo di esporre Active Directory come un'unità.
Fortunatamente, quel ricco ecosistema di cui abbiamo discusso prima torna in gioco con le estensioni della PowerShell Community. Stiamo parlando di un componente aggiuntivo gratuito e open-source disponibile sul sito codeplex.come/powershellcx. Una volta installate, queste estensioni vi permetteranno di indirizzare facilmente lo shell al vostro nome dominio per iniziare a gestire la directory come se si trattasse di un'unità:
CD COMPANY:
CD SINGERS
DIR
Questi comandi verranno modificati nel dominio COMPANY, nell'OU Singers, quindi visualizzeranno un elenco di oggetti, come illustrato nella figura 2. A questo punto, è possibile iniziare a utilizzare comandi quali Del per cancellare un utente, Md di creare una nuova OU, e così via. Ci sono alcune cose da dire sul provider PSDrive delle estensioni della community. Sostanzialmente, si tratta di cose che hanno a che fare con la funzionalità che ci si aspetterebbe di implementare, ma che non è disponibile per via della mappatura inesatta con Active Directory. Queste cose richiedono un'estrema attenzione: modificando la radice del dominio ed eseguendo del * -recurse, di fatto si elimina ogni oggetto del dominio, sempre che si sia autorizzati a eseguire questo comando. Per impostazione predefinita, non viene neanche richiesta conferma dell'operazione. Certo, la riga di comando è potente, ma questa potenza comporta una buona dose di rischio per chi non è particolarmente esperto e attento.
Figura 2 Uso delle estensioni della PowerShell Community per indirizzare lo shell e gestire la directory
Figura 2 Uso delle estensioni della PowerShell Community per indirizzare lo shell e gestire la directory

Come utilizzare PowerShell oggi
Gli studenti dei miei corsi chiedono sempre cosa possono fare con Windows PowerShell oggi. Dopotutto, non tutti i prodotti Microsoft sono stati riprogettati per potersi avvalere di Windows PowerShell e si potrebbe pensare che Windows PowerShell stia ancora aspettando che l'ambiente intorno si adegui.
Ma questo adeguamento è già in atto. Anche se Microsoft ha non ancora preparato Active Directory all'uso della gestione dalla riga di comando, altri si sono già cimentati in questa impresa e hanno ottenuto dei risultati abbastanza buoni. Windows PowerShell può essere utilizzato per eseguire molte attività amministrative, compresa l'automazione di alcune delle attività più onerose in termini di tempo e carico di lavoro, come la creazione di gruppi di nuovi utenti. Il trucco sta nel riuscire a scoprire alcune delle cose che la community sta facendo per rendere Windows PowerShell più utile nell'immediato. (A questo scopo, può essere utile visitare PowerShellCommunity.org, un sito co-sponsorizzato da Microsoft e che si avvale del mio contributo per l'amministrazione). Dotando Windows PowerShell degli strumenti giusti, potete iniziare lo scripting di alcune delle attività amministrative più onerose dal punto di vista del tempo e diventare amministratori più efficienti ed efficaci.

Don Jones è co-autore di Windows PowerShell: TFM, seconda edizione, autore di VBSCRIPT, WMI e ADSI Unleashed e direttore di PowerShellCommunity.org.


 Hey, Scripting Guy!: Utilizzo delle espressioni regolari
Hey, Scripting Guy!
Utilizzo delle espressioni regolari
Gli Scripting Guy di Microsoft
Scarica il codice per questo articolo: HeyScriptingGuy2008_05.exe (150KB)

Nel novembre del 2007, gli Scripting Guy hanno speso un giorno a Parigi mentre erano in viaggio per la conferenza Tech•Ed IT Forum che si sarebbe tenuta a Barcellona. Durante la nostra sosta di un giorno, abbiamo colto l'opportunità di visitare il Louvre, il museo d'arte di fama mondiale della città.
Come hanno trovato il Louvre gli Scripting Guy? La risposta è semplice: abbiamo camminato fino a Notre Dame e poi abbiamo svoltato a sinistra.
Oh, intendete dire che vi è piaciuto il museo? In linea di massima, sì. L'unico problema che abbiamo avuto è che nel Louvre, come in molti musei, vige la regola del "guardare ma non toccare". Tutti sanno che Monna Lisa avrebbe un aspetto migliore se avesse le sopracciglia, ma per qualche arcano motivo i gestori del Louvre si infuriano se qualcuno tenta di "ritoccare" un quadro.
Nota: in realtà, a noi Scripting Guy Monna Lisa è piaciuta molto. E questa è stata una piacevole sorpresa perché, dopo tutta la pubblicità a cui abbiamo assistito, temevamo che potesse essere soltanto un quadro come un altro. Ma non lo è stato. È molto bello! (Nonostante sarebbe meglio aggiungere le sopracciglia.) Sorprendentemente, tuttavia, entrambi siamo rimasti piuttosto delusi dall'altrettanto famosa Venere di Milo. Nessuno di noi ha trovato la scultura così spettacolare e lo Scripting Guy che sta scrivendo questo articolo è rimasto piuttosto perplesso dall'idea complessiva della Venere de Milo. Una statua di donna senza braccia? E come fa a spazzare il pavimento o a lavare i piatti!?!
Nota per le nostre lettrici donne (sperando che ce ne sia rimasta qualcuna): ovviamente la frase precedente non è stata formulata correttamente. In realtà volevamo dire questo: una statua di una donna senza braccia? Eppure è in grado di svolgere due volte il lavoro di qualunque uomo e di svolgerlo nel migliore dei modi!
Gli Scripting Guy si scusano per eventuali malintesi creati dalla nostra affermazione iniziale.
In ogni caso, dopo aver posato i loro occhi sui meravigliosi tesori del Louvre, i due Scripting Guy sono stati colpiti dallo stesso identico pensiero: dove sono i bagni? Durante la ricerca, lo Scripting Guy che scrive questo articolo è stato colpito da un altro pensiero: gli Scripting Guy sono ipocriti. Dopotutto, siamo seccati per il fatto che il Louvre non ci consentirà di ritoccare Monna Lisa. Eppure, anche noi abbiamo commesso un peccato simile. Nel numero del gennaio 2008 di TechNet Magazine, abbiamo scritto un articolo relativo all'utilizzo delle espressioni regolari in uno script. Tale script è un ottimo esempio della regola "guardare ma non toccare": abbiamo mostrato come utilizzare le espressioni regolari per identificare i problemi in un file di testo, ma non abbiamo spiegato come risolverli. Accidenti!
Nota: ma se gli Scripting Guy sono andati al Louvre nel novembre 2007, come è possibile che lo Scripting Guy che scrive questo articolo ha avuto un'illuminazione riguardante un articolo che è comparso in TechNet Magazine soltanto nel gennaio 2008? Wow! Si tratta di un indovinello, o no? Deve avere a che fare con le differenze di fuso orario tra Redmond e Parigi.
Fortunatamente, tuttavia, e a differenza dei gestori del Louvre, gli Scripting Guy sono disposti ad ammettere quando commettono un errore. Abbiamo sbagliato a mostrarvi soltanto come ricercare degli elementi tramite le espressioni regolari; avremmo dovuto spiegarvi come sostituire tali elementi utilizzando le espressioni regolari. In realtà, avremmo dovuto mostrarvi uno script come quello della Figura 1.
Figure 1 Ricerca e sostituzione (Close Figure 1)
      Set objRegEx = _
    CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.IgnoreCase = True
objRegEx.Pattern = "Mona Lisa"

strSearchString = _
    "The Mona Lisa is in the Louvre."
strNewString = _
    objRegEx.Replace(strSearchString, _
                     "La Gioconda")

Wscript.Echo strNewString
Ora, a dirvi il vero, questo è un uso piuttosto ordinario delle espressioni regolari: in questo caso, stiamo semplicemente sostituendo tutte le istanze del valore di stringa Mona Lisa con La Gioconda (traduzione italiana di "E ora dove sono finite quelle sopracciglia?"). Sinceramente, avremmo potuto eseguire questa sostituzione molto più facilmente utilizzando la funzione Replace di VBScript. Ma, non temete: utilizzeremo questo piccolo e semplice script per spiegare come eseguire le operazioni di ricerca e sostituzione utilizzando delle espressioni regolari e, in seguito, vi mostreremo alcune delle operazioni più elaborate che è possibile eseguire con queste espressioni.
Come si può vedere, lo script non è affatto elaborato. Iniziamo creando un'istanza dell'oggetto VBScript.RegExp, che ci consente di utilizzare le espressioni regolari in uno script VBScript. Dopo la creazione dell'oggetto, assegniamo dei valori a tre delle proprietà dell'oggetto:
Global Impostando questa proprietà su True, lo script ricercherà (e sostituirà) ogni istanza di Mona Lisa presente nel testo di destinazione. Se la proprietà Global fosse False (il valore predefinito), lo script ricercherebbe e sostituirebbe soltanto la prima istanza di Mona Lisa.
IgnoreCase Impostando IgnoreCase su True, lo script eseguirà una ricerca senza distinzione di maiuscole/minuscole; in altre parole, mona lisa e Mona Lisa verranno trattate nello stesso modo. Per impostazione predefinita, VBScript esegue una ricerca con distinzione di maiuscole/minuscole, il che significa che mona lisa e Mona Lisa vengono considerate dei valori completamente differenti.
Pattern La proprietà Pattern contiene il valore che stiamo cercando. In questo caso, stiamo ricercando soltanto un semplice valore di stringa: Mona Lisa.
In seguito, assegniamo il testo che vogliamo ricercare ad una variabile denominata strSearchString:
strSearchString = "The Mona Lisa is in the Louvre."
Poi chiamiamo il metodo di espressione regolare Replace, inviando a tale metodo due parametri: Il testo di destinazione che intendiamo ricercare (la variabile strSearchString) e il testo di sostituzione (La Gioconda). Ecco come si procede:
strNewString = objRegEx.Replace(strSearchString, "La Gioconda")
Ed ecco il risultato. Il testo modificato viene memorizzato nella variabile strNewString. Se ora eseguiamo un'istruzione echo di strNewString, otterremo il seguente risultato:
The La Gioconda is in the Louvre.
La grammatica è discutibile, ma si ottiene l'idea generale.
Come abbiamo indicato in precedenza, tutto ciò va benissimo, ma è eccessivo; avremmo potuto realizzare lo stesso identico risultato utilizzando queste righe di codice (in realtà, se avessimo voluto, avremmo potuto utilizzare anche una sola riga):
strSearchString = "The Mona Lisa is in the Louvre."
strNewString = Replace(strSearchString, "Mona Lisa", "La Gioconda")
Wscript.Echo strNewString
In altre parole, le espressioni regolari ci consentono di fare qualcosa che non è consentito con la funzione Replace in VBScript.
Vi state chiedendo cos'è questo "qualcosa"? Bene, intanto vi proponiamo un'idea. Spesso noi Scripting Guy finiamo per copiare il testo da un tipo di documento ad un altro. Talvolta questa pratica funziona, ma non è sempre così. Quando non funziona, ci ritroviamo a dover combattere con strani problemi di spaziatura tra parole, che generano un testo simile al seguente:
Myer Ken, Vice President, Sales and Services
Ahi ahi...guardate tutti quegli strani spazi! E, in questo caso, la funzione Replace è di scarso aiuto. Perché? Beh, ci troviamo di fronte ad un numero apparentemente casuale di spazi estranei: il numero di tali spazi è indefinito, il che rende difficile risolvere il problema tramite Replace. Ad esempio, se tentiamo di cercare 2 spazi consecutivi (sostituendoli con un unico spazio), finiamo per ottenere il seguente risultato:
Myer Ken, Vice President, Sales and  Services
È migliore, ma non perfetto. Esiste un modo per ottenere il risultato che stiamo cercando ma richiede la ricerca di un numero arbitrario di spazi (ad esempio, 39); la relativa sostituzione; la sottrazione di 1 dal numero iniziale, la ricerca di 38 spazi; la relativa sostituzione e così via. In alternativa, potremmo utilizzare questo script di espressioni regolari molto più semplice e infallibile:
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = " {2,}"

strSearchString = _
"Myer Ken, Vice President, Sales and Services"
strNewString = objRegEx.Replace(strSearchString," ")

Wscript.Echo strNewString
la chiave per questo script (e per la maggior parte degli script di espressioni regolari) è Pattern:
objRegEx.Pattern = " {2,}"
In questo esempio, si ricercano 2 o più spazi consecutivi. Come sappiamo che questo Pattern ricerca 2 o più spazi? Dunque...nei nostri contrassegni con doppi apici è presente un singolo spazio seguito da questo costrutto: {2,}. Nella sintassi di espressioni regolari, ciò indica di ricercare almeno 2 istanze consecutive del carattere precedente (in questo caso, uno spazio). E come fare in presenza di 3, 4 o 937 spazi consecutivi? Nessun problema. Verranno rilevati comunque. (Se, per qualche ragione, volessimo individuare almeno 2 ma al massimo 8 spazi, utilizzeremmo la sintassi {2,8}, in cui 8 specifica il numero massimo di corrispondenze).
In altre parole, ogni volta che vengono rilevati 2 o più spazi, tutti gli spazi consecutivi verranno sostituiti con un singolo spazio. Cosa succederà al nostro valore di stringa originale, con tutti gli spazi? Questo:
Myer Ken, Vice President, Sales and Services
Visto? Gli Scripting Guy possono realmente migliorare le cose. Se solo i gestori del Louvre ci consentissero di ritoccare Monna Lisa...
Di seguito viene riportato un interessante scenario piuttosto insolito. Supponiamo che la vostra azienda abbia un elenco telefonico in cui tutti i numeri hanno il seguente formato:
555-123-4567
Ora, il vostro capo ha deciso che tutti i numeri di telefono dovranno avere il seguente formato:
(555) 123-4567
Come fare per modificare il formato di tali numeri? Potremmo essere così audaci da suggerirvi di utilizzare uno script simile al seguente:
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\d{3})-(\d{3})-(\d{4})"

strSearchString = "555-123-4567"
strNewString = objRegEx.Replace _
(strSearchString, "($1) $2-$3")

Wscript.Echo strNewString
In questo esempio stiamo cercando 3 cifre (\d{3}) seguite da un trattino, seguite da altre 3 cifre e da un trattino, seguiti da 4 cifre. In altre parole, stiamo cercando il seguente schema, in cui ogni X rappresenta un numero da 0 a 9:
XXX-XXX-XXXX
Nota: come potevamo sapere che \d{3} avrebbe consentito allo script di ricercare tre numeri a ritroso? Per quanto possiamo ricordarci, lo abbiamo letto da qualche parte. Forse nello scioccante capitolo finale del Codice da Vinci o nel VBScript Language Reference di MSDN® online (vedere go.microsoft.com/fwlink/?LinkID=111387).
A questo punto, è fantastico poter ricercare un numero di telefono arbitrario utilizzando le espressioni regolari. Tuttavia, resta ancora un problema fondamentale da risolvere. Dopotutto, non possiamo sostituire tale numero di telefono arbitrario con un numero di telefono ugualmente arbitrario, ma dobbiamo usare lo stesso numero di telefono con un formato leggermente diverso. Come fare?
Utilizzando il seguente testo di sostituzione:
"($1) $2-$3"
$1, $2 e $3 sono degli esempi di un'espressione un regolare "con riferimento all'indietro". Un riferimento all'indietro è semplicemente una parte del testo trovato che può essere salvata e riutilizzata. In questo specifico script, stiamo ricercando tre corrispondenze secondarie:
  • Una serie di 3 cifre
  • Una serie di altre 3 cifre
  • Una serie di 4 cifre
A ciascuna di tali corrispondenze secondarie viene assegnato automaticamente un riferimento all'indietro: la prima corrispondenza secondaria è $1; la seconda è $2 e così via, fino a $9. In altre parole, questo script assegna automaticamente alle tre parti del nostro numero di telefono i riferimenti all'indietro mostrati nella Figura 2.
Figure 2 Riferimenti all'indietro nei numeri di telefono (Close Figure 2)

Parte del numero di telefono | Riferimento all'indietro
555 | $1
123 | $2
4567 | $3
Nella nostra stringa di sostituzione, abbiamo usato tali riferimenti all'indietro per garantire il possibile riutilizzo del numero di telefono. Il nostro testo di sostituzione indica semplicemente questo: prendere il primo riferimento all'indietro ($1) e includerlo fra parentesi. Lasciare uno spazio e inserire il secondo riferimento all'indietro ($2) seguito da un trattino. Infine, aggiungere il terzo riferimento all'indietro ($3).
Quale sarà il risultato? Un numero di telefono simile al seguente:
(555) 123-4567
Niente male.
Di seguito viene riportata una variazione allo script dei numeri di telefono. Supponiamo che la vostra organizzazione abbia installato un nuovo sistema telefonico e che, in seguito al cambiamento, tutti i numeri di telefono hanno ora lo stesso prefisso; tutti i numeri che iniziavano originalmente con 666, 777 o 888 iniziano ora con 333. Possiamo riformattare contemporaneamente tali numeri e modificarne il prefisso? Ovviamente sì.
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\d{3})-(\d{3})-(\d{4})"

strSearchString = "555-123-4567"
strNewString = objRegEx.Replace _
(strSearchString,"($1) 333-$3")

Wscript.Echo strNewString
Ecco come abbiamo ottenuto questo risultato: abbiamo rimosso il vecchio prefisso (il riferimento all'indietro $2) nel nostro testo di sostituzione; al suo posto abbiamo inserito il valore di prefisso codificato e standard 333. Come apparirà il numero 555-123-4567 dopo l'esecuzione di questo script modificato? Apparirà come riportato nel seguente esempio:
(555) 333-4567
Di seguito viene riportato un altro uso comune del riferimento all'indietro. Supponiamo la presenza di un valore di stringa simile al seguente:
Myer, Ken
Esiste un modo per modificare tale valore e visualizzare il nome nel modo seguente?
Ken Myer
Appariremmo piuttosto stupidi se la risposta fosse no, giusto? Ecco uno script che consente di ottenere esattamente il risultato desiderato:
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\S+), (\S+)"

strSearchString = "Myer, Ken"
strNewString = objRegEx.Replace _

strSearchString,"$2 $1")

Wscript.Echo strNewString
In questo specifico script, stiamo cercando una parola, (\S+), seguita da una virgola, seguita da uno spazio, seguito da un'altra parola. (In questo caso, utilizziamo \S+ per indicare una parola). Il valore \S+ indica qualsiasi serie consecutiva di caratteri diversi da uno spazio. In altre parole, tale valore può rappresentare una lettera, un numero, un simbolo, purché sia un carattere diverso da uno spazio, una tabulazione, un ritorno a capo o un avanzamento riga. Come potrete notare, ci aspettiamo di trovare due corrispondenze secondarie in questo caso: una che rappresenti il cognome ($1) e una che rappresenti il nome ($2). Di conseguenza, possiamo visualizzare il nome utente come FirstName LastName tramite la seguente sintassi:
"$2 $1"
Dov'è la virgola? In realtà, non ne avevamo bisogno e l'abbiamo semplicemente tolta.
Nota: è divertente che, per qualche motivo, abbiamo iniziato a pensare anche all'editor di script. Hmmm...
Desideriamo mostrarvi un altro esempio o prima di chiudere. Non si tratta di un esempio infallibile al 100%; dopo tutto, non vogliamo che un articolo introduttivo come questo diventi troppo complicato. (E le espressioni regolari hanno il potenziale di diventare estremamente complicate). Tuttavia, ecco uno script che, nella maggior parte dei casi, rimuoverà gli zero iniziali da un valore come 0000,34500044:
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "\b0{1,}\."

strSearchString = _
"The final value was 0000.34500044."
strNewString = objRegEx.Replace _
strSearchString,".")

script.Echo strNewString
Come al solito, l'unico motivo per cui lo script funziona è per il modello: "\b0{1,}\." Iniziamo con il ricercare un vincolo di parola (\b); che garantisca che non vengano rimossi gli zero in un valore quale, ad esempio, 100,546. Ricercheremo poi uno o più zero, 0{1,}, seguiti da una virgola decimale (\,). Se il modello viene rilevato, gli zeri e la virgola decimale vengono sostituiti da una singola virgola decimale ",". Se tutto procede secondo il piano, la nostra stringa verrà convertita nel seguente modo:
The final value was .34500044.
È tutto per questo mese. Prima di chiudere, potremmo sottolineare che, mentre il quadro era ancora in esecuzione, la Monna Lisa divenne l'oggetto di una notevole controversia. Chi è la donna misteriosa? Perché sorride in quel modo? Perché non ha le sopracciglia? Diversi storici d'arte sostengono che Monna Lisa in realtà non era neanche una donna e che il ritratto non è niente altro che l'autoritratto di Leonardo da Vinci. (Se fosse vero, Leonardo avrebbe potuto trovare un sarto migliore). Nel frattempo, la Unarius Educational Foundation è andata ancora oltre, sostenendo che il dipinto è in realtà quello dell'anima gemella di Leonardo e che tale anima del "mondo superiore" avrebbe guidato la mano di Leonardo. Per una stranissima coincidenza, questo è esattamente il modo in cui è stato scritto l'articolo di Hey, Scripting Guy! di questo mese.
Il che significa che le eventuali lamentele potranno essere inviate all'indirizzo the-twin-soul-of-the-scripting-guy-who-writes-that-column@the-other-microsoft.com. Grazie!

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

Maggio 2008: Script-doku
Questo mese, giochiamo a Sudoku, ma con una lieve modifica. Al posto dei numeri dall'1 al 0 nella griglia, sono presenti le lettere e i simboli che compongono un cmdlet Windows PowerShell™. Nella soluzione finale, una delle righe riporterà il nome di cmdlet.
Nota: per tutti coloro che non sanno giocare a Sudoku, consigliamo di consultare uno delle diverse migliaia di siti Web contenenti le istruzioni che, siamo spiacenti, non verranno ripetute in questo articolo.

Il rompicapo di script del Dottor Scripto
Risposta: Script-doku, maggio 2008

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.


 Security Watch: Principi di sicurezza quantistica
Security Watch
Principi di sicurezza quantistica
Jesper M. Johansson

Può essere molto divertente dire qualcosa di assolutamente imprevisto, ma pertinente, in una conversazione. Ho scelto di utilizzare il principio di indeterminazione di Heisenberg per spiegare i concetti correlati alla sicurezza. (Chi ha sentito la mia storia sull'unicorno sa già che mi piace fare le mie considerazioni prendendo in prestito le teorie fondamentali di altre discipline.) Per quanto
strano possa sembrare, esistono delle verità per la sicurezza delle informazioni che si deducono dai concetti fondamentali di altre branche della scienza.
Il principio di indeterminazione di Heisenberg, derivante dalla fisica quantistica, si basa sull'equazione mostrata nella figura 1. Il principio stesso afferma che la posizione di una particella (p) e il momento della particella (x) sono correlati al punto tale che se si aumenta la precisione di misurazione della precisione, viene ridotta la precisione di misurazione del momento. Il limite per la precisione dei due fattori è un piccolo multiplo fisso della costante di Planck. In parole semplici, questo principio afferma che non è possibile osservare contemporaneamente con la massima precisione determinati fatti relativi a una stessa particella.
Figura 1 Principio di indeterminazione di Heisenberg
Figura 1 Principio di indeterminazione di Heisenberg
Ciò è associato direttamente alla previsione delle bande di incertezza, che consentono di predire il proprio livello di incertezza sullo stato di una coppia di fatti relativi a una particella. Anche se non è ancora possibile predire le bande, il fatto di non poter prevedere con certezza in che modo due variabili in un'unica rete di computer incideranno sulla sicurezza della stessa è estremamente importante.
Sono necessari anche dei compromessi. Anche se si potrebbe non essere vincolati dalla costante di Planck nella sicurezza delle informazioni, in effetti lo si è. Il compromesso più importante da fare è quello tra fattori quali la sicurezza e l'utilizzabilità o l'utilità. Se si ignora la disponibilità per un momento (e francamente ritengo che il personale della sicurezza dovrebbe essere responsabile per la disponibilità solo per quanto riguarda agli attacchi Denial of Service), il modo migliore per rendere sicuro un componente consiste nel disattivarlo completamente. In questo modo, non potrà più essere vittima di attacchi. Tuttavia, l'utilità diminuisce considerevolmente.
Analogamente, anche se più impegnativo, è possibile impedire la perdita di dati molto di più implementando un costoso prodotto per la prevenzione delle perdite di dati anziché inviando un messaggio di posta elettronica a tutti i dipendenti una volta all'anno per informarli che le applicazioni di messaggistica immediata non sono adatte per l'uso aziendale. Ma l'organizzazione è disposta a spendere per l'acquisto di uno strumento di prevenzione delle perdite di dati? A questo punto, viene illustrato in che misura la fisica quantistica risulta correlata alla sicurezza.

Gatto di Schrödinger
Un altro concetto della fisica quantistica correlato è espresso nella parabola del gatto di Schrödinger. Si dice che Erwin Schrödinger, un eminente fisico del ventesimo secolo, ebbe una discussione durata a lungo con Albert Einstein (un altro eminente fisico del ventesimo secolo di cui probabilmente si è già sentito parlare) sul concetto di sovrapposizione. Schrödinger individuò le aree della meccanica quantistica che avevano elementi esistenti nella sovrapposizione di due stati paradossali.
Per sostenere ciò, Schrödinger propose un esperimento mentale in cui un gatto veniva rinchiuso in una scatola sigillata ermeticamente. L'altro elemento inserito nella scatola era un contenitore di materiale radioattivo, il cui rilascio veniva controllato da una (immaginaria) particella radioattiva subatomica. Se la particella si fosse disintegrata, il materiale radioattivo sarebbe stato rilasciato e il gatto sarebbe morto.
La particella subatomica, essendo sottoposta alle leggi della meccanica quantistica, esiste in una sovrapposizione di stati. Di conseguenza, anche il gatto atomico, dato che il suo stato dipende interamente dallo stato della particella subatomica, esiste nella sovrapposizione di stati. Solo con un'osservazione diretta del gatto è possibile affermare se il suo stato sia di essere vivo o morto.
Ovviamente, con questo paradosso, Schrödinger intendeva illustrare quanto assurde siano alcune leggi della meccanica quantistica quando applicate ai sistemi atomici. Nonostante ciò, il suo esempio viene spesso ritenuto all'origine di quel concetto profanamente definito "effetto osservatore". Tale effetto, anche se non si applica ai sistemi subatomici della meccanica quantistica, risulta interessante per i professionisti della sicurezza. In parole semplici, afferma che è possibile modificare un qualcosa semplicemente osservandolo.
Effetto osservatore
Per spiegare ulteriormente il concetto, si prenda in considerazione l'esempio di una tazza di tè. Per scoprire quanto è caldo il tè, è possibile inserire un termometro nella tazza. Supponiamo che quando si inserisce il termometro nel tè la sua temperatura sia di 80 °C e che il termometro a sua volta abbia una temperatura di 22 °C (la temperatura ambiente). Non appena il termometro entra a contatto con il tè, inizia ad assorbire il calore del tè e quest'ultimo perde parte del suo calore per far scaldare il termometro. Alla fine, il termometro e il tè avranno la stessa temperatura. Tuttavia, la temperatura del tè non sarà né di 80 °C né tanto meno di 22 °C, ma sarà compresa in tale intervallo. In questo modo, attraverso la misurazione, la temperatura del tè è stata modificata.
L'effetto osservatore può essere applicato anche alla sicurezza delle informazioni. Ogni volta che si fa qualcosa per attenuare un problema di sicurezza, vengono potenzialmente modificate le condizioni di sicurezza dato che si modifica il sistema. In mancanza di un termine più adatto, questo effetto verrà chiamato effetto SPFE (Security Posture Fluidity Effect).
Uno degli esempi più semplici di questo effetto è quello delle dipendenze degli account di servizio. Nel capitolo 8 del libro Protect Your Windows Network (protectyourwindowsnetwork.com), viene illustrata l'installazione di un servizio di identificazione di intrusione (IDS) sui sistemi per rilevare gli eventuali attacchi. Tuttavia, il servizio IDS accede a un sistema centrale e richiede un accesso con privilegi di alto livello ai sistemi monitorati. Generalmente, ciò vuol dire che il servizio viene eseguito in un account del servizio con privilegi di alto livello.
Se uno di tali sistemi viene compromesso, l'autore dell'attacco può ottenere l'accesso alle credenziali dell'account del servizio e accedere a tutti gli altri sistemi, oltre che disabilitare il servizio IDS stesso. Questo è un perfetto esempio di effetto SPFE. Installando un componente per fornire sicurezza all'ambiente in uso, viene creato un nuovo potenziale problema di sicurezza.
Esistono numerosi altri esempi che spiegano l'effetto SPFE. La descrizione di Steve Riley del motivo per il quale 802.1x presenta tali problemi sulle reti cablate (microsoft.com/technet/community/columns/secmgmt/sm0805.mspx) è un altro ottimo esempio. In numerosi ambienti è auspicabile l'uso di firewall basati su host. Tuttavia, se utilizzati insieme a 802.1x, contribuiscono a creare un ambiente che fa aumentare la probabilità di specifici tipi di attacco. Occorre di nuovo ricordare che una tecnologia di sicurezza modifica le condizioni di sicurezza dell'ambiente e consente un attacco che altrimenti non sarebbe possibile.
Tuttavia, niente di tutto ciò indica che tali misure sono inutili e che devono essere evitate. È semplicemente necessario prendere in considerazione le implicazioni in termini di sicurezza a un livello generale. Quando si implementa la gestione dei rischi, è necessario considerare gli effetti che vengono prodotti sulla sicurezza dalle azioni e dalle misure di prevenzione adottate. Quando si tenta di risolvere un problema, non ci si dovrebbe fermare dopo aver implementato le contromisure. In effetti, la sicurezza è un processo. È necessario implementare una strategia di difesa in profondità, ma si ha bisogno di considerare in che modo tale strategia modificherà le condizioni di sicurezza e come sarà possibile affrontare le minacce che emergeranno dalla stessa.

Una strategia di protezione avanzata efficace
Sono impegnato nello sviluppo di linee guida per la protezione avanzata da oltre 10 anni. Ripensando alle prime linee guida su cui ho lavorato, mi rendo conto che erano poco più che semplici elenchi di impostazioni che gli utenti avrebbero dovuto attivare. A quell'epoca, la strategia generale per la sicurezza era estremamente semplice: se si pensava che qualcosa potesse fornire sicurezza, doveva semplicemente essere attivato. Il fatto che potessero esistere validi motivi per non farlo era assolutamente irrilevante.
Alla fine, mi resi conto che il processo per implementare una strategia di protezione avanzata efficace è molto complesso e occorre prendere in considerazione anche tutte le minacce alle quali viene esposto il sistema. Questa rivelazione ha portato alla creazione dell'elenco di scenari illustrati nella guida Windows 2000 Security Hardening Guide (go.microsoft.com/fwlink/?LinkID=22380). Da quel momento, ho pensato di suddividere le linee guida in base ai diversi livelli di minaccia, come illustrato nella guida Windows Server 2003 Security Guide (go.microsoft.com/fwlink/?linkid=14846).
Nonostante ciò, continuavo a essere tormentato dal fatto che fosse sempre possibile irrompere in un sistema in cui erano state adottate tutte le linee guida impartite. Ciò era dovuto all'assenza di alcune patch, all'implementazione di determinate procedure operative o all'installazione di un software di terze parti non sicuro.
Risulta quindi chiaro che tutte le linee guida fornite in queste due guide non si rivelano molto utili per creare delle condizioni di sicurezza generali. Tutto si riduceva ad alcuni fattori fondamentali. In effetti, il sistema più sicuro che abbia mai creato (msdn2.microsoft.com/library/aa302370) utilizzava solo quattro o cinque delle modifiche di sicurezza indicate nelle guide e nessuna di loro riusciva a bloccare gli eventuali attacchi a cui veniva esposto il sistema. Sfortunatamente, le persone desiderano semplicemente avere a disposizione un grande pulsante in grado di fornire automaticamente la protezione avanzata ai sistemi, ma la sicurezza è un fattore molto più complicato.

Come affrontare il rischio
Per essere realmente protetti (e non solo limitatamente sicuri), è necessario affrontare i rischi adottando un approccio ragionevole. È necessario comprendere quali sono i rischi a cui si dovrà far fronte, decidere quali di essi si desidera attenuare e quindi comprendere come farlo: tutto ciò non può esser fatto semplicemente con delle opzioni.
In generale, tali opzioni di sicurezza sono progettate per specifici scenari e non permettono necessariamente di creare la configurazione migliore per il proprio caso. In realtà, rappresentano un buon punto di partenza e sono disponibili principalmente perché la maggior parte del mercato ne ha bisogno. Molte di loro risultano attivate per impostazione predefinita nelle applicazioni moderne ed è probabile che quelle che non lo sono abbiano dei significativi effetti collaterali.
Inoltre, rendere disponibile un grande numero di opzioni può generare un sistema non supportabile e instabile che potrebbe non riuscire a eseguire le attività desiderate (e tutto per attenuare delle minacce non ancora identificate). L'effetto SPFE e la fisica quantistica insegnano a fare un'ulteriore analisi del sistema dopo aver implementato le misure di sicurezza, ma sono ancora troppo poche le organizzazioni che lo fanno. In realtà, non si preoccupano di partire da un'analisi delle minacce. Se si parte da un'analisi delle minacce, ci si renderà conto che ciò che fa davvero la differenza non sono le restrizioni anonime per gli elenchi dei nomi account e le modifiche generali degli elenchi di controllo di accesso.
Ciò che rende davvero diverse le cose è stabilire se il sistema deve fornire un particolare servizio e quali sono i destinatari, nonché applicare tali criteri. Il fattore fondamentale è verificare che solo i sistemi e gli utenti che hanno assolutamente bisogno di comunicare con voi ricevano l'autorizzazione per farlo. È inoltre importante accertarsi che a tutti gli utenti e le applicazioni vengano assegnati i privilegi di livello inferiore. In breve, ciò che fa davvero la differenza è adottare un approccio ragionevole alla sicurezza e svolgere le difficili attività di analisi per assegnare a ciascun sistema la responsabilità della propria sicurezza.
Questo è il motivo per il quale l'approccio attuale alla sicurezza ora impiega strumenti quali la soluzione Server and Domain Isolation (microsoft.com/sdisolation), Configurazione guidata impostazioni di sicurezza nei prodotti Windows Server® e gli strumenti di Server Manager per la gestione dei ruoli in Windows Server 2008. Questi strumenti consentono di comprendere gli scenari da supportare e permettono di bloccare i sistemi nel modo appropriato. È vero, questi strumenti non offrono un rimedio universale, ma consentono di creare una configurazione supportabile che possa realmente eseguire le attività per le quali è stato acquistato il software.

Applicare la sicurezza dove necessario
Quello che è stato detto finora indica che non è possibile implementare la sicurezza facendo affidamento su altri o applicando semplici modifiche di sicurezza. Ogni risorsa deve essere in grado di difendersi autonomamente perché concetti come "perimetro" e "rete interna" oggi hanno perso completamente di significato.
Nella migliore delle ipotesi, la maggior parte delle reti aziendali sono "semi-ostili". Bisogna capire ciò e prendere le dovute misure, senza fare affidamento esclusivamente su linee guida per la protezione avanzata automatiche. Per iniziare, è necessario capire quali siano le proprie esigenze. Quindi, si dovrebbero ricercare le linee guida da coloro che hanno capito tali esigenze.
Un ospite in una trasmissione webcast di recente ha consigliato agli utenti delle aziende di piccole dimensioni di accedere al sito del Department of Homeland Security e scaricare le linee guida per la protezione avanzata per Internet Explorer®. Perché ci si dovrebbe aspettare che un ente governativo con il compito di proteggere il sistema di sicurezza nazionale e militare fornisca linee guida per rendere sicuro un browser Web in un'azienda di piccole dimensioni? Si tratta di un perfetto esempio della debole logica che ancora prevale nel campo della sicurezza informatica. Il presupposto da cui si parte è che, visto che le linee guida vengono impartite da un ente governativo, i risultati ottenuti siano necessariamente della massima sicurezza.
Generalmente, viene chiesto di optare per una "sicurezza di alto livello" o una "sicurezza di basso livello". Sarebbe meglio che la scelta fosse tra una "sicurezza di alto livello " e una "sicurezza adeguata". La sicurezza non è una soluzione valida per tutti sempre allo stesso modo.
In effetti, una sicurezza di alto livello in genere va bene solo in pochissimi casi. Non è un obiettivo finale al quale si dovrebbe mirare. Si tratta di una configurazione specifica per quei sistemi la cui eventuale compromissione verrebbe sentita come un'autentica tragedia. Se la sicurezza di alto livello si addice al proprio profilo e modello di rischio, è opportuno utilizzarla.
Se invece non risulta appropriata, se ne dovrebbe scegliere un altro tipo. È quasi sicuro che tutte le eventuali modifiche configurabili siano già impostate, per impostazione predefinita, su un livello di profilo di rischio moderato. Tale stato predefinito, utilizzato al momento nella maggior parte dei prodotti Microsoft, fornisce un compromesso ragionevole tra sicurezza, utilizzabilità, utilità e prestazioni, Per ciò che riguarda la protezione avanzata, fa al caso proprio.
È ora necessario prendere in considerazione altre operazioni per la sicurezza. Un buon punto di partenza è il sito TechNet Security Center (microsoft.com/technet/security) e, naturalmente, libri come Windows Server 2008 Security Resource Kit.

Gestione dei rischi
È probabile che a questo punto si sia compreso che il fattore primario è la gestione dei rischi. Il messaggio fondamentale del principio di indeterminazione di Heisenberg è la necessità dei compromessi. Quella parte del principio non è scienza missilistica.
Nonostante ciò, il messaggio che emerge dalla storia del gatto di Schrödinger è qualcosa che viene ignorato dalla gente fin troppo spesso. Il fattore importante non è solo analizzare tutti i lati del problema e prendere una decisione in merito ai compromessi, ma anche prendere in considerazione le modifiche introdotte dalle soluzioni. Una strategia di gestione dei rischi efficace prende in considerazione il modo in cui tale modifiche incidono sul sistema e se sono state implementate nell'ambito di una strategia di attenuazione dei rischi o per un qualsiasi altro motivo.

Perdita annuale attesa
Il modo più comune per quantificare il rischio, e il metodo appreso in numerosi corsi di certificazione per la sicurezza, è l'equazione relativa alla perdita annuale attesa (Annual Loss Expectancy, ALE), mostrata nella figura 2. L'ALE standard è estremamente semplice. Viene stabilita la probabilità di un incidente e il costo di ogni singola ricorrenza e, quindi, si moltiplicano i due valori. Ciò restituisce la cifra che si prevede di pagare per gli incidenti di sicurezza su base annua. Se il costo del rischio è abbastanza alto, viene implementata la strategia di attenuazione.
Figura 2 L'ALE rappresenta la probabilità di una perdita, moltiplicata per il costo della perdita per incidente
Figura 2 L'ALE rappresenta la probabilità di una perdita, moltiplicata per il costo della perdita per incidente
In questo caso, il problema è che l'ALE standard non giustifica il costo per l'attenuazione. Oltre ad avere un proprio costo, le strategie di attenuazione producono anche effetti collaterali, ai quali sono associati ulteriori costi.
Bisogna prendere in considerazione una delle principali modifiche di sicurezza standard: il blocco account. Molte organizzazioni distribuiscono il blocco account, apparentemente per impedire agli autori degli attacchi di identificare le password. Viene calcolata matematicamente la probabilità che un autore di attacchi riesca a identificare una singola password. Con un po' di fantasia, è possibile prevedere un costo medio per la violazione risultante nel caso in cui un autore di attacchi riesca a identificare una password. In base a questi due numeri, molte organizzazioni hanno deciso che l'ALE non è sufficiente e, di conseguenza, hanno implementato un blocco account.
Tuttavia, questo particolare tipo di strategia di attenuazione ha un costo, che non si dovrebbe sottovalutare. Si tratta del costo per la sua implementazione, anche se è assolutamente minimo. Per essere precisi, il calcolo dovrebbe includere anche i costi degli effetti collaterali derivanti dalla strategia di attenuazione.
In primo luogo, esiste un costo associato all'operazione di sblocco degli account per gli utenti da parte dell'help desk. Se un account viene bloccato per un periodo di tempo ridotto, diciamo 15 minuti, esiste comunque un costo per la produttività persa in tale periodo. Questo fattore viene considerato come il costo di ogni incidente, moltiplicato per la probabilità per la quale l'incidente può verificarsi nel periodo in questione. In questo caso, il costo viene moltiplicato per il numero di eventi di blocco previsti (tale numero è fornito dai registri in uso).
Si dovrebbe prendere in considerazione anche il fattore di aggravamento relativo agli utenti. Prove anedottiche indicano che gli utenti tendono a utilizzare password meno complicate se sono soggetti a un blocco account, in quanto sono più facili da digitare. Pertanto, la probabilità che si verifichi l'incidente che si desidera evitare non scende interamente a zero dopo aver implementato la strategia di attenuazione.
Infine, possono esistere delle vulnerabilità introdotte dalla strategia di attenuazione e non presenti nel sistema prima della sua introduzione. Nel caso del blocco account, un autore di attacchi può usare tale funzione per disabilitare tutti gli account nella rete semplicemente digitando ripetutamente le password non corrette. Esiste la probabilità che si verifichi anche questa situazione, con un costo associato di ciascun incidente.
Prendendo in considerazione tutti questi fattori, risulta evidente che è necessario modificare l'equazione relativa alla perdita attesa. In primo luogo, è necessario modificare la probabilità dell'incidente. Questo incidente dovrebbe avere meno probabilità di verificarsi rispetto al passato, anche se la probabilità, come già illustrato, potrebbe non essere scesa completamente a zero. Anche il costo di ogni incidente potrebbe essere cambiato. A tale prodotto è necessario aggiungere il costo della strategia di attenuazione stessa. Si tratta del costo costituito dal costo di implementazione più il costo annuale di tutti gli effetti collaterali. Ognuno dei costi annuali è il prodotto della probabilità dell'effetto collaterale verificatosi e del costo di ogni incidente associato a tale effetto. Semplificando leggermente l'equazione, si ottiene l'equazione per l'analisi dei rischi più accurata mostrata nella figura 3.
L'equazione della figura 3 fornisce un modo molto più accurato per analizzare il rischio di un particolare problema. Diverse organizzazioni hanno già adottato tale metodo per analizzare i loro rischi. Tuttavia, molte di loro hanno ancora una visione semplificata del rischio che non mette adeguatamente in evidenza la necessità di analizzare l'impatto delle strategie di attenuazione. Utilizzando la nuova equazione ALE, tale esigenza ottiene una considerazione fondamentale.
Figura 3 Considerazione dei costi aggiuntivi per l'attenuazione
Figura 3 Considerazione dei costi aggiuntivi per l'attenuazione

Conclusioni
Dopo aver letto questo articolo, si dovrebbe mettere in discussione l'approccio convenzionale alla base delle strategie di sicurezza. La maggior parte di ciò che viene fatto nel campo della sicurezza delle informazioni si basa su una visione stereotipata del mondo e molte delle supposizioni risultano ora superate.
Gli attacchi sono cambiati. Gli autori degli attacchi ora sono dei veri professionisti, che svolgono la loro attività per denaro, per primeggiare a livello nazionale e per ideologia. Non ci si può permettere di perdere tempo e denaro con modifiche di sicurezza che non migliorano affatto la sicurezza. Ciò vuol dire anche che è necessario adottare un approccio molto più sofisticato alla gestione dei rischi.
In primo luogo, è importante comprendere che tutto ciò che viene fatto comporta un compromesso. Non è possibile sapere tutto con una certezza assoluta.
In secondo luogo, è necessario capire che si agisce in un sistema interdipendente. Introducendo modifiche di sicurezza in un sistema di questo tipo, viene modificato il sistema stesso e quindi diventa necessario poterlo rianalizzare.
È opportuno che ciò venga fatto prima di implementare tali modifiche perché esse hanno, fin troppo spesso, enormi conseguenze sul sistema e producono un impatto più negativo che positivo. Se si utilizzano strumenti di analisi migliori che ricordano di analizzare tali modifiche, è molto meno probabile che non vengano prese in considerazione.
Infine, non bisogna dimenticare mai il fattore umano. L'obiettivo primario di qualsiasi operazione svolta nel campo della sicurezza delle informazioni è consentire all'azienda, e ai suoi utenti, di agire nel modo più sicuro possibile.
In una recente presentazione, ho sottolineato il fatto che oggi non esiste un solo utente che acquisti un computer per eseguire un programma antivirus. La sicurezza è il nostro obiettivo principale, ma non quello dell'azienda. Le organizzazioni che si occupano della sicurezza perché è nei loro migliori interessi lo fanno solo momentaneamente. Non bisogna dimenticare mai che il gruppo di sicurezza delle informazioni è a disposizione dell'azienda e non il contrario. Se si ignora questo fatto, gli utenti saranno disposti a tutto per svolgere il proprio lavoro, anche se ciò comporta non rispettare i controlli di sicurezza che non capiscono o non accettano.

Jesper M. Johansson, Software Architect, si occupa dei problemi di sicurezza del software e collabora con TechNet Magazine come redattore. Ha conseguito il titolo di PhD nei sistemi di gestione delle informazioni e vanta di oltre venti anni di esperienza nel campo della sicurezza; è inoltre Microsoft Most Valuable Professional (MVP) nella sicurezza aziendale. Il suo ultimo libro è Windows Server 2008 Security Resource Kit.


 File desktop: Come sbarazzarsi del ruolo di amministratore
File desktop
Come sbarazzarsi del ruolo di amministratore
Wes Miller

Più di tre anni fa, ho iniziato il processo di conversione del mio account utente sul sistema Windows primario da amministratore locale ad utente locale. Lavoro alla Microsoft da più di sette anni, utilizzando sempre l'esecuzione come amministratore provvisto di tutti i privilegi. Certamente tale situazione era conveniente, ma quella terribile mancanza di sicurezza
evidenzia la fortuna sorprendente che ho avuto (insieme a molti altri utenti), dovuta al fatto che attualmente l'esecuzione costante come amministratore non è più pericolosa come un tempo.
Spesso mi sarebbe piaciuto raccogliere delle valide statistiche su questa situazione, ma il mio istinto e il mio impegno mi suggeriscono che troppe organizzazioni e troppi professionisti dell'IT utilizzano attualmente l'esecuzione come amministratori locali. Alla Winternals, quando ho iniziato ad utilizzare l'esecuzione come utente, la premessa era capire quanto ciò fosse difficile, in qualità di "prosumer" (ovvero di professional-consumer), e acquisire informazioni su come il nostro prodotto, Winternals Protection Manager, potesse fornire supporto in un'organizzazione di medie dimensioni. Dal momento che la maggior parte delle organizzazioni utilizzavano, e utilizzano ancora, una buona percentuale di utenti come amministratori, il nostro obiettivo era consentire agli amministratori di operare come utenti, rendendo la transizione (o almeno i punti salienti) più semplice possibile. Indipendentemente dalla tecnologia utilizzata, non è semplice convertire la propria organizzazione da un contesto in cui gli utenti sono amministratori ad un contesto in cui sono utenti, ma è l'unica maniera efficace ridurre la superficie di attacco all'interno dell'organizzazione stessa. Si pensi ad essa come ad un firewall interno al sistema, perché è questa la sua natura.

Come siamo giunti fin qui?
La mia sfida per voi: toccare con mano il problema
Se non avere ancora pensato alla conversione dei vostri amministratori in utenti, dovreste iniziare a farlo. E vi consiglio di iniziare da voi. Non su un computer secondario...così non vale! Provate a farlo sul vostro sistema primario, quello che utilizzate ogni giorno. Vi invito inoltre a provare senza utilizzare il Controllo dell'account utente (UAC) se disponete di Windows Vista®. Quando iniziate a diffondere la volontà di cambiamento all'interno della vostra organizzazione, è una buona idea esporsi in prima persona. Penso che vi renderete conto che l'utilizzo dell'esecuzione come non amministratore non è poi così difficile e che, grazie alla maggiore sicurezza garantita da tale cambiamento, riuscirete realmente a modificare la superficie di attacco della vostra organizzazione.

Nella storia di Windows® è dimostrato chiaramente che la maggior parte degli utenti operano come amministratori. Con le prime versioni di Windows, prima di Windows NT® 3.1, ogni utente interattivo disponeva degli stessi privilegi del successivo; a livello funzionale, non vi era alcuna sicurezza. In un ambiente familiare, questo scenario non era poi così terribile; significava soltanto che tutto il software veniva installato nello stesso modo. Il presupposto era che l'utente fosse il proprietario del computer e che tutto il software venisse installato per tutti gli utenti di tale computer.
Quando fece la sua comparsa Windows NT, non conquistò immediatamente il mercato aziendale (senza parlare del consumatore). E, in virtù della compatibilità Win32® tra Windows a 32 bit e Windows NT, la maggior parte dei fornitori di applicazioni non ha ricostruito le proprie applicazioni proprio per l'infrastruttura di sicurezza di Windows NT. In effetti, è stato soltanto con Windows 2000 che diversi fornitori di software indipendenti orientati al consumatore hanno iniziato a prestare attenzione a Windows NT. Ovviamente è stato proprio Windows XP che ha sollevato il problema, poiché è stato l'ultimo della famiglia 9x di Windows.
Tuttavia, sono state create diverse applicazioni, presupponendo che ogni utente sul sistema disponesse dell'accesso di scrittura su Programmi (gli utenti non hanno tale accesso), HKEY_LOCALE_LA COMPUTER (HKLM) nel Registro di sistema (gli utenti non hanno tale accesso) e HKEY_LE CLASSI_LA RADICE (gli utenti non hanno tale accesso). Generalmente, i giochi sono i peggiori colpevoli quando si parla di accesso. A tal proposito, si rimanda all'articolo di Matt Clapham disponibile all'indirizzo technetmagazine.com/issues/2007/02/Gaming.
Questa situazione è problematica poiché la maggior parte delle applicazioni per più sistemi memorizzano i relativi file e impostazioni del Registro di sistema in tali percorsi e, per installarle, è necessario disporre dell'accesso in lettura e scrittura per tali percorsi. Sfortunatamente, alcune applicazioni richiedono la scrittura in tali chiavi dopo l'installazione. Ad esempio, mia figlia possiede un gioco basato su Flash. Ogni volta che viene eseguito, tale gioco tenta di installare un giocatore personalizzato, il che significa che quando mia figlia utilizza il ruolo di utente e non di amministratore, l'applicazione non viene avviata e restituisce un errore fatale. Sebbene questo sia un caso estremo e riguardi l'applicazione di un consumatore, la realtà è che molte delle applicazioni di non consumatori non possono essere utilizzate in modo adeguato nel mondo degli utenti non amministrativi. In effetti, se si prosegue nella mia sfida (consultare la barra laterale "La mia sfida per voi: toccare con mano il problema), si scoprirà quanto Windows stesso non sia tollerante nei confronti dell'esecuzione come utente.
Se si esamina la Figura 1, si noterà che l'esecuzione di IPConfig /release come utente è simile su Windows XP. Se si confronta tale scenario con quello della Figura 2, si noterà che lo stesso comando in Windows Vista non ottiene poi risultati migliori, ma almeno si capisce perché il comando non riesce. Tenere presente che gli strumenti di rete nell'insieme sono stati migliorati per consentire agli utenti di aggiornare i propri indirizzi IP. In modo analogo, se si tenta la Gestione computer (compmgmt.msc) come utente in qualsiasi versione, è possibile eseguire un numero limitato di attività, che generalmente terminano con frustranti vicoli ciechi, come mostrato nella Figura 3. Sebbene Windows Vista non consenta inizialmente molti degli strumenti di Gestione computer, non presenta messaggi più chiari di accesso negato.
Figura 1 Esecuzione come utente in Windows XP
Figura 1 Esecuzione come utente in Windows XP
Figura 2 Esecuzione come utente in Windows Vista
Figura 2 Esecuzione come utente in Windows Vista
Figura 3 Messaggio fuorviante dopo l'esecuzione di compmgmt.msc come utente su Windows XP
Figura 3 Messaggio fuorviante dopo l'esecuzione di compmgmt.msc come utente su Windows XP

Motivi dell'importanza dell'esecuzione come utente
Perché la questione dovrebbe interessarci? Perché, in qualità di professionisti dell'IT, dovremmo iniziare a forzare le applicazioni per adattarle ad utenti con meno privilegi, anziché fare il contrario, ovvero lasciare che le applicazioni suppongano che l'utente interattivo sia il proprietario del sistema.
Sfortunatamente, gli stessi criteri che consentono degli amministratori di scrivere nelle chiavi del Registro di sistema concedono anche a qualunque malware eseguito nel relativo contesto utente l'accesso totale a tutti i contesti che non sono stati esplicitamente negati tramite gli elenchi di controllo degli accessi (ACL). Nel mondo di UNIX, gli utenti rispettano la regola che impone di non utilizzare l'esecuzione come utente root (l'equivalente funzionale dell'account Amministratore di Windows), soprattutto perché l'ecosistema di software che supera i limiti del modello di sicurezza è praticamente inesistente.
Tuttavia, la regola più saggia da seguire è fidarsi del buon senso e utilizzare l'esecuzione come amministratore soltanto quando è strettamente necessario, o ancora meglio, eseguire unicamente singole applicazioni come amministratore. In questo modo, si erige il firewall interno al sistema citato poc'anzi. E quindi, quando un malware o spyware tenta di accedere al sistema, non riesce a farlo, poiché non può scrivere nei percorsi del Registro di sistema o del file system necessari per infettare il sistema (ad esempio, installando un servizio o un driver o eseguendo un'installazione per tutti gli utenti). In più, in questo modo aumentano le probabilità che il software anti-malware riconosca il malware e gli impedisca di accedere all'intero sistema.
Tenere presente, tuttavia, che gli utenti non sono immuni dagli attacchi. Nonostante questa classe di malware non sia molto diffusa, esiste un elevato potenziale che infetti il contesto di un singolo utente individuale o distrugga i suoi dati. Ma il vettore di attacco rappresentato da tale software è limitato. Di conseguenza, lo stesso elemento che limita le istanze di malware su Linux o Macintosh (il numero più basso di vittime potenziali rendono tale sistema appetibile per gli autori di malware) può garantire attualmente la protezione generale dei vostri utenti finali e di voi stessi.

Eliminati anche i Power User?
Mentre sviluppavamo Protection Manager, uno dei commenti dei clienti era: "Attualmente eseguiamo Windows XP con tutti i nostri utenti come Power User, non come amministratori, quindi siamo al sicuro!" La realtà, tuttavia, è che i Power User non sono molto diversi dagli amministratori. Pochi sono i passi che consentono, con attività minime, ad un Power User in Windows XP di diventare un amministratore. Infatti, il gruppo Power User è stato eliminato in Windows Vista e Windows Server® 2008; soltanto un sistema aggiornato da una versione precedente di Windows disporrà di tale gruppo. Tutto sommato, è preferibile non utilizzare mai il gruppo Power User, neanche se si utilizza Windows XP.

Autorizzazioni pericolose
Nella mia rubrica di marzo sui thin client Windows (technetmagazine.com/issues/2008/03/DesktopFiles), ricorderete che ho mostrato parere contrario nei confronti della prospettiva di ridurre Windows XP per risparmiare spazio. Con lo stesso spirito, è una pratica diffusa consentire la conversione degli amministratori in utenti, ma è consigliabile eseguire questa procedura con cautela. Si tratta della modifica degli ACL sul Registro di sistema e sul file system per consentire gli utenti di scrivere in percorsi generalmente a loro vietati, abilitando così applicazioni problematiche.
Ovviamente, la soluzione migliore consiste nell'ottenere una versione aggiornata di un'applicazione che non richiede tale modifica, ma ciò non è sempre possibile. Se occorre modificare le autorizzazioni (eliminandole), procedere con estrema cautela. Tenere a mente che il firewall tra un utente e un amministratore è definito ampiamente dalle autorizzazioni di Registro di sistema e file system. La loro concessione riduce la vostra protezione e potenzialmente amplia la superficie di attacco rappresentata dal malware, quindi è bene essere molto prudenti.

E per quanto riguarda UAC?
Non si può parlare della transizione da amministratori ad utenti senza affrontare il Controllo dell'account utente (UAC) in Windows Vista. UAC, presente anche su Mac OS X, consente l'esecuzione come amministratore senza troppi rischi.
Come funziona tale controllo? Esaminiamo la Figura 4 e i dati mostrati da Process Explorer relativamente a cmd.exe. L'istanza di cmd.exe sulla destra è stata avviata senza elevazione: ho utilizzato l'esecuzione come amministratore. Di conseguenza, anche se l'utente sulla destra è identico all'utente sulla sinistra (in cui cmd.exe è stato avviato con elevazione), l'applicazione stessa non contiene i privilegi e i token necessari per consentire all'utente che esegue tale istanza di svolgere delle attività che richiedano diritti amministrativi. UAC riduce la superficie di attacco all'interno del contesto interattivo dell'utente. L'unico problema è costituito dal fatto che Windows non sa che questa attività richiede privilegi di amministratore e che l'utente può ricevere l'elevazione richiesta per completarla.
Figura 4 Due istanze di cmd.exe con privilegi diversi
Figura 4 Due istanze di cmd.exe con privilegi diversi
I piccoli scudi in Windows Vista mostrano le attività che richiedono elevazione (vedere la Figura 5). Tali attività richiedono elevazione ogni volta che vengono eseguite e questo è uno dei punti dolenti evidenziati dalla stampa relativamente a Windows Vista. L'alternativa, ovvero un rafforzamento delle credenziali, pone una potenziale minaccia alla sicurezza, che potrebbe essere utilizzata per sfruttare più facilmente il sistema.
Figura 5 Gli scudi in Windows Vista indicano che è richiesta un'elevazione
Figura 5 Gli scudi in Windows Vista indicano che è richiesta un'elevazione
Se UAC è attivato e i propri utenti scelgono un'esecuzione come utenti, verrà loro richiesta una serie di credenziali amministrative quando un'applicazione richiede privilegi di questo tipo. In questo caso, come nel caso dell'utilizzo di runas o psexec, l'applicazione viene eseguita letteralmente nel contesto dell'utente che l'ha avviata e non nel contesto dell'amministratore come avviene in UAC. L'attività viene quindi eseguita nel proprio contesto ma con privilegi elevati.

Esecuzione di Windows Vista come utente?
Personalmente, prediligo l'esecuzione di Windows Vista come utente, non come amministratore con UAC, poiché ritengo che questa sia l'idea migliore nell'azienda di medie dimensioni. Dopo tutto, gli utenti hanno controllo totale dei loro sistemi ed è possibile ridurre le opportunità di attacchi malware.
Inoltre, se si intende gestire i propri utenti con politiche di gruppo, anti-virus, anti-malware o un altro software e si desidera un controllo centrale sull'eventuale applicazione o completamento di tali attività, occorre senza dubbio garantire che i propri utenti finali non siano amministratori. Gli utenti amministratori possono arrestare i servizi, aggiungere o rimuovere driver e non solo. Ovviamente, un utente finale astuto può utilizzare Windows PE per eludere alcuni ostacoli della sicurezza. BitLocker® può rendere tale operazione più difficile ma, ancora una volta, è bene tenere presente che gli utenti finali con accesso fisico sono padroni assoluti del loro PC e possono disporne nel modo che preferiscono, fermo restando il tempo, l'esperienza e l'impegno in tal senso.
L'esecuzione di Windows Vista come utente non è poi così diversa dall'esecuzione di Windows XP come utente. Personalmente utilizzo gli stessi strumenti, ovvero PSExec, RunAs e ora anche UAC, per eseguire le attività come amministratore, laddove necessario. L'aspetto interessante è che le poche attività che in Windows XP richiedevano privilegi di amministratore ora non li richiedono più. Ad esempio, un utente di Windows Vista può installare una stampante locale. In Windows XP, gli utenti potevano installare le stampanti di rete ma non una stampante locale, attività per la quale erano richiesti privilegi di amministratore. In Windows Vista, se l'utente si trova fisicamente davanti al PC e il driver della stampante è presente nell'archivio driver, tale utente può installare una stampante e gestire i processi di stampa su tale periferica. Per ulteriori informazioni, consultare go.microsoft.com/fwlink/?LinkId=111534). Tenere presente che questa funzionalità è disabilitata in Windows Server 2008.
Ovviamente, gli utenti "si prendono gioco" della funzionalità dell'orologio (o della sua assenza) in Windows XP. Provate a fare doppio clic sull'orologio come utente (spesso si esegue tale azione per visualizzare la data, indipendentemente dal fatto che tale funzionalità non sia stata concepita per tale scopo) e riceverete l'errore mostrato nella Figura 6. Non molto simpatico... In Windows XP, è possibile modificare i criteri per consentire all'utente di svolgere tale operazione, mentre in Windows Vista questo non è necessario perché la suddetta funzione è stata concepita esattamente per l'uso che la maggior parte degli utenti ne fa. Quindi alla fine, l'esecuzione come utente, indipendentemente dal fatto che si utilizzi UAC o l'esecuzione come utente formale e l'elevazione come un altro utente, è generalmente più supportata in Windows Vista di quanto non lo fosse in Windows XP.
Figura 6 In Windows XP, gli utenti non amministratori non possono cambiare l'ora
Figura 6 In Windows XP, gli utenti non amministratori non possono cambiare l'ora

Consapevolezza dei limiti
Non dimenticare mai che l'esecuzione come utenti non amministratori non è una panacea. Gli utenti finali appassionati utilizzano fisicamente il proprio PC e lavorano diligentemente per sfruttare al meglio i propri sistemi, soprattutto se i privilegi di criteri o di utente creano degli inconvenienti o impediscono loro di completare un'attività.
Se i propri utenti utilizzano l'esecuzione come amministratori, non è difficile eludere i vari criteri di gruppo in uso. Senza dubbio, con un po' più di ingegno, gli utenti possono eseguire l'avvio in Windows PE e modificare le autorizzazioni per le quali normalmente non dispongono di privilegi sebbene, se si utilizza BitLocker o un'altra codifica di unità/volumi, è possibile impedire tale pratica o comunque renderla particolarmente complicata.
La soluzione migliore da adottare nel caso in cui la propria organizzazione non abbia ancora iniziato la transizione degli utenti finali verso l'esecuzione come utenti è acquisire familiarità con i motivi per cui è consigliabile dedicare tempo, denaro e impegno in tale attività, abbandonando l'esecuzione come amministratori.
Certamente, non tutte le applicazioni legacy consentono l'esecuzione come utenti, ma continuare ad utilizzare tali applicazioni equivale a sottoporre la propria organizzazione a minacce di violazione della sicurezza. È bene considerare la possibilità di una virtualizzazione dell'applicazione, spostandola letteralmente in una Virtual Machine in cui l'utente è un amministratore. In questo modo l'applicazione può essere utilizzata nei casi di necessità, senza compromettere la sicurezza del resto del sistema grazie alla conversione da amministratori ad utenti.
Si tenga presente che in questa rubrica non ho utilizzato il termine "blocco" né i relativi derivati. Molte persone considerano il passaggio da amministratori ad utenti parte di un'attività che viene spesso descritta utilizzando il suddetto termine. Sarà probabilmente a causa del mio background psicologico o del mio universo di marketing attuale, ma ritengo sia importante non utilizzare parole che diano agli utenti finali la sensazione che vengano loro tolti dei privilegi (anche se, a livello semantico, è così).
Preferisco sia più corretto sottolineare i vantaggi in termini di sicurezza per l'organizzazione e garantire la presenza di un valido piano per i casi limite in cui non è assolutamente consentita l'esecuzione come utente o in cui una specifica attività richiede privilegi di amministratore. Quando si utilizza un elemento manuale, come il mio script Run.vbs (disponibile in technetmagazine.com/issues/2007/03/DesktopFiles) o una soluzione commerciale per facilitare la transizione (in modo da nascondere i dettagli agli utenti finali e far funzionare semplicemente le cose), è importante concentrarsi da subito sull'attuazione della transizione da amministratore ad utente. Assiduo collaboratore di TechNet Magazine, Aaron Margosis è un sostenitore dell'esecuzione come non amministratore. Se non conoscete il suo blog, è un vero peccato! È la fonte più completa di informazioni sull'argomento (blogs.msdn.com/aaron_margosis). 

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


 Taccuino: Pi&#249; mouse, un solo PC
Taccuino
Più mouse, un solo PC
Kentaro Toyama

L'India attuale è un paese di contrasti. Da una parte, è una superpotenza dell'IT con menti esperte nello sviluppo della tecnologia per le esigenze dell'informatica nel mondo. Dall'altra parte, il 70% del paese vive ancora con meno di $2 al giorno. Questi due poli si incontrano nelle classi di informatica occasionali delle scuole pubbliche più povere in cui, al massimo, è presente una manciata di PC. Tali computer sono generalmente il frutto di donazioni, poiché le scuole non hanno un budget che consenta loro di acquistare tali beni.
In questi ambienti, gli studenti quasi sempre superano il numero dei computer. È molto frequente trovare i gruppi di 10 ragazzi che si affollano intorno ad un computer e spesso il bullo locale ha la meglio. Ovviamente, il concetto di "personale" nel personal computer significa che i PC sono stati progettati per essere utilizzati da una sola persona. Noi della Microsoft Research India ci siamo chiesti in che modo potevamo fornire a più studenti l'accesso ai computer.
La soluzione è risultata sorprendentemente semplice: MultiPointTM consente il collegamento di più mouse USB ad un computer e ogni mouse corrisponde ad un colore diverso sullo schermo (research.microsoft.com/users/udaip/multipoint.htm). Effettivamente, tale soluzione crea un ambiente per più persone, esattamente come una console per giochi, quindi tale software di apprendimento scritto per il paradigma di più mouse consente l'interazione simultanea di più ragazzi con un solo PC.
I giovani studenti hanno accettato subito con entusiasmo la soluzione, malgrado le preoccupazioni degli adulti relative ad un possibile caos totale sullo schermo. Durante rigorosi studi condotti su studenti delle scuole medie, in cui sono state confrontate configurazioni MultiPoint-PC per cinque persone con configurazioni con PC singoli per un singolo studente, i ricercatori hanno scoperto diverse cose. In primo luogo, i ragazzi si impegnano nell'uso del PC e nell'interazione con i compagni per periodi molto più lunghi rispetto ai tempi in cui ognuno di loro poteva accedere ad un unico mouse, probabilmente grazie al fattore aggiuntivo del divertimento. In secondo luogo, è importante progettare delle applicazioni software che incoraggino la collaborazione anziché la competizione pura, per evitare che alcuni studenti, particolarmente i maschi, regrediscano ad una competizione spasmodica con scarso valore educativo. Infine, se la collaborazione fosse integrata, gli studenti imparerebbero da un'applicazione MultiPoint come se si dedicassero allo studio del PC per conto loro, almeno per le semplici attività di apprendimento del vocabolario. Per ulteriori informazioni sulla ricerca, si rimanda al collegamento MultiPoint fornito precedentemente.
Acquistati in blocco, i mouse costano pochi dollari ognuno, il che significa che la fornitura di applicazioni di apprendimento MultiPoint alle scuole comporterebbe un costo IT per studente notevolmente inferiore rispetto a quello attuale. Ad esempio, un PC da $500 condiviso da cinque studenti con un mouse da $5 corrisponde ad una spesa di $105 per ragazzo e tutte le soluzioni che riducono il costo per studente sono le benvenute tra coloro che gestiscono il budget per l'istruzione.
I gruppi Unlimited Potential (microsoft.com/unlimitedpotential) ed Education (microsoft.com/education) di Microsoft hanno riconosciuto il valore di MultiPoint per scuole che versano in condizioni economiche precarie. Per favorire un'adozione rapida e diffusa di tale soluzione, hanno rilasciato un kit di sviluppo software che consente agli sviluppatori del contenuto di apprendimento di applicare senza difficoltà tale paradigma di più mouse nelle applicazioni C#. SDK può essere sviluppato e utilizzato gratuitamente e tutti i computer con sistema operativo Windows® supportano le applicazioni MultiPoint (microsoft.com/downloads).
In qualità di uno dei programmi raggruppati sotto l'espressione Unlimited Potential, l'obiettivo del MultiPoint SDK è quello di estendere l'importanza del PC al maggior numero possibile di studenti e, a tale scopo, abbiamo bisogno del vostro supporto. Nel caso vi capitasse di provare personalmente un'applicazione di apprendimento provvista di MultiPoint, non esitate a comunicarcelo. Vi forniremo dei collegamenti preziosi ai siti MultiPoint.
Per il prossimo futuro, Microsoft Research India e il team del prodotto Terminal Services stanno considerando un'altra soluzione di condivisione di un PC. Split Screen, in cui due persone, due tastiere e due mouse condividono un PC e un monitor. Il monitor è suddiviso al centro in modo che sia possibile eseguire una sessione separata del sistema operativo su ciascun lato. 

Kentaro Toyama è l'Assistant Managing Director di Microsoft Research India (research.microsoft.com/india) e Principal Researcher del gruppo Technology for Emerging Markets (research.microsoft.com/research/tem), che sviluppa le tecnologie per le comunità meno abbienti del mondo.


 Windows Confidential: Le icone a 16 bit sono cos&#236; fuori moda
Windows Confidential
Le icone a 16 bit sono così fuori moda
Raymond Chen

Come ho indicato nella rubrica del febbraio 2008 Windows Confidential, le funzioni talvolta scompaiono da Windows®. Tale "sparizione" avviene generalmente in modo lento e assolutamente impercettibile e, ogni volta, il team di un prodotto celebra l'evento senza troppo scalpore. Un'altra funzione che è svanita in Windows Vista® è la capacità per il codice a 32 bit di accedere alle icone memorizzate in moduli a 16 bit, soprattutto gli EXE e le DLL a 16 bit.
Prima di ottenere i risultati prestabiliti, è bene considerare che un codice a 16 bit può accedere alle icone memorizzate in moduli a 16 bit e che il tutto avviene nel livello di emulazione a 16 bit. La funzionalità "scomparsa" è la capacità di accedere a tali icone da un codice a 32 bit o, in modo più specifico, la possibilità che l'estrazione di icone a 32 bit operi come la funzione ExtractIcon per caricare tali icone dalla propria DLL a 16 bit.
Il codice a 32 bit che estrae le icone da moduli a 16 bit non prevede l'utilizzo di funzioni kernel come, ad esempio, FindResource per individuare l'icona nel file. Tale codice deve, invece, implementare il proprio mini-programma di caricamento che analizza l'intestazione di moduli a 16 bit, esegue ricerche nella tabella di risorse e quindi analizza tale tabella per individuare la risorsa dell'icona desiderata. Solo dopo avere svolto tutte le suddette attività, il codice a 32 bit converte infine i pixel in un'icona.
Come si potrà immaginare, il codice che esegue tale operazione è obsoleto e instabile. Esistono numerose possibilità di errore durante l'analisi di binari che potrebbero risultare danneggiati, per errore o per intento di un malintenzionato. Il team di prestazioni richiederà le modifiche alla modalità di apertura del file per migliorare le prestazioni sulle reti, poiché differenti modalità di apertura e condivisione provocano conseguenze diverse per gli effetti di caching della rete. Il team di affidabilità potrebbe richiedere la riscrittura del codice di analisi per evitare di utilizzare file connessi alla memoria. Alla fine, il costo di gestione di questo tipo di codice inizia a superare il valore offerto. Per spiegarmi meglio, chi è che scrive ancora programmi a 16 bit?
Attualmente, i programmi a 16 bit funzionano soltanto grazie alla presenza del livello di emulazione a 16 bit. È vero, Windows Vista a 64 bit non dispone di tale livello, ma ciò non rappresenta un passo indietro rispetto a Windows XP, poiché neanche Windows XP a 64 bit disponeva di un livello di emulazione a 16 bit. Quindi non sono stati compiuti progressi in tal senso, ma non si è neanche tornati indietro.
La caratteristica che non è più presente in Windows Vista è la possibilità di eseguire ExtractIcon dal proprio programma a 32 bit e ottenere un'icona da una DLL a 16 bit. Se si dispone di un collegamento ad un programma a 16 bit nel proprio menu Start, l'icona per tale collegamento verrà visualizzata come icona di programma generico, poiché Esplora risorse di Windows non consente più l'estrazione dell'icona del programma a 16 bit dal relativo EXE principale. Non è una gran perdita. Ma se si desidera recuperare tale funzionalità, è possibile modificare le proprietà del collegamento e assegnare a tale collegamento un'icona da un modulo a 32 bit.
L'unico contesto in cui ho notato che l'assenza di tale funzione rappresenta un problema è nelle librerie di icone prodotte da un particolare strumento di modifica icone. Per qualche motivo, tale programma salva per impostazione predefinita le proprie icone come DLL a 16 bit, il che significa che non è più possibile accedervi da un codice a 32 bit. Ovviamente, la soluzione più semplice consiste nel salvare di nuovo tali librerie di come risorse in DLL a 32 bit.
Sono certo che alla fine qualcuno, se non è ancora stato fatto, scriverà un programmino per estrarre tutte le icone da una DLL a 16 bit per poi creare una DLL di sole risorse a 32 bit con tali icone, per consentire a coloro che dispongono di icone obsolete in DLL a 16 bit di continuare ad utilizzarle in collegamenti del menu Start. Ma devo ammettere che, se mai si scriverà questo programma, probabilmente non si troverà nessuno che ne avrà realmente bisogno. Il numero di richieste per un programma del genere pervenute al team dell'interfaccia utente di Windows: zero.

Raymond Chen, The Old New Thing, così come nell'omonimo libro, vengono illustrate la storia di Windows e la programmazione in Win32. La sua è un'analisi attenta e obiettiva.