Scripts et planification via GPO¶

Les 4 types de scripts GPO¶

Vue d'ensemble¶

Group Policy permet d'attacher des scripts à quatre événements du cycle de vie machine/utilisateur.

Deux événements sont liés à la machine : Startup (démarrage) et Shutdown (arrêt). Deux événements sont liés à l'utilisateur : Logon (ouverture de session) et Logoff (fermeture de session). Ces quatre points d'accroche correspondent à des CSE distinctes et à des emplacements distincts dans le GPT.

Emplacement dans le GPT¶

Les scripts sont stockés dans SYSVOL, à l'intérieur du dossier de la GPO :

\\<domain>\SYSVOL\<domain>\Policies\{GPO-GUID}\
  Machine\
    Scripts\
      Startup\         ← scripts de démarrage machine
      Shutdown\        ← scripts d'arrêt machine
      scripts.ini      ← configuration de tous les scripts machine
  User\
    Scripts\
      Logon\           ← scripts d'ouverture de session utilisateur
      Logoff\          ← scripts de fermeture de session utilisateur
      scripts.ini      ← configuration de tous les scripts utilisateur

Les fichiers de script eux-mêmes (.bat, .ps1, .vbs) doivent être copiés dans le sous-dossier correspondant à leur type. Si vous référencez un script par son nom seul dans scripts.ini, Windows le cherche dans ce sous-dossier. Vous pouvez aussi spécifier un chemin UNC absolu — le script n'a alors pas besoin d'être dans le GPT.

GUIDs des CSE Scripts¶

Chaque type de script est géré par une CSE enregistrée sous HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\.

Comparatif des 4 types¶

Lecture de scripts.ini par la CSE¶

Au moment du traitement (Startup, Logon, etc.), gpsvc invoque gpscript.dll. Celle-ci localise scripts.ini dans le GPT de chaque GPO applicable, lit la section correspondante au type d'événement, et lance gpscript.exe pour chaque script déclaré.

gpscript.exe est le processus intermédiaire responsable du lancement effectif. Il détermine le moteur à utiliser (cmd, PowerShell, wscript) en fonction de l'extension du script, et signale à gpsvc la complétion ou le timeout.

Format de scripts.ini¶

Structure générale¶

scripts.ini est un fichier INI standard avec quatre sections possibles, une par type de script.

[Startup]
0CmdLine=MonScript.ps1
0Parameters=-Mode Deploy -Verbose

[Shutdown]
0CmdLine=Cleanup.bat
0Parameters=

[Logon]
0CmdLine=MapDrives.ps1
0Parameters=-Env Prod

[Logoff]
0CmdLine=AuditSession.ps1
0Parameters=

Clés numérotées et ordre d'exécution¶

Chaque script dans une section est défini par deux clés numérotées : NCmdLine= (chemin du script) et NParameters= (paramètres à passer). La numérotation commence à 0 et est continue.

[Startup]
; Premier script : configuration réseau
0CmdLine=ConfigNetwork.ps1
0Parameters=-SiteCode PAR01

; Deuxième script : déploiement d'agent
1CmdLine=\\deploy.corp.local\agents\InstallAgent.ps1
1Parameters=-Silent -NoRestart

L'ordre d'exécution respecte la numérotation : 0 est exécuté avant 1, 1 avant 2, etc. Si une GPO de niveau supérieur et une GPO de niveau inférieur définissent toutes les deux des scripts Startup, ils sont fusionnés — les scripts de la GPO la plus haute dans LSDOU sont exécutés en premier pour Startup/Logon, et en dernier pour Shutdown/Logoff.

Clés reconnues dans scripts.ini¶

Les autres clés sont ignorées. Il n'y a pas de clé pour définir le timeout ou le compte d'exécution dans scripts.ini — ces comportements sont contrôlés par les Administrative Templates et les valeurs de registre Winlogon.

Scripts PowerShell dans le contexte GPO¶

Politique d'exécution requise¶

Par défaut, la politique d'exécution PowerShell sur les systèmes Windows est Restricted — aucun script n'est autorisé. Pour exécuter des scripts GPO en PowerShell, la politique doit être au minimum RemoteSigned.

La méthode recommandée est de la définir via GPO :

Computer Configuration
  └── Policies
        └── Administrative Templates
              └── Windows Components
                    └── Windows PowerShell
                          └── Turn on Script Execution
                                → Enabled : Allow local scripts and remote signed scripts
                                  (équivalent à RemoteSigned)

