Un script GPO permet d’exécuter automatiquement un fichier sur des ordinateurs ou des utilisateurs ciblés dans Active Directory, sans intervention manuelle. La stratégie de groupe peut déclencher ce script à quatre moments précis : démarrage de l’ordinateur, arrêt, ouverture de session ou fermeture de session. La configuration se fait dans la console GPMC, sous Stratégies, Paramètres Windows, puis Scripts, avant de lier la GPO à l’OU, au domaine ou au site concerné.
Configuration ordinateur ou Configuration utilisateur : où ajouter le script
Une GPO contient deux grandes sections distinctes : Configuration ordinateur et Configuration utilisateur. Le choix entre les deux dépend du moment où le script doit s’exécuter.
Les scripts de démarrage et d’arrêt se configurent dans Configuration ordinateur, car ils s’appliquent à la machine elle-même, avant ou après la session d’un utilisateur. Les scripts d’ouverture de session et de fermeture de session se configurent dans Configuration utilisateur, puisqu’ils dépendent du compte qui se connecte. Cette distinction est essentielle : un script placé au mauvais endroit ne s’exécutera tout simplement jamais, même si la GPO est correctement liée.
Le chemin GPMC pour ajouter un script à une GPO
Dans la console de gestion des stratégies de groupe (GPMC), la configuration d’un script suit toujours le même chemin :
- Ouvrez ou créez la GPO concernée, puis cliquez sur Modifier.
- Déroulez Configuration ordinateur ou Configuration utilisateur selon le cas.
- Allez dans Stratégies, puis Paramètres Windows.
- Cliquez sur Scripts (démarrage/arrêt) ou Scripts (ouverture de session/fermeture de session).
- Double-cliquez sur l’événement souhaité, puis ajoutez le fichier script et ses éventuels paramètres.
Ce chemin reste identique quel que soit le type de script utilisé, qu’il s’agisse d’un script PowerShell, d’un script batch ou d’un fichier VBS.
Script de démarrage, arrêt, ouverture ou fermeture de session : quel cas choisir
Le contexte d’exécution change selon l’événement choisi, ce qui a une influence directe sur les droits disponibles et les cas d’usage possibles.
- Démarrage : le script s’exécute avant l’ouverture de session, avec le compte Local System. Il convient aux tâches système comme le mappage de lecteurs réseau globaux ou l’installation silencieuse de composants.
- Arrêt : le script s’exécute juste avant l’extinction de l’ordinateur, également avec Local System. Il est utile pour nettoyer des fichiers temporaires ou journaliser un état avant coupure.
- Ouverture de session : le script s’exécute dans le contexte de l’utilisateur connecté, dès qu’il ouvre sa session. Il permet par exemple de mapper des lecteurs personnels ou de lancer une configuration propre au profil.
- Fermeture de session : le script s’exécute quand l’utilisateur se déconnecte, toujours avec ses propres droits, souvent pour journaliser la déconnexion ou nettoyer des données temporaires liées à la session.
Tableau comparatif : démarrage, arrêt, ouverture et fermeture de session
| Événement | Contexte d’exécution | Emplacement GPO | Cas d’usage typique |
|---|---|---|---|
| Démarrage | Local System | Configuration ordinateur | Mappage réseau global, installation |
| Arrêt | Local System | Configuration ordinateur | Nettoyage, journalisation système |
| Ouverture de session | Utilisateur connecté | Configuration utilisateur | Mappage personnel, configuration profil |
| Fermeture de session | Utilisateur connecté | Configuration utilisateur | Nettoyage, journalisation session |
PowerShell, batch ou VBS : quel type de script utiliser dans une GPO
Les GPO acceptent plusieurs formats de script, et le choix dépend surtout des habitudes de l’administrateur et de la complexité de la tâche à réaliser.
Un script PowerShell GPO convient bien aux tâches modernes et complexes, grâce à ses nombreuses cmdlets et à sa meilleure gestion des erreurs. Il faut cependant vérifier la stratégie d’exécution PowerShell (Execution Policy) sur les postes cibles : si elle bloque les scripts non signés, le script GPO ne s’exécutera pas, même correctement configuré dans la console. Un script batch GPO reste pertinent pour des actions simples et rapides, comme lancer une commande ou copier un fichier, avec l’avantage d’une compatibilité universelle sans configuration supplémentaire. Les scripts VBS sont plus anciens et de moins en moins recommandés, mais restent parfois utilisés dans des environnements historiques.
Dans l’onglet des scripts PowerShell d’une GPO, il est possible de définir l’ordre d’exécution par rapport aux scripts batch ou VBS, ce qui permet de faire cohabiter plusieurs types de fichiers si nécessaire.
Où placer le fichier script : SYSVOL et partage réseau
Le fichier script doit être accessible par tous les ordinateurs ou utilisateurs ciblés par la GPO. Par défaut, lorsqu’un script est ajouté depuis la console GPMC, il est automatiquement copié dans le dossier de la GPO au sein du SYSVOL, ce qui garantit sa réplication sur tous les contrôleurs de domaine.
Il est également possible de référencer un script situé sur un partage réseau externe, mais cela ajoute une dépendance : si ce partage est indisponible au moment de l’exécution, notamment au démarrage avant que le réseau soit pleinement initialisé, le script échouera. Utiliser le SYSVOL reste donc la solution la plus fiable pour les scripts de démarrage et d’arrêt, où la disponibilité réseau n’est pas toujours garantie.
Lier la GPO à une OU, un domaine ou un site Active Directory
Une fois le script configuré, la GPO doit être liée à un conteneur Active Directory pour s’appliquer réellement. Cette liaison peut se faire sur une unité d’organisation (OU), sur le domaine entier, ou sur un site Active Directory. Le choix du niveau de liaison détermine l’étendue des ordinateurs ou utilisateurs concernés par le script.
Pour limiter les risques, il est recommandé de lier d’abord la GPO à une OU de test contenant un nombre restreint d’ordinateurs ou de comptes utilisateurs, avant de l’étendre à une population plus large une fois le comportement validé.
Tester son script GPO avant déploiement
Avant de généraliser une GPO contenant un script, un test contrôlé permet d’éviter les mauvaises surprises à grande échelle :
- Créez une OU de test contenant un ou deux ordinateurs, ou déplacez temporairement un compte utilisateur de test dans cette OU.
- Liez la GPO uniquement à cette OU de test.
- Sur le poste concerné, exécutez la commande gpupdate /force pour forcer l’application immédiate de la stratégie.
- Redémarrez l’ordinateur pour un script de démarrage ou d’arrêt, ou reconnectez-vous pour un script d’ouverture ou de fermeture de session.
- Vérifiez que le script s’est bien exécuté, par exemple via un fichier journal généré par le script lui-même.
Cette étape de test évite de déployer un script défaillant sur l’ensemble du domaine, et permet de repérer rapidement un problème de droits ou de chemin d’accès.
Pourquoi un script GPO ne se lance pas : les causes les plus fréquentes
Plusieurs raisons expliquent généralement qu’un script GPO ne s’exécute pas comme prévu :
- La GPO n’est pas correctement liée à l’OU contenant l’ordinateur ou l’utilisateur concerné, ou un filtrage de sécurité exclut la cible sans que cela soit visible au premier coup d’œil.
- Le chemin du script est inaccessible au moment de l’exécution, notamment pour un partage réseau externe sollicité avant que la connexion réseau ne soit pleinement établie.
- Les droits sur le fichier ou le dossier du script sont insuffisants pour le compte qui doit l’exécuter, qu’il s’agisse de Local System ou d’un utilisateur standard.
- La stratégie d’exécution PowerShell bloque les scripts non signés, ce qui empêche silencieusement le lancement d’un script PowerShell GPO pourtant bien configuré.
- Le test a été réalisé sans redémarrage ni reconnexion, alors que ces actions sont indispensables pour déclencher respectivement les scripts ordinateur et les scripts utilisateur.
- Le script est trop long ou contient une boucle bloquante, ce qui peut retarder l’ouverture de session au point de sembler ne jamais se terminer.
Vérifier ces points dans l’ordre permet généralement d’identifier rapidement la cause d’un script GPO qui ne se déclenche pas.
Bonnes pratiques de sécurité pour les scripts déployés par GPO
Un script exécuté via une GPO tourne souvent avec des droits élevés, ce qui impose une certaine rigueur. Évitez d’intégrer des mots de passe en clair dans un script batch ou PowerShell, car le fichier reste accessible dans le SYSVOL à toute personne disposant des droits de lecture nécessaires. Privilégiez systématiquement un test sur une OU limitée avant tout déploiement large, et ajoutez une journalisation simple dans le script, par exemple l’écriture d’un fichier log horodaté, pour pouvoir vérifier facilement son bon fonctionnement sur plusieurs postes.
Script GPO ou tâche planifiée via GPO : comment choisir la bonne méthode
Un script GPO classique convient parfaitement pour une action simple, déclenchée une seule fois au démarrage, à l’arrêt, à l’ouverture ou à la fermeture de session. Dès que le besoin devient plus complexe, une tâche planifiée déployée par GPO devient souvent préférable : elle permet de définir un compte d’exécution spécifique, de programmer plusieurs déclencheurs indépendants, et d’obtenir un historique d’exécution plus détaillé que celui offert par un simple script. En résumé, le script GPO reste la solution la plus rapide à mettre en place pour une automatisation ponctuelle, tandis que la tâche planifiée s’impose dès que la fiabilité, la traçabilité ou la flexibilité des déclencheurs deviennent prioritaires.
