RemoteApp consente di pubblicare applicazioni Windows da un’infrastruttura centralizzata, presentandole agli utenti come normali programmi locali. La tecnologia fa parte dei Remote Desktop Services di Windows Server ed è disponibile nelle versioni 2019, 2022 e 2025. Per utilizzarla in produzione servono però un’architettura RDS correttamente dimensionata, licenze adeguate e controlli di sicurezza specifici.
Invece di installare e aggiornare lo stesso software su ogni endpoint, l’applicazione viene eseguita su uno o più server RD Session Host. Il client riceve tramite Remote Desktop Protocol l’interfaccia grafica e invia al server input da tastiera e mouse. Il dato applicativo può quindi restare nel datacenter o nel cloud, mentre l’utente interagisce con una finestra integrata nel proprio desktop.
Questo modello è particolarmente utile per software gestionali, applicazioni legacy, programmi che richiedono una configurazione uniforme o scenari nei quali è necessario fornire accesso controllato a utenti remoti, sedi periferiche, consulenti e partner.
Che cosa sono Remote Desktop Services e RemoteApp
I Remote Desktop Services (RDS) sono la piattaforma integrata in Windows Server per distribuire desktop e applicazioni tramite RDP. I principali modelli di erogazione sono:
- Desktop basato su sessione: più utenti condividono un sistema operativo Windows Server, mantenendo sessioni separate.
- RemoteApp: viene pubblicata una singola applicazione, senza mostrare all’utente l’intero desktop del server.
- VDI: ogni utente utilizza una macchina virtuale Windows client dedicata o assegnata da un pool.
RemoteApp non installa realmente il programma sul dispositivo dell’utente. La finestra dell’applicazione viene visualizzata sul client, ma il processo, l’accesso ai file, la memoria e la maggior parte dell’elaborazione rimangono sul Session Host. Questo riduce la dispersione delle installazioni e rende più controllabili patch, versioni e configurazioni.
Quando RemoteApp è una scelta efficace
RemoteApp è adatta soprattutto quando il requisito principale è distribuire applicazioni Windows centralizzate mantenendo un’esperienza simile a quella locale. I vantaggi più rilevanti sono:
- Gestione centralizzata: installazione, aggiornamento e manutenzione dell’applicativo avvengono sui Session Host.
- Uniformità operativa: tutti gli utenti utilizzano la stessa release e la stessa configurazione del software.
- Controllo dei dati: database, file e credenziali applicative possono restare all’interno dell’infrastruttura aziendale.
- Compatibilità con applicazioni legacy: alcuni software non sono facilmente distribuibili via browser, SaaS o gestione moderna degli endpoint.
- Accesso multi-dispositivo: gli utenti possono utilizzare client Windows, macOS, iOS, Android o il web client supportato.
- Onboarding più rapido: l’IT assegna l’applicazione a un gruppo senza installarla su ogni singolo PC.
La soluzione non elimina la necessità di test applicativi. Un programma deve essere compatibile con l’esecuzione multi-sessione e non deve presumere che file, chiavi di registro, porte locali o componenti condivisi siano utilizzati da un solo utente.
Ruoli necessari per un'infrastruttura RemoteApp
Un deployment RDS completo può distribuire i ruoli su server distinti oppure consolidarli in base a utenti, disponibilità richiesta e carico. I componenti principali sono i seguenti:
RD Session Host
Ospita le sessioni degli utenti e le applicazioni pubblicate. È il componente sul quale vengono installati i programmi destinati a RemoteApp. In una farm possono essere presenti più Session Host per aumentare capacità e disponibilità.
RD Connection Broker
Gestisce le connessioni alle collection, distribuisce le nuove sessioni tra i Session Host e riconnette l’utente alla sessione già esistente. Nei deployment critici il Broker deve essere progettato in alta disponibilità.
RD Web Access
Espone il portale e i feed dai quali gli utenti visualizzano desktop e RemoteApp autorizzate. Il servizio utilizza HTTPS e deve essere pubblicato con un certificato attendibile e coerente con il nome DNS utilizzato.
RD Gateway
Consente l’accesso da reti esterne incapsulando RDP in HTTPS sulla porta TCP 443. È il punto di ingresso raccomandato per l’accesso remoto: la porta RDP 3389 dei Session Host non deve essere esposta direttamente su Internet.
RD Licensing
Installa, assegna e traccia le Remote Desktop Services Client Access License. Le RDS CAL sono disponibili per utente o per dispositivo e devono essere compatibili con la versione del Session Host. Un Session Host Windows Server 2025 richiede RDS CAL Windows Server 2025; CAL di versioni successive possono invece accedere a Session Host precedenti.
Quick Start o Standard Deployment
Server Manager propone due approcci distinti. La scelta non deve essere basata soltanto sulla rapidità di installazione.
- Quick Start: installa i ruoli principali su un singolo server. È adeguato per laboratorio, proof of concept o ambienti molto piccoli con requisiti limitati.
- Standard Deployment: consente di distribuire i ruoli su sistemi separati e costituisce la base corretta per farm scalabili, ridondanti e manutenibili.
In produzione è necessario valutare almeno separazione dei ruoli, ridondanza del Connection Broker, bilanciamento di RD Gateway e RD Web Access, capacità dei Session Host, storage dei profili, certificati, monitoraggio e procedure di manutenzione senza interruzione del servizio.
Installazione delle applicazioni sul Session Host
Le applicazioni devono essere installate sul RD Session Host secondo le indicazioni del produttore e validate in un contesto multiutente. Per i programmi che richiedono esplicitamente la modalità di installazione di Remote Desktop Session Host, è possibile utilizzare:
Dopo il completamento dell'installazione:
La modalità non sostituisce i test di compatibilità. Prima della pubblicazione occorre verificare almeno avvio simultaneo da più sessioni, gestione dei file temporanei, componenti Office o database locali, mapping delle stampanti, periferiche, aggiornamenti automatici e comportamento del software durante logoff e disconnessioni.
Creazione di una Session Collection
Una Session Collection raggruppa uno o più RD Session Host e definisce quali utenti possono accedere ai desktop o alle RemoteApp pubblicate. Il processo tipico comprende:
Nota operativa: Le collection sono anche il confine operativo per capacity planning e manutenzione. Applicazioni con requisiti o cicli di aggiornamento differenti possono essere collocate su collection separate per ridurre conflitti e impatti.
Come pubblicare una RemoteApp
Dopo aver creato la collection e installato l’applicazione, la pubblicazione avviene dalla sezione RemoteApp Programs della collection:
Nota operativa: L’accesso via feed consente di integrare le applicazioni autorizzate nel client e, sui sistemi Windows supportati, nel menu Start. L’URL viene normalmente pubblicato tramite RD Web Access e deve utilizzare HTTPS con un certificato valido.
Sicurezza di RemoteApp e RDS
Un ambiente RDS concentra accessi, applicazioni e dati; una configurazione debole può quindi trasformarlo in un punto di ingresso ad alto impatto. La pubblicazione deve rispettare almeno le seguenti misure:
Assessment tecnico dell'ambiente RDS
Nexsys analizza architettura, licensing, accesso esterno, profili, capacità, sicurezza e continuità operativa di deployment Remote Desktop Services esistenti o da progettare.
Licenze RDS CAL: per utente o per dispositivo
Ogni utente o dispositivo che accede a un RD Session Host deve essere coperto da una RDS CAL appropriata. Le modalità principali sono:
- Per User: assegnata all’utente, che può collegarsi da più dispositivi. È normalmente adatta quando ogni persona utilizza PC, notebook o dispositivi differenti.
- Per Device: assegnata al dispositivo, che può essere condiviso da più utenti. È spesso più adatta a postazioni su turni, reparti produttivi o terminali condivisi.
Il periodo di tolleranza iniziale non deve essere considerato un modello di esercizio. Il License Server deve essere attivato, configurato nella modalità corretta e monitorato. La compatibilità delle CAL è discendente: una CAL più recente può coprire Session Host precedenti, mentre una CAL precedente non può essere utilizzata per un Session Host più recente.
Prestazioni, profili e dimensionamento
Il numero di utenti per server non può essere definito con una soglia universale. Il dimensionamento dipende da CPU, memoria, storage, profilo applicativo, stampa, grafica, periferiche, antivirus, logon storm e concorrenza reale.
Il capacity planning deve distinguere almeno utenti task worker, knowledge worker e power user. È necessario eseguire test con carichi realistici, monitorare CPU per sessione, memoria impegnata, latenza disco, tempi di logon e banda, mantenendo capacità residua per picchi e manutenzione.
La strategia dei profili incide direttamente su tempi di accesso e affidabilità. Profili locali non controllati generano crescita dei dischi e incoerenze tra Session Host; profili centralizzati o containerizzati richiedono storage resiliente, bassa latenza e procedure di backup compatibili.
RemoteApp, desktop RDS o Azure Virtual Desktop
La scelta deve partire dal carico di lavoro e non dalla tecnologia disponibile.
- RemoteApp: indicata quando l’utente deve utilizzare una o poche applicazioni Windows senza ricevere un desktop completo.
- Desktop basato su sessione RDS: adatto quando l’utente necessita di un ambiente di lavoro centralizzato con più applicazioni integrate.
- Azure Virtual Desktop: da valutare quando sono prioritari elasticità cloud, distribuzione geografica, integrazione con servizi Azure o desktop Windows client in modalità multi-sessione.
In ambienti ibridi, RemoteApp può convivere con servizi SaaS, Microsoft 365 e soluzioni Modern Workplace. La decisione deve includere costi ricorrenti, requisiti applicativi, identità, sicurezza, latenza, gestione degli endpoint e competenze operative.
Errori frequenti nei deployment RemoteApp
Competenze necessarie per amministrare RDS
La gestione di RemoteApp richiede competenze trasversali su Windows Server, Active Directory, Group Policy, certificati, networking, hardening, licensing, storage e monitoraggio. Il corso Windows Server di Nexsys include amministrazione di Windows Server 2025, servizi di rete, sicurezza, accesso remoto e Remote Desktop Services.
Progettazione e gestione RDS con Nexsys
Nexsys progetta, aggiorna e mette in sicurezza infrastrutture Remote Desktop Services per aziende che devono distribuire applicazioni Windows in modo centralizzato. L’attività può comprendere assessment dell’ambiente esistente, architettura dei ruoli, migrazione da Terminal Server legacy, pubblicazione sicura tramite RD Gateway, MFA, certificati, RDS CAL, profili, alta disponibilità, monitoraggio e procedure di continuità operativa.
L’intervento viene integrato con gli altri servizi IT per aziende, evitando configurazioni isolate e verificando dipendenze con Active Directory, networking, backup, sicurezza degli endpoint e applicazioni di business.
Devi pubblicare o aggiornare applicazioni tramite RemoteApp?
Richiedi una valutazione del perimetro: numero di utenti, applicazioni, sedi, requisiti di accesso esterno, disponibilità, sicurezza e licensing.
Domande frequenti su RemoteApp e Remote Desktop Services
RemoteApp funziona su Windows Server 2025?
Sì. RemoteApp fa parte dei Remote Desktop Services ed è supportata su Windows Server 2025, oltre che sulle versioni 2022, 2019 e 2016. Per una migrazione occorre verificare compatibilità applicativa, ruoli RDS, certificati e RDS CAL.
Qual è la differenza tra RemoteApp e desktop remoto?
Con il desktop remoto l’utente visualizza un intero ambiente desktop ospitato sul server. Con RemoteApp viene presentata soltanto la finestra dell’applicazione pubblicata, pur continuando a essere eseguita sul Session Host.
Per usare RemoteApp servono le RDS CAL?
Sì. Ogni utente o dispositivo che accede a un RD Session Host deve disporre di una RDS CAL compatibile, configurata in modalità Per User o Per Device in base al modello di utilizzo.
È sicuro pubblicare RemoteApp su Internet?
La pubblicazione può essere sicura se utilizza RD Gateway su HTTPS, certificati attendibili, MFA, hardening, segmentazione, logging e patching. Non è corretto esporre direttamente la porta RDP 3389 dei Session Host su Internet.
Quando conviene usare Quick Start?
Quick Start è adatto soprattutto a laboratori, proof of concept e piccoli ambienti non critici. Per servizi produttivi con requisiti di disponibilità, scalabilità e manutenzione è preferibile uno Standard Deployment con ruoli distribuiti e ridondanza progettata.
RemoteApp sostituisce Azure Virtual Desktop?
No. Le due piattaforme rispondono a requisiti in parte sovrapposti ma hanno modelli operativi e di costo differenti. RemoteApp su RDS mantiene il controllo dell’infrastruttura Windows Server; Azure Virtual Desktop offre un servizio desktop cloud integrato con Azure.