Administration de Windows

Conception de structures d'UO fonctionnelles

Ken St. Cyr

Vue d'ensemble:

• Principes clés d'une bonne conception d'UO
• Modèles de conception d'UO courants
• Description de votre conception d'UO

Ne sous-estimez pas l'importance, ni la complexité, de la conception d'une bonne structure d'Unité d'organisation (UO). J'ai découvert que les services informatiques s'orientent souvent vers un extrême ou l'autre ;

soit ils insistent trop sur la structure d'UO, soit ils n'y prêtent pas suffisamment attention. Dans un cas comme dans l'autre, cela peut être source de problèmes au niveau de votre modèle Active Directory®.

Accorder trop d'importance à la structure d'UO minimise l'importance d'autres aspects de la conception d'Active Directory, tels que la planification de la topologie de site ou la détermination de la taille des contrôleurs de domaine. D'autre part, lorsque la planification d'UO est reléguée au second plan, la Stratégie de groupe et la délégation en pâtissent.

L'une des excuses que j'ai entendues à l'occasion veut que comme la structure d'UO est flexible, elle peut être modifiée ultérieurement si elle ne convient pas. Il est vrai que la structure d'UO est flexible. Cependant, les administrateurs découvrent souvent qu'il est plus difficile de modifier la structure d'UO qu'ils ne l'avaient imaginé à l'origine. Bien entendu, il est possible d'ajouter de nouvelles UO, mais les anciennes ne sont pas faciles à nettoyer.

Une structure d'UO mal planifiée a tendance à vivre sa propre vie. Si un nouvel objet est créé dans l'annuaire et que l'administrateur ne sait pas où placer l'objet dans la structure d'UO, soit il créera une nouvelle UO, soit il placera l'objet à un endroit où il ne devrait pas se trouver. Ces deux scénarios recèlent de graves dangers. Il est facile de créer une nouvelle UO, mais difficile d'assurer son suivi à long terme. La création débridée d'UO se traduit par une structure d'UO chaotique, et il est facile de laisser des éléments s'insinuer dans l'annuaire sans être consignés. D'autre part, si vous ajoutez un objet à une UO existante à laquelle il n'appartient pas vraiment, le nouvel objet pourrait être associé à des stratégies qui ne le concernent pas ou des autorisations pour l'objet pourraient être déléguées à des utilisateurs non prévus.

Lors de la conception d'une structure d'UO, vous devez garder une équation fondamentale à l'esprit : simplicité + évolutivité = durabilité. Si votre conception est trop simple, elle risque de ne pas être évolutive et devra donc être souvent modifiée. Si votre conception est trop évolutive, tout sera compartimenté, ce qui entraîne trop de complexité.

Il existe trois principes clés liés à la stratégie de groupe, la délégation et l'administration d'objet qui peuvent contribuer à orienter votre décision de conception. Ces principes peuvent être résumés en trois questions que vous devez vous poser et qui vous permettront de vous assurer que la structure d'UO que vous créez résistera au temps et aux modifications organisationnelles :

1. Cette UO doit-elle être créée de sorte qu'un objet de stratégie de groupe (GPO) unique puisse lui être appliqué ?
2. Un groupe particulier d'administrateurs doit-il disposer d'autorisations pour les objets de cette UO ?
3. Cette nouvelle UO facilitera-t-elle l'administration des objets qu'elle contient ?

Si la réponse à l'une de ces questions est « oui », vous devez probablement créer l'UO. Si la réponse à ces trois questions est « non », vous devez réexaminer la disposition et déterminer si une conception différente pourrait être mieux appropriée. Mais avant de plonger plus avant et de vous montrer comment appliquer ces principes, je dois tout d'abord vous expliquer pourquoi ces principes sont importants.

Principe 1 : Stratégie de groupe

