• Guide, Sistemi Operativi
• 25 Febbraio 2021

L’alta disponibilità dei Remote Desktop Services in Windows Server viene stabilita attraverso la duplicazione di ognuno dei ruoli di infrastruttura Desktop remoto, come descritto alla pagina Servizi Desktop remoto – Disponibilità elevata | Microsoft Docs

Abbiamo già visto nell’articolo Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016 e Windows Server 2019 – ICT Power come mettere in piedi un RDS Session-based deployment e come configurare le RemoteApp.

I Remote Desktop Services (RDS) sono una piattaforma di presentation virtualization che permette agli utenti di poter accedere in desktop remoto alle applicazioni, senza che queste vengano installate sulle proprie macchine.

In questa guida mostrerò come mettere in alta disponibilità una Farm RDS pensata per il Session-based deployment. Utilizzerò Windows Server 2019, ma le stesse operazioni sono valide anche per Windows Server 2016.

Per creare un RDS Session-based deployment abbiamo bisogno di installare in Windows Server 2016 i seguenti ruoli dei Remote Desktop Services:

• Remote Desktop Session Host – è il server in cui sono installate le applicazioni che vogliamo utilizzare
• Remote Desktop Connection Broker – è il server che si occupa di gestire le connessioni verso i Session Host e verso le RemoteApp
• Remote Desktop Web Access – consente agli utenti di accedere alla RemoteApp tramite un portale web ed un browser
• Remote Desktop Licensing Server – è il server che controlla che abbiate le licenze per potervi collegare (RDS CAL)
• Remote Desktop Gateway – questo server utilizza il Remote Desktop Protocol (RDP) su HTTPS per stabilire una connessione sicura e crittografata tra utenti remoti in Internet e i Session Host interni alla nostra rete in cui vengono eseguiti le applicazioni

Nella figura sotto sono mostrati i nomi dei server che utilizzerò per il mio deployment.

Figura 1: RDS Farm realizzata

Dopo aver creato i server, li ho aggiunti al mio dominio (demo.lab), come mostrato nella figura sotto:

Figura 2: I server sono stati aggiunti al dominio

Per poter gestire comodamente le diverse macchine, mi sono collegato ad una macchina del dominio con le credenziali di un domain admin e ho utilizzato il Server Manager per aggiungere al pool di server da gestire tutte le macchine che faranno parte della farm RDS.

Figura 3: Aggiunta al server pool delle macchine che faranno parte della farm RDS

Figura 4: Tutte le macchine sono gestibili da un unico server

Ho provveduto a creare un gruppo di computer in Active Directory nel quale ho inserito le due macchine su cui installerò il ruolo di RD Connection Broker. questo gruppo mi servirà più avanti per poter accedere al database condiviso che verrà utilizzato dai due . Ho chiamato il gruppo RDS_Broker e ho aggiunto le due macchine NIC-RDCB1 e NIC-RDCB2

Figura 5: Gruppo RDS_Broker con le due macchine che hanno il ruolo di Connection Broker

Nel DNS ho anche creato il nome NIC-RDCB che risolve in Round Robin i nomi dei due RD Connection Broker. Il nome verrà utilizzato più tardi quando metterò in alta disponibilità il ruolo di Connection Broker.

Figura 6: Creazione nel DNS dei record per la risoluzione degli indirizzi IP dei due Connection Broker

Creazione della Farm RDS

Procedete a questo punto all’ installazione dei servizi di Remote Desktop Services per la creazione del session-based deployment. Non è possibile mettere in alta disponibilità i ruoli al momento della creazione della farm RDS. Per questo motivo procedete all’ installazione dei diversi ruoli sulle prime macchine e successivamente provvederemo a mettere in alta disponibilità uno ad uno tutti i ruoli della Farm.

Dalla macchina di gestione, autenticati con le credenziali di Domain Admin, lanciate il wizard di installazione dei ruoli e delle funzionalità di Windows Server. Nelle figure sotto sono mostrati tutti i passaggi, che non necessitano di spiegazioni.

