Migrare la configurazione a Citrix Cloud™

Automated Configuration Tool (ACT) consente la migrazione della configurazione di Citrix Virtual Apps and Desktops™ (criteri, applicazioni, cataloghi, ruoli amministrativi, ambiti e altro) da uno o più siti on-premise a Citrix DaaS ospitato su Citrix Cloud. Può essere utilizzato anche per migrare informazioni tra diverse regioni o tenant di Cloud.

Questo strumento rileva ed esporta uno o più siti on-premise come una raccolta di file di configurazione, che è possibile modificare facoltativamente. La configurazione di questi file può quindi essere importata in Citrix DaaS. La migrazione viene eseguita in più fasi, eseguendo lo strumento più volte, consentendo di raggiungere facilmente lo stato di configurazione desiderato.

ACT non è solo uno strumento di migrazione usa e getta. È possibile utilizzarlo per gestire le operazioni cloud quotidiane, ad esempio:

• Automatizzare il trasferimento da account cloud di test o di staging ad account cloud di produzione
• Eseguire il backup e il ripristino della configurazione
• Dividere un ambiente cloud in più cloud

Il seguente video di 2 minuti offre una rapida panoramica della configurazione automatizzata.

Per ulteriori informazioni sulla configurazione automatizzata, vedere Prova di concetto: Strumento di configurazione automatizzata su Tech Zone.

Per un’analisi più approfondita dello spostamento della distribuzione e della preparazione della configurazione on-premise per la migrazione, vedere Guida alla distribuzione: Migrazione di Citrix Virtual Apps and Desktops da on-premise a Citrix Cloud su Tech Zone.

Limitazioni note

• I cataloghi di macchine di cui è stato eseguito il provisioning tramite Machine Creation Services™ presentano considerazioni speciali. Per ulteriori informazioni su MCS, vedere Comprendere la migrazione dei cataloghi di cui è stato eseguito il provisioning di Machine Creation Services.

Prerequisiti per la migrazione della configurazione

Per l’esportazione della configurazione da Citrix Virtual Apps and Desktops, è necessario:

• Citrix Virtual Apps and Desktops: versione corrente e il suo predecessore immediato o Citrix Virtual Apps and Desktops, XenApp e XenDesktop® LTSR: tutte le versioni
• Una macchina aggiunta a un dominio con .NET Framework 4.7.2 o versioni successive e l’SDK Citrix PowerShell. Questo viene installato automaticamente sul Delivery Controller. (Per l’esecuzione su una macchina diversa dal Delivery Controller on-premise, è necessario installare Citrix Studio, poiché Studio installa gli snap-in PowerShell corretti. Il programma di installazione di Studio è disponibile sul supporto di installazione di Citrix Virtual Apps and Desktops.)

Per importare la configurazione in Citrix DaaS, è necessario:

• Una macchina con accesso a Citrix Cloud. Non deve essere un Delivery Controller™ o una macchina aggiunta a un dominio.
• Citrix DaaS con provisioning.
• Una posizione delle risorse attiva con Connector installato e aggiunto allo stesso dominio della configurazione on-premise.
• La connettività ai siti che accedono a Citrix Cloud deve essere consentita e disponibile. Per maggiori informazioni, vedere Requisiti di sistema e connettività.

Nota:

Automated Configuration non può essere installato su un sistema Cloud Connector.

Passaggi chiave

1. Scaricare lo strumento Automated Configuration e rivedere i requisiti di sistema. Vedere Scaricare Automated Configuration.
2. Popolare il file CustomerInfo.yml con i valori CustomerName, CustomerID e SecretKey generati dal portale Citrix Cloud. Vedere Generare l’ID cliente, l’ID client e la chiave segreta e Popolare il file delle informazioni del cliente.
3. Se il sito on-premise contiene più zone, aggiornare il file ZoneMapping.yml per mappare le zone alle posizioni delle risorse Citrix DaaS. Vedere Popolare il file di mappatura delle zone.
4. Se il sito contiene più connessioni di hosting, aggiornare il file CvadAcSecurity.yml con le informazioni di connessione per ogni tipo di host che migra in Citrix DaaS. Se è presente una sola connessione host, aggiornare il file CvadACSecurity.yml con le informazioni di connessione per la connessione host. Vedere Aggiornare il file di sicurezza per le connessioni host.
5. Aprire ACT ed esportare il sito on-premise utilizzando il comando Export-CvadAcToFile. Vedere Oggetti di migrazione supportati per l’elenco dei componenti supportati per la migrazione. Per informazioni sui passaggi per l’esportazione, vedere Esportare la configurazione on-premise.
6. Importare i componenti in fasi utilizzando il comando Merge-CvadAcToSite. In alternativa, migrare l’intero sito in una sola volta. Assicurarsi di migrare i componenti nell’ordine elencato in Ordine di migrazione dei componenti. Per informazioni sui passaggi per l’importazione, vedere Eseguire un’importazione.
7. Attivare il sito cloud. Vedere Attivare i siti.

