Gestion structurée du schéma Active Directory chez Microsoft

Création d'un workflow de changement cohérent et normalisé

Paru le 01 septembre 2005 | Dernière mise à jour le 02 décembre 2005

Livre blanc technique

Sur cette page

Résumé
Introduction aux changements de schéma
Environnement Microsoft Active Directory
L'architecture du système de gestion des changements
Parcours du processus de changement
Atténuation des risques
Méthodes recommandées et normes IdM
Conclusion
Pour plus d'informations

Résumé

Microsoft® Active Directory® (AD) offre une infrastructure globale de gestion des identités et des accès. En outre, Active Directory offre des fonctionnalités et une extensibilité de l'annuaire, que les développeurs d'applications peuvent et doivent utiliser lorsque des fonctionnalités d'annuaire sont requises dans une application en cours de développement. L'utilisation de la fonctionnalité AD centralise et simplifie l'administration de l'annuaire. Active Directory réduit en outre les coûts de développement et améliore la compatibilité des données. Par exemple, l'utilisation de l'interopérabilité entre le service d'authentification et le service d'autorisation Active Directory dans une application permet d'atteindre deux objectifs. Il supprime la nécessité de créer une base de données de sécurité supplémentaire et simplifie la gestion de la sécurité d'entreprise.

Pour utiliser les fonctionnalités Active Directory afin de prendre en charge des processus métier ou de nouveaux outils, les développeurs d'applications étendent le schéma Active Directory. Le schéma est un composant AD qui définit tous les objets et attributs utilisés par le service d'annuaire pour stocker les données. En général, un administrateur de schéma apporte des changements indépendamment, ou le processus d'installation des logiciels automatise les changements. Microsoft recommande d'institutionaliser un système de gestion des changements afin d'optimiser les résultats d'un changement de schéma.

Ce document décrit l'approche du département Microsoft IT s'agissant de la gestion du processus de changement de schéma dans un workflow structuré. Le workflow structuré garantit la conception, l'implémentation, l'utilisation, l'appartenance et la sécurité de chaque changement déployé dans chaque forêt. L'expérience de Microsoft IT montre qu'un système de gestion des changements robuste et soigneusement planifié basé sur MOF (Microsoft® Operations Framework) contribue à une infrastructure de schéma hautement gérable. Avec MOF, Microsoft IT a créé un processus à cinq phases incluant la justification, l'évaluation, le test, les étapes intermédiaires et l'implémentation. En planifiant soigneusement et en déployant progressivement les changements de schéma, tout en gérant les communications des clients et leurs attentes, Microsoft IT parvient à gérer le processus de changement de schéma Active Directory sans heurts, limitant ainsi les risques. Grâce à un processus cohérent et prévisible, les parties peuvent se concentrer sur les objectifs métier.

Les entreprises qui souhaitent garantir un résultat optimal pour chaque changement de schéma via un workflow structuré pourront tirer parti de ce document. Ce document s'adresse aux professionnels de l'informatique, aux architectes et aux professionnels des services d'annuaire, déjà familiarisés avec les fonctionnalités de Windows, Active Directory et les questions de gestion d'identité. Le document offre un examen approfondi de la solution de gestion des changements de schéma chez Microsoft IT. Il comporte des méthodes recommandées et des considérations relatives au déploiement. Les adopteurs peuvent appliquer les recommandations de conception, principes et techniques de gestion des changements à la plupart des environnements informatiques à l'échelle de l'entreprise, à l'aide de produits Microsoft. Cependant, étant donné que chaque environnement d'entreprise est unique, les adopteurs ne doivent pas utiliser ce document comme guide de procédure. Chaque organisation doit adapter les informations qui suivent à ses propres besoins.

Remarque :* *Pour des raisons de sécurité, les exemples de noms de forêts, domaines, ressources internes, organisations et fichiers développés en interne sont fictifs et ne représentent pas les noms réels utilisés chez Microsoft et sont proposés à des fins d'illustration uniquement.

Introduction aux changements de schéma

Les développeurs d'applications Windows expérimentés utilisent ou étendent les fonctionnalités Active Directory existantes lors de la création d'applications nécessitant des fonctionnalités d'annuaire. Cela inclut la gestion des identités, la configuration centrale et la gestion des accès, ou les fonctionnalités générales d'annuaire. L'extension ou l'utilisation des fonctionnalités Active Directory permet à l'application d'utiliser le sous-système de sécurité existant ainsi que les données partagées dans l'annuaire global. Étant donné que cela permet d'optimiser l'efficacité des ressources, Microsoft recommande d'utiliser ou d'étendre les fonctionnalités Active Directory existantes, plutôt que de créer une nouvelle base de données d'identité en dehors d'Active Directory.

Remarque : L'extension du schéma* *fait référence au processus de modification ou de mise à jour du schéma.

Étant donné l'impact potentiel sur Active Directory, il est important de s'assurer que le changement de schéma n'entraîne pas de résultats imprévisibles. Les entreprises peuvent exécuter les changements de schéma sans heurts via la planification, les tests et la gestion des attentes client.

Notions fondamentales des schémas

Le schéma est un composant AD qui définit tous les objets et attributs utilisés par le service d'annuaire pour stocker les données. Le service d'annuaire utilise des objets comme unités de stockage. Chaque fois que le service d'annuaire traite des données, il interroge le schéma afin d'obtenir une définition d'objet appropriée. En fonction de la définition d'objet dans le schéma, le service d'annuaire crée l'objet et stocke les données. Par exemple, lorsqu'un administrateur crée un nouvel objet utilisateur, Active Directory utilise les définitions du schéma pour créer et configurer l'objet utilisateur par défaut. La structure physique du schéma est constituée des définitions d'objet stockées dans leur propre partition de schéma dans l'annuaire. Tous les domaines d'une forêt partagent le même schéma.

Les définitions d'objet contrôlent les types de données que les objets peuvent stocker, ainsi que la syntaxe des données. Comme le montre la figure 1, les objets de sous-classe héritent des caractéristiques des classes situées au-dessus. À partir de ces informations, le schéma garantit que tous les objets sont conformes à ses définitions standard. Par conséquent, Active Directory peut stocker, extraire et valider les données qu'il gère, indépendamment de l'application qui génère les données. Seules les données dont le schéma comporte une définition d'objet existante peuvent être stockées dans l'annuaire. Si un nouveau type de données doit être stocké dans l'annuaire, les administrateurs du schéma doivent d'abord créer une nouvelle définition d'objet de données dans le schéma.

Figure 1. Classes d'objet de schéma avec héritage

Modifications de schéma

Normalement, les utilisateurs n'interagissent pas directement avec le schéma au quotidien. Active Directory utilise le schéma pour permettre la création des objets stockés dans l'annuaire. Les utilisateurs interagissent avec ces objets et non avec le schéma. Les administrateurs interagissent directement avec le schéma lorsqu'ils y apportent des modifications, en ajoutant des définitions ou en modifiant des définitions existantes. Étant donné que les listes de contrôle d'accès (ACL, Access Control Lists) protègent les objets de schéma, seuls les utilisateurs autorisés peuvent modifier le schéma.

Extensions de schéma

Le schéma par défaut est un ensemble élémentaire de classes et d'attributs dans une forêt Active Directory. Lorsque les définitions de classe et d'attribut existantes du schéma ne satisfont pas aux besoins d'une organisation, cette dernière peut ajouter ou modifier des objets de schéma afin d'étendre le schéma. Les développeurs et administrateurs expérimentés peuvent étendre le schéma en définissant de nouvelles classes et de nouveaux attributs pour les classes existantes, afin de stocker un nouveau type d'information dans l'annuaire.

Les raisons pour lesquelles les administrateurs sont généralement amenés à modifier le schéma sont les suivantes :

• Applications packagées utilisant les fonctionnalités Active Directory. L'installation d'une application qui utilise des fonctionnalités Active Directory peut modifier le schéma en ajoutant des définitions d'objet personnalisées pour stocker les informations dans l'annuaire. Par exemple, Microsoft Office Live Communications Server 2003 ajoute de nouvelles classes d'objet et des attributs complémentaires au schéma afin de gérer la détection de présence.

• Applications internes utilisant les fonctionnalités Active Directory. L'installation d'une application personnalisée utilisant les fonctionnalités Active Directory peut nécessiter des modifications de schéma.

Portée de modification de schéma

L'extension du schéma est une opération avancée qui nécessite une planification et des tests soigneux. Le schéma est fondamental, à la fois pour l'utilisation et l'exploitation d'Active Directory dans une forêt. Par conséquent, les entreprises doivent bien réfléchir avant d'apporter des extensions ou des changements au schéma de base fourni avec le système, afin d'éviter les problèmes. Les changements de schéma peuvent affecter des paramètres importants tels que l'indexation de la base de données d'annuaire, la disponibilité des données du catalogue global, ainsi que la taille et l'intégrité des bases de données Active Directory.

En général, l'annulation des modifications du schéma n'est pas possible. Lorsque vous envisagez des modifications, tenez compte des éléments suivants :

• Les extensions de schéma sont globales. Le contrôleur de schéma réplique tout changement apporté au schéma sur chaque contrôleur de domaine de la forêt.

• Les classes de schéma liées au système ne sont pas modifiables. Les administrateurs système ne peuvent pas modifier les classes système par défaut dans le schéma Active Directory. Cependant, ils peuvent changer les classes système facultatives qu'ils ont ajoutées.