Figura 7: Lancio del wizard di installazione die ruoli e delle funzionalità di Windows Server

Figura 8: Scelta di installazione dei Remote Desktop Services

Figura 9: Creazione di uno standard deployment

Figura 10: Creazione di un sessione-based deployment

Figura 11: Ruoli che verranno installati perché necessari al session-based deployment

Figura 12: Scelta del primo RD Connection Broker – è possibile aggiungerne solo uno durante il wizard

Figura 13: Aggiunta dell’RD Web Access – è possibile aggiungerne solo uno durante il wizard

Figura 14: Aggiunta di tutti gli RD Session Host che volete utilizzare – è possibile aggiungerne più di uno durante il wizard

Figura 15: Conferma del deployment

Figura 16: Installazione e riavvio delle macchine con il ruolo di RD Session Host

Figura 17: Dopo il riavvio la configurazione viene completata con successo

Come è possibile vedere dalla figura sotto, nel Server Manager è stato creato un nuovo nodo che mostra il sessione-based deployment realizzato.

Figura 18: Session-based deployment nel Server Manager

Configurazione dell’alta disponibilità del ruolo RD Web Access

Il Remote Desktop Web Access consente agli utenti di accedere alla RemoteApp tramite un portale web ed un browser. Per poterlo mettere in alta disponibilità è sufficiente dal Server Manager cliccare col tasto destro sull’icona dell’RD Web Access e scegliere Add RD Web Access Servers. Nelle figure sotto sono mostrati tutti i passaggi, che non necessitano di commenti.

Figura 19: Aggiunta di un altro server RD Web Access

Figura 20: Scelta del secondo server RD Web Access

Figura 21: Aggiunta del secondo server RD Web Access al deployment

Figura 22: Aggiunta del secondo server RD Web Access completata

Come si può vedere dalla precedente figura, al termine del wizard di aggiunta del secondo server RD Web Access viene chiesto di configurare i certificati digitali. Ce ne occuperemo più avanti nel corso di questa guida.

Bilanciamento del carico per gli RD Web Access

Per completare l’alta disponibilità del ruolo RD Web Access è necessario utilizzare un bilanciatore di carico che permetta poi di potersi connettere ai servizi web offerti dal ruolo. Potete servirvi di un bilanciatore di carico esterno oppure potreste utilizzare il servizio Network Load Balancing di Windows Server.

Qui di seguito vi mostro come installare e configurare il servizio di Network Load Balancing di Windows Server sui due server con il ruolo di RD Web Access. Dal Server Manager installate su entrambe le macchina con il ruolo di RD Web Access la funzionalità.

Figura 23: Installazione della funzionalità di Network LOAD Balancing sulle due macchine con il ruolo di RD Web Access

Una volta installata la funzionalità sulle due macchine, aprite il Network Load Balancing Manager su una delle macchine e procedete con la creazione del cluster e con le configurazioni mostrate nelle figure sotto. Quello che B lanceremo sarà il traffico diretto verso la porta TCP 443.

Figura 24: Creazione del nuovo nodo del cluster NLB con aggiunta del primo nodo

Figura 25: Primo nodo del cluster NLB

Figura 26: Scelta del cluster IP utilizzato dal cluster NLB

Figura 27: Nome del cluster e tipo di modalità operativa (Multicast)

Figura 28: Configurazione della porta e del protocollo da bilanciare

Figura 29: Completamento del wizard di creazione del cluster NLB

Figura 30: Aggiunta del secondo nodo al cluster NLB

Figura 31: i due nodi RD Web Access sono stati aggiunti al cluster e sono funzionanti

Le stesse operazioni potevano essere effettuate con pochi comandi PowerShell:

Poiché per l’accesso alla mia farm RDS ho deciso di utilizzare un certificato pubblico e ho deciso di utilizzare un nome differente da quello del dominio, ho creato una zona DNS interna (ictpower.cloud) che ne permettesse la risoluzione anche ai computer che accedono dalla rete di dominio. Per i computer che invece accederanno da Internet inserirò nel pannello DNS pubblico l’indirizzo IP pubblico della farm RDS.

