• Guide, Sistemi Operativi
• 25 Maggio 2019

Quando dobbiamo gestire un’infrastruttura RDS, soprattutto se le connessioni avvengono tramite reti poco performanti, è probabile che gli utenti lamentino malfunzionamenti generalizzati.

A volte la causa può essere imputata alla connessione, ma anche il comportamento degli utilizzatori può determinare situazioni che necessitano di approfondimento. Ad esempio, gli utenti che “chiudono” la finestra relativa alla sessione RDP senza effettuare una disconnessione corretta generano un numero elevato di sessioni disconnesse.

Per verificare il funzionamento dell’infrastruttura è utile interrogare il registro eventi in modo da individuare gli eventi significativi, soprattutto in caso di problemi di connessione.

Una RDS Farm può essere strutturata in diversi modi. L’esempio che prenderemo in considerazione in questo articolo si basa su una configurazione con accesso per mezzo di un portale Web e di un Connection Broker che ridirige le sessioni di connessione su più Session Host.

Prima di passare all’analisi vera e propria degli eventi è utile rivedere quali sono i flussi e le interazioni tra i vari componenti l’intera Farm RDS

I 5 ruoli che compongono una Farm RDS sono:

• Remote Desktop Web Access
  
• Remote Desktop Connection Broker
  
• Remote Desktop Session Host
  
• Remote Desktop Gateway
  
• Remote Desktop Licensing
  

Nel contesto analizzato in questa guida il ruolo RD Gateway non è installato e quindi non verrà considerato

Figura 1 schema dei ruoli RDS

Lo schema di figura 1 riporta in modo semplificato le relazioni tra i vari ruoli, l’uso del Web Access è utile in quanto permette da un unico portale l’accesso alle risorse che vengono rese disponibili

Configurazione della Farm tramite Server Manager

L’immagine qui sotto riporta la configurazione dell’ambiente utilizzato per l’analisi degli eventi

Figura 2 configurazione della farm RDS

Ruoli RDS

Il ruolo di Connection Broker che ha il compito di orchestrare gli accessi coordinando la distribuzione delle risorse in base al carico ed alla disponibilità degli host di sessione.

Il ruolo di Session Host, definisce i server dove fisicamente sono disponibili ed installate le applicazioni che vengono accedute tramite RDS.

Questo caso di studio non prevede la gestione di risorse di tipo Virtual Desktop (VDI)

Dal pannello di configurazione di RDS sono definiti 2 Session Host con uguale peso che verranno orchestrati tramite il Broker

Figura 3 infrastruttura Session Host

Analisi del flusso delle connessioni

Web Access

Il collegamento verso una farm RDS inizia dal ruolo di Web Access, quando l’utente ha effettuato il login viene generato e firmato digitalmente un file .RDP che permette la connessione sul Session Host

Il server Web essendo basato su IIS, ha i file di log che di default sono in “C:\inetpub\logs\LogFiles\W3SVC1”

In questa cartella, all’interno è presente un log testuale di tutte le attività. Analizzandolo è possibile identificare l’IP di provenienza della connessione ed anche l’utente che si è identificato