Le processus gpscript.exe¶

gpscript.exe est le lanceur de scripts GPO. Il est invoqué par gpscript.dll pour chaque script à exécuter.

Pour un script PowerShell, gpscript.exe construit et exécute une commande de la forme :

powershell.exe -NonInteractive -NoProfile -ExecutionPolicy RemoteSigned
  -File "\\domain\SYSVOL\domain\Policies\{GUID}\Machine\Scripts\Startup\MonScript.ps1"
  -Mode Deploy -Verbose

Pour un script .bat ou .cmd, il invoque cmd.exe /c. Pour un .vbs, il invoque wscript.exe ou cscript.exe.

gpscript.exe est visible dans le Gestionnaire des tâches et dans Process Monitor pendant la phase de traitement des scripts. Son PID parent est le processus gpsvc ou winlogon.exe selon le contexte.

Timeout par défaut : 600 secondes¶

Par défaut, gpscript.exe attend 600 secondes (10 minutes) l'exécution de chaque script avant de considérer le traitement comme échoué. Si le script dépasse ce délai, il est terminé de force et un événement d'erreur est consigné.

Ce timeout est modifiable via GPO :

Computer Configuration
  └── Policies
        └── Administrative Templates
              └── System
                    └── Scripts
                          ├── Maximum wait time for Group Policy scripts
                          │     → Valeur en secondes (0 = attente infinie, déconseillé)
                          └── (Paramètres séparés pour Startup, Shutdown, Logon, Logoff)

Passer des paramètres à un script PowerShell¶

Les paramètres définis dans NParameters= sont transmis directement à la ligne de commande PowerShell. Ils doivent être compatibles avec la syntaxe -File de PowerShell — c'est-à-dire des paramètres nommés correspondant aux param() déclarés dans le script.

param(
    [string]$Mode = "Default",
    [switch]$Verbose
)

# Corps du script...
Write-EventLog -LogName Application -Source "GPO-Scripts" `
    -EventId 9000 -Message "Script executed in mode: $Mode"

[Startup]
0CmdLine=MonScript.ps1
0Parameters=-Mode Deploy -Verbose

Scripts synchrones vs asynchrones¶

Valeurs de registre Winlogon¶

Le comportement synchrone ou asynchrone des scripts GPO est contrôlé par des valeurs DWORD sous :

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Ces valeurs sont écrites par la GPO via les Administrative Templates (System > Scripts) — ne les modifiez pas directement dans le registre sans GPO associée, car un refresh GPO les écrasera.

Get-ItemProperty `
    "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" |
    Select-Object RunStartupScriptSync, RunLogonScriptSync, RunShutdownScriptSync

RunStartupScriptSync  RunLogonScriptSync  RunShutdownScriptSync
--------------------  ------------------  ---------------------
                   1                   0                      1

Mode synchrone : comportement¶

En mode synchrone, Windows attend la complétion de tous les scripts du type concerné avant de continuer.

Pour Startup synchrone (RunStartupScriptSync=1) : la machine ne présente pas l'écran de logon tant que tous les scripts Startup ne sont pas terminés. L'utilisateur voit l'écran "Applying computer settings..." pendant toute la durée.

Pour Logon synchrone (RunLogonScriptSync=1) : le bureau de l'utilisateur n'est pas affiché tant que tous les scripts Logon ne sont pas terminés. L'utilisateur voit l'écran "Applying your settings..." pendant toute la durée.

Mode asynchrone : comportement¶

En mode asynchrone (défaut pour Logon), les scripts sont lancés en arrière-plan. Le bureau apparaît immédiatement et les scripts continuent de s'exécuter en parallèle.

L'impact visible est minimal pour l'utilisateur. Mais si le script doit produire un effet visible avant que l'utilisateur interagisse (mapper un lecteur réseau, créer un fichier de configuration), il peut ne pas être terminé au moment où l'utilisateur en a besoin.

Quand le mode asynchrone est dangereux¶

Certaines tâches doivent impérativement être terminées avant que l'utilisateur accède au bureau :

• Mappage de lecteurs réseau utilisés par des applications lancées au démarrage
• Configuration de proxy requise pour l'accès à l'intranet
• Création de profil ou de répertoire utilisateur absent

Pour ces cas, le script doit être synchrone — ou migré vers une GPP Scheduled Task de type Immediate qui s'exécute dans le contexte SYSTEM sans impacter le logon.