• Les classes et attributs de schéma ne peuvent pas être supprimés. Après l'ajout d'une classe ou d'un attribut au schéma, les administrateurs peuvent désactiver la classe ou l'attribut en le (la) marquant comme défunt(e). Bien que les administrateurs ne puissent pas supprimer totalement la classe ou l'attribut, ils peuvent modifier certains attributs ou certaines propriétés de classe après la création. Par exemple, si un objet existant doit changer un attribut inchangeable, les administrateurs peuvent le faire en marquant l'objet initial comme défunt, puis en changeant le nom distinctif relatif (RDN, Relative Distinguished Name) de l'objet. Cela permet la création d'une nouvelle instance d'objet avec la valeur d'attribut corrélée. Pour plus d'informations, reportez-vous au site suivant : https://msdn.microsoft.com/library/en-us/ad/ad/disabling_existing_classes_and_attributes.asp.

Avec la planification soigneuse des changements de schéma, associée à la communication avec les clients et à la gestion des attentes, les administrateurs peuvent gérer sans heurts le processus de changement de schéma Active Directory, en limitant au maximum les risques pour l'annuaire.

Gestion des changements de schéma

L'extension du schéma est à la fois puissante et facile. Un système de gestion des changements correctement conçu aide les organisations à appliquer les changements de schéma de manière cohérente et prévisible. Cela permet aux organisations de se concentrer sur les objectifs métier ou opérationnels. Il est très important pour une organisation d'établir un processus formel de gestion des changements de schéma avant de procéder à l'extension du schéma.

Conception du processus

Un processus de gestion des changements bien conçu offre un workflow standard qui garantit des résultats optimaux. Une fois le processus en place, les responsabilités et attentes sont claires pour chaque partie. Le processus doit fournir des instructions détaillées pour le workflow complet. Cela va de la distribution initiale des demandes de changement à la détermination de qui communique à toutes les parties concernées que le processus s'est déroulé avec succès.

Le processus Microsoft IT

Ayant déployé le service d'annuaire Active Directory dans le cadre de Microsoft Windows 2000 Server, Microsoft a toujours soutenu Active Directory et le développement de logiciels utilisant les fonctionnalités Active Directory. Dans la mesure où Microsoft est une entreprise de développement de logiciels, les changements de schéma Active Directory sont plus fréquents chez Microsoft que sur la plupart des sites d'entreprise. Les logiciels développés par Microsoft utilisent généralement les fonctionnalités Active Directory. Par conséquent, les installations logicielles et tests internes de Microsoft IT impliquent souvent des changements de schéma. En outre, étant donné que Microsoft IT utilise ses propres logiciels en version bêta dans son environnement de production, dans le cadre du processus de développement, ils doivent installer plusieurs versions provisoires de chaque programme, chacune pouvant nécessiter une mise à jour du schéma.

Microsoft IT a procédé à au moins 25 changements de schéma uniques au cours des cinq dernières années, avec généralement un déploiement dans plusieurs forêts. Au cours de cette période, ils ont créé un workflow qui a évolué vers un processus de changement normalisé. Sur la base de cette expérience importante, Microsoft IT a normalisé le workflow en un système officiel de gestion des changements, pour tous les changements de schéma chez Microsoft. Le processus de gestion des changements de schéma de Microsoft IT a contribué à la normalisation des changements de schéma et offre des résultats optimaux avec les principaux logiciels, notamment :

• Exchange Server 2003. Microsoft IT a installé six versions provisoires d'Exchange pour les besoins des tests et a changé à chaque fois le schéma sur quatre à six environnements de production. Ils ont pu effectuer ces opérations sans aucune perturbation du réseau.

• DPM (Data Protection Manager). Microsoft IT a installé la version provisoire de DPM dans quatre environnements de production. Le changement de schéma a permet d'activer une fonctionnalité permettant aux utilisateurs de récupérer leurs propres fichiers dans les répertoires partagés du serveur de fichiers.

• Avaya Unified Messaging. Microsoft IT a déployé les extensions Avaya dans trois environnements de production, sans problèmes.

Environnement Microsoft Active Directory

Pour comprendre le processus de changement de schéma chez Microsoft, il est important de comprendre l'environnement Active Directory, l'infrastructure de gestion des identités et des accès prise en charge, ainsi que les équipes qui assurent le support Active Directory.

Vue d'ensemble de l'infrastructure

L'infrastructure Microsoft de gestion des identités et des accès est semblable aux environnements d'autres grandes entreprises. L'infrastructure offre un ensemble de services essentiels pour l'environnement informatique Microsoft. Active Directory est la base de l'infrastructure d'identité dans chaque forêt. Il offre la gestion centralisée des identités afin de préserver la disponibilité et la sécurité des ressources. L'infrastructure sert également de base pour les logiciels de gestion des identités développés par Microsoft.

Configuration multiforêt

Comme le montre la figure 2, la gestion centralisée des forêts multiples caractérise l'infrastructure d'identité de Microsoft.

Figure 2. Organisation de l'infrastructure d'identité de Microsoft

Microsoft IT gère intégralement plusieurs de ces forêts. Ils gèrent les autres forêts conjointement avec l'équipe en charge de chaque forêt. Chaque forêt partage une relation d'approbation unidirectionnelle ou bidirectionnelle avec la forêt d'entreprise. 70 % des applications utilisées chez Microsoft résident sur la forêt d'entreprise. Ces forêts contiennent plus de 35 banques d'identités. Les banques d'identités sont AD, SAP, Siebel, Group Membership Manager, Account Manager Application et diverses autres. L'équipe de gestion des identités de Microsoft IT utilise Microsoft Identity Integration Server (MIIS) 2003 avec Service Pack 1 (SP1) pour synchroniser les données d'identité entre plusieurs banques d'identités.

Microsoft nécessite plusieurs forêts, pour différentes raisons. Les applications logicielles en cours de développement, telles que les versions préliminaires d'Exchange, nécessitent leur propre forêt afin d'éviter toute interférence avec la forêt d'entreprise au cours des premiers déploiements et tests. Les forêts existent également pour des raisons de sécurité lors de la collaboration avec des partenaires externes via un extranet. En outre, étant donné les exigences légales associées à la joint-venture MSNBC, cette dernière gère une forêt distincte. Enfin, Microsoft IT crée spécifiquement certaines forêts pour les départements de l'entreprise, par exemple le département MSN.

Configuration réseau

Microsoft comporte 215 contrôleurs de domaine à travers le monde, dans les cinq forêts gérées par Microsoft IT. Cela concerne 16 domaines, 138 contrôleurs de domaine de forêt et 30 contrôleurs de domaine d'extranet. Il existe 184 sites Active Directory, dont 63 avec des contrôleurs de domaine, qui gèrent quotidiennement 60 000 ouvertures de session unique sur la forêt. La forêt de l'entreprise comporte neuf domaines pour un total de plus d'un million d'objets et une taille moyenne du catalogue global de 9 gigaoctets (Go). Le réseau offre une bande passante moyenne de 1,5 mégaoctet (Mo) par seconde et une bande passante minimale de 256 kilo-octets (ko) par seconde.

Topologie de réplication

Microsoft IT a configuré les forêts pour une réplication toutes les heures avec cinq sauts entre les sites, offrant une latence maximale de cinq heures. Ils gèrent une topologie de site complexe correspondant à leur topologie réseau, avec plus de 300 sites à travers le monde. L'essentiel des changements administratifs, y compris tous les changements de schéma, ont lieu à Redmond, Washington, États-Unis. Redmond est le point central, avec une latence maximale de trois heures vers tous les autres sites.

Environnement de support des changements de schéma

Microsoft IT est responsable de toutes les activités liées à l'exécution et à la maintenance des systèmes informatiques Microsoft à travers le monde. Dans l'organisation Microsoft IT, l'équipe de gestion des identités (IdM, Identity Management) et l'équipe d'ingénierie d'infrastructure (IEng, Infrastructure Engineering) sont responsables d'Active Directory. L'équipe IdM est responsable de la gestion des identités entre forêts et, en particulier, de la gestion des schémas Active Directory. L'équipe IEng gère les contrôleurs de domaine et la réplication.

Organisation de Microsoft IT

Microsoft IT est responsable des opérations globales et de la fourniture des services informatiques à l'ensemble de l'organisation Microsoft. Microsoft IT dirige toutes les activités liées à l'exécution et à la maintenance des systèmes informatiques à travers le monde. Ils gèrent l'infrastructure technologique en plus des systèmes informatiques d'entreprise et marketing. Cela concerne la production, la distribution et d'autres systèmes internes essentiels. L'objectif de Microsoft IT est l'excellence dans les opérations métier. Pour cela, ils sont à la pointe de la conception et de l'intégration des stratégies, processus et architecture de l'entreprise.

Microsoft IT offre une gamme étendue de services, incluant le support serveur et utilisateur, la gestion des télécommunications, les opérations réseau et la sécurité des informations. Ce rôle inclut la gestion de la connectivité pour plus de 300 000 PC à travers le monde. Microsoft IT garanti que les 63 000 employés et les 35 000 sous-traitants, répartis dans 90 pays et sur plus de 400 sites Microsoft, peuvent accéder aux services et ressources du réseau de l'entreprise, 24 heures sur 24 et 7 jours sur 7.

Dans la mesure où l'activité principale de Microsoft est la conception de logiciels, Microsoft IT a une deuxième mission, unique parmi tous les fournisseurs globaux. Microsoft IT est le premier adopteur des technologies de l'entreprise et est en charge des tests et du déploiement des produits Microsoft tels que SharePoint™, Windows Server 2003, Microsoft Identity Integration Server 2003 et Exchange Server 2003, avant leur commercialisation. Ce processus de déploiement avant commercialisation est désigné chez Microsoft sous le nom « Eating our own dog food » (ce qui signifie littéralement « manger la nourriture de son chien »).