Le premier principe de la conception d'UO est de tenir compte des objets de stratégie de groupe qui seront appliqués à une UO. Un GPO vous permet de configurer des paramètres pour les utilisateurs et les ordinateurs de façon applicable. Vous pouvez définir plusieurs GPO dans Active Directory et les appliquer au domaine entier, à diverses UO ou même à des sites du domaine. Les GPO sont divisés en deux catégories : une pour les utilisateurs et une pour les ordinateurs.

Des stratégies ordinateur et des stratégies utilisateur peuvent être définies dans le même GPO. La section Configuration utilisateur du GPO définit surtout l'environnement présenté à l'utilisateur lorsqu'il est connecté. Ces types de paramètres existent également dans la section Configuration ordinateur, mais cette section contient aussi d'autres paramètres liés à la sécurité de l'ordinateur, tels que les personnes autorisées à ouvrir une session localement sur l'ordinateur ou la façon dont les données sont chiffrées.

Voici certains principes de base à garder à l'esprit lors de la définition d'UO pour la prise en charge de GPO. Premièrement, le simple fait que des stratégies utilisateur et des stratégies ordinateur puissent être définies dans le même GPO ne signifie pas qu'il est judicieux de placer les objets utilisateur et ordinateur dans la même UO. La combinaison de ces deux types dans le même GPO rend l'application de GPO plus difficile à dépanner. Ceci devient évident lorsqu'une stratégie de bouclage est activée.

Deuxièmement, beaucoup oublient qu'il est possible d'appliquer des GPO au niveau du site et conçoivent donc leurs structures d'UO de sorte qu'elles modélisent la structure de leur site pour l'application de GPO. Il s'agit d'un modèle de conception d'UO courant, qui porte le nom de modèle géographique. Je parlerai davantage de ce modèle dans un instant. Il serait négligent de ma part de ne pas reconnaître que le modèle géographique possède une place dans la conception d'UO mais, comme vous le verrez plus tard, je ne pense pas que l'application de GPO devrait être la raison principale de l'implémentation de ce modèle.

En outre, lorsque vous réfléchissez à votre structure d'UO en termes de GPO, l'objectif devrait être d'éliminer la complexité. Assurez-vous que l'UO s'ajoute au flux d'héritage de GPO. Si votre UO contient des serveurs qui nécessitent la même stratégie que d'autres serveurs, envisagez de placer ces objets ordinateur sous une UO Serveurs plus vaste et de créer plusieurs UO pour les différents types de serveurs sous l'UO Serveurs (voir la figure 1). Ceci peut simplifier l'application des stratégies dans la mesure où chaque objet ordinateur des UO de niveau inférieur obtiendra la stratégie de l'UO Serveurs ainsi que toute autre stratégie spécifique à ce type particulier de serveur.

Figure 1** Création d'UO multiples pour différents types de serveurs **(Cliquer sur l'image pour l'agrandir)

Un autre principe fondamental consiste à s'assurer que vous ne créez ou ne liez pas inutilement plusieurs GPO. Avec un GPO, vous pouvez créer une stratégie et l'appliquer à plusieurs UO. Ceci est parfois utile, mais peut également être néfaste. Si vous devez modifier un paramètre de GPO et possédez un système trop complexe de GPO liés, vous pourriez accidentellement appliquer une modification aux mauvais objets. Plus vous créez de liens et plus il sera difficile de déterminer l'étendue d'une stratégie. De même, évitez de créer des stratégies supplémentaires avec les mêmes paramètres que d'autres stratégies. Si vous vous apercevez que vous le faites régulièrement, envisagez de modifier votre structure d'UO pour appliquer un nouveau modèle d'héritage de GPO.