Cycle de vie de gpscript.exe¶

Le diagramme suivant illustre le flux complet depuis l'appel de gpsvc jusqu'à la complétion ou l'expiration du timeout.

sequenceDiagram
    participant W as winlogon.exe / gpsvc
    participant G as gpscript.dll (CSE Scripts)
    participant S as gpscript.exe
    participant P as powershell.exe / cmd.exe

    W->>G: ProcessGroupPolicy()<br/>(événement : Startup / Logon / etc.)
    G->>G: Localise scripts.ini dans le GPT<br/>de chaque GPO applicable
    G->>G: Parse la section [Startup] / [Logon]<br/>construit la liste des scripts

    loop Pour chaque script (0, 1, 2…)
        G->>S: CreateProcess(gpscript.exe)<br/>/startup "CmdLine" "Parameters"
        S->>P: CreateProcess(powershell.exe -File ... -Params)<br/>ou cmd.exe /c ... ou wscript.exe ...
        P-->>S: Exécution du script

        alt Script terminé avant timeout (600s)
            P->>S: ExitCode
            S->>G: Complétion signalée
        else Timeout dépassé
            S->>P: TerminateProcess()
            S->>G: Timeout signalé
            G->>W: Event ID 4018 (timeout)<br/>écrit dans le journal System
        end
    end

    G->>W: ProcessGroupPolicy() retourne<br/>(succès ou échec partiel)
    W->>W: Continue (affichage bureau / démarrage)

GPP Scheduled Tasks¶

Pourquoi GPP Scheduled Tasks plutôt que scripts GPO¶

Les scripts GPO (Startup/Logon) présentent des limitations architecturales importantes :

• Ils s'exécutent dans un seul contexte temporel défini par l'événement système.
• Ils bloquent la session en mode synchrone.
• Ils ne supportent pas de déclencheurs avancés (délai, heure précise, inactivité).
• Ils n'offrent aucun reporting natif.

Les GPP Scheduled Tasks (Group Policy Preferences > Scheduled Tasks) permettent de créer, modifier ou supprimer des tâches planifiées Windows via GPO, avec toute la puissance du moteur de tâches planifiées Windows.

Types de tâches GPP¶

La GPMC propose plusieurs types de tâches dans Computer/User Configuration > Preferences > Control Panel Settings > Scheduled Tasks :

Format XML dans SYSVOL¶

Les tâches GPP sont stockées dans SYSVOL sous forme de fichiers XML :

\\<domain>\SYSVOL\<domain>\Policies\{GPO-GUID}\
  Machine\
    Preferences\
      ScheduledTasks\
        ScheduledTasks.xml
  User\
    Preferences\
      ScheduledTasks\
        ScheduledTasks.xml

Exemple de ScheduledTasks.xml pour une Immediate Task PowerShell exécutée en SYSTEM :

<?xml version="1.0" encoding="utf-8"?>
<ScheduledTasks clsid="{CC63F200-7309-4ba0-B154-A0CE60491FE6}">
  <ImmediateTaskV2
    clsid="{9756B581-76EC-4169-9AFC-0CA8D43ADB5F}"
    name="Deploy-AgentCorp"
    image="0"
    changed="2025-03-01 09:00:00"
    uid="{A1B2C3D4-E5F6-7890-ABCD-EF1234567890}"
    userContext="0"
    removePolicy="0">
    <Properties
      action="C"
      name="Deploy-AgentCorp"
      runAs="NT AUTHORITY\System"
      logonType="S4U">
      <Task version="1.3">
        <RegistrationInfo>
          <Author>CORP\gpo-admin</Author>
          <Description>Deploy monitoring agent via GPO</Description>
        </RegistrationInfo>
        <Principals>
          <Principal id="Author">
            <UserId>NT AUTHORITY\System</UserId>
            <RunLevel>HighestAvailable</RunLevel>
          </Principal>
        </Principals>
        <Settings>
          <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
          <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
          <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
          <ExecutionTimeLimit>PT30M</ExecutionTimeLimit>
        </Settings>
        <Actions>
          <Exec>
            <Command>powershell.exe</Command>
            <Arguments>-NonInteractive -NoProfile -ExecutionPolicy RemoteSigned
              -File "\\deploy.corp.local\scripts\Install-Agent.ps1" -Silent</Arguments>
          </Exec>
        </Actions>
      </Task>
    </Properties>
  </ImmediateTaskV2>