En utilisant les produits en version bêta dans l'environnement d'entreprise, Microsoft IT teste de manière approfondie les produits en situation et évalue leur valeur ajoutée. Cela permet d'affiner la configuration finale du produit et d'établir des méthodes recommandées afin de guider les déploiements des produits par les clients. L'environnement rigoureux de test d'entreprise permet à Microsoft d'avoir la certitude de proposer aux clients des produits de qualité. À partir des leçons tirées à l'issue du processus, les groupes produit peuvent ainsi améliorer le produit avant sa version finale.

Équipe IdM (Identity Management) de Microsoft IT

L'équipe IdM gère l'infrastructure de gestion des identités de Microsoft. L'équipe gère l'ensemble des applications et outils associés, les comptes et les groupes, ainsi que le workflow pour les ajouts ou les changements.

L'équipe IdM gère tous les comptes utilisateur. Cela comprend les utilisateurs normaux, les utilisateurs bénéficiant d'un accès élevé, les comptes de service et les comptes intégrés. Ils gèrent également les groupes, notamment les groupes administratifs, ainsi que les applications internes associées. En outre, l'équipe IdM gère les unités d'organisation, les objets stratégie de groupe et les approbations. Ils supervisent la synchronisation entre forêts avec MIIS 2003 SP1 afin de synchroniser divers types d'objet, notamment les utilisateurs et groupes, les sites et sous-réseaux, ainsi que les files d'attente d'impression. Cela permet l'utilisation cohérente des ressources et des fonctionnalités des applications lorsque les utilisateurs passent d'une forêt à une autre.

Les responsabilités de l'équipe IdM incluent la gestion du schéma Active Directory. Étant donné que l'équipe IdM est propriétaire du contenu de l'annuaire, elle gère les données des annuaires comme une instance logique unique. Pour préserver la cohérence entre forêts, lorsque l'équipe IdM change le schéma dans une forêt, elle le change généralement dans toutes les autres forêts. Si l'équipe IdM est en charge du processus de changement de schéma, elle ne gère cependant pas tous les aspects du processus. Par exemple, elle ne gère pas physiquement les contrôleurs de domaine, la topologie de réplication ou les applications. Ces aspects sont gérés par l'équipe IEng et par les propriétaires de ces applications spécifiques.

Équipe IEng (Infrastructure Engineering)

L'équipe IEng est responsable des serveurs d'infrastructure essentiels de Microsoft IT, lesquels incluent les contrôleurs de domaine où réside Active Directory. L'équipe gère les performances, l'administration et la configuration des serveurs. En outre, l'équipe IEng détermine où placer les contrôleurs de domaine sur le réseau, en fonction des dépendances d'application et de la connectivité réseau. L'équipe IEng gère la topologie de réplication des données. Leur implication dans le processus de changement de schéma provient des responsabilités concernant la topologie de réplication des données. L'équipe IEng collabore avec l'équipe IdM afin de garantir la réussite de la réplication des changements de schéma dans chaque forêt gérée.

Gestion des schémas Microsoft

Le développement logiciel est le premier contributeur au volume des changements de schéma chez Microsoft. Chaque fois qu'une unité installe ou met à jour un logiciel utilisant des fonctionnalités Active Directory et modifie le schéma, l'unité doit passer par le processus de gestion des changements de schéma. Microsoft IT assure le support des efforts de développement de chaque équipe produit, en testant leurs versions bêta dans l'environnement de production Microsoft. Cela complique encore la gestion des schémas, car Microsoft IT installe souvent plusieurs versions provisoires au cours du processus de développement, ce qui augmente encore le nombre de changements de schéma.

Système de gestion des changements

L'équipe IdM a créé un site Web interne qui guide à travers le processus toute personne demandant un changement de schéma. Le site offre un aperçu du processus, des liens vers les informations associées, ainsi qu'un formulaire de changement de schéma en ligne. Le demandeur remplit le formulaire, lequel est examiné par l'équipe IdM. L'équipe IdM évalue les justifications métier une fois qu'elle a déterminé que le demandeur a correctement rempli le formulaire et que tous les problèmes ont été résolus. Si la demande est acceptable d'un point de vue métier, l'équipe IdM la place dans la file d'attente des changements. Après l'approbation du formulaire de demande, elle crée un document de package de schéma. Le package de schéma est un document actif qui suit le changement du début à la fin. L'équipe IdM entre toutes les données complémentaires et approbations à chaque étape du processus. Lorsque l'équipe IdM apporte des modifications au schéma, l'équipe IEng suit la réplication dans les forêts et garantit la précision. Enfin, l'équipe IdM place le formulaire, les scripts et toutes les informations associées dans un dossier, qu'elle stocke dans un emplacement sécurisé en vue de sa sauvegarde.

Changements de schéma

Le système de gestion des changements de schéma IdM gère les opérations suivantes :

• Extensions. Chez Microsoft, le changement de schéma le plus courant est une extension. Parmi les trois options de gestion des schémas, une extension est plus simple et son impact potentiel est plus limité. L'ajout de nouvelles définitions, plutôt que le changement des définitions existantes, nie la possibilité d'affecter les applications existantes.

• Modifications. Les modifications de schéma sont beaucoup moins fréquentes que les extensions. Si un objet existant est changé, il peut en résulter un impact négatif sur les applications qui dépendent de cet objet. Par conséquent, l'équipe IdM examine soigneusement les modifications apportées aux objets de schéma existants et ne continue que si elle comprend parfaitement les conséquences. En outre, Microsoft ne considère aucun attribut fourni par Windows Server System comme inutilisé, car tous ont un rôle. Par conséquent, la modification des définitions inutilisées ne s'applique qu'aux attributs personnalisés.

• Désactivations. Microsoft IT désactive rarement les définitions inutilisées. En revanche, lorsqu'ils n'ont plus besoin de certaines données d'attribut ou d'objet, Microsoft IT supprime les instances de ces valeurs ou objets. En effet, les objets de schéma inutilisé ne consomment pas beaucoup de ressources. En fait, Microsoft a spécialement conçu Active Directory pour contenir des données clairsemées. En outre, les administrateurs de schéma ne peuvent pas désactiver les objets de schéma Windows par défaut. Ils peuvent uniquement désactiver les objets de schéma personnalisés.

Performances d'Active Directory

Les définitions inutilisées dans le schéma Active Directory n'ont pas d'impact négatif sur les performances d'Active Directory. Les définitions de schéma ne font qu'augmenter la taille de la table, de la même façon que l'ajout de colonnes à une base de données. En outre, les définitions de schéma n'augmentent pas de manière significative la taille des fichiers. Dans un cas extrême, le problème de performance le plus notable est une initialisation un peu plus lente de certains outils de gestion de schéma.

L'architecture du système de gestion des changements

Étant donné le nombre élevé de changements de schéma chez Microsoft, l'implémentation d'un processus approprié pour la gestion de ces changements est essentielle. Microsoft IT utilise MOF (Microsoft Operations Framework) comme base pour ses processus de gestion essentiels. L'équipe IdM a adopté le processus de gestion des changements défini dans le MOF afin de gérer les demandes de changement de schéma, les tests et l'implémentation. Le site Web MOF, à l'adresse https://www.microsoft.com/mof, offre une documentation complète sur MOF.

Le système de gestion des changements de schéma de l'équipe IdM est constitué d'un processus formel, d'un site Web interne et d'un document de gestion des changements. Le processus définit la gestion de tous les changements de schéma chez Microsoft. Il détaille chaque activité, de la demande de changement à l'annonce de la réussite du changement. L'équipe IdM applique ce processus formel en utilisant un site Web interne comme point de départ pour la gestion de tous les changements de schéma. Le site Web définit les attentes, répond aux questions fréquentes (FAS) et permet l'accès à un formulaire de demande de changement en ligne. Ce document procédural fournit la structure d'un workflow normalisé et applique le processus formel.

Propriété du schéma

En raison de l'impact potentiel de la gestion et des modifications des schémas, l'équipe IdM contrôle chaque changement de schéma chez Microsoft. L'équipe gère le schéma comme une entité unique, en accumulant tous les changements de schéma. Cela permet une compréhension parfaite de tous les éléments actuellement contenus dans le schéma, ainsi que de l'impact des changements complémentaires.

Cette compréhension concerne les éléments suivants :

• Conception. L'équipe IdM analyse la conception de chaque élément de schéma afin de vérifier le respect des méthodes définies. La section Méthodes recommandées et normes IdM de ce document contient la liste complète des méthodes de schéma définies.

• Implémentation et utilisation. Bien qu'étroitement lié à la conception et à la propriété, cet aspect inclut la façon dont les administrateurs procèdent aux extensions de schéma, ainsi que la méthodologie d'alimentation des instances des éléments dans l'annuaire.  

• Propriété. L'équipe IdM effectue le suivi du propriétaire des éléments de schéma personnalisés afin de garantir qu'un point de contact est disponible pour tout changement ultérieur susceptible d'affecter cet élément.

• Sécurité. La sécurité des éléments du schéma doit être déterminée, gérée et faire l'objet d'un suivi. Chaque élément doit prendre en charge l'appartenance, la délégation des droits d'objet, ainsi que l'objectif de sécurité général de l'entreprise.

Pour garantir ce niveau de compréhension, Microsoft IT limite à l'équipe IdM l'autorité pour apporter les changements au schéma. En tant que gardien, l'équipe IdM garantit le bon fonctionnement du schéma Active Directory en gérant activement tous les changements.

Stratégie de changement

Pour appliquer les restrictions de changement de schéma, Microsoft IT limite l'appartenance au groupe d'administrateurs du schéma aux membres de l'équipe IdM. En outre, l'équipe IdM n'accorde la propriété au groupe d'administrateurs du schéma que de manière temporaire, le temps d'apporter les changements approuvés. Sinon, le groupe d'administration de schéma par défaut reste vide.