Enfin, vous devriez presque toujours créer une nouvelle UO pour les objets utilisateur et ordinateur. Par défaut, les objets utilisateur et ordinateur sont placés dans des conteneurs, qui ne vous permettent pas de leur lier directement des GPO. Les GPO peuvent être appliqués aux conteneurs Utilisateurs et Ordinateurs du domaine, mais à moins que vous ne bloquiez l'héritage ailleurs, ces stratégies seront appliquées à tous les utilisateurs et ordinateurs du domaine. Dans Windows Server® 2003, vous pouvez utiliser les outils rediruser.exe et redircomp.exe pour modifier l'emplacement par défaut des objets utilisateur et ordinateur pour utiliser l'UO que vous avez créée pour eux.

Principe 2 : Délégation

Il est important de créer la structure d'UO d'une façon qui soit cohérente avec la façon dont les autorisations sont déléguées dans le domaine. Gardez à l'esprit que lorsque les autorisations sont déléguées dans Active Directory, les modifications d'autorisation sont apportées à l'objet uniquement. Par conséquent, si vous deviez donner à un utilisateur le contrôle total d'un objet ordinateur particulier, cette personne pourrait modifier les attributs de l'objet, mais ne disposerait pas de droits d'administrateur sur l'ordinateur.

Vous trouverez ci-après quelques pratiques recommandées concernant la délégation pour la conception d'une structure d'UO :

Concevez avec l'héritage d'autorisation à l'esprit Par exemple, imaginons que vous vouliez que les administrateurs de niveau 1 aient la possibilité de modifier le mot de passe de la plupart des comptes. Il existe un groupe spécial d'utilisateurs pour lesquels les administrateurs ne doivent pas avoir la possibilité de réinitialiser les mots de passe, mais les administrateurs doivent pouvoir modifier les noms complets de ces comptes.

Vous avez ici véritablement deux options. Le premier scénario consiste à créer deux UO parallèles distinctes et à séparer les utilisateurs spéciaux des utilisateurs standard. Cette approche implique cependant que si vous voulez modifier les options de délégation pour tous les utilisateurs, vous devez alors modifier ces autorisations dans deux emplacements distincts. Elle contredit également la pratique consistant à ne pas effectuer inutilement de liaisons multiples (voir la figure 2).

Figure 2** Maintenance de deux UO parallèles distinctes **(Cliquer sur l'image pour l'agrandir)

Le second scénario consiste à créer une UO imbriquée et à placer un refus d'autorisation explicite sur l'UO qui comporte des utilisateurs spéciaux. Tout spécialiste de la délégation vous dira qu'il est préférable de ne pas recourir à un refus explicite, mais en l'occurrence, vous devez choisir le moindre de deux maux (voir la figure 3). Vous pouvez dupliquer et maintenir les paramètres sur deux UO distinctes ou placer un refus explicite sur l'une des UO. À long terme, le refus explicite constitue la meilleure solution.

Figure 3** Utilisation d'un refus d'autorisation explicite **(Cliquer sur l'image pour l'agrandir)