</ScheduledTasks>

GPP Scheduled Tasks vs Scripts GPO¶

Options de compte d'exécution¶

Les GPP Scheduled Tasks offrent plusieurs options pour le compte sous lequel la tâche s'exécute :

• NT AUTHORITY\System : recommandé pour les tâches d'infrastructure (installation, configuration système). Accès complet à la machine locale, mais pas d'accès aux ressources réseau avec l'identité de la machine.
• Utilisateur connecté (logonType="InteractiveToken") : la tâche s'exécute dans le contexte de la session courante — utile pour les tâches utilisateur avec accès à la session graphique.
• Compte de service : un compte de service AD dédié — requis si la tâche doit accéder à des ressources réseau authentifiées (partages, bases de données).

Exemple complet : PowerShell en SYSTEM au démarrage¶

Scénario : déployer un agent de supervision lors du démarrage, sans bloquer la session.

Dans la GPMC :

Computer Configuration
  └── Preferences
        └── Control Panel Settings
              └── Scheduled Tasks
                    └── Clic droit → New → Immediate Task (Windows Vista and later)
                          → General : Run as NT AUTHORITY\System, Run whether user is logged on or not
                          → Actions : powershell.exe
                            Arguments : -NonInteractive -NoProfile -ExecutionPolicy RemoteSigned
                                        -File "\\deploy.corp.local\scripts\Install-Agent.ps1" -Silent
                          → Settings : Stop task if it runs longer than 30 minutes

Vérification sur le poste cible :

Get-ScheduledTask -TaskName "Deploy-AgentCorp" |
    Select-Object TaskName, State, @{n="LastRunTime";e={$_.LastRunTime}},
                  @{n="LastResult";e={$_.LastTaskResult}}

TaskName         State    LastRunTime          LastResult
--------         -----    -----------          ----------
Deploy-AgentCorp Ready    2025-03-01 09:14:32           0

Un LastResult de 0 indique une exécution réussie (0x00000000 = S_OK).

Event IDs pour le diagnostic des scripts¶

Tableau des Event IDs Scripts CSE¶

Les événements liés au traitement des scripts GPO sont enregistrés dans le journal System (pour les scripts Machine) et Application (pour certains scripts utilisateur), sous la source Microsoft-Windows-GroupPolicy.

Analyser les délais de logon avec Event ID 4018¶

L'Event ID 4018 contient les informations critiques pour identifier le script incriminé et la durée dépassée.

Log Name:    System
Source:      Microsoft-Windows-GroupPolicy
Event ID:    4018
Level:       Error
Description: The Group Policy Scripts Client Side Extension timed out
             (600 seconds) while processing Logon script for user CORP\jdoe.
             The script was: \\corp.local\SYSVOL\corp.local\Policies\
             {A1B2C3D4-...}\User\Scripts\Logon\MapDrives.ps1

Mesurer la durée réelle avec les Event IDs 4016 et 4017¶

Les Event IDs 4016 (début) et 4017 (fin) permettent de calculer la durée exacte du traitement de la CSE Scripts.

$start = Get-WinEvent -LogName System |
    Where-Object { $_.Id -eq 4016 -and $_.ProviderName -eq "Microsoft-Windows-GroupPolicy" } |
    Sort-Object TimeCreated -Descending |
    Select-Object -First 1

$end = Get-WinEvent -LogName System |
    Where-Object { $_.Id -eq 4017 -and $_.ProviderName -eq "Microsoft-Windows-GroupPolicy" } |
    Sort-Object TimeCreated -Descending |
    Select-Object -First 1

$duration = $end.TimeCreated - $start.TimeCreated
Write-Output "Scripts CSE duration: $($duration.TotalSeconds) seconds"

Scripts CSE duration: 47.38 seconds

wevtutil set-log "Microsoft-Windows-GroupPolicy/Operational" /enabled:true

Corrélation avec le délai perçu par l'utilisateur¶

En mode Logon synchrone, la durée entre les Event IDs 4016 et 4017 (ou le timeout 4018) correspond exactement au délai que l'utilisateur perçoit entre la saisie de ses credentials et l'apparition du bureau.

Un délai > 10 secondes mérite investigation. Un délai > 30 secondes est un incident de niveau 2.

Piège de production : logon bloqué par un script lent¶

Symptôme¶