L'équipe IdM a l'autorité pour définir des stratégies afin de garantir que le système de gestion des changements de schéma est utilisé, que les normes appropriées sont respectées et que les attentes sont définies. Les changements de schéma nécessitent les éléments suivants :

• Approbation IdM. Tous les changements de schéma nécessitent l'approbation de l'équipe IdM.

• Utilisation du système de gestion des changements de schéma. Tous les changements de schéma doivent passer par le processus et le service d'approbation de schéma Active Directory de l'équipe IdM. 

• Test préalable. Les personnes qui demandent des changements de schéma sont responsables des tests du fonctionnement du changement de schéma. Cela inclut la méthode d'implémentation. L'équipe IdM ne traite aucune demande sans les tests appropriés.

• Documentation appropriée. La condition préalable à toute demande IdM est de documenter les fonctionnalités du schéma et les processus de test, y compris la méthodologie d'implémentation. Les demandeurs doivent documenter ces informations ainsi que d'autres dans le formulaire de domaine de schéma avant que l'équipe IdM ne planifie l'examen initial.

Infrastructure de changement

L'infrastructure requise pour gérer le système de gestion des changements de schéma est minimale. Elle est constituée d'un site Web interne, de l'équipe IdM et des environnements de test appropriés.

Site Web interne

L'équipe IdM a créé un site Web Microsoft SharePoint 2003 interne. Ce site offre une interface de collaboration entre l'équipe IdM et le personnel qui demande un changement de schéma. Il s'agit du point de départ du système de gestion des changements. Le processus commence lorsqu'un demandeur fournit les informations requises via un formulaire en ligne. L'équipe IdM implémente le formulaire en ligne sous forme d'une simple enquête SharePoint. L'enquête stocke l'historique de demande, permet les révisions et utilise le mécanisme d'alerte SharePoint pour informer l'équipe lorsque des changements ont lieu. L'équipe IdM capture les données du formulaire afin de créer le document de package de schéma. Elle gère le document de package de schéma comme un document dynamique et le complète à chaque étape du processus de changement de schéma. L'équipe gère les formulaires et les documents de package de schéma dans les dossiers du projet dans la bibliothèque de documents du site SharePoint.

Équipe IdM

L'équipe IdM reçoit et traite les demandes, examine les changements demandés, effectue ses propres tests, établit les communications appropriées et implémente les changements. Cela nécessite l'accès au site Web IdM interne et au service Microsoft Terminal Server, ainsi que l'accès au contrôleur de domaine qui héberge l'opération FSMO (Flexible Single-Master Operation) du contrôleur de schéma. Cela nécessite également un compte avec des droits Admin de schéma, ainsi que l'accès à tout environnement de test nécessaire. Les techniciens confirmés effectuent tous les changements de schéma.

Environnements de test

Le demandeur doit tester toutes les demandes de changement de schéma avant de les envoyer à l'équipe IdM. L'équipe IdM nécessite alors deux niveaux de test pour chaque changement de schéma. Le test est progressif, passant à l'étape suivante uniquement lorsque l'étape précédente est terminée. Les phases de test incluent le test de l'implémentation et le test fonctionnel.

L'équipe IdM procède aux tests d'implémentation. Elle commence par charger le changement de schéma dans un environnement virtuel, avant de passer à un environnement de laboratoire. Les tests dans ces environnements permettent de découvrir les problèmes d'implémentation et les conflits d'appellation. L'équipe IdM configure toujours l'environnement virtuel avec une installation propre de Windows Server 2003, afin de détecter les conflits système. Ce test initial vérifie la validité du changement de schéma. L'environnement de laboratoire contient toutes les extensions de schéma de Microsoft, afin de permettre la détection des conflits avec des extensions personnalisées ou tierces. Cette deuxième étape d'implémentation et de test détermine s'il convient de passer aux tests fonctionnels.

L'équipe qui demande le changement de schéma procède aux tests fonctionnels en chargeant le changement de schéma dans un environnement pilote. Cela permet au propriétaire de l'application de tester le fonctionnement de l'application associée aux changements. Les environnements pilotes sont des forêts de production limitées, avec des utilisateurs réels qui en ont besoin pour accéder au réseau. Cela permet un test en situation réelle, dans un environnement de production limité. Les propriétaires de l'application gèrent le pilote et évaluent sa réussite.

Gestion des attentes

Le processus de changement de schéma implique trois parties distinctes lors de la gestion d'un changement de schéma : la partie qui fait la demande, l'équipe IdM et l'équipe IEng. Chaque partie présente ses propres exigences et responsabilités, ainsi que des attentes diverses. Ces attentes incluent notamment la planification, les résultats, les responsabilités et les normes. Pour un résultat optimal, le processus de gestion des changements gère ces attentes afin de limiter la confusion. Pour cela, l'équipe IdM s'assure que depuis le début, chaque partie comprend parfaitement le projet. L'expérience montre qu'une documentation initiale plus claire et plus complète permet de rationaliser le processus et d'améliorer le résultat. Microsoft a constaté que pour aligner les attentes et garantir un résultat optimal, le système de gestion des changements doit fournir des normes et procédures claires, des attentes justifiées et des plannings clairement communiqués.

Normes et procédures claires

Pour que les trois équipes puissent collaborer, des normes et procédures claires doivent être définies dès le départ. Ces normes permettent d'éviter les surprises et de garantir le bon déroulement du processus. L'équipe IdM détaille les normes de changement de schéma sur son site Web interne. Outre la fourniture d'un point de départ pour le processus, le site Web fournit des instructions, stratégies et normes complètes. Une fois que le demandeur comprend parfaitement les normes à respecter pour un changement de schéma, il est prêt à documenter et à soumettre la demande.

Attentes justifiées

Le demandeur doit compléter la documentation requise et justifier le caractère raisonnable de ses objectifs. En outre, il doit détailler et justifier toute différence par rapport aux stratégies et normes IdM. Le formulaire nécessite à la fois une justification métier et une justification technique.

L'équipe IdM ne refuse généralement pas une demande en raison de justifications métier ou techniques insuffisantes. En tant que conseillers, ils utilisent ces informations pour déterminer si l'objectif peut être atteint et si la solution est optimale. Si tel n'est pas le cas, l'équipe IdM suggère des modifications qui permettront d'améliorer les résultats. Cela permet d'éliminer les changements de schéma inutiles, ou les demandes de changements incorrects.

Planning clairement communiqué

L'équipe IdM détermine que tous les changements standard nécessiteront un minimum de sept semaines entre la demande et l'implémentation, et décrit le processus sur le site Web. Les sept semaines incluent trois semaines pour la découverte et l'examen, et quatre semaines pour les tests et le déploiement. L'équipe IdM peut avoir besoin de plus de temps pour les changements complexes.

Plusieurs facteurs peuvent affecter le calendrier standard de sept semaines. Cependant, aucun de ces facteurs ne modifie les normes strictes que ces changements doivent respecter, à savoir :

• Critères d'urgence. L'équipe IdM accorde automatiquement un statut de priorité et définit un planning accéléré pour les demandes qui répondent à des critères d'urgence établis. L'équipe IdM publie ces critères sur le site Web de changement de schéma.

• Urgence. Même si le changement de schéma ne répond pas aux critères d'urgence établis, l'urgence de la situation peut justifier l'accélération du planning. Par exemple, un demandeur peut être amené à définir certains attributs utilisateur Active Directory comme défunts. Cela impliquerait l'utilisation d'autres attributs d'une nouvelle application métier globale. Dans ce cas, le demandeur peut solliciter un planning accéléré. L'équipe IdM peut répondre à la demande en fonction de sa complexité, des ressources disponibles et des autres demandes prioritaires.

• Autres changements de schéma prioritaires. En général, les changements de schéma sont gérés par les membres les plus expérimentés de l'équipe informatique. Ces personnes sont généralement très occupées. À l'exception des demandes qui répondent à des critères d'urgence, les demandeurs doivent ajouter toute nouvelle demande de changement de schéma à la fin de la file d'attente existante. Au cours des périodes anormalement chargées, il peut s'avérer nécessaire d'accorder plus de temps.

Remarque :* *L'équipe IdM applique à tous les changements de schéma les mêmes normes élevées, quelle que soit la complexité et indépendamment de l'accélération du planning.

Phases du processus de changement

Le processus de changement de schéma comporte cinq phases distinctes :

• Découverte

• Examen

• Test d'implémentation

• Test du fonctionnement de l'application

• Déploiement en production

La section suivante de ce document décrit en détail les activités de chaque phase.

Parcours du processus de changement

Le graphique suivant illustre le flux des activités au cours du processus de gestion des changements de schéma.

Figure 3. Le workflow de changement de schéma

En général, un système de gestion des changements communique et suit plusieurs changements liés dans plusieurs domaines informatiques. Par conséquent, il est essentiel d'intégrer le processus de changement de schéma au système de gestion des changements de Microsoft IT, tel que défini par MOF, afin de garantir que les changements de schéma n'entraînent pas de conflits avec d'autres domaines. Il convient pour cela d'inclure une note de contrôle de changement dans le cadre du processus de changement de schéma, comme illustré figure 3. Il en résulte un processus simultané. Une fois que l'équipe IdM a approuvé le déploiement du changement de schéma, elle informe le groupe CAB (Change Advisory Board) du changement de schéma, de sorte que le groupe CAB puisse gérer les éventuels conflits pour la suite du processus. En tant qu'intermédiaire, le groupe CAB joue le rôle de conseil entre les différents groupes.

