In una farm RDS le RemoteApp avviate dal Session Host A funzionano, mentre dal Session Host B falliscono con “Windows cannot start the remote program…” o “Remote Desktop can’t connect…”. Questa guida pratica spiega cause, verifiche e correzioni, più un caso su app locali a 127.1.1.1:8000.
Indice
Scenario e sintomi
Hai una farm Remote Desktop Services (RDS) con due Session Host (A e B). Le applicazioni pubblicate su A partono regolarmente da RD Web Access o tramite i file RDP/Feed. Le stesse applicazioni, quando instradate dal Connection Broker verso B, non partono e presentano uno o più di questi messaggi:
- “Windows cannot start the remote program. The following RemoteApp program is not in the list of authorized programs.”
- “Remote Desktop can’t connect to the computer for one of these reasons…”
In genere ciò indica che il Session Host B non è in grado di accettare/gestire correttamente la sessione RDP o che l’app pubblicata non è riconosciuta/ammessa su quel nodo.
Soluzioni rapide verificate
Se devi agire subito, parti da queste azioni già testate sul campo. Nella tabella seguente trovi l’ambito e la correzione suggerita.
| Ambito | Azione | Note |
|---|---|---|
| Abilitazione RDP | Disattiva e riattiva Impostazioni > Sistema > Desktop remoto quindi riavvia il server B. | Ripristina lo stato del servizio TermService e le ACL predefinite. |
| TCP/IPv6 | Da Pannello di controllo > Centro connessioni di rete disabilita IPv6 sull’interfaccia in uso, quindi riavvia. | Solo per test: in produzione è preferibile mantenere IPv6 se l’infrastruttura lo supporta correttamente. |
| Windows Firewall | In Pannello di controllo > Windows Defender Firewall > App consentite, abilita Remote Desktop per reti Private e Public. | Verifica anche le regole “Remote Desktop (TCP-In)” e “Remote Desktop (UDP-In)”. |
| Porta 3389 | Controlla che la porta TCP 3389 sia in ascolto su B (netstat -ano | find "3389") e consentita nel firewall locale e di rete. | La 3389 deve essere aperta su tutti i Session Host della farm. |
| Pubblicazione RemoteApp | Assicurati che le app di B risultino effettivamente pubblicate nel Connection Broker (RemoteApp Programs) e che il certificato del broker sia valido. | Se le app sono pubblicate per Collection, verifica che B sia membro della Collection corretta. |
| Documentazione | Riferisciti alla guida “Can’t establish a Remote Desktop session – Windows Server”. | Consulta i log eventi per dettagli puntuali. |
Log utili: apri Event Viewer > Applications and Services Logs > Microsoft > Windows > RemoteDesktopServices‑RdpCoreTS per analisi dettagliata. Verifica anche TerminalServices‑RemoteConnectionManager e TerminalServices‑SessionBroker‑Client/‑Server.
Perché accade: quadro delle cause più comuni
- Allow‑list RemoteApp non aggiornata su B: la Collection non ha propagato a B l’elenco delle app autorizzate (TSAppAllowList) oppure B non appartiene alla Collection corretta.
- Percorso eseguibile diverso: l’app è installata in un path differente su B (es.
C:\Program Files (x86)\...vsC:\Program Files\...), quindi l’alias pubblicato non corrisponde. - Porta 3389 bloccata: firewall locale/di rete o policy che impediscono connessioni in ingresso al Session Host B.
- Certificati RDS non allineati: certificato del ruolo “Publishing” o “Broker” non valido/scaduto o non riconosciuto dai client.
- NLA/Policy: Network Level Authentication o Criteri di sicurezza che impediscono il logon remoto per il gruppo utenti della Collection.
- DNS/FQDN errati: il Broker reindirizza verso un FQDN/IP non raggiungibile (multi‑NIC, DNS registrazioni multiple o interfaccia sbagliata).
- RD Gateway obbligatorio: se la policy richiede il Gateway ma non è raggiungibile, la connessione fallisce prima dell’inizializzazione della RemoteApp.
- Servizi RDS non attivi:
TermServiceo dipendenze non avviate/corrotte sul Session Host B.
Procedura diagnostica passo‑passo
Di seguito un percorso “dal filo alla matassa”. Seguilo nell’ordine: ti aiuterà a isolare rapidamente se il problema è di connettività, di pubblicazione o di autorizzazioni.
Verifica di base sul Session Host B
# Stato del servizio RDP
Get-Service -Name TermService
Porta in ascolto
netstat -ano | find ":3389"
Test di connettività dal client verso B (o da un server intermedio)
Test-NetConnection -ComputerName -Port 3389
Prova RDP diretta (bypass Broker/RemoteApp) con sessione amministrativa
mstsc /v: /admin Se la 3389 non è in LISTEN o il test fallisce, risolvi prima la rete/firewall. Se l’RDP diretto funziona, il problema è verosimilmente nella pubblicazione RemoteApp, nelle policy o nella redirezione del Broker.
Controllo membership della Collection e lista app autorizzate
# Elenco Collection
Get-RDSessionCollection
Host membri della Collection
Get-RDSessionHost -CollectionName "<NomeCollection>"
Elenco RemoteApp pubblicate (per Collection)
Get-RDRemoteApp -CollectionName "<NomeCollection>"
(Sul Session Host B) Verifica allow-list applicazioni RemoteApp a livello registro
Get-Item "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\Applications" | Get-ChildItem | Select PSChildName </code></pre>
<p><strong>Se B non è nella Collection</strong>, aggiungilo e attendi la propagazione (o forza un riavvio). <strong>Se la allow‑list su B non contiene le app</strong>, rimuovi e ri‑aggiungi B alla Collection per forzare la pubblicazione, quindi riesegui i test.</p>
<h3>Allineamento percorso eseguibile e alias RemoteApp</h3>
<p>Per ogni RemoteApp verifica che il campo <em>Program Path</em> sia identico su A e B e che il file esista nello stesso path. Esempio:</p>
<pre><code class="language-powershell"># Confronta path dell'eseguibile tra A e B
Invoke-Command -ComputerName A,B -ScriptBlock {
Get-Item "C:\Program Files\Contoso\App\app.exe" -ErrorAction SilentlyContinue |
Select-Object PSComputerName, FullName, Length, LastWriteTime
}
</code></pre>
<p>Se i path differiscono, riallinea l’installazione o modifica la pubblicazione in modo coerente su tutta la Collection.</p>
<h3>Certificati RDS e firma dei file RDP</h3>
<p>Verifica che i certificati assegnati ai ruoli RDS (RD Connection Broker – Publishing, RD Web Access, RD Gateway se presente) siano validi, non scaduti e con CN/SAN coerenti con i FQDN usati dai client. Se il certificato di Publishing è errato, i client potrebbero rifiutare l’avvio della RemoteApp.</p>
<pre><code class="language-powershell"># Elenco certificati personali del computer
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, NotAfter, Thumbprint
(Opzionale) Imposta/aggiorna certificati RDS dai Deployment Properties
Verifica anche da Server Manager > Remote Desktop Services > Overview
</code></pre>
<h3>Network Level Authentication e criteri</h3>
<p>Se i client sono datati o se ci sono proxy/inspection, l’NLA può fallire. Per prova, deseleziona temporaneamente “Consenti connessioni solo dai computer che eseguono Desktop remoto con Autenticazione a livello di rete (NLA)”, quindi riprova. Verifica anche i criteri:</p>
<ul>
<li><em>Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections</em>: “Allow users to connect remotely using RDS”.</li>
<li><em>Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment</em>: “Allow log on through Remote Desktop Services”.</li>
</ul>
<h3>DNS, FQDN e redirezione dal Broker</h3>
<p>Il Connection Broker può restituire ai client un FQDN del Session Host. Assicurati che:</p>
<ul>
<li>Il nome di B risolva all’<strong>IP corretto e raggiungibile</strong> dalla rete dei client.</li>
<li>Se B ha più NIC, solo l’interfaccia “giusta” registri il record DNS (deseleziona “Registra gli indirizzi di questa connessione in DNS” sulle NIC non usate).</li>
<li>La redirezione via <strong>FQDN</strong> sia abilitata se lavori dietro NAT o bilanciatori (disabilita l’IP redirection a favore del FQDN).</li>
</ul>
<h3>Firewall e protocolli RDP</h3>
<p>Oltre a <strong>TCP 3389</strong>, abilitare anche <strong>UDP 3389</strong> può migliorare la qualità. Se usi RD Gateway, verifica <strong>TCP 443</strong> verso il Gateway e <strong>TCP 3389</strong> dal Gateway ai Session Host. In ambienti con IDS/IPS, escludi il traffico RDP interno dalle ispezioni troppo aggressive.</p>
<h3>Event Viewer: cosa cercare</h3>
<ul>
<li><strong>RemoteDesktopServices‑RdpCoreTS</strong>: errori di handshake, listener, TLS/NLA.</li>
<li><strong>TerminalServices‑RemoteConnectionManager</strong>: negoziazione e autorizzazioni.</li>
<li><strong>TerminalServices‑SessionBroker‑Client/Server</strong>: problemi di reindirizzamento.</li>
<li><strong>RemoteApp and Desktop Connections</strong>: problemi con feed e firma RDP.</li>
</ul>
<pre><code class="language-powershell"># Estrai rapidamente gli eventi recenti sul componente RDP Core
Get-WinEvent -LogName "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational" -MaxEvents 30 |
Select-Object TimeCreated, Id, LevelDisplayName, Message
</code></pre>
<h3>Ripubblicazione forzata su B</h3>
<p>Se tutto torna ma l’errore “not in the list of authorized programs” persiste, prova a forzare la ripubblicazione:</p>
<ol>
<li>Rimuovi B dalla Collection.</li>
<li>Riavvia B.</li>
<li>Riaggiungi B alla Collection e ripubblica le app.</li>
</ol>
<pre><code class="language-powershell"># Esempio (attenzione: modifica l'ambiente!)
Remove-RDSessionHost -CollectionName "<NomeCollection>" -SessionHost "<B.FQDN>" -Force
Riavvia B, poi:
Add-RDSessionHost -CollectionName "<NomeCollection>" -SessionHost "<B.FQDN>"
Verifica che Get-RDRemoteApp mostri le app e che la allow-list su B si popoli
</code></pre>
<h3>Controllo licenze RDS (diagnostica rapida)</h3>
<p>Un problema di licenze raramente genera il messaggio “not in the list…”, ma può causare disconnessioni o rifiuti. Controlla che il ruolo RD Licensing sia configurato e raggiungibile, e che il tipo di licenza (Per Device/Per User) sia quello previsto.</p>
<h2>FAQ: serve aprire la 3389 su tutti i Session Host?</h2>
<p><strong>Sì.</strong> Ogni Session Host deve accettare connessioni RDP in ingresso (<strong>porta 3389</strong>) dal Connection Broker, da RD Web Access e dai client (direttamente o via RD Gateway). In caso contrario, quando il Broker indirizza la sessione a quel nodo, la RemoteApp non potrà essere inizializzata e vedrai errori di connessione o di autorizzazione apparente.</p>
<h2>Caso reale: applicazione locale su <code>127.1.1.1:8000</code> non si apre</h2>
<p>Un utente tenta di aprire un’applicazione web locale in ascolto su <code>127.1.1.1:8000</code> e il browser mostra “This page isn’t working”.</p>
<h3>Concetto chiave sul loopback</h3>
<p>Tutta la rete <code>127.0.0.0/8</code> è riservata al loopback, ma molte app bindano <em>solo</em> su <code>127.0.0.1</code>. Se il processo ascolta su <code>127.0.0.1:8000</code>, una richiesta a <code>127.1.1.1:8000</code> può fallire perché l’indirizzo esatto non è tra quelli su cui il socket è in ascolto. Per questo l’indirizzo “convenzionale” è <strong><code>127.0.0.1</code></strong>.</p>
<h3>Spunti di risoluzione</h3>
<ol>
<li><strong>Usa l’indirizzo corretto</strong>: prova <code>http://127.0.0.1:8000</code> o <code>http://localhost:8000</code>.</li>
<li><strong>Verifica il listener</strong>:
<pre><code class="language-powershell">netstat -ano | find ":8000"
oppure
Get-NetTCPConnection -LocalPort 8000
Se vedi 127.0.0.1:8000, significa che il servizio accetta solo su quell’indirizzo. Firewall locale: crea un’eccezione per il processo o per la porta TCP 8000 (inbound e – se serve – outbound).
Proxy/antivirus: disabilita temporaneamente proxy/IDS o aggiungi un’esclusione per il traffico locale, solo per test.
Log dell’app: controlla eventuali stack‑trace o errori di binding (porta già in uso, permessi, ecc.).
Consigli pratici per gli ambienti di sviluppo
- Se vuoi raggiungere l’app da altri host della LAN, avviala in ascolto su
0.0.0.0:8000e usa l’IP del server (con firewall configurato). Attenzione: esponi l’app solo in ambienti controllati. - Strumenti come Python/Django o Node.js spesso partono in
127.0.0.1per default; verifica il parametro di bind (es.--host 0.0.0.0o--bind 0.0.0.0).
Checklist rapida
- RDP abilitato e servizio
TermServiceavviato - Porta TCP corretta aperta e in ascolto (3389 per RDS, 8000 per app locale)
- IPv6 disattivato se non necessario o correttamente configurato
- Regole Windows Firewall aggiornate (Inbound + Outbound)
- RemoteApp pubblicate correttamente nel Connection Broker
- Certificati RDS validi e distribuiti ai client
- Event Viewer privo di errori critici relativi a RemoteDesktopServices
Con questi controlli la maggior parte dei problemi di avvio applicazioni da RD Web Access o via loopback locale viene risolta rapidamente.
Approfondimento tecnico: cosa controllare in dettaglio
Verifica e ripristino delle regole firewall
# Abilita i gruppi firewall per Desktop Remoto (TCP e UDP)
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
Consenti esplicitamente TCP/3389 in ingresso su profili Domain/Private/Public
New-NetFirewallRule -DisplayName "Allow RDP 3389 Inbound" -Direction Inbound -Protocol TCP -LocalPort 3389 -Action Allow -Profile Any
(Opzionale) Consenti UDP/3389
New-NetFirewallRule -DisplayName "Allow RDP 3389 UDP Inbound" -Direction Inbound -Protocol UDP -LocalPort 3389 -Action Allow -Profile Any Abilitazione RDP via registro/PowerShell
# Abilita connessioni RDP (equivale a disattivare fDenyTSConnections)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name fDenyTSConnections -Value 0
Abilita NLA (testa l'impatto in ambienti legacy)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name UserAuthentication -Value 1 Controllo gruppi autorizzati e diritti utente
# Verifica membri del gruppo "Utenti desktop remoto"
Get-LocalGroupMember -Group "Remote Desktop Users"
Utenti autorizzati alla Collection
(Get-RDSessionCollectionConfiguration -CollectionName "").UserGroup Diagnostica Broker e redirezione
# Elenco server nel deployment RDS
Get-RDServer
Proprietà di redirezione della Collection
Get-RDSessionCollectionConfiguration -CollectionName "<NomeCollection>" -LoadBalancing
Verifica che sia disabilitata la IP redirection se usi NAT/LB e preferisci FQDN
Allineamento applicazioni pubblicate
Due aspetti sono spesso trascurati:
- Alias e nome visualizzato: l’alias è l’identificativo “tecnico” della RemoteApp; deve essere coerente su tutti i nodi.
- Variabili d’ambiente e prerequisiti: se l’app su B richiede componenti diversi (es. librerie, ODBC, PAC), l’avvio può fallire dopo l’autenticazione.
# Elenco dettagli RemoteApp (alias, path, argomenti)
Get-RDRemoteApp -CollectionName "<NomeCollection>" |
Select Alias, DisplayName, FilePath, CommandLineSetting, RequiredCommandLine
RD Gateway: quando è obbligatorio
Se in “RD Gateway settings” della tua distribuzione/Feed è impostato “Use these RD Gateway server settings” e un criterio di Connection Authorization (RD CAP) obbliga l’uso del Gateway, i client esterni non raggiungeranno mai la 3389 interna se il Gateway non è disponibile o se il client tenta la connessione diretta. In tal caso:
- Verifica connettività TCP 443 dal client al Gateway.
- Verifica connettività TCP 3389 e DNS interni dal Gateway verso B.
- Controlla le RD CAP/RAP per la macchina B e il gruppo utenti.
DNS multipli e NIC multiple
In ambienti con più NIC su B (ad es. rete di gestione + rete utenti), è frequente che il record A di B punti alla NIC “sbagliata”. Assicurati che:
- La NIC di management non registri automaticamente in DNS.
- Le metriche di interfaccia e i binding siano corretti (interfaccia “utente” con metrica più bassa).
- Il Broker consegni sempre l’FQDN corretto ai client.
Quando non conviene disattivare IPv6
IPv6 viene spesso disabilitato per test. Va bene per isolare problemi, ma in produzione è consigliato mantenerlo attivo se i componenti (client, DNS, gateway) lo supportano. Disattivalo solo se necessario e documenta sempre la scelta.
Playbook operativo: dalla diagnosi al fix
- Test RDP diretto verso B (
mstsc /v:B /admin). Se fallisce, sistema connettività/Firewall/NLA. - Verifica Collection e RemoteApp (membership, alias, path). Riallinea e forza la ripubblicazione.
- Certificati (Publishing, Broker, Web Access, Gateway). Rigenera/riassegna se scaduti o non fidati.
- DNS/FQDN (reindirizzamento corretto, multi‑NIC, record A). Correggi registrazione e policy.
- Event Viewer per evidenza tecnica dell’errore. Agisci sul componente indicato.
Script PowerShell di diagnostica rapida
Questo snippet raccoglie i controlli principali sul Session Host B. Eseguilo da una console con privilegi elevati:
$server = "$env:COMPUTERNAME" # Imposta FQDN di B se lo lanci da remoto
Write-Host "=== Stato servizi RDP su $server ==="
Get-Service -ComputerName $server TermService | Format-Table -AutoSize
Write-Host "`n=== Listener RDP (3389) ==="
Invoke-Command -ComputerName $server -ScriptBlock { netstat -ano | findstr ":3389" }
Write-Host "`n=== Regole Firewall Remote Desktop ==="
Invoke-Command -ComputerName $server -ScriptBlock { Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
Select-Object DisplayName,Enabled,Direction,Action | Format-Table -AutoSize }
Write-Host "`n=== Membership Collection ==="
try { Get-RDSessionHost -CollectionName "" } catch { "RDMS non raggiungibile o modulo non presente." }
Write-Host "`n=== RemoteApp pubblicate ==="
try {
Get-RDRemoteApp -CollectionName "" | Select-Object Alias,FilePath
} catch { "Impossibile leggere la Collection. Verifica permessi o apri Server Manager." }
Write-Host "`n=== Allow-list su B ==="
Invoke-Command -ComputerName $server -ScriptBlock {
$path="HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\Applications"
if (Test-Path $path) { Get-ChildItem $path | Select-Object PSChildName } else { "Chiave non presente." }
} Best practice per evitare il problema in futuro
- Standardizza i percorsi di installazione delle app tra i nodi (scripting o immagini dorate).
- Automatizza la pubblicazione delle RemoteApp (PowerShell/CI) per ridurre gli errori manuali.
- Monitoring: metrica listener 3389, stato
TermService, feed RDWeb e certificati con scadenza < 30 giorni. - Documenta l’uso di RD Gateway e l’impatto su reti remote/VPN.
- DNS governance: processi chiari per record, multi‑NIC e split‑brain DNS.
Riepilogo finale
Quando le RemoteApp funzionano su A ma non su B, pensa in termini di triade: connettività (porta 3389 e firewall), pubblicazione (Collection, allow‑list, path/alias) e trust (certificati, DNS/FQDN, policy). Il messaggio “not in the list of authorized programs” punta alla allow‑list/Collection o a un disallineamento del percorso; il generico “Remote Desktop can’t connect…” invita a controllare prima rete/NLA/DNS. Per l’app locale 127.1.1.1:8000, ricorda che il listener quasi sempre è su 127.0.0.1: usa quell’indirizzo o modifica il bind. Con la checklist e i comandi suggeriti, la diagnosi diventa ripetibile e veloce.
Appendice: tabella azioni mirate e risultati attesi
| Azione | Comando/GUI | Esito atteso | Se fallisce |
|---|---|---|---|
| Test RDP diretto su B | mstsc /v:B /admin | Logon riuscito | Verifica firewall/NLA/DNS |
| Porta 3389 in ascolto | netstat -ano | find "3389" | Stato LISTEN | Riavvia TermService, controlla ACL |
| Membership Collection | Get-RDSessionHost | B elencato | Riaggiungi B alla Collection |
| RemoteApp pubblicate | Get-RDRemoteApp | App presenti | Ripubblica/aggiorna alias e path |
| Allow‑list su B | Registro TSAppAllowList | App elencate | Forza ripubblicazione su B |
| Certificati RDS | Deployment Properties | Validi/non scaduti | Riassegna o rigenera |
| DNS corretto | nslookup/FQDN | IP raggiungibile | Correggi record/registrazioni NIC |
Nota operativa: le modifiche a Collection, ruoli RDS e certificati impattano gli utenti connessi. Pianifica finestre di manutenzione e comunica eventuali disconnessioni.
Contenuti chiave richiamati
- Errore RemoteApp su B: controlla allow‑list, path, membership della Collection, certificati, DNS.
- Porta 3389: deve essere aperta su tutti i Session Host RDS.
- App locale 127.1.1.1:8000: usa
127.0.0.1o adegua il bind; verifica listener, firewall e proxy.