Windows Server 2022: avvio automatico di un programma all’accesso RDP con “Start a program on connection”

Vuoi far partire automaticamente un’app all’accesso RDP su Windows Server 2022 e ottenere la chiusura della sessione quando l’app termina? In questa guida risolviamo il caso reale di “calc.exe non parte” e costruiamo una checklist completa per far funzionare “Start a program on connection” in modo affidabile.

Indice

Scenario e sintomi

Un amministratore desidera che gli utenti locali, collegandosi in Desktop Remoto (RDP) a un server Windows Server 2022, vedano eseguito C:\Windows\System32\calc.exe al posto del desktop completo. Attiva quindi il criterio Start a program on connection in Gpedit.msc → Computer Configuration / User Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Remote Session Environment. Nonostante l’oggetto risulti applicato in RSOP, al logon RDP appare comunque il desktop e Calculator non si avvia. Lo stesso set-up funzionava su Windows Server 2012 e con utenti di dominio.

Questo comportamento è tipico quando mancano i prerequisiti del ruolo RDS, quando la priorità dei criteri non è compresa (Computer vs User), quando è abilitato il criterio che impone sempre la visualizzazione del desktop, o quando sono stati impostati percorsi/parametri errati. Nei paragrafi che seguono vedremo come arrivare a una soluzione robusta e ripetibile.

Panoramica della soluzione

La soluzione si basa su tre pilastri:

Prerequisiti RDS: il criterio “Start a program on connection” funziona correttamente solo su un host con ruolo RD Session Host. Senza questo ruolo, il criterio viene ignorato.
Priorità dei criteri: la voce esiste sia sotto Computer Configuration sia sotto User Configuration. Se configurate entrambe, in Windows Server 2022 la configurazione a livello Computer è dominante e può neutralizzare quella a livello Utente.
Eliminare i criteri che forzano il desktop: se è abilitato Always show desktop on connection, il programma non parte mai, perché il desktop viene imposto come esperienza di sessione.

Prerequisiti: assicurarsi che RDS sia installato

Il criterio “Start a program on connection” nasce per ambienti Remote Desktop Services. Su un server “vergine”, senza il ruolo RD Session Host, alcune impostazioni della sezione Remote Session Environment vengono ignorate o non producono l’effetto atteso.

Verifica rapida del ruolo RD Session Host

Apri Server Manager → Manage → Add Roles and Features.
Vai a Server Roles → Remote Desktop Services e verifica che sia selezionato Remote Desktop Session Host.

Installazione via PowerShell

Se il ruolo non è presente, installalo così (richiede privilegi amministrativi):

Install-WindowsFeature -Name RDS-RD-Server -IncludeAllSubFeature -IncludeManagementTools -Restart

Verifica:

Get-WindowsFeature RDS-RD-Server

Nota: per scenari di test è sufficiente l’RD Session Host; in produzione valuta anche la configurazione della Remote Desktop Licensing. Il criterio di avvio programma funziona anche nel periodo di grazia, ma una licenza non corretta può influire sull’esperienza utente a lungo termine.

Comprendere la priorità dei criteri

La stessa impostazione “Start a program on connection” è presente in due rami:

Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Remote Session Environment
User Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Remote Session Environment

Se entrambe le voci sono configurate (Enabled), la configurazione a livello Computer ha la precedenza. Questo significa che un’impostazione errata o “residua” in Computer Configuration può annullare l’impostazione a livello Utente e impedire l’avvio del programma, mostrando comunque il desktop. È ciò che accade spesso durante migrazioni 2012 → 2022 quando si ereditano GPO “storiche”.

Quando usare Computer vs User

Computer Configuration: utile se vuoi che tutti gli utenti che accedono a quel server partano dallo stesso programma (kiosk o server dedicato).
User Configuration: utile se vuoi differenziare il programma per gruppi/utenti (es. operatori vs supervisori). In questo caso evita conflitti e lascia Non configurato il ramo Computer.

Loopback processing e OU

Se applichi impostazioni utente basate sull’OU del computer (tipico nelle farm RDS), valuta il Group Policy Loopback Processing in modalità Merge o Replace. Tuttavia, anche con il loopback attivo, una configurazione esplicita del ramo Computer per “Start a program on connection” continuerà ad avere la meglio sulla corrispondente impostazione utente. Mantieni un solo “punto di verità”.