Évaluation de l'expertise du demandeur

Le demandeur du changement de schéma représente généralement un groupe produit qui développe un nouveau produit, une unité métier ou un groupe d'infrastructure informatique qui souhaite une extension de schéma pour la prise en charge d'une nouvelle application. Le plus grand nombre de changements de schéma chez Microsoft provient des groupes produit Exchange et Windows. L'équipe IdM fournit des commentaires précieux aux groupes produit concernant les changements de schéma et les options d'implémentation proposées.

Par exemple, l'installation de Microsoft Exchange Server 2003 fournit forestprep.exe pour mettre à jour et étendre automatiquement le schéma, créer de nouveaux objets et définir des autorisations pour les nouveaux objets. L'équipe IdM souhaitait étendre le schéma séparément, avant que l'installation n'ajoute des objets et n'alimente les données dans Active Directory. L'équipe IdM a demandé au groupe produit de fournir une option de fichier LDIF, laquelle fait à présent partie de l'offre produit finale.

Les changements de schéma pour les applications tierces sont plus difficiles à implémenter, car de nombreuses applications présentent des exigences de changement de schéma masquées. Les applications tierces peuvent étendre le schéma avec un fichier .EXE, ce qui rend plus difficile l'extraction des changements. En outre, le fichier .EXE ne peut importer un fichier LDIF qu'au cours du processus d'installation. Cela rend le fichier LDIF difficile à obtenir pour les tests.

Par exemple, Microsoft nécessitait une extension de schéma tierce pour prendre en charge le système de messagerie unifié Avaya. Cela a permis la messagerie unifiée chez Microsoft, via l'intégration de la messagerie vocale et d'Exchange. Le fichier d'installation contenait des changements de schéma masqués, provoquant l'échec de l'installation en raison d'autorisations insuffisantes.

Envoi d'une demande de changement de schéma

Tous les changements de schéma commencent sur le site Web IdM. Le site est disponible en interne pour tout le personnel Microsoft. Les instructions sont associées à un formulaire de demande en ligne et à des informations complémentaires.

Instructions

Les instructions définissent un planning minimum de trois semaines pour la découverte et l'examen. En cas d'approbation par l'équipe IdM, le planning minimal pour les tests et l'implémentation est de quatre semaines supplémentaires. Une exception au planning standard de sept semaines peut être accordée pour les changements qui répondent à des critères d'urgence.

Figure 4. Le formulaire de demande de schéma

Le formulaire de demande permet à l'équipe IdM de définir les attentes des utilisateurs concernant le niveau de connaissance requis pour implémenter un changement de schéma. Par exemple, le demandeur doit fournir des ID d'objet (OID, Object ID) appropriés et uniques, les résultats des tests préalables et les plans de test de fonctionnement. En outre, le demandeur doit fournir les demandes de changement de schéma sous la forme d'un fichier texte LDIF. Le format LDIF montre clairement chaque changement et inclut la source d'autorité.

Demandes d'urgence

Si un changement de schéma urgent est requis, le responsable de l'unité métier doit soumettre la demande et prouver qu'elle répond à certains critères. Les critères incluent l'arrêt du travail, l'arrêt de l'activité ou des problèmes de sécurité. L'équipe IdM fournit une recommandation au responsable IdM. Le responsable IdM doit approuver tous les schémas d'urgence avant le déploiement. Le processus comporte un planning accéléré.

Découverte

Après l'envoi du formulaire de demande de schéma, un membre de l'équipe IdM suit la demande de changement jusqu'à la fin. La première tâche consiste à examiner les justifications métier et techniques, ainsi que les détails de la demande. Au cours de l'examen, qui peut être long, le membre de l'équipe IdM peut renvoyer le document de changement plusieurs fois afin d'extraire des informations complémentaires ou de résoudre les erreurs. Lorsque la demande satisfait aux normes IdM, elle est acceptée et passe à l'étape suivante.

Justification métier et technique

Pour éliminer les changements de schéma inutiles ou les demandes de changements incorrects, l'équipe IdM impose au demandeur de fournir une justification métier et une justification technique.

La justification métier décrit la valeur ajoutée des changements pour l'unité. Elle permet à l'équipe IdM de comprendre pourquoi le demandeur souhaite les changements, ainsi que les délais dans lesquels les changements doivent avoir lieu. Par exemple, un groupe produit peut avoir besoin de déployer une application utilisant les fonctionnalités Active Directory dans l'environnement de production Microsoft, afin de recevoir des commentaires avant sa fabrication.

La justification technique définit spécifiquement ce que les changements de schéma proprosés sont censés accomplir. L'équipe IdM examine les changements demandés par rapport à l'objectif technique afin de déterminer si ces objectifs peuvent être atteints et si la solution est optimale.

Lorsqu'un groupe produit se concentre sur l'ajout de fonctionnalités et la sécurisation d'un produit, il repose sur Microsoft IT pour tester comment l'application affecte un environnement de travail. L'équipe IdM découvre parfois des problèmes significatifs dans la conception des applications. Par exemple, l'équipe IdM peut détecter que le groupe produit utilise Active Directory pour capturer des données qui changent fréquemment. Elles peuvent changer si fréquemment qu'elles risquent de changer de nouveau avant que les données aient pu être répliquées dans toute la forêt. Par conséquent, des données non valides peuvent exister sur certains contrôleurs de domaine de la forêt, annulant ainsi la valeur ajoutée du changement de schéma.

Examen de la demande de changement de schéma

Une fois que l'équipe IdM a compris et validé les justifications métier et techniques, elle examine soigneusement le fichier LDIF. Elle recherche les erreurs, analyse la conception, puis renvoie des commentaires à l'auteur. En cas de problème, ces commentaires permettent à l'auteur d'optimiser la solution et de reformuler la demande afin qu'elle soit acceptée.

Lors de l'examen d'un fichier de schéma, l'examinateur :

• Note les nouveaux attributs et les nouvelles classes d'objet requis par le changement de schéma, afin de faciliter les tests.

• Examine les changements des descripteurs de sécurité par défaut, afin de détecter les autorisations excessives et les délégations.

• Recherche les objets qui contribuent à la charge du système, par exemple l'attribut indexé, la reconstruction d'un ensemble d'attributs partiel (PAS, Partial Attribute Set) ou un SDProp.

• Évalue les changements potentiels et s'assure que tous sont conformes aux méthodes recommandées du schéma Active Directory, ainsi qu'aux normes IdM.

• Vérifie chaque OID afin de s'assurer qu'il est unique et enregistré. Cette opération peut être effectuée à l'adresse suivante : http://asn1.elibel.tm.fr/oid/index.htm.

• Vérifie les éléments du schéma afin de s'assurer qu'il comporte des définitions appropriées, des valeurs cohérentes et des descriptions significatives.

• Vérifie la cohérence des conventions d'appellation et leur conformité aux normes Microsoft. Reportez-vous au site Web Microsoft à l'adresse : https://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/naming_attributes_and_classes.asp.

L'équipe IdM utilise un script qui automatise l'essentiel de la collecte générale d'informations. Lorsqu'il est satisfait des informations envoyées, l'examinateur accepte la demande de changement, définit un planning et passe aux tests d'implémentation.

Test d'implémentation

Une fois qu'une demande de changement de schéma a été acceptée, l'équipe IdM la met en file d'attente en vue des tests d'implémentation. Par conception, le schéma de la forêt varie légèrement d'une forêt à l'autre chez Microsoft. Par exemple, les forêts gèrent différentes versions des logiciels Microsoft, pour la prise en charge des versions antérieures et pour le développement. Plutôt que d'effectuer des tests sur chaque forêt séparément, l'équipe IdM gère un environnement de laboratoire avec un schéma cumulatif contenant chaque extension de schéma de chaque forêt. Par conséquent, grâce aux tests d'implémentation dans cet environnement, l'équipe IdM peut identifier les conflits dans chaque forêt avant le déploiement.

En chargeant le fichier LDIF dans le laboratoire, l'équipe IdM peut vérifier qu'il n'y a pas de conflits d'OID ou d'appellation, et que le fichier LDIF est chargé correctement. L'activation de l'option de journalisation au cours de l'implémentation, et l'examen du journal à la recherche d'erreurs, permettent de vérifier cela. L'équipe IdM recherche toutes les erreurs et peut renvoyer le fichier LDIF au demandeur si le fichier nécessite des modifications. Il ne doit subsister aucun doute quant à l'installation correcte du fichier LDIF final.

Approbation du déploiement

Une fois que l'équipe IdM a examiné la demande de changement et testé l'implémentation, elle peut approuver ou refuser le déploiement. En cas d'approbation, l'équipe IdM informe le CAB et fait passer la demande de changement en phase de test fonctionnel. En cas de refus, l'équipe IdM renvoie la demande de changement au demandeur, avec une explication détaillée du refus.

Notification du groupe CAB

Le groupe CAB (Change Advisory Board) est une fonction Microsoft IT définie en conformité avec MOF. Le groupe CAB est distinct de l'équipe IdM. Le groupe CAB est un groupe interfonction, défini pour évaluer toutes les demandes de changements Microsoft IT en termes de besoins métier, de priorité, de rapport coût/avantage et d'impact potentiel sur d'autres systèmes ou processus. En général, le groupe CAB émet des recommandations en termes d'implémentation, l'analyse, de report ou d'annulation.

Lorsque l'équipe IdM envoie une note de contrôle de changement au groupe CAB, ce dernier exécute le processus simultanément avec l'équipe IdM. Le groupe CAB est le point d'intégration avec le système général de création de tickets pour la gestion des changements chez Microsoft IT.

