Citrix Virtual Apps and Desktops

Migrare la configurazione a Citrix Cloud™

Lo Strumento di configurazione automatizzata (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 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 fornisce una rapida panoramica della configurazione automatizzata.

Per ulteriori informazioni sulla configurazione automatizzata, consultare Proof of Concept: Automated Configuration Tool su Tech Zone.

Per un approfondimento sullo spostamento della distribuzione e sulla preparazione della configurazione on-premise per la migrazione, consultare Deployment Guide: Migrating Citrix Virtual Apps and Desktops from on-premises to Citrix Cloud su Tech Zone.

Limitazioni note

Prerequisiti per la migrazione della configurazione

Per esportare la configurazione da Citrix Virtual Apps and Desktops, è necessario:

  • Citrix Virtual Apps and Desktops: versione corrente e la sua immediata precedente 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 versione successiva e l’SDK Citrix PowerShell. Questo viene installato automaticamente sul Delivery Controller. (Per l’esecuzione su una macchina diversa dal Delivery Controller on-premise, Citrix Studio deve essere installato, poiché Studio installa gli snap-in PowerShell corretti. Il programma di installazione di Studio è disponibile sui supporti 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 di cui è stato eseguito il 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 ulteriori informazioni, consultare Requisiti di sistema e connettività.

Nota:

La configurazione automatizzata non può essere installata su un sistema Cloud Connector.

Passaggi chiave

  1. Scaricare lo Strumento di configurazione automatizzata e rivedere i requisiti di sistema. Vedere Scaricare la configurazione automatizzata.
  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 sul cliente.
  3. Se il sito on-premise contiene più zone, aggiornare il file ZoneMapping.yml per mappare le zone alle posizioni delle risorse di 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 più 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 la versione più recente disponibile di ACT.

Per conoscere la versione dello strumento, procedere come segue:

  1. Fare doppio clic sull’icona Auto Config. Verrà visualizzata una finestra PowerShell.
  2. Eseguire il comando seguente per controllare il numero di versione.

    Get-CvadAcStatus
    <!--NeedCopy-->
    
  3. Controllare la versione dello strumento rispetto alla versione elencata in Citrix Downloads. La versione più recente dello strumento si trova lì.
  4. Scaricare e installare la versione più recente dello strumento. Non è necessario disinstallare la vecchia versione per aggiornare la configurazione automatizzata.

Nota:

Quando si eseguono i cmdlet per accedere al cloud nella configurazione automatizzata, lo strumento avvisa quando è disponibile una versione più recente per il download. Per ulteriori informazioni sui cmdlet, consultare Cmdlet dello strumento di configurazione automatizzata.

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

Per migrare il sito on-premise 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 differenziare 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 sul cliente

Il file CustomerInfo.yml elimina la necessità di fornire i parametri delle informazioni sul cliente ogni volta che si esegue il cmdlet. Qualsiasi informazione sul 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ò potrebbe 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-->

È possibile creare il file CustomerInfo.yml anche utilizzando il parametro SecurityCsvFileSpec che punta al file security.csv scaricato. È inoltre necessario specificare 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 esempio di file CustomerInfo.yml.

            # 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-premise è l’equivalente della posizione delle risorse cloud. A differenza di altri componenti del sito, non è possibile importare automaticamente la zona on-premise 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-premise hanno una sola zona e i siti cloud hanno una sola posizione delle risorse, lo strumento di configurazione automatizzata crea l’associazione corretta, eliminando la necessità di gestire manualmente il file ZoneMapping.yml.

Tuttavia, se i siti on-premise 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-premise 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-premise 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 delle risorse. Se nel nome della zona o della posizione delle risorse vengono utilizzati 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 on-premise per motivi di sicurezza. È necessario fornire manualmente le informazioni in modo che la configurazione automatizzata 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, consultare 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 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. I nomi delle connessioni host e degli hypervisor devono corrispondere esattamente alle loro controparti on-premise in modo che i cataloghi di macchine che utilizzano le connessioni host possano essere importati correttamente.

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

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

Oggetti di migrazione supportati

La configurazione automatizzata supporta lo spostamento della configurazione dei seguenti componenti:

  • Tag
  • Amministrazione delegata
    • Ambiti
    • Ruoli
  • Connessioni host
    • Un singolo pool di risorse
    • Ambiti di amministrazione
  • Cataloghi macchine
    • Ambiti di amministrazione
    • Macchine
    • Accesso PC remoto, Fisico, In pool, Con provisioning, 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 di amministrazione
    • 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 locale

  1. Fare doppio clic sull’icona Auto Config. Verrà visualizzata una finestra di PowerShell.
  2. Eseguire il comando seguente per esportare tutti i componenti. L’esportazione della configurazione locale 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 .yml e i log. 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.

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

Importare la configurazione in Citrix DaaS

Importante:

  • Quando si esegue la migrazione di una distribuzione locale al cloud, assicurarsi che gli oggetti Criteri di gruppo (GPO) di dominio e unità organizzativa (OU) che contengono le impostazioni Citrix vengano migrati al cloud. Citrix Web Studio™ non supporta GPMC e, pertanto, gli oggetti Criteri di gruppo di dominio e unità organizzativa non sono visibili in Web Studio. Il motore dei criteri Citrix applica gli oggetti Criteri di gruppo di dominio e unità organizzativa ai VDA e agli utenti che si trovano nei domini e nelle unità organizzative. Dopo l’accesso a un VDA, un utente potrebbe notare che i criteri degli oggetti Criteri di gruppo di dominio e unità organizzativa 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 relative dipendenze sono elencati qui. Le dipendenze di un componente devono essere presenti prima che possa essere importato o unito. Se una dipendenza è mancante, il comando di importazione o unione potrebbe non riuscire. La sezione Correzioni del file di log mostra le dipendenze mancanti se un’importazione o un’unione non riesce.

  1. Tag
    • Nessuna pre-dipendenza
  2. Amministrazione delegata
    • 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. Verrà visualizzata una finestra di PowerShell.
  2. Eseguire il comando seguente 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 verificano errori o eccezioni, consultare la sezione Correzioni nel file di log.

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.

Per ripristinare la configurazione originale di Citrix DaaS, vedere Eseguire il backup della configurazione di Citrix DaaS.

Comprendere l’operazione di importazione

Il processo di importazione è progettato per eseguire gli 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 lo stato 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 altri.
  • I parametri dei nomi dei componenti supportati includono i parametri IncludeByName ed ExcludeByName e altri.

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

Attivare i siti

Il Delivery Controller nei siti locali e cloud controlla le risorse come il brokering di desktop, applicazioni e il riavvio delle macchine. Si verificano problemi quando un set 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 Delivery Controller locali che quelli cloud gestiscano lo stesso set di risorse. Tale gestione duale può portare a risorse non disponibili e non gestibili, e può essere difficile da diagnosticare.

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

L’attivazione del sito viene 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 macchine.

  • Set-CvadAcSiteActiveStateCloud
  • Set-CvadAcSiteActiveStateOnPrem

Tutti i cmdlet supportano il filtro IncludeByName ed ExcludeByName. 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

Ulteriori informazioni 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 locale a cloud in questa situazione, impostare il sito locale su inattivo utilizzando Set-CvadAcSiteActiveStateOnPrem. Quindi, impostare il sito cloud su attivo utilizzando Set-CvadAcSiteActiveStateCloud -SiteActive.
  • I cmdlet Set-CvadAcSiteActiveStateCloud e Set-CvadAcSiteActiveStateOnPrem vengono utilizzati anche 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. Verificare la versione utilizzando Get-CvadAcStatus all’interno della configurazione automatica.

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 sistema operativo 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 sistema operativo 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 utilizzando la configurazione automatica.

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 è mantenuto 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 utilizzando lo strumento, esso crea i metadati del catalogo e avvia 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 il suo completamento. Dopo il completamento dell’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à perché si avrebbe capacità consumata dall’utilizzo locale.

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 Attivare i 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 locale, è necessario selezionare lasciare VM e 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 la migrazione dalla configurazione locale 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 del 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 alcun 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 alcun 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 delle risorse correlate alle VM.