Disattivare i criteri che forzano il desktop

Il criterio Always show desktop on connection (Sempre mostra desktop alla connessione) impone l’avvio della shell desktop e rende inefficace l’impostazione del programma.

Percorso: Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Remote Session Environment.
Stato consigliato: Not Configured (o Disabled).

Se è Enabled, il desktop verrà sempre mostrato a prescindere dal “Program path” configurato.

Impostare correttamente Program Path e Working Directory

Due campi governano il comportamento:

Program path: il percorso completo dell’eseguibile da lanciare.
Start in (Working directory): la cartella di lavoro (facoltativa).

Linee guida pratiche

Usa sempre un percorso assoluto, ad esempio: C:\Windows\System32\calc.exe
Evita ambiguità legate a WOW64: se l’app è a 64 bit, indicare System32; se è a 32 bit su OS 64 bit e si trova in C:\Windows\SysWOW64, specifica quel percorso.
Compila la Working directory quando l’app salva file relativi o carica risorse dalla directory corrente. In caso contrario lascia vuoto (usa la predefinita dell’app). Esempio: Program path: C:\Windows\System32\calc.exe Working directory: C:\Windows\System32
Evita di racchiudere il percorso tra virgolette se non necessario. Se il percorso contiene spazi (es. C:\Program Files\...) usa le virgolette: "C:\Program Files\Contoso\App\App.exe"
Non passare parametri al programma in questo campo, salvo esplicita necessità e supporto dell’app; se servono parametri, includili dopo l’eseguibile: "C:\Program Files\Contoso\App\App.exe" /silent /profile:KIOSK

Aggiornare e verificare l’applicazione della GPO

Dopo ogni modifica esegui un aggiornamento dei criteri e verifica lo stato effettivo.

Aggiornamento criteri

gpupdate /force

Per un’applicazione sicura, riavvia il server o disconnetti/riconnetti la sessione RDP.

Verifiche con RSOP e GPResult

RSOP.msc: controlla che “Start a program on connection” sia Enabled nel nodo Computer Configuration (se usi il ramo Computer) e osserva i valori effettivi di “Program path” e “Working directory”.
GPResult: genera un report HTML per confermare la provenienza del criterio (GPO name, precedence): gpresult /H C:\Temp\gpo.html /F Apri il file e cerca la policy in questione per capire quale GPO l’ha impostata e se esistono conflitti.

Eventi utili

Durante il test controlla i log:

Applications and Services Logs → Microsoft → Windows → TerminalServices-LocalSessionManager.
Applications and Services Logs → Microsoft → Windows → TerminalServices-RemoteConnectionManager.
Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational per capire l’ordine di applicazione delle GPO.

Controlli aggiuntivi consigliati

Appartenenza gruppi: gli utenti devono essere membri di Remote Desktop Users (o avere diritti equivalenti). Verifica con: net localgroup "Remote Desktop Users"
Task Scheduler: non usare l’Utilità di pianificazione per “simulare” l’avvio all’accesso RDP; in ambiente RDS produce comportamenti non prevedibili e si sovrappone alla logica del criterio. Affidati alla policy o alle alternative seguenti.
Impostazioni dal lato client (.rdp): nel file RDP puoi prescrivere l’avvio del programma con questi parametri: alternate shell:s:C:\Windows\System32\calc.exe shell working directory:s:C:\Windows\System32 Utile quando vuoi differenziare il comportamento per client specifici senza toccare il server.
Active Directory (per utenti di dominio): nelle proprietà dell’utente → scheda Environment puoi impostare “Start the following program at logon”. Questo vale per quell’utente ovunque entri in una sessione RD Session Host (salvo override del ramo Computer).
Licensing e grazie: fuori dal perimetro di questa guida, ma ricorda che dopo il periodo di grazia RDS è necessario configurare un License Server per evitare interruzioni nel tempo.

Procedura guidata completa