2019-05-19 21:32:29 10.0.1.81 GET /RDWeb/Pages/rdp/mstsc256_32x32.png – 443 dominio\utente
10.0.1.81 Mozilla/5.0+(Windows+NT+10.0;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko https://ts.ictpower.it/RDWeb/Pages/it-IT/Default.aspx 200 0 0 31

Ruolo Connection Broker

Il ruolo di Broker ha la responsabilità di assicurare la connessione, ossia di fare sì che sulla base delle regole configurate, ogni utente riceva le risorse corrette siano esse Sessioni Terminal, Remote App o VM in un ambiente VDI.

Il Broker si occupa anche di gestire le sessioni interrotte riconnettendole al Session Host corretto

All’interno del Registro Eventi il ruolo di Broker archivia le informazioni in:

“Microsoft-Windows-TerminalServices-SessionBroker/Operational“

“Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational”

Registro Eventi

“Microsoft-Windows-TerminalServices-SessionBroker/Operational”

Le informazioni disponibili in questo ramo del registro permettono di rilevare le attività del broker durante la connessione verso le risorse che questo espone.

Una connessione che avviene in modo normale, senza errori, riporta i seguenti eventi in ordine cronologico

Figura 4 Sessione di login

Event ID 800

Event ID 801

Event ID 787

Event ID 818

Dettaglio di singoli eventi

Event ID 800

Figura 5 event ID 800

Questo evento riporta le richieste di connessione ed è utile per identificare le richieste di da parte degli utenti

Event ID 801

Figura 6 event ID 801

In questo evento sono riportate informazioni di dettaglio relativamente alla sessione ed in particolare il Session Host di destinazione e l’informazione su eventuali sessioni disconnesse su cui il Broker ha riconnesso la sessione in ingresso

Disconnected Session Found 0x0 indica che non erano presenti sessioni disconnesse su cui l’utente è stato indirizzato

Figura 7 event ID 801 con riconnessiona ad una sessione disconnessa

Il dettaglio dell’evento sopra informa che il collegamento in ingresso è stata assegnato ad una sessione disconnessa che non ha ancora raggiunto i limiti impostati per il reset.

Disconnected Session Found 0x1 è il dettaglio dell’evento che evidenzia questo comportamento

La condizione sopra si verifica per ogni singolo utente, non verranno mai riassegnate sessioni disconnesse ad utenti differenti

Event ID 787

Figura 8 event ID 787

Con l’interrogazione dell’evento ID 787 è possibile conoscere il nome della farm per cui l’utente ha richiesto l’accesso, viene identificata come “farm” il nome della Collection (figura 2).

Il Session ID è invece utile per identificare puntualmente la sessione utente anche sul session Host in quanto identificata in entrambe i ruoli con lo stesso ID

Event ID 818

Figura 9 event ID 818

È l’informazione ultima delle attività relative al Broker, da questo momento gli eventi dovranno essere seguiti direttamente sul Session Host su cui l’utente ha fatto accesso.

l’evento ID 818 riporta testualmente

“This connection request has resulted in a successful session logon (User successfully logged on to the end point). Remote Desktop Connection Broker will stop monitoring this connection request.”

Registro Eventi

“Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational”

In questo registro si trovano le informazioni relative alla gestione e reindirizzamento delle connessioni che il broker riceve in ingresso e ridirige verso i Session Host

Gli eventi che sono presenti per una sessione che avviene in modo normale, senza disconnessioni, sono

Event ID 1301

Event ID 1307

Figura 10 event ID 1301 versione del client RDP

Questo evento riporta il nome utente che accede alla farm RDS e l’indicazione della versione del client

Event ID 1307

Figura 11 event ID 1307

In questo evento è riportata l’informazione del Session Host di destinazione

La sequenza di eventi descritta sopra è presente anche se si accede ad una Remote App anziché ad una sessione desktop come in questo caso

Ruolo Session Host

Su questo server viene indirizzata la connessione ed è il ruolo che ospita le applicazioni, i registri eventi utili per la diagnostica delle connessioni RDP sono

“Microsoft-Windows-TerminalServices-LocalSessionManager/Operational”

“Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational”

Registro Eventi

“Microsoft-Windows-TerminalServices-LocalSessionManager/Operational”

Analogamente a quanto visto con il ruolo di Broker questo registro riporta gli eventi relativi alle connessioni che il Session Host riceve.

L’esempio sotto riporta la sequenza di eventi che è rilevabile per una connessione che inizia e viene terminata in modo normale, senza disconnessioni forzate

Figura 12 sequenza completa degli eventi su un Session Host Server

La sequenza degli eventi è la seguente e sono elencati nell’ordine quelli relativi alla connessione e successivamente quelli relativi alla disconnessione

Eventi Relativi alla connessione

Event ID 41

Event ID 42

Event ID 21

Eventi relativi alla disconnessione

Event ID 22

Event ID 23

Event ID 40

Event ID 24

Dettaglio di singoli eventi

Event ID 40/41

Figura 13 eventi 40 e 41 arbitraggio delle sessioni

Questi due eventi in successione temporale, indicano che il Session Host ha gestito l’arbitraggio della connessione ed è riportato l’ID della sessione che come abbiamo visto in precedenza, ha la sua corrispondenza sul Broker nell’evento ID 787

Event ID 21

Figura 14 event ID 13 logon utente

Questo evento riporta il dettaglio della connessione verso il Session Host con il nome utente e l’ip del client da cui è stata richiesta la connessione

Event ID 22

Figura 15 event ID 22 assegnazione della Shell

È l’ultimo degli eventi relativi al login ed all’accesso dell’utente, i tre eventi che seguono sono relativi alla disconnessione

Event ID 23

Figura 16 logoff utente

Quando viene richiesta la disconnessione “pulita” della sessione il primo evento che viene registrato è relativo all’ID 23

Event ID 40

Figura 17 event ID 40 e Reason Code 12

Questo è l’evento più significativo in caso di diagnostica, rilevarne la presenza, ma soprattutto il “Reason Code” può aiutare a diagnosticare problemi di connessione, evidenziare problemi di autenticazione o di risorse del Session Host

Figura 18 event ID 40 e reason code 5

Reason code 5 indica una disconnessione non richiesta dall’utente e tipicamente è indice di due possibili cause

Chiusura della sessione in modo anomalo della sessione RDS con la funzione “Chiudi Finestra”

Cadute della connessione di rete, questo evento è comune nel caso di connessioni particolarmente degradate

Reason code 3 indica che una sessione ha raggiunto il limite di inattività ed è stata terminata

La tabella seguente riporta i codici possibili relativi agli eventi di disconnessione

Figura 19 reason codes di disconnessione

Event ID 24

Figura 20 conclusione della sessione e completamento della disconnessione

Questo, in ordine temporale è l’ultimo evento e informa della conclusione della sessione.

Considerazioni

L’ambiente RDS è molto complesso e le variabili con cui può essere implementato sono molteplici, il caso analizzato in questo articolo prende spunto da una installazione reale dove si sono presentati problemi di gestione delle connessioni, problemi in parte dovuti alle reti di connessione ed in parte alla scelta di utilizzare alcuni utenti comuni per l’accesso al desktop e di demandare l’autenticazione dell’utente all’applicativo.

Questa modalità operativa, ha amplificato il “problema” delle sessioni disconnesse in quanto il tempo minimo impostabile per il reset di queste sessioni è di 1 minuto, l’individuazione di determinati eventi ha permesso di correggere alcune configurazioni e di implementare le modalità di accesso in modo differente

Individuazione degli eventi tramite PowerShell

Al fine di agevolare la ricerca degli eventi descritti nell’articolo, è proposto qui un semplice script PowerShell che con poche modifiche può aiutare nella ricerca dei vari eventi all’interno del registro

Per operare lo script deve aver popolata la varibile $RdsShServers con il nome di tutti i Session Host, quando eseguito verranno riportati gli eventi di disconnessione con Reason Code 5

 

Il reset delle sessioni in stato disconnesso può essere gestito in modo alternativo come descritto in questo articolo

https://massarobi.wordpress.com/2019/05/10/gestione-delle-sessioni-rds-disconnesse/