Errore 1376 GPO MSI a startup: come risolvere “The specified local group does not exist” in Windows Server

Errore 1376 (“The specified local group does not exist”) durante l’installazione di un MSI lanciato da script di avvio GPO: guida completa per capire perché accade solo a startup, come riprodurlo, come correggerlo in modo stabile e come migliorare sicurezza e affidabilità delle distribuzioni.

Indice

Panoramica del problema

Scenario tipico: un computer, inserito in un’OU di test, riceve un Criterio di Gruppo che esegue, all’avvio, uno script .cmd. Lo script lancia un pacchetto .msi con parametri aggiuntivi – compresi un utente di dominio e la relativa password – richiesti dall’installer per creare e avviare un servizio Windows. L’installazione parte ma, quando l’MSI prova a creare/avviare il servizio, fallisce e fa rollback, lasciando solo una cartella vuota in C:\Program Files\. Nel log MSI (di solito in C:\Windows\Temp) compare: System error 1376 – The specified local group does not exist. Se lo stesso script viene eseguito manualmente, quando l’utente ha già effettuato il logon, tutto funziona. Il malfunzionamento si presenta solo via GPO a startup.

Sintomi e indizi che puntano all’errore 1376

Cartella dell’applicazione creata ma vuota; assenza di chiavi/valori previsti nel registro.
Nel registro eventi: eventi MSIInstaller con codice 1603 o 1920, vicino a un’azione personalizzata che crea/avvia il servizio.
Nel log verboso MSI (/l*v): messaggi che citano gruppi locali (es. Users, <Software> Users) o la risoluzione di un SID di dominio fallita, subito prima del codice 1376.
Lo stesso pacchetto installato manualmente (post logon) non mostra l’errore.

Perché succede: analisi tecnica

L’errore 1376 indica che un gruppo locale richiesto dall’installer non esiste (ancora) o non è risolvibile nel contesto in cui gira l’MSI. Con gli script di avvio GPO il contesto è LocalSystem (SYSTEM) e l’esecuzione avviene prima del logon. In quella finestra temporale:

la rete può essere non pronta (Workstation / Netlogon non ancora operativi),
la macchina potrebbe non aver completato il secure channel verso il Domain Controller,
la risoluzione di SID e la valutazione della membership dei gruppi di dominio non è ancora disponibile.

Molti installer, quando configurano un servizio da eseguire con un account di dominio, verificano o creano gruppi locali (es. Users o un gruppo specifico del prodotto) e aggiornano i diritti LSA (in particolare Log on as a service, cioè SeServiceLogonRight). Se la creazione/risoluzione del gruppo fallisce o se il diritto non può essere assegnato perché manca il gruppo bersaglio, l’azione MSI va in errore con 1376 e l’intera installazione viene annullata.

Tempi di avvio e risoluzione SID

La fase di boot non garantisce da subito la disponibilità di DNS, Kerberos/NTLM, Netlogon e policy applicate. Di conseguenza, le query SID→Nome e la membership dei gruppi di dominio potrebbero non risolversi. Lato GPO, se gli script di avvio sono eseguiti in modo asincrono e senza attendere la rete, la probabilità di incappare nell’errore cresce.

Interazione MSI con servizi e gruppi locali

Le Custom Actions tipiche di installazione servizi svolgono una o più delle seguenti operazioni:

Creazione del servizio con CreateService specificando Domain\Account e password.
Verifica/creazione di un gruppo locale “app-specific” o utilizzo di Users/Administrators per permessi NTFS/ACL.
Assegnazione del diritto Log on as a service all’account indicato (tramite LSA/Secepol).

Se uno di questi step non riesce a causa dell’assenza o irrisolvibilità di un gruppo, si ottiene 1376.

Il diritto “Log on as a service” e perché conta

Un servizio gestito da un account di dominio deve possedere il diritto LSA “Accedi come servizio”. Alcuni MSI tentano di concederlo aggiungendo l’utente a un gruppo locale o manipolando direttamente i diritti. In entrambi i casi, se il gruppo target non esiste oppure l’account non è risolvibile in quel momento, l’operazione fallisce.

Soluzioni e workaround consigliati

Di seguito, le azioni più efficaci per eliminare l’errore 1376 in contesti GPO, con il razionale tecnico e note operative.