Installa/Verifica RD Session Host su Windows Server 2022.
Decidi il livello: vuoi un avvio programma per tutti (Computer) o per gruppi/utenti (User)? Evita doppioni.
Imposta la policy “Start a program on connection” nel ramo scelto, con:
- Program path: C:\Windows\System32\calc.exe
- Working directory: C:\Windows\System32 (facoltativo)
Assicurati che “Always show desktop on connection” sia Not Configured (o Disabled) nel ramo Computer.
Rimuovi eventuali conflitti:
- Se usi il ramo User, lascia Not Configured la voce nel ramo Computer.
- Se usi il ramo Computer, allinea o rimuovi la voce nel ramo User.
Esegui gpupdate /force e testa con una nuova sessione RDP (non riutilizzare sessioni già aperte).
Verifica con RSOP/GPResult che il criterio applicato sia quello atteso e proveniente dalla GPO giusta.

Tabella di diagnosi rapida

Segnale	Possibile causa	Rimedio
Compare il desktop invece del programma	“Always show desktop on connection” abilitato	Imposta su Not Configured o Disabled
Il criterio risulta “Applied” ma non succede nulla	Manca il ruolo RD Session Host	Installa RDS-RD-Server e riprova
Funziona con utenti di dominio ma non locali	Conflitto fra rami Computer/User o permessi gruppi	Rimuovi la voce confliggente nel ramo Computer; verifica appartenenza a Remote Desktop Users
Partono app diverse per utenti diversi	GPO multiple e Loopback in Merge	Consolida la definizione in un solo ramo e una sola GPO
L’app si avvia ma non trova file	Working directory non impostata	Definisci “Start in” coerente con l’applicazione
Errori su app 32 bit	Percorso in `System32` su OS 64 bit	Usa `SysWOW64` se l’eseguibile è 32 bit

Esempio pratico con Calculator

L’obiettivo è avviare Calculator ad ogni accesso RDP e chiudere la sessione alla chiusura dell’app.

Su Gpedit.msc, nella sezione Computer Configuration → … → Remote Session Environment, abilita Start a program on connection.
Imposta: Program path: C:\Windows\System32\calc.exe Working directory: C:\Windows\System32
Verifica che Always show desktop on connection sia Not Configured.
Esegui gpupdate /force, disconnetti e ricollegati via RDP con un utente locale.

Se al momento dell’accesso vedi Calculator e, chiudendolo, la sessione termina immediatamente, hai ottenuto il comportamento desiderato. In caso contrario, torna alla tabella di diagnosi.

Perché su Windows Server 2012 funzionava e su 2022 no?

Spesso nelle migrazioni tra versioni si ereditano GPO che in passato non entravano in conflitto, o che venivano “bypassate” da assenza/presenza di determinati ruoli. Su Windows Server 2022 la separazione funzionale dei criteri è più rigorosa e il ruolo RD Session Host è prerequisito. Inoltre, l’esistenza della stessa policy su due rami (Computer e User) può generare priorità inattese se si attivano entrambi senza una strategia chiara. Allineare (o rimuovere) la configurazione nel ramo “sbagliato” è risultata la chiave per far partire Calculator in modo affidabile.

Approfondimenti e best practice

Progetta la governance delle GPO

Usa una sola GPO per definire l’avvio del programma.
Documenta la scelta del ramo (Computer o User) e applica filtri di sicurezza/WMI solo se strettamente necessario.
Evita modifiche locali (Local Group Policy) su server che ricevono GPO di dominio: sono difficili da auditare.

Ambienti multi-app

Se hai bisogno di lanciare app diverse a seconda del profilo:

Preferisci la configurazione in User Configuration e mantieni Not Configured la voce nel ramo Computer.
Se devi imporre regole per tutti i server di una farm, usa Loopback in Merge o Replace e pianifica con cura l’ordine di link delle GPO sull’OU dei server RDS.

Alternative lato client

Come anticipato, il file .rdp può forzare l’avvio di un programma senza toccare le GPO. Questo è utile in contesti con client eterogenei o dove non è possibile intervenire sui server. Ricorda però che un’impostazione a livello Computer sul server può prevalere.

Impostazioni per utente in Active Directory

Per gli utenti di dominio, la scheda Environment nelle proprietà dell’utente (in Active Directory Users and Computers) permette di definire un programma all’accesso. È una soluzione granulare e immediata, ma valuta l’impatto se gli utenti accedono a server diversi con esigenze differenti.

Gestione della chiusura sessione

