Les GPO

L’une des nouveautés du côté d’Active Directory dans Windows Server 2008 et ultérieur, c’est l’optimisation des GPOs à travers le Group Policy Template ou GPT.

Optimisation des GPOs

Le GPT est la composante physique de l’objet stratégie de groupe que l’on retrouve dans le volume SYSVOL.

Nous pouvons l’afficher dans le répertoire \\FQDN\sysvol\FQDN\Policies

Chaque dossier portant comme nom un GUID correspondant à la composante physique des GPOs affichés dans votre console GPMC

Les modèles d’administration ont pour but d’ajouter de nouveaux paramètres configurables aux GPOs, ceux-ci peuvent aussi bien configurer le système d’exploitation que des applications Microsoft ou d’autres programmes tiers. Ces configurations s’effectuent par de simples changements de valeurs de clés de registre dans la base d’un client Windows.

Sous Active Directory dans Windows Server 2008 ces modèles d’administration prennent un nouvel essor à travers le format ADMX, un nouveau format dont l’édition s’en retrouve plus simple (XML).

Afin d’utiliser au mieux ces ADMX, un magasin central est nécessaire. Dans ce référentiel nous déposerons tous les fichiers ADMX afin d’avoir un répertoire centralisé qui concentre tous les fichiers ADMX nécessaires pour les GPOs.

Pour commencer, il va falloir récupérer des fichiers ADMX.

Vous pouvez les récupérer sur le Microsoft Download Center pour Windows Server 2008 R2 et Windows 7.

Téléchargez et installez le MSI dans le répertoire de votre choix

Celui-ci va créer un dossier « PolicyDefinitions », dans ce dossier seront stockés vos ADMX ainsi que les fichiers de régionalisation de la console Editeur de stratégie de groupe (ADML). Ces fichiers ADML ne servent uniquement à traduire l’éditeur de stratégie de groupe dans la langue du système sur lequel on lance gpme.msc, un même fichier ADMX peut bien sûr configurer un Windows 7 qu’il soit FR,EN,ou ES. Les nouveaux OS ayant d’abord un langage neutre sur lequel se greffent les packs de langues.

Vous pouvez ensuite incorporer d’autres sources ADMX de votre choix afin de pouvoir configurer certains paramètres directement depuis vos GPOs.

Prenons l’exemple d’Office 2010. Microsoft fourni sur le MDC les modèles d’administration nécessaires.

L’exécutable nous invite à choisir un dossier pour l’extraction. Il nous donne les ADMX mais également les modèles d’administration classiques ADM ainsi que l’Office Customization Tool.

Nous allons récupérer le contenu du répertoire « ADMX » afin de l’ajouter dans le dossier PolicyDefinitions précédemment crée par le MSI

Au passage nous ajouterons une dernière gamme de fichiers ADMX, ceux d’un programme tiers, Google Chrome.
La popularité des navigateurs tiers qui monte en flèche, les besoins de certaines populations d’utilisateurs sont autant de raisons qui justifient la gestion des navigateurs autre que notre cher Internet Explorer. Pourtant nous ne sommes démunis d’outils.
En effet nous retrouvons sur le site Chromium Projects des admx. Même chose, à partir du fichier ZIP fourni il faut naviguer dans le dossier correspondant \Windows\ADMX et extraire le contenu directement dans le dossier PolicyDefinitions

Ce dossier PolicyDefinitions contenant les fichiers ADMX ADML de Windows 7,Server 2008 R2, Office 2010 ainsi que Google Chrome pèse 190Mo.
La création de notre Magasin Central va se faire par le déplacement de notre dossier tout juste préparé vers le partage SYSVOL. Plus exactement dans le répertoire \\FQDN\sysvol\FQDN\Policies

Si le dossier ne porte pas le nom exact « PolicyDefinitions » votre Central Store ne sera pas opérationnel

Désormais les modèles d’administration affichés dans la console GPME proviennent du magasin central

A quoi sert ce Magasin Central ?

Si je crée 10 GPOs qui configurent un seul élément tel des pages d’accueil différentes sous Google Chrome, ils iront pointer vers le même et unique fichier ADMX nécessaire dans le Central Store.
Sous Windows Server 2003 on observerait un comportement totalement diffèrent, dans chacun des dossiers de GPO dans SYSVOL (GPT) le fichier ADM aurait été de nouveau recopié. Prenons un exemple :
Le fichier inetres.adm pèse 2,41 Mo. Si le même fichier est recopié dans chacun des dossiers on obtient pour 30 GPOs, 72 Mo. Imaginez l’impact du nombre GPOs et de fichiers ADM dans votre organisation. On peut atteindre facilement 1 Go pour 50~70 GPOs.
C’est ainsi qu’on arrive au phénomène tant redouté sous 2003, le Sysvol Bloat

Il se peut que des modèles d’administration classique (ADM) subsistent encore. Ils peuvent avoir été développé il y a des années de cela pour un produit dont le support n’est plus assuré. Afin d’optimiser vos GPOs et la taille de votre volume SYSVOL (et par extension le trafic de réplication) dès lors où vos machines exécutent Windows Vista, 7, Server 2008 ou Server 2008 R2 vous pourrez alors envisager de convertir vos fichiers ADM en ADMX dans le but de supprimer peu à peu la présence de vos anciens modèles d’administration.

Par ailleurs, Windows XP et Server 2003 ne peuvent pas utiliser le nouveau format des modèles d’administration, c’est pourquoi Microsoft ainsi que d’autres éditeurs proposent encore des modèles classiques ADM même pour les produits récents.

Cette conversion s’effectue avec une flopée d’outil que l’on retrouve sur Internet, dont celui proposé par Microsoft.

L’outil reste très intuitif et la conversion de vos fichiers ADM s’avérera être un jeu d’enfant. Attention cependant à la conversion des fichiers ADM « exotique ». S’ils sont mal développés, il se peut que des erreurs remontent lors du processus et que quelques paramètres de votre ADM ne soient plus supportés.

Qu’en est-il pour les GPOs existantes ?

On peut en profiter pour « faire le ménage » et supprimer les GPOs dont l’ensemble des paramètres sont désactivés.
Celles qui ont été créées à l’époque sur le contrôleur de domaine sous Windows Server 2003 pourront être purgées de leurs modèles « hérités ». Les plus courageux peuvent également les supprimer et en créer de nouvelles à partir des outils 2008 utilisant le Central Store.

Avec l’élévation du niveau fonctionnel vers du Windows Server 2008 vous gagnez une nouveauté : la possibilité d’utiliser DFSR pour la réplication du volume Sysvol.

Anciennement le répertoire commun à tous nos DCs était répliqué via NT FRS. DFSR Ayant fait ses preuves depuis de nombreuses années et ses évolutions successives font de lui le meilleur allié pour la réplication au niveau fichier dans l’environnement Microsoft.

Si vous installez votre 1^er contrôleur de domaine sous Windows 2008, celui-ci sera déjà DFSR replication-ready alors que dans le cadre de montée en version 200x – 2008 vos nouveaux DCs répliqueront SYSVOL uniquement via NTFRS.

De même si vous supprimez tous vos DCs 2003, vos contrôleurs de domaines 2008 répliqueront toujours avec FRS.
La migration de la réplication de FRS à DFS est un processus manuel, nécessaire uniquement dans les scénarios d’upgrade. Il s’effectue en plusieurs phases autour d’un utilitaire dfsrmig. Pour ne pas réinventer la roue une procédure est disponible sur Technet et également sur ce post de Benoit Sautiere