Porte seriali
La maggior parte dei nuovi PC non dispone di porte seriali (COM) integrate. Le porte sono facili da aggiungere utilizzando convertitori USB. Le applicazioni adatte alle porte seriali spesso comprendono sensori, controller, vecchi lettori di assegni, pad e così via. Alcuni dispositivi con porta COM virtuale USB utilizzano driver specifici del fornitore al posto dei driver forniti da Windows (usbser.sys). Questi driver consentono di forzare la porta COM virtuale del dispositivo USB in modo che non cambi anche se viene collegata a socket USB diversi. Questa operazione può essere eseguita da Gestione dispositivi > Porte (COM e LPT) > Proprietà o dall’applicazione che controlla il dispositivo.
Il mapping delle porte COM client consente di utilizzare i dispositivi collegati alle porte COM dell’endpoint dell’utente durante le sessioni virtuali. È possibile utilizzare questi mapping come qualsiasi altro mapping di rete.
Per ogni porta COM, un driver nel sistema operativo assegna un nome di collegamento simbolico, ad esempio COM1 e COM2. Le applicazioni utilizzano quindi il collegamento per accedere alla porta.
Importante:
Poiché un dispositivo può collegarsi all’endpoint utilizzando direttamente USB, non significa che possa essere reindirizzato utilizzando il reindirizzamento USB generico. Alcuni dispositivi USB funzionano come porte COM virtuali, alle quali le applicazioni possono accedere allo stesso modo della porta seriale fisica. Il sistema operativo può astrarre le porte COM e trattarle come condivisioni file. Due protocolli comuni per la COM virtuale sono CDC ACM o MCT. In caso di connessione tramite una porta RS-485, le applicazioni potrebbero non funzionare affatto. Usare un convertitore RS-485-RS232 per utilizzare RS-485 come porta COM. Importante:
Alcune applicazioni riconoscono il dispositivo (ad esempio un signature pad) in modo coerente solo se è collegato a COM1 o COM2 sulla workstation client.
Mappare una porta COM client a una porta COM server
È possibile mappare le porte COM client a una sessione Citrix in tre modi:
- Criteri di Studio. Per ulteriori informazioni sui criteri, vedere Impostazioni dei criteri di reindirizzamento delle porte.
- Prompt dei comandi VDA.
- Strumento di configurazione Desktop remoto (Servizi terminal).
-
Abilitare il reindirizzamento della porta COM client e i criteri di Studio per la connessione automatica delle porte COM client. Dopo l’applicazione, sono disponibili alcune informazioni in HDX Monitor.
-
Se la connessione automatica delle porte COM client non riesce a mappare la porta, è possibile mappare manualmente la porta o utilizzare script di accesso. Accedere al VDA e in una finestra del prompt dei comandi digitare:
NET USE COMX: \\CLIENT\COMZ:
oppure
NET USE COMX: \\CLIENT\CLIENTPORT:COMZ:
X è il numero della porta COM sul VDA (le porte da 1 a 9 sono disponibili per il mapping). Z è il numero della porta COM client che si desidera mappare.
Per confermare che l’operazione ha avuto esito positivo, digitare NET USE al prompt dei comandi VDA. L’elenco visualizzato contiene unità mappate, porte LPT e porte COM mappate.
-
Per utilizzare questa porta COM in un desktop virtuale o in un’applicazione, installare l’applicazione del dispositivo utente e puntare al nome della porta COM mappata. Ad esempio, se si esegue il mapping di COM1 sul client a COM3 sul server, installare l’applicazione del dispositivo della porta COM nel VDA e puntare a COM3 durante la sessione. Utilizzare questa porta COM mappata come una porta COM sul dispositivo utente.
Importante:
Il mapping delle porte COM non è compatibile con TAPI. Non è possibile mappare i dispositivi TAPI (Telephony Application Programming Interface) di Windows alle porte COM client. TAPI definisce un modo standard di controllare le funzioni telefoniche per dati, fax e chiamate vocali per le applicazioni. TAPI gestisce la segnalazione, comprese la composizione, la risposta e la fine delle chiamate. Inoltre, gestisce servizi supplementari come l’attesa, il trasferimento e le chiamate in conferenza.
Risoluzione dei problemi
-
Assicurarsi di poter accedere al dispositivo direttamente dall’endpoint, evitando Citrix. Se la porta non è mappata al VDA, non si è connessi a una sessione Citrix. Seguire le istruzioni per la risoluzione dei problemi fornite con il dispositivo e verificare innanzitutto che funzioni localmente. Quando un dispositivo è connesso a una porta COM seriale, viene creata una chiave del Registro di sistema nell’hive mostrato qui:
È inoltre possibile trovare queste informazioni dal prompt dei comandi eseguendo chgport /query.
Se le istruzioni per la risoluzione dei problemi relativi al dispositivo non sono disponibili, provare ad aprire una sessione PuTTY. Scegliere Session (Sessione) e in Serial line (Linea seriale) specificare la porta COM.
È possibile eseguire MODE in una finestra di comando locale. L’output potrebbe visualizzare la porta COM in uso e il baud/parità/bit di dati/bit di stop, necessari nella sessione PuTTY. Se la connessione PuTTY ha esito positivo, premere Invio per visualizzare il feedback del dispositivo. Qualsiasi carattere digitato potrebbe essere ripetuto sullo schermo o ricevere una risposta. Se questo passaggio non riesce, non è possibile accedere al dispositivo da una sessione virtuale.
-
Mappare la porta COM locale al VDA (utilizzando i criteri o NET USE COMX: \\CLIENT\COMZ:) e ripetere le stesse procedure PuTTY del passaggio precedente, ma questa volta dal PuTTY del VDA. Se PuTTY non mostra l’errore Unable to open connection to COM1. Unable to open serial port (Impossibile aprire la connessione a COM1. Impossibile aprire la porta seriale), un altro dispositivo potrebbe utilizzare COM1.
-
Eseguire chgport /query. Se il driver seriale Windows incorporato nel VDA assegna automaticamente \Device\Serial0 a una porta COM1 del VDA, effettuare le seguenti operazioni: A. Aprire CMD sul VDA e digitare NET USE.
B. Eliminare gli eventuali mapping esistenti (ad esempio, COM1) sul VDA.
NET USE COM1 /DELETE
C. Mappare il dispositivo al VDA.
NET USE COM1: \\CLIENT\COM3:
D. Puntare l’applicazione sul VDA su COM3.
Infine, provare a mappare la porta COM locale (ad esempio, COM3) a una porta COM diversa sul VDA (diversa da COM1, ad esempio COM3). Assicurarsi che l’applicazione punti a questa porta: NET USE COM3: \\CLIENT\COM3
-
Se ora è visibile la porta mappata, PuTTY funziona ma non vengono trasferiti dati, potrebbe trattarsi di una race condition. L’applicazione potrebbe connettersi e aprire la porta prima che venga mappata, bloccando il mapping. Provare a eseguire una delle seguenti operazioni:
- Aprire una seconda applicazione pubblicata sullo stesso server. Attendere alcuni secondi perché la porta venga mappata, quindi aprire l’applicazione reale che tenta di utilizzare la porta.
-
Abilitare i criteri di reindirizzamento della porta COM dall’Editor Criteri di gruppo in Active Directory anziché da Studio. Tali criteri sono il reindirizzamento delle porte COM client e la connessione automatica delle porte COM client. I criteri applicati in questo modo potrebbero essere elaborati prima dei criteri di Studio, garantendo che la porta COM sia mappata. I criteri Citrix vengono inviati al VDA e archiviati in:
HKLN\SOFTWARE\Policies\Citrix \<user session ID\> - Utilizzare questo script di accesso per l’utente oppure, invece di pubblicare l’applicazione, pubblicare uno script .bat che elimina innanzitutto qualsiasi mapping sul VDA, rimappa la porta COM virtuale e quindi avvia l’applicazione:
@echo off NET USE COM1 /delete NET USE COM2 /delete NET USE COM1: \\CLIENT\COM1: NET USE COM2: \\CLIENT\COM2: MODE COM1: BAUD=1200 (or whatever value needed) MODE COM2: BAUD=9600 PARITY=N Data=8 Stop=1 (or whatever value needed) START C:\Program Files\<Your Software Path>\
-
Come ultima alternativa, è possibile utilizzare lo strumento Process Monitor di Sysinternals. Quando si esegue lo strumento sul VDA, trovare e filtrare oggetti come COM3, picaser.sys, CdmRedirector, ma soprattutto <tua_app>.exe. Eventuali errori potrebbero essere visualizzati come Accesso negato o simile.