Registrazione VDA
Introduzione
Nota:
In un ambiente on-premise, i VDA si registrano con un Delivery Controller. In un ambiente di servizio Citrix Cloud, i VDA si registrano con un Cloud Connector. In un ambiente ibrido, alcuni VDA si registrano con un Delivery Controller mentre altri si registrano con un Cloud Connector.
Prima che un VDA possa essere utilizzato, deve registrarsi (stabilire la comunicazione) con uno o più Controller o Cloud Connector nel sito. Il VDA trova un Controller o un Connector controllando un elenco chiamato ListofDDCs. Il ListOfDDCs su un VDA contiene voci DNS che indirizzano tale VDA ai Controller o ai Cloud Connector nel sito. Per il bilanciamento del carico, il VDA distribuisce automaticamente le connessioni tra tutti i Controller o i Cloud Connector nell’elenco.
Perché la registrazione VDA è così importante?
- Dal punto di vista della sicurezza, la registrazione è un’operazione sensibile. Si sta stabilendo una connessione tra il Controller o il Cloud Connector e il VDA. Per un’operazione così sensibile, il comportamento atteso è quello di rifiutare la connessione se non tutto è in perfette condizioni. Si stanno effettivamente stabilendo due canali di comunicazione separati: VDA verso Controller o Cloud Connector, e Controller o Cloud Connector verso VDA. La connessione utilizza Kerberos, quindi i problemi di sincronizzazione dell’ora e di appartenenza al dominio sono implacabili. Kerberos utilizza i Service Principal Name (SPN), quindi non è possibile utilizzare IP/hostname con bilanciamento del carico.
- Se un VDA non dispone di informazioni accurate e aggiornate sul Controller o sul Cloud Connector man mano che si aggiungono e si rimuovono Controller (o Cloud Connector), il VDA potrebbe rifiutare gli avvii di sessione intermediati da un Controller o un Cloud Connector non elencato. Voci non valide possono ritardare l’avvio del software del sistema desktop virtuale. Un VDA non accetterà una connessione da un Controller o un Cloud Connector sconosciuto e non attendibile.
Oltre a ListofDDCs, il ListOfSIDs (ID di sicurezza) indica quali macchine in ListofDDCs sono attendibili. Il ListOfSIDs può essere utilizzato per ridurre il carico su Active Directory o per evitare possibili minacce alla sicurezza da un server DNS compromesso. Per maggiori informazioni, vedere ListOfSIDs.
Se un ListofDDCs specifica più di un Controller o Cloud Connector, il VDA tenta di connettersi a essi in ordine casuale. In una distribuzione on-premise, il ListofDDCs può anche contenere gruppi di Controller. Il VDA tenta di connettersi a ciascun Controller in un gruppo prima di passare ad altre voci in ListofDDCs.
Citrix Virtual Apps and Desktops™ testa automaticamente la connettività ai Controller o ai Cloud Connector configurati durante l’installazione del VDA. Vengono visualizzati errori se un Controller o un Cloud Connector non può essere raggiunto. Se si ignora un avviso che un Controller o un Cloud Connector non può essere contattato (o quando non si specificano gli indirizzi del Controller o del Cloud Connector durante l’installazione del VDA), vengono visualizzati messaggi di promemoria.
Metodi per la configurazione degli indirizzi di Controller o Cloud Connector
L’amministratore sceglie il metodo di configurazione da utilizzare quando il VDA si registra per la prima volta (la registrazione iniziale). Durante la registrazione iniziale, viene creata una cache persistente sul VDA. Durante le registrazioni successive, il VDA recupera l’elenco dei Controller o dei Cloud Connector da questa cache locale, a meno che non venga rilevata una modifica della configurazione.
Il modo più semplice per recuperare tale elenco durante le registrazioni successive è utilizzare la funzione di aggiornamento automatico. L’aggiornamento automatico è abilitato per impostazione predefinita. Per maggiori informazioni, vedere Aggiornamento automatico.
Esistono diversi metodi per configurare gli indirizzi di Controller o Cloud Connector su un VDA.
- Basato su policy (LGPO o GPO)
- Basato su registro (manuale, Group Policy Preferences (GPP), specificato durante l’installazione del VDA)
- Basato su OU di Active Directory (individuazione OU legacy)
- Basato su MCS (personality.ini)
Si specifica il metodo di registrazione iniziale quando si installa un VDA. (Se si disabilita l’aggiornamento automatico, il metodo selezionato durante l’installazione del VDA viene utilizzato per le registrazioni successive.)
La seguente grafica mostra la pagina Delivery Controller della procedura guidata di installazione del VDA.
Basato su policy (LGPO\GPO)
Citrix® consiglia di utilizzare GPO per la registrazione iniziale del VDA. Ha la priorità più alta. (Sebbene l’aggiornamento automatico sia elencato come la priorità più alta, l’aggiornamento automatico viene utilizzato solo dopo la registrazione iniziale.) La registrazione basata su policy offre i vantaggi di centralizzazione dell’utilizzo di Criteri di gruppo per la configurazione.
Per specificare questo metodo, completare entrambi i seguenti passaggi:
- Nella pagina Delivery Controller della procedura guidata di installazione del VDA, selezionare Esegui in seguito (avanzato). La procedura guidata ricorda più volte di specificare gli indirizzi del Controller, anche se non li si sta specificando durante l’installazione del VDA. (La registrazione del VDA è così importante.)
- Abilitare o disabilitare la registrazione VDA basata su policy tramite la policy Citrix con l’impostazione
Virtual Delivery Agent Settings > Controllers. (Se la sicurezza è la priorità principale, utilizzare l’impostazioneVirtual Delivery Agent Settings > Controller SIDs.)
Questa impostazione è memorizzata in HKLM\Software\Policies\Citrix\VirtualDesktopAgent (ListOfDDCs).
Basato su registro
Per specificare questo metodo, completare uno dei seguenti passaggi:
- Nella pagina Delivery Controller della procedura guidata di installazione del VDA, selezionare Esegui manualmente. Quindi, immettere il FQDN di un Controller installato e fare clic su Aggiungi. Se sono stati installati più Controller, aggiungere i loro indirizzi.
- Per un’installazione VDA da riga di comando, utilizzare l’opzione /controllers e specificare i FQDN dei Controller o dei Cloud Connector installati.
Queste informazioni sono memorizzate nel valore di registro ListOfDDCs sotto la chiave di registro HKLM\Software\Citrix\VirtualDesktopAgent o HKLM\Software\Wow6432Node\Citrix\VirtualDesktopAgent.
È anche possibile configurare questa chiave di registro manualmente o utilizzare Group Policy Preferences (GPP). Questo metodo potrebbe essere preferibile al metodo basato su policy (ad esempio, se si desidera l’elaborazione condizionale di diversi Controller o Cloud Connector, come: utilizzare XDC-001 per nomi di computer che iniziano con XDW-001-).
Aggiornare la chiave di registro ListOfDDCs, che elenca i FQDN di tutti i Controller o i Cloud Connector nel sito. (Questa chiave è l’equivalente dell’OU del sito di Active Directory.)
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
Se la posizione del registro HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent contiene sia le chiavi ListOfDDCs che FarmGUID, ListOfDDCs viene utilizzato per l’individuazione del Controller o del Cloud Connector. FarmGUID è presente se un’OU del sito è stata specificata durante l’installazione del VDA. (Questo potrebbe essere utilizzato in distribuzioni legacy.)
Facoltativamente, aggiornare la chiave di registro ListOfSIDs (per maggiori informazioni, vedere ListOfSIDs):
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)
Ricordare: se si abilita anche la registrazione VDA basata su policy tramite la policy Citrix, questa sovrascrive le impostazioni specificate durante l’installazione del VDA, perché è un metodo a priorità più alta.
Basato su OU di Active Directory (legacy)
Questo metodo è supportato principalmente per la compatibilità con le versioni precedenti e non è consigliato. Se lo si sta ancora utilizzando, Citrix suggerisce di passare a un altro metodo.
Per specificare questo metodo, completare entrambi i seguenti passaggi:
- Nella pagina Delivery Controller della procedura guidata di installazione del VDA, selezionare Scegli posizioni da Active Directory.
- Utilizzare lo script
Set-ADControllerDiscovery.ps1(disponibile su ogni Controller). Inoltre, configurare la voce di registroFarmGuidsu ogni VDA per puntare all’OU corretta. Questa impostazione può essere configurata utilizzando Criteri di gruppo.
Per i dettagli, vedere Individuazione basata su OU di Active Directory.
Basato su MCS
Se si utilizza MCS per il provisioning delle VM, MCS imposta l’elenco dei Controller o dei Cloud Connector. Questa funzione funziona con l’aggiornamento automatico. Durante la creazione del catalogo, MCS inserisce l’elenco dei Controller o dei Cloud Connector nel file Personality.ini durante il provisioning iniziale. L’aggiornamento automatico mantiene l’elenco aggiornato.
Per specificare questo metodo, nella pagina Delivery Controller della procedura guidata di installazione del VDA, selezionare Lascia che Machine Creation Services™ lo faccia.
Revisione e raccomandazioni
Come best practice:
- Utilizzare il metodo di registrazione di Criteri di gruppo per la registrazione iniziale.
- Utilizzare l’aggiornamento automatico (abilitato per impostazione predefinita) per mantenere aggiornato l’elenco dei Controller.
- In una distribuzione multi-zona, utilizzare Criteri di gruppo per la configurazione iniziale (con almeno due Controller o Cloud Connector). Indirizzare i VDA ai Controller o ai Cloud Connector locali (nella) loro zona. Utilizzare l’aggiornamento automatico per mantenerli aggiornati. L’aggiornamento automatico ottimizza automaticamente il
ListofDDCsper i VDA nelle zone satellite. -
Elencare più di un controller nella chiave di registro
ListOfDDCs, separati da uno spazio o una virgola, per prevenire problemi di registrazione se un Controller non è disponibile. Ad esempio:DDC7x.xd.local DDC7xHA.xd.local 32-bit: HKEY_LOCAL_MACHINE \Software\Citrix\VirtualDesktopAgent\ListOfDDCs HKEY_LOCAL_MACHINE \Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ) <!--NeedCopy--> - Assicurarsi che tutti i valori elencati in
ListofDDCscorrispondano a un nome di dominio completo valido per prevenire ritardi nella registrazione all’avvio.
Aggiornamento automatico
L’aggiornamento automatico (introdotto in XenApp e XenDesktop 7.6) è abilitato per impostazione predefinita. È il metodo più efficiente per mantenere aggiornate le registrazioni dei VDA. Sebbene non utilizzato per la registrazione iniziale, il software di aggiornamento automatico scarica e memorizza il ListofDDCs in una cache persistente sul VDA quando si verifica la registrazione iniziale. Questo processo viene eseguito per ogni VDA. La cache contiene anche informazioni sulla policy della macchina, il che garantisce che le impostazioni della policy vengano mantenute tra i riavvii.
L’aggiornamento automatico è supportato quando si utilizzano MCS o Citrix Provisioning™ per il provisioning delle macchine, ad eccezione della cache lato server di Citrix Provisioning. La cache lato server non è uno scenario comune perché non esiste una memoria persistente per la cache di aggiornamento automatico.
Per specificare questo metodo:
- Abilitare o disabilitare l’aggiornamento automatico tramite una policy Citrix contenente l’impostazione
Virtual Delivery Agent Settings > Enable auto update of Controllers. Questa impostazione è abilitata per impostazione predefinita.
Come funziona:
- Ogni volta che un VDA si registra nuovamente (ad esempio, dopo un riavvio della macchina), la cache viene aggiornata. Ogni Controller o Cloud Connector controlla anche il database del sito ogni 90 minuti. Se un Controller o un Cloud Connector è stato aggiunto o rimosso dall’ultimo controllo, o se si è verificata una modifica della policy che influisce sulla registrazione del VDA, il Controller o il Cloud Connector invia un elenco aggiornato ai suoi VDA registrati e la cache viene aggiornata. Il VDA accetta connessioni da tutti i Controller o i Cloud Connector nel suo elenco più recentemente memorizzato nella cache.
- Se un VDA riceve un elenco che non include il Controller o il Cloud Connector con cui è registrato (in altre parole, quel Controller o Cloud Connector è stato rimosso dal sito), il VDA si registra nuovamente, scegliendo tra i Controller o i Cloud Connector nel
ListofDDCs.
Esempio:
- Una distribuzione ha tre Controller: A, B e C. Un VDA si registra con il Controller B (che è stato specificato durante l’installazione del VDA).
- Successivamente, due Controller (D ed E) vengono aggiunti al sito. Entro 90 minuti, i VDA ricevono elenchi aggiornati e quindi accettano connessioni dai Controller A, B, C, D ed E. (Il carico non è distribuito equamente a tutti i Controller fino al riavvio dei VDA.)
- Ancora più tardi, il Controller B viene spostato in un altro sito. Entro 90 minuti, i VDA nel sito originale ricevono elenchi aggiornati perché c’è stata una modifica del Controller dall’ultimo controllo. Il VDA che originariamente si era registrato con il Controller B (che non è più nell’elenco) si registra nuovamente, scegliendo tra i Controller nell’elenco corrente (A, C, D ed E).
In una distribuzione multi-zona, l’aggiornamento automatico in una zona satellite memorizza automaticamente nella cache tutti i Controller locali per primi. Tutti i Controller nella zona primaria vengono memorizzati nella cache in un gruppo di backup. Se non sono disponibili Controller locali nella zona satellite, la registrazione viene tentata con i Controller nella zona primaria.
Come mostrato nell’esempio seguente, il file di cache contiene nomi host e un elenco di ID di sicurezza (ListofSIDs). Il VDA non interroga gli SID, il che riduce il carico di Active Directory.
È possibile recuperare il file di cache con una chiamata WMI. Tuttavia, è memorizzato in una posizione leggibile solo dall’account SYSTEM.
Importante:
Queste informazioni sono fornite solo a scopo informativo. NON MODIFICARE QUESTO FILE. Qualsiasi modifica a questo file o cartella comporta una configurazione non supportata.
Get-WmiObject -Namespace “Root\Citrix\DesktopInformation” -Class “Citrix_VirtualDesktopInfo” -Property “PersistentDataLocation”
Se è necessario configurare manualmente il ListofSIDs per motivi di sicurezza (distinti dalla riduzione del carico di Active Directory), non è possibile utilizzare la funzione di aggiornamento automatico. Per i dettagli, vedere ListOfSIDs.
Eccezione alla priorità dell’aggiornamento automatico
Sebbene l’aggiornamento automatico abbia solitamente la priorità più alta tra tutti i metodi di registrazione VDA e sovrascriva le impostazioni per altri metodi, esiste un’eccezione. Gli elementi NonAutoListOfDDCs nella cache specificano il metodo di configurazione VDA iniziale. L’aggiornamento automatico monitora queste informazioni. Se il metodo di registrazione iniziale cambia, il processo di registrazione salta l’aggiornamento automatico e utilizza il metodo di priorità configurato successivo più alto. Questo processo può essere utile quando si sposta un VDA in un altro sito (ad esempio, durante il ripristino di emergenza).
Considerazioni sulla configurazione
Visualizzare una configurazione comune di registrazione VDA.
Visualizzare i passaggi di registrazione VDA.
Considerare quanto segue quando si configurano elementi che possono influire sulla registrazione del VDA.
Indirizzi di Controller o Cloud Connector
Indipendentemente dal metodo utilizzato per specificare Controller o Cloud Connector, Citrix consiglia di utilizzare un indirizzo FQDN. Un indirizzo IP non è considerato una configurazione attendibile, perché è più facile compromettere un IP che un record DNS. Se si popola manualmente il ListofSIDs, è possibile utilizzare un IP in un ListofDDCs. Tuttavia, l’FQDN è comunque consigliato.
Bilanciamento del carico
Come notato in precedenza, il VDA distribuisce automaticamente le connessioni tra tutti i Controller o i Cloud Connector nel ListofDDCs. La funzionalità di failover e bilanciamento del carico è integrata nel Citrix Brokering Protocol (CBP). Se si specificano più Controller o Cloud Connector nella configurazione, la registrazione esegue automaticamente il failover tra di essi, se necessario. Con l’aggiornamento automatico, il failover automatico si verifica automaticamente per tutti i VDA.
Per motivi di sicurezza, non è possibile utilizzare un bilanciatore di carico di rete, come Citrix ADC. La registrazione VDA utilizza l’autenticazione reciproca Kerberos, in cui il client (VDA) deve dimostrare la propria identità al servizio (Controller). Tuttavia, il Controller o il Cloud Connector deve dimostrare la propria identità al VDA. Ciò significa che il VDA e il Controller o il Cloud Connector agiscono contemporaneamente come server e client. Come notato all’inizio di questo articolo, esistono due canali di comunicazione: VDA verso Controller/Cloud Connector e Controller/Cloud Connector verso VDA.
Un componente in questo processo è chiamato Service Principal Name (SPN), che è memorizzato come proprietà in un oggetto computer di Active Directory. Quando il VDA si connette a un Controller o a un Cloud Connector, deve specificare con chi vuole comunicare. Questo indirizzo è un SPN. Se si utilizza un IP con bilanciamento del carico, l’autenticazione reciproca Kerberos riconosce correttamente che l’IP non appartiene al Controller o al Cloud Connector previsto.
Per maggiori informazioni, vedere:
L’aggiornamento automatico sostituisce CNAME
La funzione di aggiornamento automatico sostituisce la funzione CNAME (alias DNS) delle versioni di XenApp e XenDesktop precedenti alla 7.x. La funzionalità CNAME è disabilitata, a partire da XenApp e XenDesktop 7. Utilizzare l’aggiornamento automatico invece di CNAME. (Se è necessario utilizzare CNAME, vedere CTX137960. Affinché l’aliasing DNS funzioni in modo coerente, non utilizzare contemporaneamente l’aggiornamento automatico e CNAME.)
Gruppi di Controller/Cloud Connector
In alcuni scenari, potrebbe essere necessario elaborare Controller o Cloud Connector in gruppi, con un gruppo preferito e l’altro gruppo utilizzato per un failover se tutti i Controller/Cloud Connector falliscono. Ricordare che i Controller o i Cloud Connector vengono selezionati casualmente dall’elenco, quindi il raggruppamento può aiutare a imporre un uso preferenziale.
Questi gruppi sono destinati all’uso all’interno di un singolo sito (non più siti).
Utilizzare le parentesi per specificare i gruppi di Controller/Cloud Connector. Ad esempio, con quattro Controller (due primari e due di backup), un raggruppamento potrebbe essere:
(XDC-001.cdz.lan XDC-002.cdz.lan) (XDC-003.cdz.lan XDC-004.cdz.lan)
In questo esempio, i Controller nel primo gruppo (001 e 002) vengono elaborati per primi. Se entrambi falliscono, vengono elaborati i Controller nel secondo gruppo (003 e 004).
Per XenDesktop 7.0 o versioni successive, è necessario eseguire un passaggio aggiuntivo per utilizzare la funzione Registration Groups. È necessario Proibire la policy Enable Auto Update of Controller da Citrix Studio.
ListOfSIDs
L’elenco dei Controller che un VDA può contattare per la registrazione è il ListofDDCs. Un VDA deve anche sapere quali Controller fidarsi; i VDA non si fidano automaticamente dei Controller nel ListofDDCs. Il ListofSIDs (ID di sicurezza) identifica i Controller attendibili. I VDA tentano di registrarsi solo con Controller attendibili.
Nella maggior parte degli ambienti, il ListofSIDs viene generato automaticamente dal ListofDDCs. È possibile utilizzare una traccia CDF per leggere il ListofSIDs.
Generalmente, non è necessario modificare manualmente il ListofSIDs. Esistono diverse eccezioni. Le prime due eccezioni non sono più valide perché sono disponibili tecnologie più recenti.
-
Ruoli separati per i Controller: Prima dell’introduzione delle zone in XenApp e XenDesktop 7.7, il
ListofSIDsveniva configurato manualmente quando solo un sottoinsieme di Controller veniva utilizzato per la registrazione. Ad esempio, se si utilizzavano XDC-001 e XDC-002 come broker XML, e XDC-003 e XDC-004 per la registrazione VDA, si specificavano tutti i Controller nelListofSIDs, e XDC-003 e XDC-004 nelListofDDCs. Questa non è una configurazione tipica o consigliata. Non utilizzarla in ambienti più recenti. Utilizzare invece le zone. -
Riduzione del carico di Active Directory: Prima dell’introduzione della funzione di aggiornamento automatico in XenApp e XenDesktop 7.6, il
ListofSIDsveniva utilizzato per ridurre il carico sui controller di dominio. Pre-popolando ilListofSIDs, la risoluzione dai nomi DNS agli SID può essere saltata. Tuttavia, la funzione di aggiornamento automatico elimina la necessità di questo lavoro, perché questa cache persistente contiene gli SID. Citrix consiglia di mantenere abilitata la funzione di aggiornamento automatico. - Sicurezza: In alcuni ambienti altamente sicuri, gli SID dei Controller attendibili venivano configurati manualmente per evitare possibili minacce alla sicurezza da un server DNS compromesso. Tuttavia, se si esegue questa operazione, è necessario disabilitare anche la funzione di aggiornamento automatico. In caso contrario, viene utilizzata la configurazione dalla cache persistente.
Quindi, a meno che non si abbia un motivo specifico, non modificare il ListofSIDs.
Se è necessario modificare il ListofSIDs, creare una chiave di registro denominata ListOfSIDs (REG_SZ) sotto HKLM\Software\Citrix\VirtualDesktopAgent. Il valore è un elenco di SID attendibili, separati da spazi se ce n’è più di uno.
Nell’esempio seguente, un Controller viene utilizzato per la registrazione VDA (ListofDDCs), ma due Controller vengono utilizzati per il brokering (List OfSIDs).
Ricerca Controller durante la registrazione VDA
Quando un VDA tenta di registrarsi, il Broker Agent esegue prima una ricerca DNS nel dominio locale per assicurarsi che il Controller specificato possa essere raggiunto.
Se quella ricerca iniziale non trova il Controller, il Broker Agent può avviare una query di fallback top-down in AD. Tale query cerca tutti i domini e si ripete frequentemente. Se l’indirizzo del Controller non è valido (ad esempio, l’amministratore ha inserito un FQDN errato durante l’installazione del VDA), l’attività di quella query può potenzialmente portare a una condizione di distributed denial of service (DDoS) sul controller di dominio.
La seguente chiave di registro controlla se il Broker Agent utilizza la query di fallback top-down quando non riesce a individuare un Controller durante la ricerca iniziale.
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent
- Nome:
DisableDdcWildcardNameLookup - Tipo:
DWORD - Valore:
0(predefinito) o qualsiasi valore diverso da zero
Quando impostato su 0, la ricerca di fallback è abilitata. Se la ricerca iniziale del Controller fallisce, viene avviata la ricerca di fallback top-down. Questo è il comportamento predefinito. Tuttavia, se impostato su qualsiasi valore diverso da zero, la ricerca di fallback è disabilitata. Se la ricerca iniziale del Controller fallisce, il Broker Agent smette di cercare.
Risoluzione dei problemi di registrazione VDA
Come notato in precedenza, un VDA deve essere registrato con un Delivery Controller o un Cloud Connector per essere considerato quando si avviano sessioni mediate. I VDA non registrati possono comportare un sottoutilizzo di risorse altrimenti disponibili. Esistono varie ragioni per cui un VDA potrebbe non essere registrato, molte delle quali un amministratore può risolvere. Studio fornisce informazioni sulla risoluzione dei problemi nella procedura guidata di creazione del catalogo e dopo aver creato un gruppo di consegna.
-
Identificazione dei problemi durante la creazione del catalogo macchine: Nella procedura guidata di creazione del catalogo, dopo aver aggiunto le macchine esistenti, l’elenco dei nomi degli account computer indica se ciascuna macchina è idonea per essere aggiunta al catalogo. Passare il mouse sull’icona accanto a ciascuna macchina per visualizzare un messaggio informativo su quella macchina.
Se il messaggio identifica una macchina problematica, è possibile rimuovere quella macchina (utilizzando il pulsante Rimuovi) o aggiungere la macchina. Ad esempio, se un messaggio indica che non sono state ottenute informazioni su una macchina (forse perché non si era mai registrata), si potrebbe comunque scegliere di aggiungere la macchina.
Il livello funzionale di un catalogo controlla quali funzionalità del prodotto sono disponibili per le macchine nel catalogo. L’utilizzo di funzionalità introdotte in nuove versioni del prodotto potrebbe richiedere un nuovo VDA. L’impostazione di un livello funzionale rende tutte le funzionalità introdotte in quella versione (e successive, se il livello funzionale non cambia) disponibili per le macchine nel catalogo. Tuttavia, le macchine in quel catalogo con una versione VDA precedente non saranno in grado di registrarsi.
-
Identificazione dei problemi dopo la creazione di gruppi di consegna: Dopo aver creato un gruppo di consegna, Studio visualizza i dettagli sulle macchine associate a quel gruppo.
Il riquadro dei dettagli per un gruppo di consegna indica il numero di macchine che dovrebbero essere registrate ma non lo sono. In altre parole, potrebbe esserci una o più macchine accese e non in modalità di manutenzione, ma che non sono attualmente registrate con un Controller. Quando si visualizza una macchina “non registrata, ma dovrebbe esserlo”, esaminare la scheda Risoluzione dei problemi nel riquadro dei dettagli per le possibili cause e le azioni correttive consigliate.
Maggiori informazioni sulla risoluzione dei problemi di registrazione VDA
-
Per maggiori informazioni sui livelli funzionali, vedere Versioni VDA e livelli funzionali.
-
Per maggiori informazioni sulla risoluzione dei problemi di registrazione VDA, vedere CTX136668.
-
È anche possibile utilizzare i controlli di integrità di Citrix Scout per risolvere i problemi di registrazione VDA e avvio sessione. Per i dettagli, vedere Informazioni sui controlli di integrità.