L'environnement informatique est très complexe, avec de nombreuses interdépendances, souvent globales. Le groupe CAB détermine les effets des changements sur les systèmes et départements interdépendants, et coordonne les changements entre les départements. Il coordonne les changements en utilisant le système de gestion des changements de Microsoft IT simultanément avec le système de gestion des changements de schéma. Le groupe CAB examine la demande de changement afin de déterminer les éléments suivants :

• Autorisation. Autorité des parties pour apporter les modifications.

• Interdépendances. Les changements peuvent affecter de nombreux groupes différents ainsi que leurs contrats de niveau de service (SLA, Service Level Agreements).

• Conflits. Avec une vue plus globale de Microsoft IT, le groupe CAB peut déterminer s'ils doivent modifier des changements, ainsi que le planning de ces changements pour éviter les conflits.

Après l'examen de la demande de changement, le groupe CAB approuve la demande ou la renvoie avec des recommandations de changement. Si elle est approuvée, le groupe CAB l'ajoute au système général de gestion des changements en vue de l'obtention d'un numéro de ticket, et informe par e-mail tous les groupes interdépendants. La notification permet à ces groupes de prendre les mesures nécessaires pour éviter les conflits et coordonner les changements.

Test du fonctionnement de l'application

Si le fichier LDIF est chargé correctement dans l'environnement de laboratoire, l'étape suivante consiste à démarrer le premier pilote. Le pilote autorise le demandeur à procéder à des tests fonctionnels, tels que définis dans le plan de test fonctionnel. L'équipe IdM utilise généralement la forêt de développement Windows pour lancer le premier pilote. Cette forêt est une forêt de production limitée, avec des utilisateurs qui utilisent cet environnement dans le cadre des tests. Le demandeur a généralement une semaine pour tester le fonctionnement et déterminer si les changements de schéma fonctionnent comme prévu. Si les demandeurs disposent d'une forêt supplémentaire, l'équipe IdM offre l'opportunité d'un deuxième pilote. À la fin de chaque phase pilote, le demandeur confirme la réussite des tests de fonctionnement. Le demandeur peut tenter d'apporter de petites modifications au cours des tests, afin de résoudre des problèmes mineurs. En revanche, si le demandeur découvre des problèmes majeurs, le processus est interrompu et le demandeur doit alors reprendre les changements de schéma.

Déploiement en production

Une fois les tests d'implémentation et les tests de fonctionnement terminés, le fichier LDIF entièrement vérifié et testé est prêt pour le déploiement. L'équipe IdM passe ensuite au planning de déploiement des changements. La date et l'heure de déploiement des changements dépendent des exigences en termes de planning, de l'étendue des changements, de l'impact de la réplication, ainsi que de la charge de travail actuelle des équipes IdM et IEng. L'équipe IEng doit surveiller le processus de réplication. Avec les tests appropriés, l'équipe IdM charge les petites modifications le même jour, mais les changements de schéma significatifs seront si possible chargés indépendamment. L'équipe IdM réserve les vendredis soir (heure du Pacifique) pour les changements de schéma, afin de garantir que la réplication sera terminée et que la charge Active Directory sera revenue à la normale avant le lundi matin en Asie.

Grâce à des scripts pour le processus, l'équipe IdM peut appliquer les mêmes changements à chaque forêt, sans aucune manipulation manuelle. Elle applique les changements à chaque forêt, de manière consécutive pour toutes les extensions de schéma. Pour vérifier la réussite du processus de changement, l'équipe IdM compare le nombre de changements réussis en bas du fichier journal aux changements consécutifs dans les autres forêts. S'ils sont différents, l'équipe IdM examine les journaux. En cas d'erreurs significatives affectant la stabilité d'Active Directory, l'équipe IdM peut être amenée à collaborer avec l'équipe IEng afin de lancer un plan de récupération.

Une fois le déploiement réussi, l'équipe IdM compresse le script, le fichier LDIF et le fichier journal de chaque forêt, ainsi que le fichier d'erreur s'il existe. Elle ajoute ensuite les enregistrements au fichier d'historique des changements, pour tous les changements de schéma.

Une fois que l'équipe IdM a déployé les changements dans les forêts concernées, l'équipe IEng surveille le processus de réplication afin de s'assurer qu'il n'y a pas de problèmes de réplication du schéma dans chaque forêt. L'équipe IEng est également responsable de la récupération en cas de problème majeur. Une fois que les changements de schéma ont été répliqués dans chaque forêt et que l'équipe IEng est satisfaite des résultats, elle envoie un e-mail final à toutes les personnes concernées, confirmant la réussite de la réplication des changements de schéma.

Atténuation des risques

Pour limiter les risques liés aux changements de schéma, l'entreprise doit comprendre ces risques, déterminer les causes et prendre les mesures nécessaires pour les éliminer ou les limiter. En outre, elle doit préparer un plan de contingence pour les problèmes pouvant survenir.

Mesure des risques

Microsoft IT détermine le risque d'un événement en utilisant à la fois l'impact et la probabilité d'une occurrence. Les événements susceptibles de générer l'impact le plus important, par exemple la défaillance du système, sont généralement les premiers événements contre lesquels Microsoft IT se protège, via des mesures de sécurité et des redondances. Cela crée une relation inverse entre les événements à risque élevé et les événements à impact élevé, dans lesquels les événements les plus graves sont souvent ceux qui ont le moins de probabilité de se produire. Bien qu'il soit important d'être préparé aux événements graves, la gestion des événements avec un risque d'occurrence plus élevé est plus productive. Microsoft recommande de traiter chacun des risques décrits ci-dessous.

Impact de réplication : impact limité, risque modéré

La réplication Active Directory utilise un système de priorité qui réplique les changements de schéma avant tout changement de données. Cela peut entraîner une augmentation du temps nécessaire à la convergence des données entre les différents contrôleurs de domaine. Par conséquent, les changements de schéma volumineux peuvent entraîner des goulets d'étranglement pour les changements de données requis par des applications utilisant Active Directory, et ainsi affecter les personnes utilisant ces données. Par exemple, la réplication d'un changement de propriétaire de groupe dans l'ensemble de la forêt peut prendre plus de temps que la latence de réplication normale de cinq heures, au cours d'un changement de schéma. Cela tient au fait que l'appartenance aux groupes est répliquée une fois l'extension de schéma terminée.

L'implémentation d'une application significative utilisant Active Directory, telle que Exchange 2003, entraîne un grand nombre de changements de schéma pouvant nécessiter plus d'un cycle de réplication par saut, en fonction de la topologie du site de la forêt. L'équipe IdM implémente généralement ces types de changement un vendredi soir, afin de limiter l'impact sur la productivité. D'autres attributs peuvent entraîner une charge de réplication supplémentaire, notamment les attributs indexés, la reconstruction d'un ensemble d'attributs partiel (PAS, Partial Attribute Set) ou des descripteurs de sécurité hérités (SDProp, Inherited Security Descriptors). Ces changements sont parfois nécessaires pour certaines fonctionnalités du système et les administrateurs ne peuvent pas les éviter, mais une implémentation bien pensée permet de réduire les effets négatifs.

Défaillance d'une application : impact modéré, risque modéré

Active Directory offre certaines fonctionnalités d'application dans la forêt, notamment la sécurité et l'accès au catalogue global. En outre, les applications qui étendent le schéma Active Directory présentent d'autres fonctionnalités personnalisées qui dépendent de leur accès à Active Directory et de ses extensions. Les extensions de schéma fournissent les définitions que les applications utilisent pour créer les objets dont ils ont besoin pour fonctionner. La perte de l'accès à Active Directory peut entraîner la perte de fonctionnalités spécifiques pour l'application, voire sa défaillance totale.

Un changement de schéma mal conçu peut invalider des éléments existants qui sont requis par l'application dépendante qui provoque les problèmes. En outre, une extension de schéma mal implémentée peut n'offrir qu'un changement partiel et provoquer des erreurs d'applications, ou empêcher le fonctionnement total d'une nouvelle application.

Défaillance du système : impact élevé, risque faible

Active Directory gère l'accès aux ressources réseau, ainsi que le fonctionnement des applications qui utilisent les fonctionnalités Active Directory. Par conséquent, si Active Directory n'est plus disponible, les utilisateurs de la forêt perdent l'accès à ces ressources, ainsi que les fonctionnalités de certaines applications. Cependant, pour que Active Directory ne soit plus disponible, il faut que tous les contrôleurs du domaine soient hors service. La défaillance d'un contrôleur de domaine unique n'affecte pas Active Directory pour l'ensemble de la forêt. Il s'agit d'un événement à risque limité, car les défaillances de contrôleurs de domaine sont peu fréquentes.

Les défaillances de contrôleurs de domaine peuvent être provoquées par des défaillances matérielles ou logicielles. La résolution de la défaillance d'un contrôleur de domaine consiste à résoudre le problème matériel ou à réinstaller le logiciel. Les défaillances de contrôleurs de domaine n'impliquent pas de défaillances Active Directory lorsque les administrateurs déploient plusieurs contrôleurs de domaine à des fins de redondance. Cependant, si le contrôleur de schéma connaît une défaillance au cours d'un changement de schéma, les administrateurs doivent être prudents lors de la remise en ligne du serveur, afin de garantir un état cohérent.

La corruption d'un annuaire Active Directory répliqué suite à des échecs de données est également très peu fréquente. La résolution d'une corruption d'annuaire Active Directory répliqué consiste à implémenter un plan de récupération.

Gestion des risques

