Lorsque le déploiement d’un package MSI échoue au démarrage via une GPO avec le code 1376, c’est qu’un groupe local attendu par l’installeur est introuvable. Cet article décrit en profondeur les causes techniques, les méthodes de diagnostic et les correctifs éprouvés pour bannir définitivement cette erreur.
Vue d’ensemble de la problématique
Dans de nombreux environnements Active Directory, l’automatisation du déploiement logiciel repose sur des scripts .cmd exécutés au démarrage (« startup scripts ») ; ceux‑ci appellent msiexec.exe
pour installer un package stocké dans \\DOMAIN\NETLOGON
ou \\DOMAIN\SYSVOL
. Lorsqu’un installateur MSI tente d’ajouter son compte de service à un groupe local qui n’existe pas (ou dont le nom n’est pas résolu), Windows génère l’exception System Error 1376 : « The specified local group does not exist ». L’installateur bascule alors en rollback : fichiers supprimés, service annulé, retour d’erreur 1603 dans le journal MSI, et l’administrateur se retrouve face à une application fantôme dans C:\Program Files.
Analyse détaillée de l’erreur 1376
Le code système 1376 provient de l’API NetLocalGroupAddMembers. Un MSI lève cette exception lorsqu’il exécute une Custom Action de type CreateFolder, InstallService ou LockPermissions et que la fonction Windows échoue ; l’arrêt est immédiat car la transaction Windows Installer garantit la cohérence de l’état du système.
- ID d’événement 11708 dans l’Observateur d’événements confirme l’échec d’installation.
- ID d’événement 1035 dans le canal Microsoft‑Windows‑GroupPolicy/Operational atteste de l’exécution du script de démarrage.
- La trace
/l*v
montre la tentative d’ajout deDOMAIN\serviceuser
dans un groupe introuvable ; immédiatement après, le rollback commence.
Causes typiques et correctifs
Cause probable | Explication | Correctifs suggérés |
---|---|---|
Groupe local manquant | Le MSI référence un groupe comme « [APP] Service » ou « Users » qui n’existe pas (notamment sur des éditions Server Core ou des postes désinternationalisés). | Créer le groupe avant installation : GPO ▶ Preferences ▶ Local Users & Groups ▶ New Group. Modifier la table LockPermissions du MSI pour cibler un groupe existant (BUILTIN\Users ou le SID). |
Ordre de démarrage / absence de réseau | Le script startup s’exécute sous LOCAL SYSTEM avant que la machine ait joint le domaine ; le compte DOMAIN\serviceuser n’est pas résolu, l’installeur tente de créer un groupe local équivalent, échoue et s’arrête. | Activer « Always wait for the network at computer startup and logon ». Déplacer l’installation vers : • un script d’ouverture de session (logon script) ; • une tâche planifiée différée (5 min, compte SYSTEM). |
Mauvais mode de déploiement | Utiliser un script .cmd détourne la fonctionnalité native « Software Installation » qui gère la transaction MSI dès la phase « User Logon » ou « Computer Startup ». | Publier ou assigner le MSI via : GPO ▶ Software Settings ▶ Software Installation. Placer le fichier dans \\DOMAIN\SYSVOL\ plutôt que NETLOGON ; SYSVOL hérite des ACL correctes et est répliqué via DFSR. |
Localisation Windows | Le MSI attend le nom anglais des groupes intégrés (Administrators, Users) mais le système est en français (Administrateurs, Utilisateurs). La résolution par nom échoue. | Référencer le groupe par son SID (S‑1‑5‑32‑545 pour Users). Modifier le MSI avec Orca pour remplacer le nom localisé. |
Sécurité des mots de passe | Le mot de passe du compte de service est stocké en clair dans le script ; certains antivirus/EDR bloquent la lecture, provoquant un fallback interne du MSI. | Utiliser un gMSA (Group Managed Service Account) : mot de passe géré par le domaine, pas de stockage local. Supprimer la GPP Password = * obsolète et interdite. |
Approche pas‑à‑pas pour corriger l’installation
- Reproduire le problème hors GPO :
msiexec /i \\DOMAIN\SYSVOL\Softs\App.msi /l*v %TEMP%\app-install.log
Si l’installation réussit, le hic vient du contexte GPO ; sinon, lisez la log pour identifier l’action qui déclenche 1376. - Établir/renommer le groupe requis :
net localgroup "APP Service" /add
ou, mieux, GPO Preferences pour persistance et restauration automatique. - Forcer l’attente du réseau et redémarrer la machine afin de tester le script startup dans des conditions réelles.
- Basculer vers Software Installation si le script reste nécessaire uniquement pour passer des propriétés MSI (
PROPERTY=VALUE
), envisagez un transform (.mst). - Contrôler la sécurité : si un compte de service demeure indispensable, préférez un gMSA ; sinon, ajoutez le compte au groupe Log on as a service via GPO ▶ Security Settings ▶ User Rights Assignment.
Journalisation avancée MSI
Pour activer la journalisation verbale pour tous les MSI installés par Windows Installer :
REG ADD HKLM\Software\Policies\Microsoft\Windows\Installer /v Logging /t REG_SZ /d voicewarmup /f
REG ADD HKLM\Software\Policies\Microsoft\Windows\Installer /v Debug /t REG_DWORD /d 7 /f
Les logs se trouvent ensuite dans %WINDIR%\Temp\MSI*.log
. Filtrez « Return Value 3 » pour localiser l’échec, puis inspectez les dix lignes précédentes afin de repérer la fonction qui a renvoyé 1376.
Bonnes pratiques de déploiement MSI via GPO
- Un partage de déploiement dédié (\\DOMAIN\DFS\Softs) avec NTFS = Read & Execute pour Authenticated Users.
- Signature numérique du MSI et activation de la stratégie « Trusted Publisher ». Sans signature, AppLocker ou SmartScreen peut bloquer l’exécution pendant le boot.
- Désactivation de la stratégie « Remove previous installations » si vous tracez un historique d’audit.
- Ne pas empiler les scripts startup : chaîner plutôt les actions dans un script unique ou utiliser un moteur tel que PSADT (PowerShell App Deployment Toolkit).
- Surveiller l’exécution avec la télémétrie Windows 10/11 : Intune Device install status ou Configuration Manager Status Message Queries.
Checklist récapitulative rapide
✔ | Le groupe local requis existe et porte le nom attendu ou son SID est utilisé. |
✔ | La machine attend le réseau au démarrage (stratégie activée). |
✔ | Le package MSI est distribué via SYSVOL/DFS avec droits NTFS corrects. |
✔ | Le compte de service est un gMSA ou son mot de passe n’est plus en clair. |
✔ | La journalisation MSI détaillée est activée et archivée. |
Questions fréquentes (FAQ)
Q : Le même MSI fonctionne en gpupdate /force interactif mais échoue au démarrage ; pourquoi ?
R : Interactif = profil utilisateur chargé, réseau déjà établi, variables d’environnement disponibles. Au démarrage, vous êtes dans system32 avec seulement les variables SYSTEM et la pile TCP/IP debout. Le MSI attend peut‑être %USERPROFILE%
, %APPDATA%
ou un mapping de lecteur qui n’existe pas encore.
Q : L’erreur 1376 survient sur certains OU mais pas d’autres ; comment isoler la cause ?
R : Exécutez gpresult /h C:\gpo.html
et comparez les GPO appliquées. Cherchez une préférence « Delete local group » ou un paramètre Restricted Groups qui supprime puis recrée les groupes locaux, effaçant accidentellement celui dont votre MSI dépend.
Q : Comment tester un gMSA sans installer l’application ?
R : Créez un service fictif :
sc.exe create TestSvc binPath= "cmd.exe /c timeout 300" obj= "DOMAIN\svc‑app$" type= own
Le service doit démarrer sans demande de mot de passe si le gMSA est correctement autorisé.
Conclusion
L’erreur 1376 est un symptôme clair : l’installeur ne parvient pas à localiser ou créer le groupe local ciblé. En examinant la chaîne complète — résolution du compte, disponibilité réseau, existence du groupe, localisation du nom, mode de déploiement — et en appliquant les correctifs décrits, vous transformerez un déploiement capricieux en processus fiable, traçable et sécurisé.