Quando la sessione è configurata per avviare un singolo programma, la chiusura dell’app termina la sessione. Se desideri mantenere la sessione attiva anche dopo la chiusura dell’app, questa modalità non è adatta: valuta RemoteApp o l’avvio di una shell “wrapper”.

Checklist operativa

RD Session Host installato e funzionante.
Definisci una sola sede per “Start a program on connection” (Computer oppure User).
“Always show desktop on connection” in Not Configured o Disabled.
Program path assoluto e corretto (attenzione a 32/64 bit).
Working directory impostata quando l’app la richiede.
gpupdate /force ed RSOP/GPResult verificati.
Utenti nel gruppo Remote Desktop Users.
Nessun Task Scheduler che avvia la stessa app all’accesso.
Event Viewer privo di errori di logon/applicazione inerenti al lancio.

Domande frequenti

Posso usare variabili d’ambiente nel Program path?

È possibile, ma per affidabilità è preferibile il percorso assoluto. Alcune app gestiscono male percorsi espansi in contesti di sessione remota.

Il criterio funziona per gli amministratori locali?

Sì, ma tieni conto che altre policy (es. “non avviare in sessione Admin” o criteri di sicurezza) possono modificare l’esperienza. Testa con un account utente standard del gruppo Remote Desktop Users.

Perché l’app parte ma poi mostra errori di permesso?

In modalità “single program” l’app gira nel contesto utente. Se l’app necessita scritture in percorsi protetti, fornisci ACL appropriati o reindirizza i percorsi di lavoro a cartelle utente.

Posso avviare uno script PowerShell?

Sì, specifica Program path verso powershell.exe e indica lo script come parametro, ad esempio:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -File "C:\Tools\Start.ps1"

Assicurati che la Working directory e le policy di esecuzione consentano lo script.

Come gestisco più programmi?

La policy Start a program on connection lancia un solo comando. Se devi avviarne più di uno, usa uno script (batch o PowerShell) che orchestri l’esecuzione, tenendo presente che quando lo script termina la sessione si chiude.

Risultato finale

Nel caso specifico, rimuovendo il conflitto tra la configurazione in Computer Configuration e quella in User Configuration (oppure allineandole coerentemente), disattivando il criterio “Always show desktop on connection”, e verificando Prerequisiti RDS, Program path e Working directory, Calculator si avvia correttamente ad ogni sessione RDP degli utenti locali. Come previsto dalla modalità “single program”, quando l’app viene chiusa la sessione si termina automaticamente.

Esempi di configurazione pronti da copiare

Gpedit (ramo Computer)

Start a program on connection: Enabled
- Program path: C:\Windows\System32\calc.exe
- Start in: C:\Windows\System32
Always show desktop on connection: Not Configured

File .RDP (lato client)

alternate shell:s:C:\Windows\System32\calc.exe
shell working directory:s:C:\Windows\System32

PowerShell di verifica

# Verifica ruolo RD Session Host
Get-WindowsFeature RDS-RD-Server

Forza aggiornamento GPO

gpupdate /force

Report criteri

gpresult /H C:\Temp\gpo.html /F

Conclusioni operative

Per rendere affidabile l’avvio automatico di un’app all’accesso RDP su Windows Server 2022:

Considera indispensabile il ruolo RD Session Host.
Scegli una sola sede di configurazione (Computer oppure User) ed elimina i conflitti.
Disattiva le policy che forzano il desktop.
Imposta percorsi coerenti con l’architettura dell’app (32/64 bit) e con la sua logica di lavoro.
Verifica l’applicazione con strumenti nativi (RSOP, GPResult, Event Viewer).

Seguendo questa traccia, eviti i falsi positivi (“la GPO è applicata, ma non accade nulla”) e ottieni esattamente il comportamento desiderato: l’utente entra, l’app si avvia, e alla sua chiusura la sessione termina pulita.

Abstract esecutivo: il criterio “Start a program on connection” richiede RD Session Host e non deve essere contrastato dalla voce analoga nel ramo opposto o da “Always show desktop on connection”. Usa percorsi assoluti, verifica con RSOP/GPResult, e adotta una governance GPO che eviti sovrapposizioni. Il risultato è un’esperienza RDP a singola applicazione stabile e predicibile.