Installare e attivare il ruolo RDS Licensing su Windows Server

Installare il ruolo RDS Licensing senza confondere il server licenze con i Session Host

Il punto che crea più errori in ambienti Remote Desktop Services è semplice: il ruolo RD Licensing non serve a pubblicare desktop o applicazioni, ma a gestire i Client Access License per i Session Host. Se lo installi sul server sbagliato o lo attivi senza una vista chiara della topologia, il risultato tipico è un deployment che parte ma poi entra in grace period, oppure Session Host che non trovano il license server e registrano eventi di errore nel registro di sistema.

La sequenza corretta è: installare il ruolo, attivare il server di licenze, installare le CAL RDS appropriate e infine dire ai Session Host dove cercarlo. Saltare uno di questi passaggi produce sintomi diversi, ma la radice è sempre la stessa: discovery incompleta o licenze non disponibili.

Quando conviene mettere il ruolo RD Licensing sullo stesso server

In piccoli ambienti si può mettere il ruolo su un server già esistente, ma in produzione la scelta migliore è separare almeno il piano di licensing dal resto dei servizi critici. Il motivo non è teorico: il licensing deve restare raggiungibile dai Session Host, deve essere amministrabile in modo stabile e non dovrebbe dipendere da un server che cambia spesso nome, IP o funzione.

Se vuoi ridurre il rischio operativo, usa un server membro di dominio dedicato o quasi dedicato. Evita, quando possibile, DC, host con ruoli molto dinamici o macchine usate come jump server improvvisato. Il ruolo in sé è leggero, ma il suo valore è alto: quando non è raggiungibile, l’effetto lo vedi sugli utenti finali.

Prerequisiti che vale la pena verificare prima di toccare il ruolo

Prima di installare, controlla tre cose: appartenenza al dominio, connettività tra Session Host e licensing server, e presenza di un account con privilegi adeguati per l’attivazione del server licenze. Se il server è fuori dominio, il discovery automatico diventa più fragile e spesso finisci a configurare tutto a mano, con più margine d’errore.

Verifica anche il nome DNS con cui il server sarà raggiunto. In RDS, usare un nome coerente e stabile evita problemi quando il certificato, il firewall o le policy di gruppo entrano in gioco. Se il server viene rinominato dopo l’installazione, documenta il cambio e controlla che i Session Host puntino ancora al nome corretto.

Installazione del ruolo RD Licensing da Server Manager o PowerShell

La via più pulita resta Server Manager, soprattutto se stai facendo un change controllato e vuoi ridurre il rischio di digitazione. Il percorso è quello classico: Add roles and features, selezione del server, ruolo Remote Desktop Services, quindi Remote Desktop Licensing.

Se preferisci automatizzare o replicare il deploy, PowerShell è più adatto. Il comando non richiede passaggi ambigui e ti lascia un audit più chiaro nel change record.

Comando tipico:

Install-WindowsFeature RDS-Licensing -IncludeManagementTools

Dopo l’installazione, verifica che il ruolo sia presente e che gli strumenti di gestione siano disponibili.

Get-WindowsFeature RDS-Licensing

Atteso: stato Installed. Se non lo vedi, il problema è a monte: ruolo non installato, sessione PowerShell non elevata o server non raggiungibile correttamente dal contesto amministrativo.

Attivazione del server licenze: il passaggio che molti lasciano a metà

Installare il ruolo non basta. Un server RD Licensing non attivato è tecnicamente presente, ma non può emettere licenze in modo utile. L’attivazione si fa dal console manager del licensing o tramite procedure guidate del ruolo. In ambienti con vincoli di rete o policy più rigide, può essere necessario passare da un metodo online, telefonico o web browser, a seconda della connettività consentita verso Microsoft.

Il controllo pratico è semplice: apri il Remote Desktop Licensing Manager e verifica che il server mostri stato attivo. Se il server appare ma non risulta attivato, i Session Host continueranno a non ricevere licenze anche se il ruolo è formalmente installato.

Se vuoi controllare la presenza del servizio lato sistema, usa:

Get-Service TermServLicensing

Il servizio deve risultare in esecuzione o almeno installato correttamente. Se è fermo per errore, guarda prima il registro eventi applicativo e i log del ruolo, non partire da restart casuali.

Installare le CAL RDS corrette: per utente o per dispositivo

Qui si sbaglia spesso per fretta. Le licenze RDS non sono intercambiabili a posteriori in modo libero: devi sapere se il tuo scenario richiede Per User o Per Device. La scelta dipende dal modello d’uso, non da una preferenza estetica. In uffici con postazioni fisse può avere senso Per Device; in ambienti con utenti mobili o BYOD la modalità Per User è spesso più gestibile.

Dopo l’attivazione del server, apri il licensing manager e usa il wizard per installare il pacchetto CAL fornito dal vendor o dal contratto di licensing. Il pacchetto deve corrispondere alla versione e al tipo di licenza acquistata. Se installi un pacchetto non coerente, il wizard può completarsi ma il pool non sarà utilizzabile come ti aspetti.

Errore classico: server attivato, CAL presenti, ma tipo di licenza e configurazione dei Session Host non allineati. Il sintomo non è “manca il ruolo”, è “il broker non riesce a consumare il licensing nel modo previsto”.

Dire ai Session Host dove cercare il license server