Figura 32: Creazione del record del cluster NLB degli RD Web Access

Configurazione dell’alta disponibilità del ruolo RD Connection Broker

Decisamente più impegnativa è l’operazione di mettere in alta disponibilità il ruolo di Remote Desktop Connection Broker, il server che si occupa di gestire le connessioni verso gli RD Session Host e verso le RemoteApp.

È necessario infatti che i diversi RD Connection Broker scrivano in un database SQL condiviso, che potrebbe essere un SQL Server locale oppure un database SQL di Azure. Il ruolo di RD Connection Broker è un ruolo vitale della vostra infrastruttura e rappresenta il cervello che si occupa di distribuire le nuove connessioni oppure effettuare le riconnessioni in caso di perdita di connettività.

In questa guida utilizzerò un database ospitato su SQL Server 2019. È il caso però che anche il server SQL sia altamente disponibile. Quindi vi consiglio di utilizzare un database ospitato in un SQL
Always On availability group. Date un’occhiata alla mia guida Configurare l’alta disponibilità di RDS Connection Broker in Windows Server 2016 e Windows Server 2019 con SQL Server Always On Availability Group

Come prima operazione creo, dal SQL Management Studio, una nuova login e aggiungo il gruppo degli RDS-Broker che ho creato in precedenza in Active Directory. Nella figura sotto sono mostrati tutti i passaggi necessari. Grazie a questa login i due RD Connection Broker saranno capaci di gestire il database dove verranno conservate tutte le informazioni e le configurazioni.

Figura 33: Creazione della login per l’accesso del gruppo degli RD Connection Broker

Assegnate alla login che state creando il ruolo di dbcreator

Figura 34: Assegnazione del ruolo di dbcreator alla login che permetterà l’accesso dei due RD Connection Broker

Procedete quindi alla creazione di un nuovo database, lasciando le configurazioni di default. Io l’ho chiamato RDSHA.

Figura 35: Creazione di un nuovo database

Dopo aver creato il database, modificate le proprietà della login che avete creato in precedenza e dal nodo User Mapping, selezionate il segno di spunta vicino al database creato (nel mio caso RDSHA) e selezionate la casella db owner, come mostrato nella figura sotto:

Figura 36: Assegnazione del ruolo di db owner alla login utilizzata dai due RD Connection Broker

Installate il SQL Server Native Client 11 sui vostri RD Connection Broker. Su ognuno di loro procedete a scaricare il client partendo dall’indirizzo https://go.microsoft.com/fwlink/?linkid=866658

Scegliete Download Media e dopo aver estratto i file accedete alla cartella \SQLEXPR_x64_ENU\1033_ENU_LP\x64\Setup\x64 all’interno della quale troverete il file SQLNCLI.msi

Figura 37: Download dei tools di SQL Server

Figura 38: Scelta della lingua dell’installer di SQL Server

Figura 39: Installazione del SQL Server Native Client 11 in tutti e due i Connection Broker

NOTA: Assicuratevi di installare almeno la versione 11.4.7462.6 di SQL Server Native Client 11 sui vostri RD Connection Broker ,altrimenti potreste avere problemi di connessione al server SQL 2019.

Possiamo quindi ora tornare nel Server Manager e dal Deployment Overview cliccare col tasto destro sul’icona RD Connection Broker e scegliere la voce Configure High Availability.

Figura 40: Configurazione High Availability dell’RD Connection Broker

Figura 41: Wizard di configurazione High Availability dell’RD Connection Broker

Figura 42: Scelta del tipo di database server da utilizzare

Inserite a questo punto il nome del cluster di RD Connection Broker (vi ricordate il record NIC-RDCB che abbiamo creato poco fa nel DNS?) e la stringa di connessione al database, nella forma DRIVER=SQL Server Native Client 11.0;SERVER=<nome del server SQL>;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=<nome del database>. Nel mio caso la stringa di connessione è:

DRIVER=SQL Server Native Client 11.0;SERVER=NIC-SQL1;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDSHA

Figura 43: Inserimento del nome del cluster RD Connection Broker e stringa di connessione al database

Se non ci saranno problemi, procederete col wizard. In caso contrario vi apparirà una schermata di errore e dovrete investigare sui permessi di accesso al database, sulle regole del firewall dei server SQL e dei server RDCB, sulla correttezza della stringa di connessione e sulla versione del SQL Server Native client 11. Insomma tutto quello che potrebbe impedire agli RD Connection Broker di potersi collegare al database che avete precedentemente creato.

Figura 44: Connessione al database SQL avvenuta correttamente

Figura 45: Configurazione dell’alta disponibilità completata

Una volta completata la configurazione dell’alta disponibilità degli R the connection broker , nel Server Manager sarà evidenziato che il primo RD Connection Broker (nel mio caso NIC-RDCB1) è stato configurato per l’alta disponibilità.

Figura 46: Il primo RD Connection Broker (nel mio caso NIC-RDCB1) è stato configurato per l’alta disponibilità

Procedette quindi ad aggiungere il secondo RD Connection Broker cliccando con il tasto destro sull’icona RD Connection Broker e scegliendo Add RD Connection Broker Server, come mostrato nella figura sotto:

Figura 47: Aggiunta del secondo RD Connection Broker al nostro deployment

Figura 48: Prerequisiti necessari ad aggiungere il secondo RD Connection Broker

Figura 49: Scelta del secondo RD Connection Broker

Figura 50: Conferma della selezione dl secondo server

Se tutto sarà stato configurato al meglio, il wizard aggiungerà il secondo server senza problemi. Come si può vedere dalla figura sotto, io ho avuto un messaggio di errore.

Figura 51: Se il secondo RD Connection Broker non riesce a connettersi al DB riceverete un errore

Dopo qualche investigazione e dopo aver controllato che sul secondo RD connection broker (nel mio caso NIC-RDCB2) fosse installata la versione corretta e aggiornata del SQL Server Native Client 11, ho notato che alla login utilizzata per accedere al database era stato rimosso il permesso di db owner! Dopo aver ripristinato il permesso e aver rilanciato wizard tutto è proseguito senza intoppi.

NOTA: Il wizard di aggiunta del primo server ha rimosso il permesso di db owner alla login utilizzata dai server RD Connection Broker per accedere al database condiviso.

Figura 52: Ripristino dei permessi necessari ad accedere al database

Figura 53: Wizard completato con successo

Gestione dei certificati digitali nella nostra farm RDS

I certificati digitali, che permettono di effettuare connessioni sicure i nostri server, devono essere a questo punto distribuiti e configurati su tutte le macchine della nostra farm RDS. Alla fine di diversi wizard di configurazione dell’alta disponibilità viene infatti sempre mostrato il messaggio che è necessario configurare i certificati. Se alla nostra farm RDS sarà consentito l’accesso solo ai computer del nostro dominio, potete utilizzare una Certification Authority interna per creare i diversi certificati da poter installare sulle varie macchine. Qui di seguito trovate una serie di articoli su come creare una Certification Authority interna al dominio utilizzando Windows Server:

• Deploy PKI in Windows Server 2016 – Parte 1 Architettura di una PKI Two-Tier
• Deploy PKI in Windows Server 2016 – Parte 2 – Installazione e configurazione di una Root CA Offline
• Deploy PKI in Windows Server 2016 – Parte 3 Installazione Subordinate CA
• Gestione automatizzata dei certificati su connessioni RDS Session Host ed RDP

Se invece alla vostra farm RDS dovete concedere l’accesso anche ad utenti che si collegano dall’esterno dell’azienda, si collegano da macchine che non sono joinate al dominio di Active directory interno, si collegano attraverso un Remote Desktop Gateway, allora potrebbe essere il caso di utilizzare un certificato rilasciato da una Certification Authority pubblica.

