Automatisation avec les Politiques de Groupe (GPO)

1. Introduction aux politiques de groupe

1.1 Qu'est-ce qu'une GPO?

Une Group Policy Object (GPO) ou Politique de Groupe est un ensemble de paramètres de configuration qui peuvent être appliqués automatiquement à des utilisateurs et/ou des ordinateurs dans un environnement Active Directory.

Les GPO permettent aux administrateurs de configurer et contrôler de manière centralisée :

Les paramètres système (registre, services, sécurité)
Les paramètres utilisateur (bureau, applications, scripts)
L'installation de logiciels
Les scripts d'automatisation
Les politiques de sécurité

1.2 Pourquoi les GPO sont-elles de l'automatisation?

Les GPO représentent une forme d'automatisation déclarative particulièrement puissante. Sans GPO, un technicien devrait se connecter à chaque ordinateur individuellement pour effectuer les mêmes configurations répétitives, ce qui entraîne un risque d'erreurs, d'incohérences et demande un temps considérable. Avec les GPO, la configuration est définie une seule fois et s'applique automatiquement à tous les ordinateurs ou utilisateurs ciblés, garantissant ainsi la cohérence dans tout le domaine.

Note: Qu'est-ce qu'une automatisation déclarative? C'est lorsque l'on spécifie le "quoi" (le résultat souhaité) plutôt que le "comment" (les étapes pour y parvenir). Les GPO permettent de déclarer les configurations souhaitées, et le système s'occupe de les appliquer. À l'inverse, une automatisation impérative impliquerait d'écrire des scripts détaillant chaque étape à suivre pour atteindre le résultat. Nous verrons la différence en détail lorsque nous aborderons Ansible plus tard dans le cours.

1.3 Types de configurations

Les GPO permettent de configurer deux catégories principales :

Computer Configuration :

S'applique à la machine, peu importe qui se connecte
Exemples : paramètres réseau, installation de logiciels système, configuration de services
Appliquée au démarrage de l'ordinateur

User Configuration :

S'applique à l'utilisateur, peu importe sur quel ordinateur il se connecte
Exemples : lecteurs réseau, fond d'écran, favoris Internet
Appliquée à la connexion de l'utilisateur

2. Architecture et fonctionnement

2.1 Composants d'Active Directory (rappel)

Pour bien comprendre les GPO, il faut d'abord comprendre quelques concepts fondamentaux d'Active Directory. Un domaine représente une limite administrative et de sécurité qui contient tous les objets comme les utilisateurs, ordinateurs et groupes. Les unités d'organisation (OU) sont des conteneurs logiques dans le domaine qui permettent d'organiser ces objets. Les OU sont particulièrement importantes car elles constituent les points d'application des GPO. Par exemple, on pourrait avoir une OU "Comptabilité" et une OU "Ventes", chacune recevant des configurations spécifiques. Enfin, les contrôleurs de domaine (DC) sont les serveurs qui hébergent Active Directory, stockent les GPO et authentifient les utilisateurs et ordinateurs.

2.2 Liaison des GPO

Une GPO doit être liée à un conteneur AD pour s'appliquer :

Domaine (affecte tout le domaine)
Site (affecte un site physique)
OU (affecte une unité organisationnelle spécifique)

Important : Une même GPO peut être liée à plusieurs conteneurs.

Puisque les conteneurs sont hiérarchiques (Domaine > OU > Sous-OU), une GPO liée à un conteneur parent s'applique également aux conteneurs enfants, sauf si des exceptions sont définies (filtrage de sécurité, WMI filters).

2.3 Ordre d'application (LSDOU)

Les GPO sont appliquées dans un ordre précis :

Local - Politiques locales de la machine
Site - GPO liées au site AD
Domain - GPO liées au domaine
OU - GPO liées aux OU (de la racine vers les feuilles)

Règle importante : En cas de conflit, la dernière GPO appliquée l'emporte ("last write wins").