Scaricare la configurazione automatizzata

Scaricare e installare lo strumento di configurazione automatizzata da Citrix Downloads.

Aggiornare la configurazione automatizzata

Per prevenire errori di funzionalità, utilizzare sempre l’ultima versione disponibile di ACT.

Per conoscere la versione dello strumento, procedere come segue:

1. Fare doppio clic sull’icona Auto Config. Viene visualizzata una finestra di PowerShell.

2. Eseguire il seguente comando per controllare il numero di versione.

   Get-CvadAcStatus
   <!--NeedCopy-->
   

3. Controllare la versione dello strumento rispetto alla versione elencata in Citrix Downloads. L’ultima versione dello strumento si trova lì.
4. Scaricare e installare l’ultima versione dello strumento. Non è necessario disinstallare la vecchia versione per aggiornare la configurazione automatizzata.

Nota:

Quando si eseguono i cmdlet per accedere al cloud in Configurazione automatizzata, lo strumento avvisa l’utente quando è disponibile una versione più recente per il download. Per maggiori informazioni sui cmdlet, vedere Cmdlet dello strumento di configurazione automatizzata.

Generare l’ID cliente, l’ID client e la chiave segreta

Per migrare il sito locale a Citrix DaaS, popolare il file CustomerInfo.yml con l’ID cliente, l’ID client e la chiave segreta dal portale Citrix Cloud.

Per recuperare l’ID cliente:

1. Accedere all’account Citrix Cloud e selezionare il cliente.
2. Fare clic sull’icona della griglia e selezionare Identity and Access Management.
3. Passare a API access > Secure clients. L’ID cliente viene visualizzato nella pagina.

Per recuperare l’ID client e la chiave segreta:

1. Nella pagina Secure clients, immettere un nome nella casella. Questo nome viene utilizzato per distinguere tra più ID client e chiavi segrete.
2. Fare clic su Crea client per creare l’ID client e la chiave segreta.
3. Copiare l’ID client e la chiave segreta in una posizione sicura e scaricare il file .csv contenente queste informazioni. Utilizzare il file .csv per popolare il file CustomerInfo.yml.

Nota:

• L’ID client e la chiave segreta non scadono. Se vengono compromessi, rimuoverli immediatamente utilizzando l’icona Cestino e crearne di nuovi.
• La chiave segreta non può essere recuperata se viene persa o dimenticata; è necessario creare un nuovo ID client e una nuova chiave segreta.

Popolare il file delle informazioni del cliente

Il file CustomerInfo.yml elimina la necessità di fornire i parametri delle informazioni del cliente ogni volta che si esegue il cmdlet. Qualsiasi informazione del cliente può essere sovrascritta utilizzando i parametri del cmdlet.

Utilizzare il cmdlet New-CvadAcCustomerInfoFile per creare il file CustomerInfo.yml.

Importante:

Non modificare manualmente il file CustomerInfo.yml. Ciò può causare errori di formattazione involontari.

Il cmdlet New-CvadAcCustomerInfoFile ha i seguenti parametri obbligatori.

• CustomerId: ID del cliente.
• ClientId: ID client del cliente creato su Citrix Cloud.
• Secret: segreto del cliente creato su Citrix Cloud.

Esempio:

New-CvadAcCustomerInfoFile -CustomerId markhof123 -ClientId 6813EEA6-46CC-4F8A-BC71-539F2DAC5984 -Secret TwBLaaaaaaaaaaaaaaaaaw==
<!--NeedCopy-->

È inoltre possibile creare CustomerInfo.yml utilizzando il parametro SecurityCsvFileSpec che punta al file security.csv scaricato. È necessario specificare anche il CustomerId.

New-CvadAcCustomerInfoFile -SecurityCsvFileSpec C:\Users\my_user_name\downloads/security.csv -CustomerId markhof123
<!--NeedCopy-->