Avec la compréhension des risques, il devient évident que les deux principales causes de problèmes significatifs suite à un changement de schéma sont une mauvaise conception et une mauvaise implémentation. Les problèmes de conception peuvent augmenter la latence de réplication ou la charge système du contrôleur de domaine, et ainsi entraîner l'incompatibilité de l'application ou des pannes. Les problèmes d'implémentation peuvent inclure les implémentations partielles qui empêchent le fonctionnement, ou une planification incorrecte qui entraîne une latence de réplication supérieure aux seuils généralement admis. La latence de réplication peut affecter les applications sensibles à la latence. Par conséquent, pour limiter ou supprimer les risques, il est important de gérer la conception et l'implémentation des changements de schéma. Pour cela, l'équipe IdM dispose de l'autorité exclusive pour apporter tous les changements de schéma dans les forêts gérées par Microsoft IT.

Gestion des risques de conception

Le système de gestion des changements de schéma IdM nécessite que les demandeurs suivent des règles spécifiques pour l'approbation des changements. L'équipe IdM diffère les changements de schéma dont la conception est douteuse jusqu'à l'examen des détails techniques. Le système de gestion des changements gère les risques de conception via les fonctions suivantes :

• Gestion de la documentation. Une documentation insuffisante peut poser des problèmes lors de l'implémentation. Pour résoudre ce problème, les demandeurs doivent fournir une documentation normalisée avant le début de l'examen.

• Analyse de la conception. L'équipe IdM analyse les conceptions de schéma en fonction des normes IdM et renvoie les demandes de changement mal conçues à l'auteur, avec des commentaires ou des suggestions.

• Établissement standard. L'équipe IdM impose un ensemble de normes strictes et de méthodes recommandées, qui définissent un changement de schéma acceptable. Ces normes limitent les risques de conflits avec des objets de schéma existants. Elles mettent en évidence l'utilisation des attributs qui entraînent des pics de réplication. Ces normes sont détaillées dans la section Méthodes recommandées et normes IdM de ce document.

• Responsabilité des éditeurs tiers. Les éditeurs ne fournissent pas toujours les fichiers LDIF ou les descripteurs de sécurité de schéma pour la conception ou l'évaluation de la sécurité. En raison des problèmes de conformité, il est important que les administrateurs examinent soigneusement les descripteurs de sécurité de schéma tiers, et obtiennent et valident les changements de schéma documentés.

Gestion des risques d'implémentation

Une fois que le changement de schéma a été accepté et conçu, les tests d'implémentation et de fonctionnement commencent. Les procédures sont les suivantes :

• Écriture de scripts pour le processus. L'équipe IdM utilise un script standard pour implémenter le fichier LDIF dans toutes les forêts, en prenant soin d'utiliser des paramètres corrects et cohérents dans l'entreprise. Cela permet d'éliminer les erreurs humaines au cours du processus d'implémentation, pouvant entraîner des changements de schéma partiels.

• Tests d'implémentation. Grâce au test de l'implémentation des fichiers LDIF dans un environnement de laboratoire, les erreurs et conflits peuvent être découverts et corrigés avant le déploiement du fichier dans un environnement de production.

• Tests de fonctionnement. En appliquant les changements de schéma dans un environnement limité, le fonctionnement de l'application peut être déterminé par le demandeur. Le résultat du pilote détermine si l'équipe IdM implémentera les changements de schéma. Cela permet de réduire le risque d'implémentation d'un schéma ne fonctionnant pas correctement.

• Normes d'implémentation. L'équipe IdM a développé des normes d'implémentation et des méthodes recommandées qui limitent les risques. Il s'agit notamment des normes suivantes :

  • Implémentation directe du contrôleur de schéma. L'équipe IdM utilise les services Terminal Server pour implémenter les changements de schéma localement sur le contrôleur de schéma, de sorte que l'implémentation n'est pas soumise aux problèmes de poste de travail ou de connectivité réseau. Cela permet de réduire le risque d'implémenter des changements de schéma partiels générés par ces problèmes.

  • Considérations relatives à l'impact de la réplication. L'équipe IdM implémente généralement les changements de schéma le vendredi soir, afin de permettre la réplication le week-end. Cela permet de limiter l'impact sur le reste du trafic de réplication.

  • Vérification de la réussite de la réplication. L'équipe IEng vérifie la réussite de la réplication du changement de schéma dans la forêt. Cela permet de réduire le risque d'un comportement inattendu de l'application dans un environnement de production, lorsque le changement de schéma n'a pas été totalement répliqué.

Planification de la récupération en cas d'incident

Il arrive que les changements de schéma entraînent des problèmes qui ne sont pas faciles à résoudre. La méthode de récupération préférée consiste à modifier le schéma. Cependant, il arrive que la modification du schéma ne soit pas un choix commode. Dans ce cas, un administrateur doit restaurer le domaine ou la forêt.

L'équipe IEng est responsable de la récupération après incident et dispose de plusieurs processus pour annuler les changements de schéma, à savoir :

• Sauvegarde et restauration. Pour que cette méthode fonctionne, une entreprise doit procéder à des sauvegardes régulières de l'état des contrôleurs de domaine, vérifier que les sauvegardes sont correctes, et exécuter périodiquement le processus de restauration. L'équipe IEng exécute le processus de restauration régulièrement, via une restauration non officielle mensuelle pour tester le processus, et une restauration officielle tous les trois à quatre mois, afin d'aider les utilisateurs qui ont perdu des données. Dans le cas d'un changement de schéma, une restauration de forêt est requise. Il s'agit d'une version étendue du scénario de sauvegarde et de restauration. L'équipe IEng procède à une restauration annuelle de la forêt dans le laboratoire, afin de tester le processus. Parmi les deux options, la sauvegarde et la restauration constituent la méthode préférée de l'équipe IEng, car elle est la plus simple à réaliser.

• Contrôleur de schéma hors connexion. En déconnectant le contrôleur de schéma du réseau pour y apporter directement un changement de schéma, l'équipe IdM peut vérifier la réussite de l'implémentation avant de remettre le contrôleur de schéma en ligne. Pour cela, elle peut récupérer le contrôleur de schéma en tant que contrôleur de domaine unique si elle doit annuler le changement de schéma. Cela n'offre pas la possibilité de valider l'application. En revanche, cela garantit l'installation correcte du schéma.

Méthodes recommandées et normes IdM

L'équipe IdM a beaucoup appris au fil des années, suite au déploiement de changements de schéma. Le volume des changements de schéma a permis à l'équipe IdM d'affiner en permanence le processus. À partir de ces affinages, l'équipe a pu développer un ensemble de méthodes recommandées et de normes afin de renforcer le processus et de garantir des résultats optimaux.

Méthodes recommandées

Les méthodes recommandées par Microsoft IT sont les suivantes :

• Normaliser le processus de gestion des changements. Un processus de gestion des changements bien conçu offre à une organisation un workflow normalisé qui garantit des résultats optimaux. Une fois le processus en place, toutes les responsabilités et attentes sont claires. Le processus doit inclure le workflow complet, de la distribution de la demande de changement initiale dans un format acceptable à la détermination de qui informe toutes les parties concernées que le processus s'est déroulé avec succès.

• Étendre le schéma séparément de l'installation de l'application. Lors de l'installation d'une application nécessitant des changements de schéma, étendez le schéma séparément de l'installation de l'application. L'utilisation d'un fichier LDIF pour étendre le schéma est la méthode préférée, en raison de la quantité de détails de changement qu'il contient. L'équipe IdM nécessite que les groupes produits internes et les fournisseurs externes offrent une option LDIF. L'équipe IdM autorise uniquement l'installation à créer des objets, définir des autorisations et alimenter les données, après l'extensionn séparée du schéma.

• Tester de manière approfondie avant l'implémentation. Testez de manière approfondie tous les changements de schéma avant de les implémenter dans un environnement de production. Cela inclut le test de l'implémentation et le test de fonctionnement. Effectuez les tests de fonctionnement sur toutes les applications développées en interne. Les produits prêts à l'emploi peuvent ne pas nécessiter de tests fonctionnels.

• Comprendre l'impact de chaque changement de schéma sur Active Directory. L'impact d'un changement de schéma est étendu et peut affecter la sécurité des objets, le type des données publiées dans l'annuaire, l'indexation de la base de données de l'annuaire, le coût des mises à jour de l'annuaire, la disponibilité des données dans le catalogue global, ainsi que la taille de la base de données Active Directory. Par conséquent, avant d'étendre un schéma dans un environnement de production, il est important de déterminer en quoi le changement affectera les différents aspects d'Active Directory, tels que la sécurité, l'utilisation des données, les exigences de l'infrastructure, la réplication et les applications dépendantes.