Par exemple, imaginons un ordinateur dans l'OU "Marketing-Ventes" qui est elle-même dans l'OU "Marketing". Si la GPO du domaine configure un fond d'écran bleu, la GPO de "Marketing" un fond d'écran rouge, et la GPO de "Marketing-Ventes" un fond d'écran vert, l'ordinateur aura finalement un fond d'écran vert car c'est la dernière GPO appliquée.

Domaine (GPO1: fond d'écran bleu)
  └── OU Marketing (GPO2: fond d'écran rouge)
       └── OU Marketing-Ventes (GPO3: fond d'écran vert)

Un ordinateur dans "Marketing-Ventes" aura un fond d'écran vert (dernière GPO appliquée).

Par défaut, les GPO des conteneurs parents sont héritées par les conteneurs enfants, permettant une configuration en cascade. Toutefois, il existe des mécanismes pour modifier ce comportement. Le Block Inheritance appliqué sur une OU empêche les GPO parentes de s'appliquer, ce qui est utile pour les OU nécessitant des configurations complètement différentes. À l'inverse, le paramètre Enforced (aussi appelé No Override) force l'application d'une GPO même si une OU bloque l'héritage. Ce mécanisme est particulièrement utile pour les politiques de sécurité obligatoires qui doivent s'appliquer sans exception.

3. Déploiement de scripts via GPO

Les GPO peuvent exécuter plusieurs types de scripts pour automatiser des tâches. Les scripts PowerShell (.ps1) sont recommandés pour les environnements Windows modernes en raison de leur puissance et flexibilité. Les scripts Batch (.bat, .cmd) sont toujours supportés pour la compatibilité avec les anciens systèmes, tandis que les scripts VBScript (.vbs) sont considérés comme obsolètes et déconseillés.

3.2 Moments d'exécution des scripts

Les scripts peuvent être exécutés à quatre moments différents:

Startup Scripts : Exécutés au démarrage de l'ordinateur (avant l'écran de connexion)
Shutdown Scripts : Exécutés à l'arrêt de l'ordinateur
Logon Scripts : Exécutés à la connexion de l'utilisateur
Logoff Scripts : Exécutés à la déconnexion de l'utilisateur

Il est crucial de comprendre le contexte de sécurité dans lequel ces scripts s'exécutent. Les startup scripts tournent avec les privilèges SYSTEM, ce qui leur donne des droits très élevés sur la machine et permet de modifier n'importe quelle configuration système. Les logon scripts, par contre, s'exécutent avec les privilèges de l'utilisateur connecté et sont donc limités aux actions que cet utilisateur peut effectuer. Cette distinction détermine quel type de script utiliser selon la tâche à accomplir.

3.3 Emplacement des scripts

La bonne pratique consiste à stocker les scripts sur un partage réseau centralisé plutôt qu'en local sur chaque machine. On utilise des chemins UNC comme \\serveur\partage\script.ps1 pour y accéder. Il est recommandé de créer un partage caché (se terminant par $, par exemple Scripts$) pour plus de sécurité. Les permissions doivent être configurées pour donner l'accès en lecture à Domain Computers pour les startup scripts et à Domain Users pour les logon scripts.

Un aspect intéressant des scripts PowerShell déployés via GPO est qu'ils peuvent s'exécuter même si la politique d'exécution locale est configurée sur "Restricted". Les GPO contournent automatiquement la politique d'exécution pour leurs propres scripts, sans modifier la politique générale de la machine. Il faut cependant s'assurer que le script est bien placé dans la section "PowerShell Scripts" et non dans la section "Scripts" legacy pour bénéficier de ce comportement.

4. Déploiement d'applications

4.1 Méthodes de déploiement

Le déploiement d'applications via GPO se fait principalement par la fonctionnalité Software Installation, mais celle-ci a une limitation importante : elle ne supporte que les fichiers .msi (Windows Installer). Les fichiers .exe ne peuvent pas être déployés directement par ce mécanisme. Pour les applications ne disposant pas d'un installeur MSI, il faut recourir à des scripts ou à des outils tiers.

4.2 Software Installation - Modes de déploiement

Il existe deux modes principaux de déploiement d'applications. Le mode Assigned (attribué) se comporte différemment selon qu'il est appliqué à la configuration ordinateur ou utilisateur. En Computer Configuration, l'application s'installe automatiquement au démarrage et devient disponible pour tous les utilisateurs de la machine. En User Configuration, l'application apparaît dans le menu Démarrer mais ne s'installe réellement qu'au premier lancement (installation à la demande), et elle suit l'utilisateur sur n'importe quelle machine du domaine. Le mode Published (publié) n'est disponible qu'en User Configuration. Dans ce mode, l'application apparaît dans "Ajout/Suppression de programmes" mais l'utilisateur doit l'installer manuellement. Ce mode est particulièrement utile pour les applications optionnelles que certains utilisateurs peuvent choisir d'installer selon leurs besoins.

4.3 Bonnes pratiques et limitations

Pour qu'un déploiement fonctionne, le fichier MSI doit être placé dans un partage réseau accessible avec les permissions de lecture appropriées. Le chemin doit absolument être spécifié en format UNC, pas avec une lettre de lecteur mappée. Cette approche centralisée assure que tous les ordinateurs peuvent accéder au fichier d'installation. Il est important de comprendre les limitations de cette méthode. Le mécanisme natif de GPO ne supporte pas les mises à jour automatiques des applications déjà installées. De plus, certains fichiers MSI créés par des éditeurs tiers peuvent ne pas être "bien formés" selon les standards Microsoft et poser des problèmes lors du déploiement. Enfin, il n'existe pas d'interface permettant de suivre la progression de l'installation sur les différentes machines. Pour ces raisons, de nombreuses organisations se tournent vers des gestionnaires de paquets modernes comme Chocolatey ou winget (l'outil Microsoft natif pour Windows 10/11). Ces outils peuvent être déployés via un script de démarrage, puis utilisés pour installer et maintenir à jour de nombreuses applications de manière automatisée et fiable.

5. Group Policy Preferences

Les Group Policy Preferences constituent une extension importante des GPO qui se distingue des politiques classiques. Alors que les Policies configurent des paramètres de manière stricte et empêchent l'utilisateur de les modifier (comportement "enforced"), les Preferences établissent une configuration initiale mais laissent l'utilisateur libre de la changer par la suite. Par exemple, une politique peut désactiver complètement le Panneau de configuration, tandis qu'une préférence peut créer un lecteur réseau mappé que l'utilisateur pourra ensuite déconnecter s'il le souhaite.

5.2 Cas d'usage des Preferences

Les Preferences sont idéales pour :

Mappage de lecteurs réseau
Création de raccourcis
Gestion des imprimantes
Création de dossiers et fichiers
Modification du registre
Gestion des utilisateurs et groupes locaux
Variables d'environnement

5.3 Actions disponibles dans les Preferences

Create :

Crée l'élément s'il n'existe pas
Génère une erreur s'il existe déjà
Utile pour la configuration initiale

Replace :

Supprime l'élément existant et le recrée
Écrase complètement la configuration précédente
Attention aux pertes de données

Update :

Crée si n'existe pas, modifie si existe
Action recommandée dans la plupart des cas
Comportement le plus prévisible

Delete :

Supprime l'élément
Utile pour le nettoyage ou la désinstallation

6. Mappage de lecteurs réseau

Le mappage automatique de lecteurs réseau via GPO offre plusieurs avantages significatifs. Les utilisateurs n'ont plus besoin de mémoriser les chemins UNC complexes des partages réseau. La cohérence est assurée dans toute l'organisation car tous les utilisateurs ont les mêmes lettres de lecteur pour accéder aux mêmes ressources. Cela simplifie considérablement l'accès aux ressources partagées et facilite le développement de scripts ou d'applications qui utilisent des lettres de lecteur.

6.2 Options de configuration

Reconnect :

Si coché : Le lecteur sera recréé à chaque connexion
Garantit que le lecteur est toujours disponible

Show this drive / Show all drives :

Contrôle la visibilité du lecteur dans l'Explorateur
Utile pour masquer des lecteurs administratifs

Label as :

Nom affiché dans l'Explorateur
Aide l'utilisateur à identifier le lecteur

6.3 Variables d'environnement

Les variables d'environnement jouent un rôle crucial dans la personnalisation des mappages de lecteurs. Elles permettent de créer des chemins dynamiques qui s'adaptent à l'utilisateur ou à la machine. Par exemple, en utilisant %USERNAME%, on peut mapper un lecteur vers un dossier spécifique à chaque utilisateur, comme un répertoire personnel sur un serveur de fichiers.

Variables courantes :

%USERNAME% : Nom de l'utilisateur (ex: jdupont)
%USERDOMAIN% : Domaine de l'utilisateur (ex: ENTREPRISE)
%COMPUTERNAME% : Nom de l'ordinateur
%LOGONSERVER% : Contrôleur de domaine utilisé
%HOMEDRIVE% : Lecteur du répertoire personnel (ex: H:)

Exemple pratique :

Lecteur P: → \\serveur\projets\%USERNAME%

jdupont verra : \\serveur\projets\jdupont
mtremblay verra : \\serveur\projets\mtremblay

6.4 Bonnes pratiques

Il est recommandé d'établir des conventions de lettres de lecteur standardisées dans l'organisation. On évite généralement les lettres A:, B:, C: et D: qui sont réservées aux disques locaux et optiques. Des conventions typiques incluent H: pour le répertoire personnel (Home), P: pour les projets (Projects), S: pour les partages généraux (Share) et T: pour les fichiers temporaires. Une documentation claire de ces conventions aide les utilisateurs et les techniciens à s'y retrouver rapidement.

7. Gestion des groupes locaux

7.1 Comprendre les groupes locaux

Chaque machine Windows possède des groupes locaux qui définissent les permissions sur cette machine spécifique. Le groupe Administrators local, par exemple, accorde le contrôle total sur la machine, incluant la capacité d'installer des logiciels, de modifier les configurations système et d'accéder à tous les fichiers. Sans GPO, pour donner des droits d'administrateur local à une équipe IT sur 200 ordinateurs, il faudrait se connecter manuellement à chaque machine pour ajouter le groupe approprié au groupe Administrators local.

Il existe deux méthodes pour gérer les groupes locaux via GPO, mais l'une d'elles est dangereuse. La méthode Restricted Groups, accessible sous Computer Configuration → Policies → Windows Settings → Security Settings → Restricted Groups, écrase complètement le contenu du groupe. Cela signifie qu'elle peut accidentellement supprimer le compte Administrator local, rendant la machine impossible à administrer. Cette méthode n'est pas recommandée sauf dans des cas très spécifiques.

La méthode moderne et sûre utilise les Group Policy Preferences sous Computer Configuration → Preferences → Control Panel Settings → Local Users and Groups. Avec l'action "Update", on peut ajouter des membres à un groupe local sans écraser les membres existants, ce qui est beaucoup plus sûr. Cette approche est recommandée dans pratiquement tous les cas.

Un principe de sécurité fondamental doit être respecté : le principe du moindre privilège. Il ne faut jamais ajouter le groupe "Domain Users" aux administrateurs locaux, car cela donnerait des droits d'administrateur à tous les utilisateurs du domaine, créant un risque de sécurité majeur. À la place, il faut créer des groupes spécifiques comme "IT-Admins" pour les techniciens qui ont réellement besoin de droits administrateur, "IT-Support-Level2" pour le support avancé, ou "Developers" pour les développeurs (et uniquement sur leurs machines de développement).

Au-delà du groupe Administrators, d'autres groupes locaux peuvent être utiles à gérer. Le groupe Remote Desktop Users permet la connexion à distance via RDP, ce qui est pratique pour le support technique. Le groupe Backup Operators permet de sauvegarder et restaurer des fichiers, utile pour les systèmes de sauvegarde automatisés. Chacun de ces groupes répond à des besoins spécifiques tout en limitant les permissions accordées.

8. Création de dossiers via GPO

La création automatique de dossiers via GPO permet de standardiser la structure des répertoires sur toutes les machines de l'organisation. Cette standardisation facilite grandement les scripts et les procédures, tout en réduisant les erreurs. Des exemples typiques incluent la création de C:\Logs pour les journaux d'applications, C:\Temp\CompanyApp pour un dossier temporaire spécifique, C:\Data comme emplacement standard pour les données locales, ou C:\Scripts pour stocker des scripts locaux de maintenance.

Actions disponibles :

Create : Crée le dossier s'il n'existe pas
Delete : Supprime le dossier (attention aux données!)
Update : Modifie les attributs du dossier
Replace : Supprime et recrée

Attributs Windows :

Hidden : Dossier caché (pas visible par défaut)
Archive : Marque pour la sauvegarde
Read-only : Tentative de protection en lecture seule (peu fiable pour les dossiers)

Note : Pour des permissions réelles, utiliser les ACL (Access Control Lists) via NTFS, pas les attributs.

8.4 Gestion des permissions

Il est possible de configurer des permissions NTFS sur les dossiers créés via GPO en utilisant les Group Policy Preferences. Sous Computer Configuration → Preferences → Windows Settings → Folders, lors de la création ou de la modification d'un dossier, on peut définir des permissions spécifiques pour différents utilisateurs ou groupes. Cela permet de contrôler qui peut lire, écrire ou modifier les fichiers dans ces dossiers. Cependant, pour une gestion fine des permissions sur ces dossiers, il est souvent préférable d'utiliser un script PowerShell plutôt que l'interface limitée des Preferences. Un script de démarrage peut parcourir les dossiers créés et configurer précisément les permissions NTFS avec les cmdlets Get-Acl et Set-Acl, offrant un contrôle complet sur qui peut lire, écrire ou modifier les fichiers dans ces dossiers.

9. Modification du registre Windows

Le registre Windows est une base de données hiérarchique qui stocke toutes les configurations du système d'exploitation, du matériel, des logiciels et des utilisateurs. Il est organisé en clés (similaires à des dossiers) et en valeurs (similaires à des fichiers). Les deux ruches principales à connaître sont HKEY_LOCAL_MACHINE (HKLM) qui contient la configuration de la machine et s'applique à tous les utilisateurs, et HKEY_CURRENT_USER (HKCU) qui contient la configuration spécifique à l'utilisateur actuellement connecté.

Ruches principales (Hives) :

HKEY_LOCAL_MACHINE (HKLM) : Configuration de la machine
HKEY_CURRENT_USER (HKCU) : Configuration de l'utilisateur actuel
HKEY_CLASSES_ROOT : Associations de fichiers et COM
HKEY_USERS : Tous les profils utilisateurs
HKEY_CURRENT_CONFIG : Configuration matérielle actuelle

9.2 HKLM vs HKCU

HKEY_LOCAL_MACHINE :

S'applique à tous les utilisateurs de la machine
Nécessite des droits admin pour modification
Utiliser Computer Configuration dans les GPO
Exemples : Désactiver des services, configurer le réseau

HKEY_CURRENT_USER :

Spécifique à l'utilisateur connecté
L'utilisateur peut généralement le modifier
Utiliser User Configuration dans les GPO
Exemples : Fond d'écran, paramètres d'applications

La modification du registre via GPO présente des avantages mais aussi des risques. Certains paramètres ne sont accessibles que via le registre et ne disposent pas de template administratif correspondant. Cela permet de configurer des applications tierces ou d'accéder à des paramètres système très spécifiques. Cependant, une modification incorrecte peut rendre le système instable ou inutilisable. Les clés de registre sont également moins documentées que les templates officiels et peuvent cesser de fonctionner après une mise à jour Windows. La règle d'or est donc de toujours préférer les Administrative Templates quand ils sont disponibles, et n'utiliser le registre direct que lorsque c'est absolument nécessaire.

Pour trouver les bonnes clés de registre à modifier, plusieurs méthodes existent. La documentation officielle de Microsoft ou des éditeurs de logiciels est la source la plus fiable. On peut aussi utiliser l'éditeur de registre (regedit) pour faire une modification manuellement et noter exactement quelle clé a été modifiée. L'outil Process Monitor de Sysinternals permet de surveiller en temps réel tous les accès au registre et voir exactement ce qu'une application modifie. On peut également exporter le registre avant et après une modification manuelle avec la commande reg export, puis comparer les deux fichiers pour identifier les changements.

9.6 Exemples de modifications courantes

Désactiver Cortana :

Clé : HKLM\SOFTWARE\Policies\Microsoft\Windows\Windows Search
Valeur : AllowCortana
Type : REG_DWORD
Données : 0

Configurer la page d'accueil IE :

Clé : HKCU\Software\Microsoft\Internet Explorer\Main
Valeur : Start Page
Type : REG_SZ
Données : https://www.example.com

Désactiver Windows Update (non recommandé!) :

Clé : HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
Valeur : NoAutoUpdate
Type : REG_DWORD
Données : 1

10. Diagnostic et dépannage des GPO

Comprendre le processus d'application des GPO

Comprendre le processus d'application des GPO aide grandement au diagnostic des problèmes. Au démarrage, l'ordinateur contacte un contrôleur de domaine, récupère la liste des GPO qui lui sont applicables, télécharge les fichiers nécessaires depuis SYSVOL, applique les paramètres dans l'ordre LSDOU, puis exécute les scripts de démarrage. À la connexion utilisateur, un processus similaire se déroule pour récupérer et appliquer les GPO utilisateur avant d'exécuter les scripts de connexion.

Les GPO ne sont pas appliquées uniquement au démarrage et à la connexion. Par défaut, elles sont rafraîchies toutes les 90 minutes (avec une variation aléatoire de ±30 minutes pour éviter que toutes les machines interrogent le DC simultanément). Les contrôleurs de domaine eux-mêmes rafraîchissent leurs GPO toutes les 5 minutes. Les paramètres de sécurité sont même réappliqués toutes les 16 heures même s'il n'y a eu aucun changement, pour assurer qu'aucune modification locale non autorisée ne persiste.

Outils de diagnostic

La commande gpupdate /force permet de forcer immédiatement le rafraîchissement des GPO. Le paramètre /force réapplique tous les paramètres, même ceux qui n'ont pas changé. Il faut cependant comprendre les limites de cette commande : certains paramètres de Computer Configuration nécessitent un redémarrage complet pour s'appliquer, et les scripts de démarrage ou de connexion ne sont pas réexécutés par gpupdate.

Pour diagnostiquer les problèmes, la commande gpresult est l'outil principal. La commande gpresult /r affiche un résumé des GPO appliquées, tandis que gpresult /h rapport.html génère un rapport HTML complet et détaillé. Ce rapport contient la liste complète des GPO appliquées, tous les paramètres configurés, les paramètres qui ont été refusés et les raisons de ces refus, ainsi que diverses informations de diagnostic. C'est souvent le premier outil à utiliser quand quelque chose ne fonctionne pas comme prévu.

Les journaux d'événements Windows contiennent également des informations précieuses. Le journal le plus détaillé se trouve sous Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational. Il enregistre chaque étape du processus d'application des GPO, incluant les erreurs et avertissements. Dans le journal System, on peut filtrer par source "Group Policy" pour voir les événements de niveau système. Les Event ID importants à connaître incluent 1502 pour une GPO appliquée avec succès, 1503 pour une erreur lors de l'application, 1006 pour l'exécution d'un script, et 1085 pour le début du traitement d'une GPO.

Résolution des problèmes courants

Lorsque les GPO ne s'appliquent pas, plusieurs causes sont possibles. La machine pourrait ne pas être dans la bonne OU, la GPO pourrait ne pas être liée ou être désactivée, le filtrage de sécurité pourrait empêcher l'application, un filtre WMI pourrait bloquer, ou il pourrait y avoir des problèmes de réplication Active Directory. Une approche méthodique consiste à vérifier d'abord que la GPO existe et est bien liée, puis confirmer que l'ordinateur ou l'utilisateur est dans la bonne OU, forcer ensuite la mise à jour avec gpupdate /force et générer un rapport avec gpresult /h, consulter les journaux d'événements, et enfin vérifier la réplication AD avec repadmin /showrepl.

Quand un script ne s'exécute pas, les causes communes incluent un chemin UNC inaccessible (vérifier les permissions sur le partage), un script placé dans la mauvaise section (PowerShell doit être dans "PowerShell Scripts" et non dans "Scripts" legacy), une erreur dans le script lui-même (le tester manuellement), ou simplement une GPO pas encore appliquée (redémarrer après gpupdate /force). Pour l'installation de logiciels, vérifier que le fichier MSI est accessible via son chemin UNC, que les permissions sont correctes (Domain Computers doit avoir Read), que le MSI est bien formé et compatible avec le déploiement GPO, et qu'il n'y a pas de conflits avec une version déjà installée.

11. Limitations et alternatives aux GPO

Malgré leur puissance, les GPO présentent plusieurs limitations. Elles sont spécifiques aux environnements Windows et ne s'appliquent pas aux systèmes Linux ou macOS. La gestion des GPO peut devenir complexe dans de grands environnements avec de nombreuses OU et GPO, rendant le dépannage difficile. Certaines configurations avancées ne sont pas possibles via GPO, nécessitant des scripts ou des outils tiers. De plus, les GPO ne gèrent pas efficacement les mises à jour logicielles, et le déploiement d'applications est limité aux fichiers MSI. La gestion de configuration complexe et conditionnelle est limitée, le reporting avancé n'est pas leur force, et elles ne peuvent pas gérer les machines qui ne sont pas jointes au domaine Active Directory.

Pour pallier ces limitations, plusieurs outils complémentaires existent. Microsoft Endpoint Configuration Manager (anciennement SCCM) offre un déploiement d'applications beaucoup plus avancé, la gestion centralisée des mises à jour avec WSUS intégré, un inventaire complet du matériel et des logiciels, et l'exécution de scripts à distance. C'est une solution puissante mais également plus complexe et coûteuse que les GPO. Microsoft Intune (aussi appelé Microsoft Endpoint Manager) représente l'approche cloud moderne. Il permet la gestion des appareils qui ne sont pas nécessairement joints à un domaine, supporte les appareils mobiles iOS et Android, et adopte une approche cloud-first adaptée aux organisations modernes. PowerShell DSC (Desired State Configuration) offre une configuration déclarative similaire aux GPO mais avec beaucoup plus de puissance et de flexibilité. Il peut gérer non seulement Windows mais aussi Linux et les ressources cloud. La courbe d'apprentissage est plus élevée mais les possibilités sont considérablement élargies. D'autres outils comme Ansible (que nous verrons dans ce cours), Puppet ou Chef représentent des solutions de gestion de configuration multiplateforme adoptant une approche DevOps et Infrastructure as Code, bien qu'ils ne soient pas spécifiques à Windows.

Dans une entreprise moderne, on adopte généralement une stratégie hybride. Les GPO restent l'outil de choix pour la configuration de base de Windows, les politiques de sécurité et les scripts simples. SCCM ou Intune prennent en charge le déploiement d'applications et la gestion des mises à jour. PowerShell est utilisé pour l'automatisation personnalisée et les tâches de maintenance spécifiques. Chaque outil a sa place et ses forces, et c'est leur utilisation combinée qui crée un environnement bien géré.