Un parc de 300 postes présente un délai d'ouverture de session systématique de 35 à 50 secondes après l'entrée des credentials. L'écran "Applying your settings..." reste affiché pendant toute cette durée. Le phénomène est apparu après le déploiement d'un nouveau script Logon GPO il y a deux semaines.

Diagnostic¶

Étape 1 : Identifier le délai dans les Event Logs.

Sur un poste affecté, dans le journal System (source Microsoft-Windows-GroupPolicy) :

Get-WinEvent -LogName System -MaxEvents 500 |
    Where-Object {
        $_.ProviderName -eq "Microsoft-Windows-GroupPolicy" -and
        $_.Id -in @(4016, 4017, 4018)
    } |
    Select-Object TimeCreated, Id, Message |
    Sort-Object TimeCreated

TimeCreated           Id   Message
-----------           --   -------
2025-03-15 08:42:11  4016  The Group Policy Scripts Client Side Extension...
2025-03-15 08:42:56  4017  The Group Policy Scripts Client Side Extension...

La différence : 45 secondes. C'est le temps que prend la CSE Scripts à traiter tous les scripts Logon.

Étape 2 : Identifier le script responsable.

Avec le journal opérationnel activé, les Event IDs 5000–5010 détaillent chaque script individuel et sa durée.

Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" |
    Where-Object { $_.Message -match "script" -and $_.Level -ne 4 } |
    Select-Object TimeCreated, Id, Message |
    Sort-Object TimeCreated -Descending |
    Select-Object -First 20

Le résultat pointe vers MapNetworkDrives.ps1 — un script qui tente de mapper 8 lecteurs réseau via des chemins UNC vers un serveur de fichiers distant, avec un timeout de connexion de 5 secondes par lecteur.

Étape 3 : Confirmer la cause.

Le script MapNetworkDrives.ps1 effectue une résolution DNS pour chaque serveur de fichiers et attend une réponse réseau. Sur des sites distants avec une latence WAN élevée, cela prend 4 à 6 secondes par lecteur × 8 lecteurs = 32 à 48 secondes.

Résolution¶

Option 1 (recommandée) : Migrer vers une GPP Drive Map.

La GPP Drive Maps est conçue exactement pour ce cas d'usage. Elle s'exécute en arrière-plan (asynchrone par design), supporte l'Item-Level Targeting, et ne bloque pas le logon.

User Configuration
  └── Preferences
        └── Windows Settings
              └── Drive Maps
                    └── New → Mapped Drive
                          Action : Create
                          Location : \\server\share
                          Drive Letter : H
                          Label : Profil (H:)
                          Connect As : (laisser vide pour l'utilisateur connecté)

Option 2 (si le script doit rester) : Le convertir en GPP Scheduled Task asynchrone.

Si le script contient une logique complexe qui ne peut pas être remplacée par une Drive Map native :

1. Supprimer le script du nœud User Configuration > Policies > Windows Settings > Scripts > Logon.
2. Créer une GPP Scheduled Task de type Immediate Task dans User Configuration > Preferences > Control Panel Settings > Scheduled Tasks.
3. Configurer l'action : powershell.exe -NonInteractive -NoProfile -ExecutionPolicy RemoteSigned -File "\\server\scripts\MapNetworkDrives.ps1".
4. Compte d'exécution : utilisateur connecté (logonType="InteractiveToken").

La tâche s'exécute en arrière-plan pendant que le bureau se charge. Les lecteurs réseau seront disponibles quelques secondes après l'apparition du bureau — délai imperceptible pour l'utilisateur.

Option 3 (si le script Logon doit rester synchrone) : Optimiser le script.

Si la synchronicité est indispensable (ex. : mappage requis avant le lancement d'une application de démarrage) :

• Remplacer les timeouts de connexion par des tests préalables (Test-NetConnection avec -InformationLevel Quiet -Count 1).
• Paralléliser les mappages avec Start-Job ou ForEach-Object -Parallel (PowerShell 7+).
• Supprimer les mappages de lecteurs inutilisés du script.

Voir aussi¶

• 03 — Client-Side Extensions (CSE) — structure interne de la CSE Scripts (gpscript.dll), cycle de déclenchement, valeurs de registre GPExtensions
• 07 — Traitement des GPO — contexte du traitement synchrone vs asynchrone, foreground vs background, impact sur les CSE
• 11 — Preferences GPP — architecture GPP, Drive Maps, ScheduledTasks XML, Item-Level Targeting