Amministrazione di Windows

Progettazione di strutture di unità organizzative efficaci

Ken St. Cyr

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 **(Fare clic sull'immagine per ingrandirla)

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 **(Fare clic sull'immagine per ingrandirla)

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 **(Fare clic sull'immagine per ingrandirla)

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 **(Fare clic sull'immagine per ingrandirla)

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 **(Fare clic sull'immagine per ingrandirla)

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 **(Fare clic sull'immagine per ingrandirla)

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.

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