Utilizzare il cmdlet Set-CvadAcCustomerInfoFile per aggiornare il file CustomerInfo.yml. Questo cmdlet modifica solo l’ID client.

Set-CvadAcCustomerInfoFile -ClientId C80487EE-7113-49F8-85DD-2CFE30CC398E
<!--NeedCopy-->

Di seguito è riportato un file CustomerInfo.yml di esempio.

            # Created/Updated on 2020/01/29 16:46:47
            CustomerId: ‘markhof123’
            ClientId: ‘6713FEA6-46CC-4F8A-BC71-539F2DDK5384’
            Secret: ‘TwBLaaabbbaaaaaaaaaaw==’
            Environment: Production
            AltRootUrl: ‘’
            StopOnError: False
            AlternateFolder: ‘’
            Locale: ‘en-us’
            Editor: ‘C:\Program Files\Notepad++\notepad++.exe’
            Confirm: True
            DisplayLog: True

Popolare il file di mappatura delle zone

Una zona on-premises è l’equivalente della posizione delle risorse cloud. A differenza di altri componenti del sito, non è possibile importare automaticamente la zona on-premises nel cloud. Deve invece essere mappata manualmente utilizzando il file ZoneMapping.yml. Possono verificarsi errori di importazione se il nome della zona non è associato a un nome di posizione delle risorse esistente.

Se i siti on-premises hanno una sola zona e i siti cloud hanno una sola posizione delle risorse, lo strumento di configurazione automatica crea l’associazione corretta, eliminando la necessità di gestire manualmente il file ZoneMapping.yml.

Tuttavia, se i siti on-premises hanno più zone o i siti cloud hanno più posizioni delle risorse, aggiornare manualmente il file ZoneMapping.yml per riflettere la mappatura corretta delle zone on-premises alle posizioni delle risorse cloud.

Il file ZoneMapping.yml si trova in %HOMEPATH%\Documents\Citrix\AutoConfig. Il contenuto del file .yml è un dizionario con il nome della zona come chiave e il nome della posizione delle risorse come valore.

Ad esempio, un sito on-premises di Citrix Virtual Apps and Desktops con una zona primaria denominata “Zone-1” e una zona secondaria denominata “Zone-2” viene migrato a una distribuzione Citrix DaaS con due posizioni delle risorse cloud appena create denominate “Cloud-RL-1” e “Cloud-RL-2”. In questo caso, il file ZoneMapping.yml verrebbe configurato come segue:

            Zone-1: Cloud-RL-1

            Zone-2: Cloud-RL-2

Nota:

Aggiungere uno spazio tra i due punti e il nome della posizione della risorsa. Se nel nome della zona o della posizione della risorsa sono presenti spazi, racchiudere il nome tra virgolette.

Aggiornare il file di sicurezza per le connessioni host

Le connessioni host e i relativi hypervisor associati possono essere esportati e importati utilizzando ACT.

L’aggiunta di un hypervisor a una connessione host richiede informazioni di sicurezza specifiche per il tipo di hypervisor. Queste informazioni non possono essere esportate dal sito locale per motivi di sicurezza. È necessario fornire manualmente le informazioni in modo che la configurazione automatica possa importare correttamente le connessioni host e gli hypervisor nel sito cloud.

Il processo di esportazione crea il file CvadAcSecurity.yml in %HOMEPATH%\Documents\Citrix\AutoConfig contenente segnaposto per ogni elemento di sicurezza necessario per il tipo di hypervisor specifico. È necessario aggiornare il file CvadAcSecurity.yml prima di importarlo nel sito cloud. Gli aggiornamenti dell’amministratore vengono mantenuti su più esportazioni con nuovi segnaposto di sicurezza aggiunti secondo necessità. Gli elementi di sicurezza non vengono mai rimossi. Per ulteriori informazioni, vedere Aggiornare manualmente il file CvadAcSecurity.yml

            HostConn1:
            ConnectionType: XenServer®
            UserName: root
            PasswordKey: rootPassword
            HostCon2:
            ConnectionType: AWS
            ApiKey: 78AB6083-EF60-4D26-B2L5-BZ35X00DA5CH
            SecretKey: TwBLaaaaaaaaaaaaaaaaaw==
            Region: East

Informazioni di sicurezza per hypervisor

Di seguito sono elencate le informazioni di sicurezza richieste per ogni tipo di hypervisor.