Attention à AdminSDHolder Cet exemple fonctionne bien, sauf si les utilisateurs spéciaux appartiennent tous à l'un des groupes d'administrateurs (Administrateurs du domaine, Administrateurs du schéma, Administrateurs de l'entreprise ou Administrateurs) car les autorisations pour les comptes de ces groupes sont gérées différemment. L'idée générale est de ne pas donner à quelqu'un des autorisations de compte d'administrateur par accident.

Si vous créez une UO distincte pour les administrateurs, vous découvrirez que les autorisations que vous leur déléguez ne cessent de disparaître. Ceci est dû à AdminSDHolder, qui est un conteneur spécial qui applique sa liste de contrôle d'accès à chaque compte administrateur suivant un intervalle spécifié. Par conséquent, toute modification de délégation que vous apportez à un compte d'administrateur sera annulée si les modifications ne sont pas également apportées au conteneur AdminSDHolder. Vous ne devez donc pas séparer les comptes d'administrateurs des autres comptes uniquement à des fins de délégation. Il est toutefois préférable de séparer les comptes d'administrateurs pour la stratégie de groupe. Ceci est surtout vrai dans Windows Server 2008, où vous pouvez avoir plusieurs stratégies de mot de passe.

Principe 3 : Administration d'objet

L'UO doit faciliter l'administration des objets. Le regroupement d'objets dans la même UO peut souvent faciliter l'exécution de modifications en bloc. Le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory vous permet de modifier certains attributs d'une sélection d'objets multiples. Par conséquent, si vous devez régulièrement modifier un attribut d'un groupe d'objets, il est plus facile de le faire s'ils sont tous dans la même UO.

Ceci est également particulièrement utile si vous effectuez les mises à jour avec un script. Les langages de script facilitent considérablement l'énumération de tous les objets d'une UO et leur traitement un à un. L'autre option consiste à rechercher et à modifier chaque objet individuellement. Le simple fait de placer les objets dans la même UO pour l'administration peut parfois vous faire gagner des heures de travail inutile chaque semaine.

La séparation des objets en UO différentes en fonction de leur type permet également d'en faciliter l'administration. La création d'une UO distincte pour les objets imprimante ou les partages publiés permet de s'assurer que ces objets ne devront pas être filtrés lorsque vous procéderez à l'administration des autres objets de l'UO. Cette pratique s'aligne également sur la pratique consistant à ne pas regrouper les comptes d'utilisateur et d'ordinateur dans la même UO.

Choix d'un modèle

Maintenant que j'ai couvert les principes de la conception d'UO, je peux examiner de plus près certains modèles de conception courants. Notez qu'il existe bien plus de modèles que ceux que j'ai décrits ici. Vous n'êtes en outre pas limité à travailler dans les contraintes d'un modèle unique. Vous pouvez prélever des morceaux de chacun et créer votre propre modèle hybride qui répond à vos besoins particuliers.

Pratiquement tous les modèles peuvent fonctionner à petite échelle, mais lorsque votre entreprise grandit, votre capacité à conserver le contrôle de votre environnement s'amenuise. Veillez donc à d'abord tester soigneusement votre modèle dans un environnement de laboratoire adéquat. Gardez à l'esprit que si les structures d'UO peuvent facilement être modifiées au début, plus elles sont en place depuis longtemps, plus elles sont difficiles à modifier.

Le modèle superficiel

Le modèle superficiel doit son nom au fait qu'il est essentiellement plat. Dans ce modèle, quelques UO de haut niveau contiennent la majorité des objets (voir la figure 4). Ce modèle est surtout mis en place dans les petites entreprise dotées d'un service informatique réduit et d'un nombre de services réduit, ou lorsque le personnel a tendance à assumer plusieurs rôles simultanément. Je recommande généralement de ne pas aller au-delà de 10 sous-UO, bien que Microsoft indique une limite de 15 sous-UO avant que les performances soient pénalisées.

Figure 4** Le modèle superficiel possède quelques UO de haut niveau contenant la majorité des objets **(Cliquer sur l'image pour l'agrandir)

Si le responsable des ressources humaines est également responsable de la paie, il n'y a pas de raison de créer deux UO séparées pour Ressources humaines et Paie. Dans le modèle superficiel, tous les objets utilisateur peuvent être regroupés dans une grande UO Comptes ou peuvent être conservés dans le conteneur Utilisateurs par défaut. Vos objets utilisateur doivent au strict minimum être séparés de vos objets ordinateur.

Pour ce modèle, je recommande également d'aller un peu plus loin et de séparer les postes de travail des serveurs. Vous pouvez alors appliquer des stratégies de groupe différentes sans devoir définir un GPO qui utilise une requête Windows® Management Instrumentation (WMI) pour filtrer les postes de travail ou les serveurs.

L'utilisation d'une structure d'UO large plutôt que profonde offre notamment l'avantage que les recherches dans Active Directory s'exécuteront plus rapidement. Je recommande généralement de ne pas aller au-delà de 10 sous-UO. Dans ce modèle, votre contrôle des objets n'est pas très granulaire, mais si vous gérez les objets d'une petite entreprise, vous n'aurez pas besoin d'un contrôle à granularité fine. Ainsi, ce modèle serait difficile à utiliser avec succès dans une grande entreprise, mais il fonctionne très bien dans les petites entreprises.

Modèle géographique

Dans le modèle géographique, vous créez des UO distinctes pour les différentes régions géographiques. Ce modèle est mieux adapté aux organisations qui possèdent des services informatiques décentralisés mais ne souhaitent pas subir les coûts associés à l'utilisation de plusieurs domaines (voir la figure 5).

Figure 5** Le modèle géographique sépare les UO par région géographique **(Cliquer sur l'image pour l'agrandir)

Imaginons que vous possédez des bureaux à Atlanta, Baltimore et Seattle. Si chaque site gère ses propres utilisateurs et ses propres ordinateurs, ceci peut être idéal sur le plan de la délégation. Mais que se passe-t-il si un utilisateur de Seattle s'envole pour Baltimore pour une formation et verrouille son compte ? Le personnel informatique de Baltimore peut ne pas être en mesure d'aider cet utilisateur si les autorisations pour le compte de cet utilisateur ne lui ont pas été déléguées. S'il est 8 heures du matin à Baltimore, il est 5 heures du matin à Seattle, ce qui signifie que l'utilisateur peut devoir attendre plusieurs heures avant de pouvoir entrer en contact avec quelqu'un des bureaux de Seattle et d'obtenir de l'aide.

Certaines entreprises internationales utilisent un modèle « héliotrope », où les appels au support technique sont transférés à un site situé dans un fuseau horaire où l'heure actuelle correspond à une heure ouvrable. Ceci signifie que l'entreprise ne doit pas assurer un support technique 24 heures sur 24 pour chaque site mais est toujours en mesure de fournir de l'aide aux employés travaillant tard, par exemple pour le déverrouillage de leur compte, lorsque cela s'avère nécessaire.

Si vous avez adopté ce modèle, la création d'UO distinctes en fonction de l'emplacement géographique n'est probablement pas le meilleur choix pour vos besoins opérationnels. En effet, cela vous obligerait à déléguer des autorisations distinctes à chaque support technique régional pour chaque UO d'utilisateurs. Cependant, si chacun de vos sites possède son propre service informatique, le modèle géographique peut en fait constituer un bon modèle pour votre organisation.

Le modèle géographique est également difficile à utiliser dans un domaine unique en raison de la nature du fonctionnement du domaine. Un domaine a tendance à avoir un modèle de sécurité différent des autres domaines. Ceci est plus évident lorsque vous examinez une application à l'échelle de l'entreprise, telle que Microsoft® Exchange.

Le serveur Exchange d'Atlanta peut avoir des stratégies de message différentes, mais les mêmes GPO sont probablement appliqués à tous les serveurs Exchange de l'entreprise. Si c'est le cas, le fait de placer les serveurs Exchange dans des UO distinctes en fonction de la région vous obligera à lier inutilement les mêmes GPO à plusieurs UO. Sur le plan de la délégation, vous devez déterminer si les administrateurs Exchange ont vraiment besoin d'autorisations uniques pour les objets ordinateur en ce qui concerne les serveurs Exchange. Dans la plupart des cas, les objets ordinateur qui sont fractionnés en UO géographiques le sont pour des raisons de stratégie de groupe, en non pour des raisons de délégation.

Modèle basé sur les types

Le modèle basé sur les types classe les objets selon leur fonction (voir la figure 6). Lorsque vous avez créé votre dernier objet utilisateur, était-ce pour un compte utilisateur standard, un compte d'administrateur ou un compte de service ? Dans un modèle basé sur les types, chacun de ces objets est traité différemment.

Figure 6** Le modèle basé sur les types regroupe les objets selon leur fonction **(Cliquer sur l'image pour l'agrandir)

Dans la plupart des cas, pour les stratégies, vous devez distinguer les différentes classifications d'objets utilisateur. Vos stratégies diffèreront vraisemblablement en fonction du type de compte utilisateur. Par exemple, autoriser des personnes à ouvrir une session sur un ordinateur avec un compte de service constitue généralement une mauvaise pratique. Les mots de passe des comptes de service sont habituellement partagés entre un grand nombre de personnes et si quelqu'un ouvre une session avec un compte de service, son identité demeure anonyme. Si quelque chose venait à se produire, vous auriez du mal à dépister l'utilisateur qui était connecté lorsque l'événement est survenu. Dans cet exemple, vous devrez définir sur les comptes de service une stratégie empêchant l'ouverture de session interactive. Cela correspond bien au modèle hiérarchique illustré à la figure 3.

Dans ce cas de figure, vous pourriez utiliser l'héritage de GPO à votre avantage. Par exemple, vous pourriez avoir une stratégie Tous les utilisateurs faisant référence aux stratégies en place pour tous les objets utilisateur. Vous pourriez en outre avoir une stratégie séparée et distincte pour les comptes de service, qui s'appuie sur la stratégie Tous les utilisateurs. Cette approche permet de garantir que vos comptes de service ont le même jeu de stratégies de base que tous les autres comptes, ainsi que les restrictions d'ouverture de session spécifiques.

Cette approche fonctionne également bien pour la délégation, où vous utilisez l'héritage d'autorisation à la place de l'héritage de GPO. Supposez que vous vouliez que vos administrateurs de niveau 2 aient la possibilité de réinitialiser les mots de passe pour tous les comptes sauf ceux des administrateurs de niveau 3. Avec une structure d'UO plate, vous seriez obligé de déléguer les autorisations à chaque UO contenant des comptes utilisateur. En revanche, dans un modèle basé sur les types avec une structure hiérarchique, vous pouvez donner au niveau 2 des autorisations « Réinitialiser le mot de passe » pour l'UO Comptes puis, dans l'UO de niveau 3, vous pouvez simplement déshériter les autorisations ou même définir un refus explicite de réinitialisation des mots de passe pour le niveau 2.

Ceci fonctionne également bien pour les objets ordinateur. Les serveurs et les postes de travail peuvent être séparés pour permettre l'application de stratégie différentes à chacun d'entre eux. Les serveurs peuvent être subdivisés en fonctions (voir la figure 1). Dans cette conception, vous pouvez définir sur l'UO Serveurs une stratégie de haut niveau affectant tous les serveurs et néanmoins définir des stratégies individuelles pour chaque UO de niveau inférieur.

Imaginons par exemple que vous disposez d'un compte de service Microsoft Operations Manager (MOM). Avec ce modèle multiniveau, vous pouvez créer un GPO MOM et l'appliquer à l'UO Serveurs MOM. Dans ce GPO, vous pouvez ensuite octroyer des droits au compte de service MOM pour l'ouverture de session en tant que service. Ceci s'appliquerait uniquement aux serveurs MOM de cette UO. Les serveurs MOM obtiendront toujours le GPO Serveurs de l'UO Serveurs de niveau supérieur, mais ils obtiendront également le GPO MOM spécialisé, qui est lié à l'UO MOM.

Documentation de la conception

Il peut être très gratifiant de concevoir une structure d'UO capable de résister aux nombreuses modifications que rencontre un environnement Active Directory. Mais vous devez disposer d'une méthode de suivi des caractéristiques dynamiques de l'UO. À défaut, vous pourriez rapidement perdre le contrôle de votre environnement. Lorsque des modifications doivent être effectuées et qu'une UO doit être ajoutée ou supprimée, des recommandations précises doivent être en place de façon à garantir que votre modèle continue de respecter votre modèle de conception, en adhérant aux trois principes directeurs. C'est pourquoi votre conception doit être bien documentée.

Microsoft fournit trois guides de documentation dans le kit de ressources de Windows Server. Ces guides sont suffisants si votre structure est une infrastructure solide que vous ne comptez pas beaucoup modifier. Toutefois, la plupart des entreprises ont une structure très dynamique qui évolue fréquemment. Voici donc quelques conseils importants qui vous aideront à garantir que votre structure d'UO est bien documentée et capable de prendre en charge un environnement dynamique.

Assurez-vous que toutes les informations sont pertinentes Je suis fortement convaincu qu'une documentation doit avoir un but. Trop de documents opérationnels contiennent tant d'informations superflues qu'il est difficile de trouver ce qui est important. Ne tombez pas dans le piège de la création de documentation à seul but de documentation. Avez-vous vraiment besoin d'inclure le nombre d'objets de chaque UO ou chaque Entrée de contrôle d'accès (ACE) de la Liste de contrôle d'accès de l'UO ? Pour la documentation d'UO, les informations suivantes seront habituellement suffisantes :

• Nom de l'UO
• Brève description
• Qui l'a créée, ou qui contacter pour obtenir plus d'informations ou apporter des modifications
• Date de création

Ne rendez pas les mises à jour difficiles Si vous devez laborieusement mettre à jour un document Microsoft Word complexe, vous prendrez probablement du retard dans la mise à jour de la documentation. Vous penserez que ce n'est pas grave si vous remettez à plus tard la saisie de petites modifications puisque vous savez que vous aurez bientôt une mise à jour plus conséquente à entrer d'un seul coup. Malheureusement, les gens oublient souvent ces petites modifications ou les remettent sans cesse à plus tard, si bien que la tâche n'est jamais effectuée. La mise à jour du document doit donc être très facile, afin de ne pas vous décourager. Dans la plupart des cas, une simple feuille de calcul Microsoft Excel® avec quelques colonnes suffira.

Faites vos commentaires directement sur l'objet Les objets d'UO ont un attribut de description dans lequel vous pouvez entrer des commentaires. Au lieu d'écrire des commentaires dans le document de conception, envisagez de les mettre dans l'attribut de description afin que d'autres puissent déterminer directement l'objectif de l'UO. Si devez inclure plus de détails, mettez alors une courte description dans l'attribut de description et incluez davantage de détails dans la documentation de l'UO.

Automatisez la documentation Il est possible d'écrire un script afin de décharger le contenu de la structure d'UO dans un fichier texte, une feuille de calcul Excel ou même un fichier HTML. Ce script pourrait être exécuté chaque nuit dans le cadre d'une tâche planifiée. Ceci peut être très utile si vous incluez des commentaires dans le champ de description de l'UO. Il suffit alors de vidanger l'attribut de description dans le fichier pour avoir une structure d'UO entièrement documentée et toujours à jour. Si vous créez un nouveau fichier chaque fois que le script est exécuté, au lieu de remplacer le document existant, vous pouvez garder un historique des modifications de la structure d'UO au fil du temps.

Malheureusement, la plupart des administrateurs ne se rendent pas compte de l'importance d'une bonne documentation de structure d'UO, jusqu'à ce qu'ils en aient vraiment besoin. Il est alors 3 h du matin et pratiquement impossible de déterminer quelles autres UO ont été supprimées accidentellement sans exécuter une restauration.

N'attendez pas que cela vous arrive. Je recommande fortement d'adopter une approche proactive dans ce domaine, de d'entamer une documentation d'UO dès la conception et de désigner une personne responsable de sa mise à jour. Si vous suivez la règle consistant à rendre la documentation facile à mettre à jour, la mise à jour de la documentation s'effectuera sans heurt. 

Ken St. Cyr est consultant pour Microsoft et compte 10 ans d'expérience dans le secteur informatique. Il conçoit et implémente des solutions d'annuaire basées sur Active Directory depuis sa création.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.