Il server licenze può essere perfettamente sano e non servire a nulla se i Session Host non sanno dove guardare. In dominio, la strada più pulita è la Group Policy. In particolare, configura il criterio per specificare i server di licenza RDS e il tipo di licenza da usare. Questo evita dipendenze da impostazioni manuali sparse.

Il percorso GPO tipico è:

Computer Configuration
  └─ Administrative Templates
      └─ Windows Components
          └─ Remote Desktop Services
              └─ Remote Desktop Session Host
                  └─ Licensing

Le policy da impostare sono due: specifica i server di licenza e imposta la modalità Per User o Per Device. Se la modalità sul Session Host non coincide con quella delle CAL installate, la configurazione resta formalmente valida ma il consumo licenze non funziona come previsto.

Per forzare un refresh della policy dopo il change:

gpupdate /force

Se vuoi verificare cosa è stato davvero applicato, controlla il report RSoP o la policy effettiva sul server. In caso di dubbi, il punto non è “la GPO c’è”, ma “la GPO è arrivata nel computer account giusto”.

Verifiche lato sistema: eventi, stato servizio e discovery

Dopo l’installazione e la configurazione, le verifiche utili sono tre: stato del servizio, eventi nel registro e visibilità del server licenze dai Session Host. Non serve partire da una reinstallazione se la telemetria dice già dove sta il problema.

Controlla il registro eventi su Session Host e licensing server. I log più utili sono quelli legati a Remote Desktop Services e Licensing. Se vuoi un test rapido di connettività, verifica la risoluzione DNS e la porta di management se prevista dal tuo scenario, ma il vero indicatore resta la presenza di eventi coerenti con il discovery del server licenze.

Un controllo pratico utile è confermare che il server sia raggiungibile con il nome corretto:

ping rds-lic-01.example.local

Il ping da solo non prova il funzionamento del licensing, ma smonta subito gli errori più banali di naming o DNS. Se il nome non risolve, il problema non è il ruolo: è la base di rete.

Sequenza consigliata per un change controllato

Se devi farlo in produzione, la sequenza meno rischiosa è questa: prepara DNS e naming, installa il ruolo, attiva il server, installa le CAL, applica la GPO ai Session Host, poi verifica gli eventi e l’accesso utente. Invertire l’ordine non rompe tutto subito, ma aumenta il numero di variabili quando qualcosa non torna.

1. Conferma nome host, DNS e membership al dominio del server licenze.
2. Installa il ruolo RD Licensing.
3. Attiva il server nel Licensing Manager.
4. Installa le CAL corrette per versione e modello di utilizzo.
5. Configura via GPO i Session Host con server di licenza e tipo di licenza.
6. Forza aggiornamento policy e verifica i log.

Questa sequenza riduce il blast radius: se qualcosa va storto, il rollback più semplice è rimuovere la GPO o riportarla a una OU di test, senza toccare subito il ruolo o il database di configurazione del deployment.

Problemi tipici e come riconoscerli senza andare a tentativi

Se il Session Host entra in grace period, il primo sospetto non è sempre la mancanza di licenze. Potrebbe essere il server licenze non attivato, la GPO non applicata, il tipo di licenza errato o un problema di reachability DNS. In ordine di probabilità, io guarderei prima discovery, poi attivazione, poi compatibilità delle CAL.

Se il licensing manager mostra il server ma non le CAL disponibili, verifica che il pacchetto installato sia quello giusto e che non ci sia un mismatch di versione. Se invece il manager non vede proprio il server, il problema è più a monte: servizio, firewall, nome host o dominio.

Se vuoi un test rapido lato policy, controlla che la GPO sia arrivata davvero sul computer del Session Host. Il risultato utile non è “policy presente in dominio”, ma “policy applicata localmente al server che eroga la sessione”.

Hardening minimo che non complica la vita

Il server licenze non va esposto più del necessario. Mantieni l’accesso amministrativo ristretto, applica patch regolari e tratta il servizio come componente sensibile del piano RDS. Non servono scelte elaborate: bastano least privilege, firewall coerente e controllo dei cambi di nome o IP.

Se usi account di servizio o credenziali per l’attivazione, non lasciarle in chiaro nei documenti operativi. Se devi conservarle, usa un vault e ruotale secondo policy. La parte di licensing non è un buon posto dove accumulare eccezioni di sicurezza, perché l’impatto di un errore si misura direttamente sulla disponibilità dei desktop remoti.

Rollback pratico se il change non va come previsto

Se hai installato il ruolo ma non vuoi mantenerlo, il rollback consiste nel rimuovere il ruolo dal server e annullare la GPO sui Session Host. Prima di farlo, verifica che esista un altro licensing server già attivo, altrimenti rischi di spostare il problema da una macchina all’intero deployment.

La rimozione del ruolo si fa da Server Manager o da PowerShell, ma va trattata come change con impatto: se il server era l’unico punto di licensing, il blast radius è alto e il rollback reale non è “disinstallo”, è “ripristino il percorso di licenza alternativo”.

In sintesi operativa: installa il ruolo, attivalo, carica le CAL corrette, configura i Session Host via GPO e verifica con log ed eventi. Se uno di questi passi manca, il problema non è quasi mai il wizard, ma il fatto che il licensing RDS richiede coerenza tra server, policy e tipo di licenza.