• XenServer, Hyper-V, VMware
  • Nome utente
  • Password in chiaro
• Microsoft Azure
  • ID sottoscrizione
  • ID applicazione
  • Segreto applicazione
• AWS
  • ID account di servizio
  • Segreto dell’applicazione
  • Regione

Considerazioni speciali sulla sicurezza

Tutte le informazioni di sicurezza vengono inserite come testo in chiaro. Se il testo in chiaro non è consigliato, le connessioni host e gli hypervisor associati possono essere creati manualmente utilizzando Studio. Le connessioni host e i nomi degli hypervisor devono corrispondere esattamente alle loro controparti on-premises affinché i cataloghi di macchine che utilizzano le connessioni host possano essere importati correttamente.

Esportare la configurazione on-premises di Citrix Virtual Apps and Desktops

Utilizzando un comando PowerShell export, è possibile esportare la configurazione on-premises esistente e ottenere i file .yml necessari. Questi file vengono utilizzati per importare la configurazione desiderata in Citrix Cloud.

Oggetti di migrazione supportati

Automated Configuration supporta lo spostamento della configurazione dei seguenti componenti:

• Tag
• Amministratore delegato
  • Ambiti
  • Ruoli
• Connessioni host
  • Un singolo pool di risorse
  • Ambiti di amministrazione
• Cataloghi macchine
  • Ambiti di amministrazione
  • Macchine
  • Accesso PC remoto, Fisico, In pool, Provisionato, MCS, Assegnato
• StoreFront™
• Gruppi di consegna
  • Criterio di accesso
  • Associazione ambito di amministrazione
  • Criterio di accesso alle applicazioni
  • Criterio di assegnazione
  • Criterio di diritto/desktop
  • Pianificazioni di alimentazione
  • Persistenza sessione
  • Preavvio sessione
  • Pianificazioni di riavvio
  • Tag
• Gruppi di applicazioni
  • Associazione ambito amministratore
  • Gruppi di consegna
  • Utenti e gruppi
• Applicazioni
  • Cartelle applicazioni
  • Icone
  • Applicazioni
  • FTA configurati dal broker
  • Tag
• Criteri di gruppo
• Preferenze zona utente

Esportare la configurazione on-premises

1. Fare doppio clic sull’icona Auto Config. Viene visualizzata una finestra di PowerShell.

2. Eseguire il comando seguente per esportare tutti i componenti. L’esportazione della configurazione on-premises non la modifica in alcun modo.

   Export-CvadAcToFile
   <!--NeedCopy-->
   

Dopo aver eseguito un cmdlet per la prima volta, viene creata una cartella di esportazione con i file di configurazione e i log .yml. La cartella si trova in %HOMEPATH%\Documents\Citrix\AutoConfig. Ogni esportazione successiva crea una sottocartella. La cartella padre %HOMEPATH%\Documents\Citrix\AutoConfig contiene sempre i file esportati dall’esportazione più recente.

Nota:

Se la configurazione automatica non è installata sul Delivery Controller, eseguire import-module Citrix.AutoConfig.Commands prima di utilizzare lo strumento tramite PowerShell. Questo passaggio non è necessario se si apre la configurazione automatica utilizzando l’icona Auto Config.

In caso di errori o eccezioni, consultare la sezione Correzioni nel file di registro.

Importare la configurazione in Citrix DaaS

Importante:

• Quando si esegue la migrazione di una distribuzione on-premises al cloud, assicurarsi che i GPO di dominio e OU che contengono le impostazioni Citrix siano migrati al cloud. Citrix Web Studio™ non supporta GPMC e, pertanto, i GPO di dominio e OU non sono visibili in Web Studio. Il motore dei criteri Citrix applica i GPO di dominio e OU ai VDA e agli utenti che si trovano nei domini e nelle OU. Dopo aver effettuato l’accesso a un VDA, un utente potrebbe notare che i criteri dei GPO di dominio e OU vengono applicati alla propria sessione. Tuttavia, gli amministratori non possono visualizzare questi criteri e impostazioni, il che potrebbe generare confusione.

Ordine di migrazione dei componenti

I componenti e le loro dipendenze sono elencati qui. Le dipendenze di un componente devono essere presenti prima che possa essere importato o unito. Se una dipendenza è mancante, l’importazione o il comando di unione potrebbero non riuscire. La sezione Correzioni del file di registro mostra le dipendenze mancanti in caso di errore di importazione o unione.

