Le problème
Tous ceux qui gèrent un Active Directory depuis quelques années le savent : l’application des GPO est parfois capricieuse. En théorie, Windows applique les politiques au démarrage, à l’ouverture de session, puis toutes les 90 minutes avec un décalage aléatoire. En pratique, il arrive qu’une GPO ne descende pas, qu’une machine garde une vieille config, ou qu’un changement mette un temps déraisonnable à se propager.
Un gpupdate /force systématique au démarrage force la réapplication complète de toutes les politiques, qu’elles aient changé ou non. C’est la ceinture et les bretelles : on ne compte pas sur le cycle natif, on force.
On en profite pour vider le cache DNS au passage avec ipconfig /flushdns — pratique pour repartir avec une résolution DNS propre à chaque démarrage, surtout après des changements d’enregistrements ou des migrations de serveurs.
Pourquoi un script de démarrage et pas un script de logon
C’est le point technique qui change tout.
Un script de logon s’exécute en contexte utilisateur — avec les droits de la personne qui ouvre la session. Si l’utilisateur est limité (ce qui est le cas sur un parc bien sécurisé), le script hérite de ces limitations et peut échouer silencieusement.
Un script de démarrage s’exécute en contexte SYSTEM — le compte le plus privilégié de la machine, au boot, avant même qu’un utilisateur se connecte. Aucune dépendance aux droits utilisateur, aucune limitation.
Sur mon infra, l’ancienne version tournait en script de logon et dépendait des droits de l’utilisateur. Le passage en script de démarrage en contexte SYSTEM élimine cette fragilité : le gpupdate s’exécute de façon fiable à chaque boot, quelle que soit la personne qui utilisera ensuite la machine.
Création de la GPO
Dans la GPMC :
Clic droit sur l'OU cible → Create a GPO in this domain and link it here
Nom : Startup GPUpdate FlushDNS
Lier sur STATIONS (et SERVEURS si tu veux la même fiabilité côté serveurs).
Le script PowerShell
Crée un fichier startup_maintenance.ps1 :
# Force l'application de toutes les GPO
gpupdate /force /wait:0
# Vide le cache DNS
ipconfig /flushdns
Le paramètre /wait:0 est important : il indique à gpupdate de ne pas bloquer le script en attendant la fin du traitement. La commande est lancée et rend la main immédiatement, la machine continue de démarrer pendant que les GPO s’appliquent. Sans ça, un démarrage pourrait traîner si une politique met du temps à se traiter.
Déployer le script
Place le fichier dans le dossier Scripts de la GPO :
\\domaine\SYSVOL\domaine\Policies\{GUID-GPO}\Machine\Scripts\Startup\
Puis dans la GPMC :
Computer Configuration → Policies → Windows Settings → Scripts → Démarrage
→ Onglet "Scripts PowerShell" → Ajouter → Parcourir → startup_maintenance.ps1
Une nuance à connaître
Un gpupdate /force au boot déclenche un cycle d’application qui s’ajoute à celui que Windows fait nativement au démarrage. C’est volontairement redondant — c’est exactement ce qu’on veut quand on a l’expérience d’applications de GPO aléatoires. Le léger coût en temps de démarrage est largement compensé par la fiabilité gagnée.
À noter : gpupdate /force en script de démarrage rafraîchit la politique ordinateur de façon fiable. La politique utilisateur, elle, s’applique de toute façon à l’ouverture de session qui suit le boot.
Vérification post-déploiement
Après reboot d’une machine de test, dans l’observateur d’événements :
Observateur d'événements → Journaux des applications et services
→ Microsoft → Windows → GroupPolicy → Operational
Les Event ID 4115 / 5115 confirment l’exécution du script de démarrage. On peut aussi vérifier la fraîcheur de la dernière application de politique :
gpresult /r /scope:computer
Récapitulatif
| Composant | Détail |
|---|---|
| GPO Name | Startup GPUpdate FlushDNS |
| Méthode | Script PowerShell de démarrage |
| Contexte | SYSTEM (pas de dépendance aux droits user) |
| Script | startup_maintenance.ps1 |
| Commandes | gpupdate /force /wait:0 + ipconfig /flushdns |
| Cible | STATIONS (+ SERVEURS optionnel) |
Bibliothèque GPO — retour à l’index