Come mostrato nella guida Generazione di certificati digitali pubblici utilizzando la Certification Authority gratuita Let’s Encrypt e PowerShell – ICT Power è possibile ottenere certificati pubblici gratuiti, anche di tipo SAN o di tipo WILDCARD.

Ho proceduto quindi con pochi comandi PowerShell a procurarmi un certificato di tipo wildcard virgola che poi installer o su tutte le macchine della mia farm RDS.

I comandi utilizzati sono:

I certificati sono stati creati nella cartella %localappdata%\Posh-ACME\acme-v02.api.letsencrypt.org\<numero random>\!.ictpower.cloud

Figura 54: Creazione di un certificato pubblico GRATUITO di tipo WILDCARD da utilizzare per la Farm RDS

Distribuzione del certificato digitale

Per distribuire il certificato digitale è sufficiente collegarsi al Server Manager e dal Deployment Overview potete scegliere TASKS e distribuire i certificati come mostrato nelle figure sotto:

Figura 55: Distribuzione del certificato nella FARM RDS

Io ho utilizzato il certificato fullchain.pfx, che permette anche di distribuire i certificati intermedi utilizzati dalla Certification Authority.

Figura 56: Scelta del certificato da distribuire

Figura 57: Installazione del certificato per ogni singolo ruolo della Farm RDS

Test di accesso

Se avrete configurato tutto correttamente, quando gli utenti si collegheranno al nome del cluster NLB (remoteapp.ictpower.cloud) verranno reindirizzati verso uno dei due RD Web Access e avranno la possibilità di potersi loggare. Dopo aver inserito le credenziali, potranno vedere le RemoteApp a cui sono stati autorizzati. Vi rimando alla lettura dell’articolo Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016 e Windows Server 2019 – ICT Power per poter vedere come creare una Session Collection.

Figura 58: Il Remote Desktop Web access è raggiungibile tramite l’indirizzo del cluster NLB

Dopo aver inserito le credenziali vi appariranno le icone delle applicazioni (RemoteApp) che avete deciso di aggiungere alla vostra Session Collection. Cliccate su una delle icone per aprire la connessione verso uno degli RD Session Host che fanno parte della vostra Farm RDS. Dopo aver lanciato la connessione verso l’applicazione, vi apparirà un messaggio in cui vi verrà chiesto se considerare attendibile il Publisher dell’applicazione. In più vi verranno date indicazioni anche sul computer remoto a cui vi state connettendo. L’ RD Connection Broker si occuperà di ripartire il carico sui diversi RD Session Host ed effettuare le riconnessioni nel caso vi disconnettiate, assicurandovi di accedere sull’RD Session Host dove vi site già collegati e dove è rimasta aperta la sessione di lavoro.

Figura 59: Connessione alla RemoteApp

Figura 60: Connessione all’RD Session Host

Figura 61: Connessione completata con successo

Come avete visto, in questo caso, la connessione è stata effettuata dall’interno della rete e i nomi degli RD Session Host sono stati risolti in maniera corretta.

Per potervi connettere dall’esterno della rete aziendale sarà necessario utilizzare un Remote Desktop Gateway. Nella guida Configurare Remote Desktop Gateway in Windows Server 2016 e Windows Server 2019 – ICT Power ho mostrato come installarlo nell’infrastruttura. Adesso vediamo come metterlo in alta disponibilità.

Configurazione dell’alta disponibilità del ruolo Remote Desktop Gateway

Per rendere disponibile il ruolo Remote Desktop Gateway è necessario installare altre due macchine, magari da mettere in DMZ o dietro un reverse proxy. Io ho deciso installare altre due macchine virtuali e ho deciso di utilizzare il Network Load Balancing per il bilanciamento del carico.

Procedete all’installazione del ruolo RD gateway e della funzionalità NLB su ENTRAMBE le macchine, come mostrato nelle figure sotto:

Figura 62: Installazione del ruolo di Remote Desktop Gateway e della funzionalità di Network Load Balancer

Terminata l’installazione dei ruoli e delle funzionalità sarà necessario configurare le due macchine. Aprite il Remote Desktop Gateway Manager e provvedete all’ installazione del certificato digitale pubblico. io ho utilizzato lo stesso certificato digitale che ho ottenuto prima visto che ne avevo creato uno di tipo wildcard.

Figura 63: Installazione del certificato digitale che verrà utilizzato dal Remote Desktop Gateway

NOTA: il certificato digitale dovrà essere installato su entrambe le macchine. Ripetete la procedura anche sul secondo Remote Desktop Gateway.

Per permettere ai vostri utenti di accedere al server RDGW è necessario creare una nuova Authorization Policy, che indicherà sia chi è autorizzato ad accedere alla rete interna sia a quali server specifici (risorse) è possibile accedere. Lanciate quindi il wizard come mostrato in figura e procedete alla creazione sia della Connection Authorization Policy che della Resource Authorization Policy. maggiori dettagli sono disponibili nella mia guida Configurare Remote Desktop Gateway in Windows Server 2016 e Windows Server 2019 – ICT Power

Figura 64: Creazione sia della Connection Authorization Policy che della Resource Authorization Policy

Figura 65: Creazione della Connection Authorization Policy e della Resource Authorization Policy completata

Ripetete le stesse operazioni anche sul secondo Remote Desktop Gateway.

NOTA: è importante che le policy siano identiche sulle due macchine RD Gateway, altrimenti gli utenti potrebbero avere delle difficoltà di accesso.

Bilanciamento del carico di lavoro per i Remote Desktop Gateway

Per bilanciare il carico di lavoro di due Remote Desktop Gateway e per assicurarne l’alta disponibilità passate alla creazione di un nuovo Network Load Balancing Cluster, con la stessa modalità che abbiamo visto prima. nelle figure sotto sono mostrati i passaggi principali di questa operazione.

Figura 66: Creazione di un nuovo cluster NLB e relative configurazioni

Figura 67: Modifica delle porte utilizzate e bilanciate dal cluster NLB

Figura 68: Creazione del cluster NLB completata

Poiché per l’accesso alla mia farm RDS ho deciso di utilizzare un certificato pubblico e ho deciso di utilizzare un nome differente da quello del dominio, ho creato una zona DNS interna (ictpower.cloud) che ne permettesse la risoluzione anche ai computer che accedono dalla rete di dominio. Per i computer che invece accederanno da Internet inserirò nel pannello DNS pubblico l’indirizzo IP pubblico della farm RDS. Provvedete ad aggiungere alla zona il record creato per il cluster NLB dei RD Gateway (nel mio caso gateway.ictpower.cloud).

Figura 69: Creazione del record del cluster NLB dei due RD Gateway

Configurazione della Farm di Remote Desktop Gateway

Per poter avere l’alta disponibilità e dei Remote Desktop Gateway è necessario aggiungere i due gateway server alla stessa server farm. Per questo motivo, su ognuno di due remote gateway server fate tasto destro sul loro nome e dalle proprietà scegliete la scheda Server Farm. Aggiungete i nomi dei due server e fate click su Apply.

Figura 70: Aggiunta dei due gateway server alla stessa Server Farm

Nel caso riceviate un errore come quello mostrato in figura potete proseguire senza problemi.

Figura 71: Errore relativo al bilanciamento

Se invece vi appare un errore come quello mostrato nella figura sotto, in cui dice che lo status dei server è Unreachable, allora vuol dire che dovete modificare alcune regole del firewall di Windows Server.

Figura 72: Errore di comunicazione tra i due server dovuto alle regole dei firewall di Windows Server

Procedete quindi, su entrambi i gateway server, ad abilitare le tre regole:

• Remote Desktop Gateway Server Farm (RPC HTTP Load Balancing Service)
• Remote Desktop Gateway Server Farm (RPC-EPMAP)
• Remote Desktop Gateway Server Farm (TCP-In)