1. Tag
   • Nessuna pre-dipendenza
2. Amministratore delegato
   • Nessuna pre-dipendenza
3. Connessioni host
   • Informazioni di sicurezza in CvadAcSecurity.yml
4. Cataloghi macchine
   • Macchine presenti in Active Directory
   • Connessioni host
   • Tag
5. StoreFront
6. Gruppi di consegna
   • Macchine presenti in Active Directory
   • Utenti presenti in Active Directory
   • Cataloghi macchine
   • Tag
7. Gruppi di applicazioni
   • Gruppi di consegna
   • Tag
8. Applicazioni
   • Gruppi di consegna
   • Gruppi di applicazioni
   • Tag
9. Criteri di gruppo
   • Gruppi di consegna
   • Tag
10. Preferenze zona utente

Eseguire un’importazione

1. Fare doppio clic sull’icona Auto Config. Viene visualizzata una finestra di PowerShell.

2. Eseguire il seguente comando per importare tutti i componenti.

   Merge-CvadAcToSite
   <!--NeedCopy-->
   

Verificare lo stato previsto con il nuovo stato corrente. Diverse opzioni di importazione controllano se i risultati dell’importazione sono identici o un sottoinsieme del sito locale.

Dopo aver eseguito il cmdlet, viene creata una cartella di esportazione con i file di configurazione .yml e i log. La cartella si trova in %HOMEPATH%\Documents\Citrix\AutoConfig.

Se si riscontrano errori o eccezioni, consultare la sezione Correzioni nel file di log.

Nota:

Se la configurazione automatizzata non è installata sul Delivery Controller, eseguire import-module Citrix.AutoConfig.Commands prima di utilizzare lo strumento tramite PowerShell. Questo passaggio non è necessario se si apre la configurazione automatizzata utilizzando l’icona Auto Config.

Per ripristinare la configurazione originale di Citrix DaaS, vedere Backup della configurazione di Citrix DaaS.

Comprendere l’operazione di importazione

Il processo di importazione è progettato per eseguire aggiornamenti in modo accurato, eseguire solo gli aggiornamenti necessari e verificare che tutti gli aggiornamenti siano stati eseguiti correttamente. I passaggi seguenti vengono eseguiti in tutte le operazioni di importazione:

1. Leggere il file .yml esportato (stato previsto).
2. Leggere il cloud (stato corrente).
3. Eseguire il backup dello stato del cloud pre-importazione in file .yml (il pre-backup può essere ripristinato se necessario).
4. Valutare le differenze tra lo stato previsto e quello corrente. Questo determina quali aggiornamenti eseguire.
5. Eseguire gli aggiornamenti.
6. Rileggere il cloud (nuovo stato corrente).
7. Eseguire il backup dello stato del cloud post-importazione in file .yml (il post-backup può essere ripristinato se necessario).
8. Confrontare il nuovo stato corrente con lo stato previsto.
9. Riportare i risultati del confronto.

Migrazione granulare

Importante:

Per maggiori informazioni sull’ordine di migrazione dei componenti, vedere Ordine di migrazione dei componenti.

È possibile migrare selettivamente solo i componenti o anche solo i nomi dei componenti.

• I parametri dei componenti supportati includono MachineCatalogs, Tags e altro ancora.
• I parametri del nome del componente supportati includono i parametri IncludeByName e ExcludeByName, e altri.

Per maggiori informazioni sui parametri e su come utilizzarli, vedere Parametri di migrazione granulare.

Attivare i siti

Il controller di consegna sia nei siti locali che in quelli cloud controlla le risorse come la gestione di desktop, applicazioni e il riavvio delle macchine. Si verificano problemi quando un insieme comune di risorse è controllato da due o più siti. Una situazione del genere può verificarsi durante la migrazione da un sito locale a un sito cloud. È possibile che sia i controller di consegna locali che quelli cloud gestiscano lo stesso insieme di risorse. Tale doppia gestione può portare a risorse che diventano non disponibili e non gestibili, e può essere difficile da diagnosticare.

L’attivazione del sito consente di controllare dove viene gestito il sito attivo.

L’attivazione del sito è gestita utilizzando la modalità di manutenzione del gruppo di consegna. I gruppi di consegna vengono posti in modalità di manutenzione quando il sito è inattivo. La modalità di manutenzione viene rimossa dai gruppi di consegna per i siti attivi.

L’attivazione del sito non influisce né gestisce la registrazione VDA o i cataloghi di macchine.