Passaggio	Comando/Impostazione rapida	Descrizione	Perché funziona	Rischi/Note
Creare il gruppo locale richiesto prima dell’MSI	GPO → Preferences → Local Users and Groups	Garantire l’esistenza del gruppo locale con il nome esatto atteso dall’MSI (vedere log).	Evita l’errore 1376 perché il gruppo è già presente al momento dell’installazione.	Verificare maiuscole/minuscole e localizzazione del nome; eseguire su Computer Configuration.
Assegnare “Log on as a service” via GPO	Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment	Aggiungere l’account di dominio nella policy Log on as a service sulla macchina di destinazione.	Evita che l’MSI tenti di manipolare gruppi/diritti durante l’installazione.	Attenzione ai conflitti con policy che definiscono (e non aggregano) i diritti LSA.
Ritardare lo script finché la rete è pronta	`sc.exe query lanmanworkstation` in loop	Attendere l’avvio dei servizi di rete e la stabilizzazione del canale di dominio prima di lanciare l’MSI.	Garantisce la risoluzione di SID e gruppi di dominio da contesto `SYSTEM`.	Evitare ritardi fissi lunghi: meglio attendere in modo condizionale ai servizi/rete.
Usare un gMSA come account del servizio	`New-ADServiceAccount`	Creare un Group Managed Service Account e specificarlo all’MSI (senza password).	Rimuove le password dallo script e semplifica la gestione di diritti e SID.	Richiede schema AD adeguato, KDS root key e autorizzazioni AD per i server target.
Distribuire l’MSI come “Software Installation” GPO	Computer Configuration → Software Settings → Software Installation	Assegnare direttamente il pacchetto MSI da UNC read-only; evitare script custom.	Il client MSIEXEC orchestra l’install in fasi più affidabili dopo il binding di dominio.	Condividere il pacchetto con permessi per Domain Computers; usare percorsi UNC, mai unità mappate.

Procedura operativa consigliata (step-by-step)

Stabilizzare il momento di esecuzione
- In Computer Configuration → Administrative Templates → System → Logon impostare Always wait for the network at computer startup and logon su Enabled.
- In Computer Configuration → Administrative Templates → System → Scripts impostare Run startup scripts asynchronously su Disabled per esecuzione sequenziale.
Creare/forzare il gruppo locale richiesto
- Usare Preferences → Local Users and Groups con azione Update sul gruppo, assicurandone l’esistenza.
Pre-concedere “Log on as a service”
- In User Rights Assignment aggiungere l’account (o il gMSA) alla voce Log on as a service.
Attendere la rete nello script
- Usare un’attesa condizionale (servizi/Netlogon/DNS). Vedi esempio di script.
(Opzionale ma consigliato) Passare a gMSA
- Creare e distribuire un gMSA dedicato all’applicazione; aggiornare l’MSI/proprietà.
Verificare e loggare
- Abilitare log verboso MSI (/l*v) e raccogliere gpresult; controllare Event Viewer.

Esempi di script robusti per l’avvio

Esempio CMD con attesa rete e controlli di dominio

@echo off
setlocal enabledelayedexpansion

REM --- Attesa condizionale dei servizi di rete ---
echo [INFO] Attendo Workstation...
:wait_ws
sc.exe query lanmanworkstation | find /i "RUNNING" >nul
if errorlevel 1 (
echo [INFO] Workstation non ancora attivo. Ritento tra 5s...
ping -n 6 127.0.0.1 >nul
goto :wait_ws
)

echo [INFO] Verifica canale sicuro verso il dominio...
for /l %%i in (1,1,30) do (
nltest /sc_query:DOMINIO.INTERNO | find /i "trusted" >nul
if errorlevel 1 (
echo [WARN] Secure channel non pronto (tentativo %%i/30)...
ping -n 6 127.0.0.1 >nul
) else (
echo [OK] Secure channel attivo.
goto :domain_ok
)
)
echo [WARN] Continuo comunque dopo timeout massimo.
:domain_ok

REM --- Percorso sorgente UNC, mai unità mappate ---
set SRC=\filesrv\software\Vendor\App\app.msi

REM --- Log MSI verboso per diagnosi ---
set MSI_LOG=C:\Temp\app-install.log
if not exist C:\Temp mkdir C:\Temp

REM --- ESEMPIO: proprietà dell'installer per account servizio ---
REM ATTENZIONE: evitare password in chiaro; preferire gMSA quando possibile.
msiexec /i "%SRC%" /qn /l*v "%MSI_LOG%" SERVICEACCOUNT=DOMINIO\svcApp SERVICEPASSWORD= ADDLOCAL=ALL

set ERR=%ERRORLEVEL%
if %ERR% NEQ 0 (
echo [ERRORE] Installazione MSI fallita con codice %ERR%.
exit /b %ERR%
) else (
echo [OK] Installazione completata.
)

Note: nltest richiede i RSAT o è disponibile sui sistemi recenti; in alternativa si può testare la raggiungibilità del DC via ping e la risoluzione DNS del dominio. Evitare di montare share con unità mappate: lo startup gira come SYSTEM e le unità mappate sono per sessione utente.