In modo tale che le due macchine possono parlare tra di loro e scambiarsi le informazioni necessarie a partecipare alla stessa Server Farm.

Figura 73:Modifica delle regole del firewall

Una volta che avrete modificato le regole di firewall su entrambi i gateway server procedete alla loro configurazione e nel giro di poco lo status passerà ad OK, come mostrato nella figura sotto:

Figura 74: Creazione della Server Farm di RD Gateway completata

Aggiunta dei Remote Desktop Gateway al session-based deployment

Adesso che avete configurato i vostri Remote Desktop Gateway sarà possibile aggiungerli al session-based deployment che avete precedentemente realizzato. Utilizzando il Server Manager vi basterà cliccare sull’icona RD Gateway e aggiungere i due server al deployment.

Figura 75: Aggiunta dei Remote Desktop Gateway al session-based deployment

Figura 76: Indicazione del nome FQDN da utilizzare per le connessioni dall’esterno

Figura 77: Riepilogo delle configurazioni da effettuare

Figura 78: Configurazione completata con successo

Configurazione del certificato digitale per il Remote Desktop Gateway

Nonostante abbiate già installato il certificato su due gateway server, sarà necessario impostarlo anche per il session-based deployment. Per distribuire il certificato digitale è sufficiente collegarsi al Server Manager e dal Deployment Overview potete scegliere TASKS e distribuire il certificato come mostrato nelle figure sotto:

Figura 79: Distribuzione del certificato per il Remote Desktop Gateway

Figura 80: Aggiunta del certificato per il Remote Desktop Gateway effettuata con successo

Se volete che anche dall’interno dell’infrastruttura le vostre macchine accedano al session-based deployment potete modificare il comportamento rimuovendo il segno di spunta dalla voce Bypass RD Gateway for local addresses

Figura 81: Configurazione per utilizzare l’RD Gateway anche in LAN

Test di funzionamento

Collegatevi al vostro Remote Desktop Web Access e lanciate la vostra RemoteApp. Come si può vedere dalla figura sotto, adesso ogni volta che verrà lanciata una sessione verrà utilizzato il Remote Desktop Gateway.

Figura 82: Avvio della sessione RemoteApp e connessione attraverso il Remote Desktop Gateway

Poiché abbiamo deciso di utilizzare l’RD Gateway anche in LAN, se dalla macchina client in dominio e nella stessa rete del session-based depolyment lanciate il comando

Vedrete che ci saranno alcune connessioni aperte proprio verso l’indirizzo privato del cluster di Remote Desktop Gateway.

Figura 83: Connessioni attive verso il Remote Desktop Gateway

Configurare l’alta disponibilità del Remote Desktop Licensing Server

Per configurare l’alta disponibilità dell’RD License Server è possibile installare due macchine che si occuperanno di distribuire le licenze. Dal Server Manager provvedete ad installare sulle due macchine il ruolo necessario.

Figura 84: Installazione del ruolo di Remote Desktop Licensing Server

Dopo aver terminato l’installazione dei ruoli, dalla console RD Licensing Manager provvedete ad attivare le macchine seguendo il wizard. Potete decidere di aggiungere le licenze durante il wizard oppure successivamente.

Ogni utente che si connette al Remote Desktop Session Host deve avere una licenza client access license (CAL). Esistono due tipi di RDS CAL:

• Per Device CAL: è un tipo di licenza permanente che viene assegnata ad un computer oppure ad un dispositivo che si connette al server RDS più di una volta. La prima volta che il dispositivo si connette gli viene rilasciata infatti una licenza temporanea. Questo tipo di licenze non sono concorrenti, cioè se avete 10 licenze Per Device CAL soltanto 10 host potranno connettersi al vostro server RDS.
• Per User CAL: questo tipo di licenza permette ad un utente di connettersi al server RDS da qualsiasi numero di computer o dispositivi. Questa licenza viene associata ad un utente di Active Directory e viene rilasciata in maniera non permanente, cioè solo per un periodo di tempo limitato (di default 90 giorni).