• Set-CvadAcSiteActiveStateCloud
• Set-CvadAcSiteActiveStateOnPrem

Tutti i cmdlet supportano IncludeByName e ExcludeByName filtraggio. Questo parametro consente di selezionare quali gruppi di consegna possono avere la loro modalità di manutenzione modificata. I gruppi di consegna possono essere modificati selettivamente secondo necessità.

Importazione e trasferimento del controllo al cloud

Di seguito è riportata una descrizione di alto livello su come importare e trasferire il controllo dal sito locale al sito cloud.

1. Esportare e importare il sito locale nel cloud. Assicurarsi che il parametro –SiteActive non sia presente in nessuno dei cmdlet di importazione. Il sito locale è attivo e il sito cloud è inattivo. Per impostazione predefinita, i gruppi di consegna del sito cloud sono in modalità di manutenzione.
2. Verificare il contenuto e la configurazione del cloud.
3. Durante le ore non lavorative, impostare il sito locale su inattivo. Il parametro –SiteActive deve essere assente. Tutti i gruppi di consegna del sito locale sono in modalità di manutenzione.
   • Set-CvadAcSiteActiveStateOnPrem
4. Impostare il sito cloud su attivo. Il parametro –SiteActive deve essere presente. Nessun gruppo di consegna del sito cloud è in modalità di manutenzione.
   • Set-CvadAcSiteActiveStateCloud –SiteActive
5. Verificare che il sito cloud sia attivo e il sito locale sia inattivo.

Trasferire il controllo al sito locale

Per trasferire il controllo dal sito cloud al sito locale:

1. Durante le ore non lavorative, impostare il sito cloud su inattivo. Tutti i gruppi di consegna del sito cloud sono in modalità di manutenzione.
   • Set-CvadAcSiteActiveStateCloud
2. Impostare il sito locale su attivo. Nessun gruppo di consegna del sito locale è in modalità di manutenzione.
   • Set-CvadAcSiteActiveStateOnPrem -SiteActive

Informazioni aggiuntive sull’attivazione del sito

• Se nessuna macchina è gestita dall’alimentazione e non ci sono pianificazioni di riavvio (il che di solito significa che non ci sono nemmeno connessioni host), tutti i gruppi di consegna cloud possono essere importati come attivi. Aggiungere -SiteActive a Merge-CvadAcToSite/Import-CvadAcToSite o eseguire Set-CvadAcSiteActiveStateCloud -SiteActive dopo l’importazione.
• Se le macchine sono gestite dall’alimentazione o ci sono pianificazioni di riavvio, è necessario un processo diverso. Ad esempio, quando si passa da on-premises a cloud in questa situazione, impostare il sito on-premises su inattivo usando Set-CvadAcSiteActiveStateOnPrem. Quindi, impostare il sito cloud su attivo usando Set-CvadAcSiteActiveStateCloud -SiteActive.
• I cmdlet Set-CvadAcSiteActiveStateCloud e Set-CvadAcSiteActiveStateOnPrem sono anche usati per invertire il processo. Ad esempio, eseguire Set-CvadAcSiteActiveStateCloud senza il parametro -SiteActive, quindi eseguire Set-CvadAcSiteActiveStateOnPrem con il parametro -SiteActive.

Comprendere la migrazione dei cataloghi con provisioning di Machine Creation Services

Nota:

Questa funzionalità è disponibile solo nelle versioni 3.0 e successive. Controllare la versione usando Get-CvadAcStatus all’interno di Configurazione automatizzata.

I cataloghi di Machine Creation Services (MCS) creano due diversi tipi di cataloghi:

• Quando le modifiche apportate a una macchina vengono perse o annullate (comunemente OS server, dove le applicazioni sono pubblicate) – questo è un caso d’uso VDI in pool / multi-sessione
• Quando le modifiche apportate a una macchina vengono conservate dopo il riavvio (comunemente OS client con un utente dedicato) – questo è un caso d’uso VDI statico

Il tipo di catalogo può essere confermato nel nodo del catalogo in Citrix Studio e osservando il valore “Dati utente:” del catalogo.

Nota:

MCS non può essere sottoposto a backup dal cloud usando Configurazione automatizzata.

Cataloghi VDI in pool / multi-sessione