Esempio PowerShell con gMSA e gestione errori

param(
  [string]$MsiPath = "\\filesrv\software\Vendor\App\app.msi",
  [string]$LogPath = "C:\Temp\app-install.log",
  [string]$GmsaName = "svcApp$" # gMSA termina con $
)

$ErrorActionPreference = "Stop"
New-Item -Path (Split-Path $LogPath) -ItemType Directory -Force | Out-Null

Attesa rete e dominio

Write-Host "[INFO] Attendo servizi di rete..."
while ((Get-Service -Name "LanmanWorkstation").Status -ne "Running") { Start-Sleep -Seconds 5 }

Write-Host "[INFO] Verifico il canale di dominio..."
$max = 30
for ($i=1; $i -le $max; $i++) {
try {
$dc = (Get-ADDomainController -Discover -Service "PrimaryDC").HostName
if ($dc) { Write-Host "[OK] DC trovato: $dc"; break }
} catch { }
Write-Host "[WARN] DC non ancora disponibile (tentativo $i/$max)..."
Start-Sleep -Seconds 5
}

Installazione MSI con proprietà di servizio che usano gMSA (nessuna password)

$arguments = @(
"/i `"$MsiPath`"",
"/qn",
"/l*v `"$LogPath`"",
"SERVICEACCOUNT=$GmsaName",
"ADDLOCAL=ALL"
) -join " "

$proc = Start-Process -FilePath "msiexec.exe" -ArgumentList $arguments -PassThru -Wait
if ($proc.ExitCode -ne 0) {
Write-Host "[ERRORE] MSI ha restituito $($proc.ExitCode)"; exit $proc.ExitCode
} else {
Write-Host "[OK] Installazione completata."
}

Creazione rapida di un gMSA

Esempio minimo (da eseguire su un Domain Controller o con RSAT):

# 1) Se manca la KDS Root Key:
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

2) Creare il gMSA e consentire ai computer target di usarlo:

New-ADServiceAccount -Name "svcApp" -DNSHostName "dominio.interno" `
-PrincipalsAllowedToRetrieveManagedPassword "CN=GRP-Server-App,OU=Groups,DC=dominio,DC=interno"

3) Sul server/PC di destinazione:

Install-ADServiceAccount -Identity "svcApp"
Test-ADServiceAccount -Identity "svcApp"  # deve restituire True

All’interno dell’MSI, impostare l’account del servizio come DOMINIO\svcApp$ (il simbolo $ è parte del nome dell’oggetto gMSA) e lasciare vuota la password.

Distribuire il pacchetto tramite “Software Installation” GPO

Quando possibile, preferire la distribuzione nativa MSI tramite Computer Configuration → Policies → Software Settings → Software Installation:

Pubblicare il file .msi su una share con accesso in sola lettura per Domain Computers (permessi NTFS e di condivisione coerenti).
Specificare il percorso UNC (es. \\server\share\app.msi), mai unità mappate.
Valutare le opzioni di ridistribuzione e riparazione (advertised).
Impostare Always wait for the network… come sopra per garantire l’applicazione al boot.

In questo modello il client MSIEXEC orchestri l’installazione in tempi in cui la rete e le policy sono già inizializzate, riducendo l’esposizione all’errore 1376.

Diagnostica: come verificare e dove guardare

Raccogliere evidenze GPO

gpresult /h C:\gpo.html

Aprire il report e controllare: Computer Details → Scripts e Applied Group Policy Objects. Verificare che lo script di avvio sia effettivamente applicato e in quale ordine.

Log verboso MSI

msiexec /i \\server\share\file.msi /l*v C:\Temp\app-msi.log /qn PROPERTY1=VALUE1 ...

Nel log cercare: Return value 3, voci su CustomAction legate a servizi, messaggi su local group/SID. Spesso l’ultima riga utile precede il codice 1603 e menziona la risorsa (gruppo o diritto) che l’installer non trova.

Event Viewer

Applications and Services Logs → Microsoft → Windows → GroupPolicy (operational)
Applications and Services Logs → Microsoft → Windows → MSIInstaller
System: eventi di Service Control Manager e Netlogon.

Evitare credenziali in chiaro

Preferire gMSA: elimina la password nello script e riduce gli errori su diritti/gruppi.
Se proprio necessario, considerare GPO Preferences → Properties → Common → Run in logged-on user’s security context solo per scenari utente (non adatto agli startup), o Protected Settings per offuscare valori sensibili.
Valutare un sistema di secrets management aziendale; evitare variabili d’ambiente o file temporanei con password.

Hardening del flusso di avvio

Script sincroni e attesa rete abilitata: riduce il rischio di lanciare l’MSI in condizioni non pronte.
Controllare l’ordine degli script se ce ne sono più d’uno; quello che crea gruppi/diritti deve venire prima dell’installazione.
Fissare una timeout strategy (es. massimo 3–5 minuti) per non bloccare boot lenti.

Checklist rapida (prima del rilascio in produzione)

Il gruppo locale richiesto dall’MSI esiste già via GPO Preferences.
Il diritto Log on as a service è assegnato via GPO all’account/gMSA.
Gli script di avvio sono sincroni; la rete è attesa al boot.
L’MSI è accessibile da percorso UNC leggibile da Domain Computers.
Log verboso abilitato e posizione di log documentata (C:\Temp).
Nessuna password in chiaro nello script (o comunque mitigata); preferire gMSA.
Test eseguito su macchina “pulita” e su macchina con policy aziendali standard.

Problemi correlati da tenere d’occhio

1314 – A required privilege is not held by the client: spesso indica mancanza di SeServiceLogonRight.
1332 – No mapping between account names and security IDs was done: l’account o il gruppo di dominio non è risolvibile al momento.
1058/1030 GroupPolicy: problemi di applicazione GPO (DNS, SYSVOL/NETLOGON, permessi).

Domande frequenti

Perché l’installazione manuale funziona ma quella via GPO a startup no?

Perché manualmente la rete, il canale di dominio e i gruppi sono già disponibili; allo startup SYSTEM parte “troppo presto” e l’MSI non trova il gruppo/diritto richiesto.

Posso risolvere solo aggiungendo un delay fisso (es. 30 secondi)?

Meglio di niente, ma fragile: su reti lente o DC distanti potrebbero servire più secondi. Preferisci un’attesa condizionale (servizi in esecuzione, canale di dominio attivo).

È obbligatorio usare gMSA?

No, ma è fortemente consigliato per sicurezza e stabilità. Elimina le password dagli script e riduce gli errori su gruppi/diritti.

La distribuzione “Software Installation” è sempre preferibile?

Quando l’MSI supporta l’installazione assegnata e non richiede interfacce UI, sì: riduce i rischi legati al timing di rete e al contesto di esecuzione.

Esempio di decision tree operativo

Errore 1376 presente nel log MSI?
- Sì → Vai a 2
- No → Verifica altri codici (1314, 1332, 1603) e log GPO
Il gruppo locale richiesto esiste?
- No → Crea via GPO Preferences → Riprova
- Sì → Vai a 3
L’account del servizio ha “Log on as a service” via GPO?
- No → Assegna diritto → Riprova
- Sì → Vai a 4
Rete e dominio sono pronti allo startup?
- No → Abilita Always wait…, script sincroni, attesa condizionale → Riprova
- Sì → Valuta gMSA e/o distribuzione “Software Installation”

Riepilogo

L’errore 1376 – The specified local group does not exist durante l’installazione di un MSI lanciato da uno script di avvio GPO deriva quasi sempre dal timing di inizializzazione della rete/dominio e dalla dipendenza dell’installer da gruppi locali e dal diritto Log on as a service. Stabilizzando il contesto (attesa rete, script sincroni), predisponendo prima gruppi e diritti via GPO, e – quando possibile – usando un gMSA, il problema si risolve in modo strutturale. In alternativa, distribuire il pacchetto tramite Software Installation nativa spesso evita del tutto la condizione d’errore. Con log accurati (/l*v), gpresult e Event Viewer si ottiene la visibilità necessaria per una diagnosi rapida e ripetibile.

Appendice: snippet utili

Verifica rapida gruppo locale: net localgroup "Nome Gruppo"
Aggiunta membro a gruppo locale (script di preparazione): net localgroup "Nome Gruppo" "DOMINIO\Account" /add
Controllo diritto “Log on as a service”: usare secedit /export /cfg C:\secpol.cfg e cercare SeServiceLogonRight.
Forzare aggiornamento Criteri: gpupdate /force (consapevoli che a startup l’ordine è comunque determinante).

Con queste modifiche la maggior parte dei casi di errore 1376 in distribuzioni GPO viene risolta senza necessità di intervento manuale post‑installazione.

Se devi applicare la soluzione su larga scala, prepara un modello GPO che includa: (1) creazione gruppo locale, (2) assegnazione SeServiceLogonRight, (3) script di attesa rete + install, (4) logging centralizzato (cartella su share con ACL per computer), (5) passaggio a gMSA. In questo modo trasformi un problema episodico in un processo standard, auditabile e sicuro.