• Écrire des scripts pour le processus. Utilisez un script normalisé pour exécuter tous les changements de schéma, afin de garantir la cohérence du processus. Le script exécute les changements du fichier LDIF avec les commutateurs de ligne de commande ldifde.exe requis et traite toutes les variables qu'il contient. Cela permet d'éviter les oublis et de garantir que tous les changements de schéma suivent les procédures standard et renvoient des résultats cohérents. Un script normalisé inclut les éléments suivants :

  • Automatisation de l'appellation des forêts. Les fichiers LDIF spécifient le nom distinctif (DN, Distinguished Name) de chaque objet ajouté ou modifié. Dans la mesure où ce DN doit contenir le domaine racine de la forêt, ceux-ci doivent être changés avec les éléments spécifiques du contrôleur de domaine pour la forêt cible. La norme de-facto pour les fichiers LDIF consiste à utiliser DC=X comme espace réservé pour les éléments contrôleur de domaine. En utilisant DC=X dans le fichier LDIF, le script détermine le contexte actuel du nom de domaine et le remplace par une valeur significative. Le fichier LDIF est ainsi très portable, ce qui permet d'exécuter le même script sur chaque forêt, sans modification manuelle du fichier LDIF. Cela permet également d'éliminer les problèmes de contrôle de version.

  • Utilisation correcte des commutateurs de ligne de commande. Le script utilise l'outil de ligne de commande LDIFDE.exe avec un ensemble standard de paramètres. Il utilise le paramètre de commande J pour générer un fichier journal de type texte. Le script utilise le paramètre de commande C pour automatiser les changements de noms de forêt par opération rechercher/remplacer. Avec l'option K de paramètre de commande, si des erreurs se produisent dans le processus de changement de schéma, le script se poursuit et ne crée pas d'éléments manquants. Cela est également important parce que les administrateurs ajoutent souvent des changements de schéma supplémentaires à la fin du changement de schéma original, par simplicité. Lors de l'exécution du script, les changements de schéma dupliqués apparaissent comme une erreur, sans provoquer l'échec du script. Lors des tests de validation, il est important d'être prudent lors de l'examen des journaux, car le paramètre de commande K continue également après toute erreur de violation de contrainte. Assurez-vous que toutes les erreurs consignées ont une bonne explication.

  • Cohérence des forêts. L'utilisation du même script sur toutes les forêts sans modification manuelle améliore la cohérence du schéma entre les forêts. Les changements manuels du fichier LDIF peuvent entraîner des erreurs provoquant des changements de schéma partiels.

  • Cohérence des processus. Si le processus ne fait pas l'objet de scripts, l'opérateur doit entrer les paramètres corrects chaque fois. Cela entraîne un risque d'erreur humaine. Par exemple, un opérateur ne peut pas créer de fichier journal après que le processus s'est déjà exécuté sans paramètre J. En outre, l'oubli du paramètre K peut entraîner un changement de schéma partiel et nécessiter l'examen des journaux.

• Apporter les changements localement sur le contrôleur de schéma. Utiliser une session Terminal Server pour la connexion au contrôleur maître lors des modifications de schéma. Dans la mesure où les services Terminal Server exécutent les changements localement sur le contrôleur de schéma, cela limite les risques concernant le réseau et le client, pouvant entraîner des problèmes de changement de schéma partiel.

• Conserver l'historique des changements de schéma. Conservez des copies de tous les enregistrements relatifs à chaque changement de schéma. Cela permet de disposer d'un historique des changements et d'un résumé des résultats, pouvant être consultés en cas de besoin. En outre, avec la conservation des fichiers, les administrateurs peuvent ajouter des changements à la fin du fichier LDIF, ce qui simplifie les changements ultérieurs. Avec chaque changement de schéma, Microsoft IT compresse le script, le fichier LDIF, le journal et le fichier d'erreur pour chaque forêt.

• Tester les changements de schéma séquentiels ensemble. Il est vivement recommandé que les administrateurs effectuent des tests séquentiels spécifiques avant le déploiement des changements de schéma séquentiels. Effectuez les changements de schéma de manière individuelle afin de préserver des scripts uniques pour chacun.

• Supprimer les anciennes données des objets de schéma inutiles. Si Active Directory contient des données inutilisées, il est préférable de supprimer les données et de récupérer les ressources en créant un script simple. Non seulement cela permet de libérer de l'espace dans les fichiers, mais cela permet également de réduire la charge du serveur au cours de l'indexation et de la réplication. Enfin, le nettoyage des anciennes données empêche la conservation non intentionnelle et l'exposition possible de données confidentielles ou sensibles.

Normes IdM Microsoft IT

L'équipe IdM nécessite le respect des normes suivantes pour tous les changements de schéma. Ces normes garantissent que le processus de changement de schéma est cohérent et offre des résultats optimaux. Les normes sont les suivantes :

• Conception des schémas

  • Tous les éléments de schéma nécessitent un OID valide.

  • Observez les conventions d'appellation recommandées par Microsoft.

  • Les administrateurs ne doivent indexer que les éléments qui sont uniques et largement alimentés.

  • N'apportez des ajouts aux attributs partiels que lorsque cela s'avère nécessaire.

  • Le propriétaire d'un ensemble de propriétés personnalisé doit approuver les éventuelles modifications de cet ensemble.

  • Un objet unique dans Active Directory ne doit pas présenter une taille supérieure à 1 Mo.

• Propriété du schéma

  • Les propriétaires des éléments de schéma doivent être des employés à temps plein.

  • Pour les applications développées en interne, définissez la propriété de chaque élément de schéma avant l'implémentation de l'extension.

  • Les propriétaires doivent informer l'équipe IdM concernant les éléments de schéma inutilisés et les rendre défunts.

• Implémentation et utilisation du schéma

  • Il ne doit pas exister d'éléments de schéma avec des objectifs identiques.

  • Apportez toutes les modifications de schéma avec un script LDIF. Lorsque des produits tiers utilisent des exécutables ou un wrapper d'installation, rendez un fichier LDIF disponible pour l'examen, l'installation manuelle ou les deux.

  • Archivez tous les fichiers LDIF afin de pouvoir y faire référence ultérieurement.

  • Seule l'équipe IdM implémente les changements dans le schéma pour toute forêt gérée par Microsoft IT.

  • Documentez le niveau de test auquel une extension de schéma proposée est soumise.

  • Fournissez une procédure permettant d'implémenter toute modification de schéma, avec un script LDIF, un programme exécutable, un wrapper d'installation, etc.

• Sécurité du schéma

  • L'équipe IdM est très attentive lors du changement du descripteur de sécurité par défaut des éléments du schéma, car cela affecte la sécurité du réseau.

• Déploiement dans plusieurs forêts

  • Les efforts de cohérence doivent être conciliés avec la commodité. IdM déploie les changements de schéma dans différentes forêts afin de vérifier les méthodes d'implémentation, d'identifier les éventuels conflits de compatibilité et de garantir la cohérence entre les forêts.

Conclusion

Microsoft IT recommande d'institutionaliser un processus cohérent de changement de schéma Active Directory, incluant la justification, l'évaluation, le test, les étapes intermédiaires et l'implémentation. Microsoft IT recommande également d'intégrer le processus de changement de schéma au système de gestion des changements existant, afin de limiter les conflits et les risques.

Microsoft IT a donné à un groupe spécifique l'autorité pour la gestion de tous les changements de schéma et l'application des normes. Les normes sont définies de manière explicite et peuvent être appliquées. Le processus de changement de schéma impose des normes et des procédures, crée et gère les attentes, et communique des plannings clairs.

Les changements de schéma nécessitent une gestion active et peuvent nécessiter la coopération entre plusieurs équipes. Le processus de changement de schéma de Microsoft attribue des responsabilités et fournit des vérifications et équilibres entre les parties. Grâce à un processus pas-à-pas standard, la confusion est supprimée et toutes les exigences sont satisfaites.

Avec l'établissement du processus de changement de schéma, Microsoft IT a normalisé les changements de schéma avec un workflow structuré qui impose des normes organisationnelles et qui établit des attentes solides. À présent, le workflow élimine les problèmes de changement de schéma très tôt dans le processus, et offre des responsabilités claires pour chaque partie impliquée. Cela permet d'améliorer la collaboration entre toutes les parties impliquées, ce qui permet d'obtenir des résultats rapides et optimisés.

Pour plus d'informations

Pour plus d'informations sur les produits ou services Microsoft, appelez le Microsoft Sales Information Center au (800) 426-9400. Au Canada, appelez le Microsoft Canada information Centre au (800) 563-9048. En dehors des États-Unis et du Canada, veuillez contacter votre filiale Microsoft locale. Pour accéder aux informations via le World Wide Web, accédez au site suivant :
https://www.microsoft.com

https://www.microsoft.com/itshowcase

https://www.microsoft.com/technet/itshowcase

Si vous avez des questions, commentaires ou suggestions à propos de ce document, ou pour obtenir des informations complémentaires sur Microsoft IT Showcase, adressez un courrier électronique à :
showcase@microsoft.com

Pour plus d'informations sur MOF (Microsoft Operations Framework), consultez le site suivant :
https://www.microsoft.com/mof

Pour plus d'informations sur le processus MOF de gestion des changements, consultez le site suivant : https://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfchgmg.mspx#EGAA

Pour plus d'informations sur le processus de gestion des changements déployé par l'équipe IdM, consultez le site suivant :
https://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfchgmg.mspx.

Les informations contenues dans ce document représentent le point de vue actuel de Microsoft Corporation sur les questions traitées, à la date de publication. Dans la mesure où Microsoft doit s'adapter aux conditions fluctuantes du marché, ces informations ne doivent pas être considérées comme un engagement de la part de Microsoft; pour sa part, Microsoft ne peut en garantir la validité après la date de publication.

Téléchargez

Téléchargez tout le document

ADSchema ManagementTWP.doc
395 ko
Fichier Microsoft Word

Situation

Les changements de schéma Active Directory sont fréquents chez Microsoft. L'implémentation d'un changement de schéma sans planification et tests avancés peut avoir des conséquences imprévisibles. Par conséquent, les changements nécessitent un workflow structuré pour garantir un processus cohérent et sans heurts.

Solution

Microsoft a institutionalisé un processus de gestion des changements de schéma qui offre un workflow cohérent et structuré. Le processus définit des normes, attentes et plannings clairs. Le processus limite les risques et offre des résultats optimaux pour les changements de schéma.

Avantages

• Réduction des risques via la normalisation des changements de schéma

• Création d'un workflow structuré

• Application de normes organisationnelles

• Établissement d'attentes solides

• Normalisation des communications requises

Produits et technologies

• Microsoft Windows Server 2003

• Active Directory

• Microsoft Identity Integration Server 2003 SP1

• Microsoft SharePoint 2003

• Microsoft Exchange Server 2003

• Terminal Server