I cataloghi con “Dati utente: Scarta” sono cataloghi VDI in pool e possono migrare solo l’immagine principale e la configurazione. Le macchine virtuali in questi cataloghi non vengono migrate. Questo perché il ciclo di vita della macchina virtuale è gestito dal sito da cui si sta importando, il che significa che ogni volta che le macchine vengono accese, il loro stato potrebbe cambiare. Ciò rende impossibile l’importazione poiché i dati di importazione per le macchine virtuali si disallineano rapidamente.

Quando si migrano questi cataloghi usando lo strumento, vengono creati i metadati del catalogo e viene avviata la creazione dell’immagine principale, ma nessuna macchina viene importata.

Poiché questo processo può richiedere del tempo per essere creato in base alle dimensioni dell’immagine principale, il comando di importazione all’interno dello strumento avvia solo la creazione del catalogo MCS e non attende che sia completata. Una volta completata l’importazione, monitorare l’avanzamento della creazione del catalogo utilizzando Studio nella distribuzione cloud.

Una volta creata l’immagine principale, è possibile eseguire il provisioning delle macchine. Considerare le considerazioni sulla capacità poiché si avrebbe capacità consumata dall’utilizzo on-premises.

Tutti gli altri oggetti (gruppi di consegna, applicazioni, criteri e così via) che utilizzano tale catalogo possono essere importati e non devono attendere la creazione dell’immagine principale. Una volta completata la creazione del catalogo, le macchine possono essere aggiunte al catalogo importato e quindi gli utenti possono avviare le proprie risorse.

Nota:

Utilizzare gli stessi comandi disponibili all’interno dello strumento per migrare i cataloghi e tutti gli altri oggetti.

Cataloghi VDI statici

Nota:

Poiché questa operazione importa dettagli di basso livello archiviati nel database, questo processo deve essere eseguito da una macchina con accesso al database.

I cataloghi VDI statici migrano l’immagine principale, le configurazioni e tutte le macchine virtuali. A differenza del caso d’uso VDI in pool, non è necessario creare immagini.

I VDA devono essere puntati al connettore affinché si registrino con il cloud.

Fare riferimento alla sezione Attivazione dei siti per rendere attivo il sito cloud, in modo che la pianificazione del riavvio, la gestione dell’alimentazione e altri elementi siano controllati dal cloud.

Una volta completata la migrazione, se si desidera eliminare questo catalogo dal sito on-premises, è necessario selezionare lasciare la VM e l’account AD. In caso contrario, verranno eliminati e il sito cloud rimarrebbe puntato alla VM eliminata.

Aggiornare i tag MCS per rilevare le risorse orfane dopo la migrazione

Dopo aver eseguito la migrazione dalla configurazione on-premises a un sito cloud, o dalla configurazione cloud a un altro sito cloud, è necessario aggiornare i tag ID del sito MCS in caso di VM persistenti in modo che le risorse orfane possano essere rilevate correttamente. Per fare ciò, utilizzare il comando PowerShell Set-ProvResourceTags. Attualmente, questa funzionalità è applicabile ad Azure.

I passaggi dettagliati sono i seguenti:

1. Aggiornare i tag ID sito MCS dal nuovo sito Citrix utilizzando il comando PowerShell Set-ProvResourceTags. Ad esempio:

   Set-ProvResourceTags -ProvisioningSchemeUid xxxxx  [-VMName <String>] [-VMBatchSize XX] [-ResourceType XX]
   <!--NeedCopy-->
   

   Oppure,

   Set-ProvResourceTags -ProvisioningSchemeName xxxxx  [-VMName <String>] [-VMBatchSize XX] [-ResourceType XX]
   <!--NeedCopy-->
   

I dettagli dei parametri sono i seguenti:

• ProvisioningSchemeUid o ProvisioningSchemeName è un parametro obbligatorio.
• VMName è un parametro facoltativo. Se non viene specificato VMName, i tag di tutte le VM di questo catalogo macchine vengono aggiornati.
• VMBatchSize è un parametro facoltativo per dividere tutte le VM in batch. Se non viene specificato VMBatchSize, viene applicato il valore predefinito (10). L’intervallo va da 1 a 60.

• ResourceType può essere uno dei seguenti:

  • MachineCatalog: Per l’aggiornamento dei tag delle risorse del catalogo macchine.
  • VirtualMachine: Per l’aggiornamento dei tag delle risorse correlate alle VM.
  • All: (ResourceType predefinito): Per l’aggiornamento dei tag sia delle risorse del catalogo macchine che di quelle correlate alle VM.