Sul licensing dei servizi RDS ne abbiamo parlato abbondantemente nella guida Considerazioni sul licensing dei Remote Desktop Services (RDS)

A aprtire da Windows Server 2003, quando aggiungete le licenze e avete più  di un license server, i server si avvisano tra di loro della disponibilità delle licenze e reindirizzano le richieste per le CAL quando non hanno più CAL da distribuire.

Distribuzione delle CAL sui diversi RD LIcensing Server

Se utilizzate le Per User CAL potete installare tutte le licenze su un unico license server. Al momenro dell’indirsponibilità di questo server, il secondo license server rilascerà aglu utenti delle licenze temporanee per permettere l’accesso e non ci saranno problemi.

Se utilizzate le Per Device CAL dovete assicurare che i license tokens siano sempre disponibili. Se installate tutte le licenze sul primo license server, al momento della sua indisponibilità il secondo server (solo la prima volta cheil dispositivo si connetterà) rilascerà una licenza temporanea per permettere l’accesso. Il problema si pone se il dispositivo si connetterà più di una volta. Il consgiglio è quello di avere daparte delel licenze di backup da installare all’occorrenza, nel caso di un prolungato malfunzionamento del primo licensing server.

Prima che l’RD Licensing Server rilasci le licenze è necessario attivarlo. DallìRD Licensing Manager cliccate col tasto destro sul nome del server e scegliete Activate. Seguite il wizard di attivazione inserendo tutte le informazioni richieste.

Figura 85: Attivazione dei due RD Licensing Server

Terminata l’attivazione sarà necessario registrare i due RD Licensing Server in Active Directory. Assicuratevi di avere i permessi sufficienti (Domain Admin) per poterlo fare dalla console, oppure fatelo direttamente dal domain controller. Fino a quando il server non verrà aggiunto al gruppo non potrà erogare licenze per utente.

Figura 86: Aggiunta del server RD Licensing al gruppo Terminal Server License Servers

Assicuratevi di effettuare l’operazione per entrambe le macchine

Figura 87: Configurazione dei due RD Licensing Server terminata

Completate il deployment aggiungendo le due macchine RD Licensing Server. Dal Server Manager, dopo aver selezionato il deployment, Cliccate sull’icona RD Licensing e aggiungete le due macchine.

Figura 88: Aggiunta delle due macchine RD Licensing al deployment

Figura 89: Aggiunta delle due macchine RD Licensing al deployment completata

Gestione degli User Profile Disks

Gli User Profile Disks sono una funzionalità dei Remote Desktop Services introdotta in Windows Server 2012. Si tratta di una valida alternativa ai Roaming Profiles e alle Folder Redirection quando utilizziamo gli scenari RDS. Il profilo dell’utente all’utente viene conservato all’interno di un disco VHDX che si trova in una cartella di rete condivisa. Questo disco virtuale viene montato ogni volta che l’utente si collega al Remote Desktop Session Host e viene smontato quando l’utente si scollega. Tutte le modifiche apportate al profilo dell’utente sono salvate all’interno del disco VHDX.

Per poter mettere in alta disponibilità le cartelle di rete condivise e quindi gli User Profile Disks vi consiglio di utilizzare uno Scale-out File Server, di cui ho parlato nell’articolo Creare uno Scale-out File Server in Windows Server 2019 – ICT Power

Conclusioni

Per assicurare l’alta disponibilità della nostra infrastruttura di Remote Desktop Services è necessario almeno raddoppiare tutti gli elementi che compongono l’infrastruttura. Sicuramente l’operazione non è banale e richiede l’utilizzo di molte risorse. Se volete automatizzare il tutto vi consiglio di utilizzare PowerShell e vi suggerisco di dare un’occhiata alla pagina GitHub – citrixguyblog/PowerShellRDSDeployment: Create a fully automated RDS Farm (2016) with HA and Gateway in 25 minutes