Migrare la configurazione a Citrix Cloud
Perché utilizzare Automated Configuration
Gli amministratori IT responsabili di ambienti grandi o complessi spesso considerano le migrazioni un processo noioso. Spesso finiscono per scriversi da soli gli strumenti per svolgere con successo questo compito poiché tende a essere specifico per i loro casi d’uso
Citrix vuole contribuire a semplificare questo processo automatizzando il processo di migrazione mediante lo strumento Automated Configuration. Gli amministratori possono facilmente testare le configurazioni attuali in Citrix Cloud e sfruttare i vantaggi offerti da Citrix DaaS (in precedenza servizio Citrix Virtual Apps and Desktops), mantenendo intattigli ambienti attuali. Inoltre, non vi è alcun impatto sull’utente finale, poiché Automated Configuration funziona perfettamente in background. Tali vantaggi includono una riduzione del sovraccarico amministrativo quando Citrix gestisce parte del back-end e del piano di controllo, aggiornamenti automatici e personalizzabili dei componenti Citrix Cloud e altri.
Citrix utilizza la configurazione standard del settore come codice per offrire un meccanismo che aiuta ad automatizzare i processi di migrazione. Automated Configuration rileva ed esporta uno o più siti locali come raccolta di file di configurazione. La configurazione di questi file può quindi essere importata in Citrix DaaS.
Automated Configuration consente inoltre agli amministratori di unire più siti locali in un unico sito, evitando conflitti di nomi. Gli amministratori possono stabilire se le risorse debbano essere controllate dalla configurazione locale o cloud.
Automated Configuration non è solo uno strumento di migrazione una tantum, ma può anche automatizzare la configurazione quotidiana in Citrix Cloud. Lo spostamento della configurazione Citrix DaaS può essere utile per molte ragioni:
- Sincronizzazione del sito dalla fase di test o di staging alla fase di produzione
- Effettuare il backup e ripristinare la configurazione
- Raggiungere i limiti delle risorse
- Migrare da una regione all’altra
Il seguente video di 2 minuti fornisce una panoramica rapida di Automated Configuration.
Per ulteriori informazioni su Automated Configuration, vedere Proof of Concept: Automated Configuration Tool in Tech Zone.
Per uno sguardo più approfondito sullo spostamento della distribuzione e sulla preparazione della configurazione locale per la migrazione, vedere l’articolo Deployment Guide: Migrating Citrix Virtual Apps and Desktops from on-premises to Citrix Cloud in Tech Zone.
Scaricare Automated Configuration
Scaricare e installare lo strumento Automated Configuration da Citrix Downloads.
Importante:
Per evitare errori di funzionamento, utilizzare sempre l’ultima versione disponibile di Automated Configuration.
Aggiornamento di Automated Configuration
Quando si eseguono cmdlet che accedono al cloud in Automated Configuration, lo strumento avvisa l’utente quando è disponibile per il download una versione più recente.
È possibile assicurarsi di avere la versione più recente attenendosi alla seguente procedura:
- Fare doppio clic sull’icona Auto Config. Viene visualizzata una finestra di PowerShell.
-
Eseguire il seguente comando per verificare il numero di versione.
Get-CvadAcStatus - Controllare la versione dello strumento rispetto alla versione elencata nell’avviso o su Citrix Downloads. L’ultima versione dello strumento si trova lì.
- Scaricare e installare l’ultima versione dello strumento. Non è necessario disinstallare la versione precedente per aggiornare Automated Configuration.
Nota:
L’avviso viene visualizzato ogni volta che si esegue un cmdlet che accede al cloud. Per ulteriori informazioni sui cmdlet, vedere Automated Configuration tool cmdlets.
Limitazioni note
- I cataloghi di macchine forniti tramite Machine Creation Services hanno considerazioni speciali. Per ulteriori informazioni su MCS, vedere Understanding migrating Machine Creation Services provisioned catalogs.
Oggetti di migrazione supportati
Automated Configuration supporta lo spostamento della configurazione dei seguenti componenti:
- Tag
- Amministrazione delegata
- Ambiti
- Ruoli
- Connessioni host
- Un unico pool di risorse
- Ambiti di amministrazione
- Cataloghi di macchine
- Ambiti di amministrazione
- Macchine
- Accesso remoto al PC, fisico, in pool, con provisioning, MCS, assegnato
- StoreFronts
- Gruppi di consegna
- Criteri di accesso
- Associazione di ambiti di amministrazione
- Criteri di accesso alle applicazioni
- Criteri di assegnazione
- Criteri di autorizzazione/desktop
- Pianificazioni dell’alimentazione
- Permanenza della sessione
- Prelavancio della sessione
- Pianificazioni di riavvio
- Tag
- Gruppi di applicazioni
- Associazione di ambiti di amministrazione
- Gruppi di consegna
- Utenti e gruppi
- Applicazioni
- Cartelle delle applicazioni
- Icone
- Applicazioni
- FDA configurati da broker
- Tag
- Criteri di gruppo
- Preferenze dell’area utente
Ordine di migrazione dei componenti
I componenti e le relative dipendenze sono elencati qui. Le dipendenze di un componente devono essere presenti prima di poter essere importate o unite. Se manca una dipendenza, è possibile che il comando di importazione o unione non riesca. La sezione Fixups del file di registro mostra le dipendenze mancanti in caso di errore di importazione o unione.
- Tag
- Nessuna pre-dipendenza
- Amministrazione delegata
- Nessuna pre-dipendenza
- Connessioni host
- Informazioni sulla sicurezza in CvadAcSecurity.yml
- Cataloghi di macchine
- Macchine presenti in Active Directory
- Connessioni host
- Tag
- StoreFronts
- Gruppi di consegna
- Macchine presenti in Active Directory
- Utenti presenti in Active Directory
- Cataloghi di macchine
- Tag
- Gruppi di applicazioni
- Gruppi di consegna
- Tag
- Applicazioni
- Gruppi di consegna
- Gruppi di applicazioni
- Tag
- Criteri di gruppo
- Gruppi di consegna
- Tag
- Preferenze dell’area utente
Prerequisiti comuni
Di seguito sono riportati alcuni prerequisiti comuni necessari per il corretto funzionamento di Automated Configuration. Questi prerequisiti vengono utilizzati sia nelle migrazioni da locale a cloud che da cloud a cloud.
Generazione dell’ID cliente, dell’ID client e della chiave segreta
Prima di iniziare la migrazione utilizzando Automated Configuration, è necessario disporre dell’ID cliente Citrix Cloud e creare un ID client e una chiave segreta per importare la configurazione in Citrix Cloud. Tutti i cmdlet che accedono al cloud richiedono questi valori.
I passaggi seguenti consentono di recuperare l’ID cliente e creare l’ID client e la chiave segreta.
Per recuperare l’ID cliente:
-
Accedere al proprio account Citrix Cloud e selezionare il cliente.
-
Fare clic sul menu a forma di hamburger, quindi selezionare Identity and Access Management (Gestione identità e accessi) nel menu a discesa.
-
L’ID cliente si trova nella pagina Gestione identità e accessi .
Per recuperare l’ID client e la chiave segreta:
-
Nella pagina Identity and Access Management, fare clic sulla scheda API Access.
-
Inserire un nome nella casella. Questo nome viene utilizzato per distinguere tra più ID client e chiavi segrete. Fare clic su Create client per creare l’ID client e la chiave segreta.
-
La seguente finestra di dialogo viene visualizzata dopo aver creato correttamente l’ID client e la chiave segreta. Fare attenzione a copiare entrambi i valori in una posizione sicura e scaricare il file .csv contenente queste informazioni. Il file .csv può essere utilizzato per creare il file CustomerInfo.yml.
-
L’ID client e la chiave segreta sono stati creati correttamente.
Mettere questi valori in una posizione sicura e condividerli solo con membri dell’azienda fidati che hanno bisogno di accedere allo strumento o accedere alle API Rest del cloud. L’ID client e la chiave segreta non scadono. Se sono compromessi, rimuoverli immediatamente utilizzando l’icona Cestino e crearne di nuovi.
Nota:
La chiave segreta non può essere recuperata se viene persa o dimenticata; è necessario creare un nuovo ID client e una chiave segreta.
Compilare il file di informazioni sul cliente
L’utilizzo del file CustomerInfo.yml elimina la necessità di fornire i parametri delle informazioni sui clienti con l’esecuzione di ogni cmdlet. È possibile sovrascrivere qualsiasi informazione sul cliente utilizzando i parametri del cmdlet.
Creare il file CustomerInfo.yml utilizzando il cmdlet New-CvadAcCustomerInfoFile.
Importante:
Non modificare manualmente il file CustomerInfo.yml. Ciò potrebbe causare errori di formattazione involontari.
New-CvadAcCustomerInfoFile ha i seguenti parametri richiesti.
- CustomerId: ID cliente.
- ClientID: ID cliente creato su Citrix Cloud.
- Segreto: il segreto del cliente creato su Citrix Cloud.
New-CvadAcCustomerInfoFile -CustomerId markhof123 -ClientId 6813EEA6-46CC-4F8A-BC71-539F2DAC5984 -Secret TwBLaaaaaaaaaaaaaaaaaw==
È inoltre possibile creare CustomerInfo.yml 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
Aggiornare il file CustomerInfo.yml utilizzando il cmdlet Set-CvadAcCustomerInfoFile. Questo cmdlet modifica solo l’ID client.
Set-CvadAcCustomerInfoFile -ClientId C80487EE-7113-49F8-85DD-2CFE30CC398E
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
Compilare il file di mappatura delle zone
Una zona locale è equivalente alla posizione di una risorsa cloud. A differenza di altri componenti del sito, non è possibile importare automaticamente l’area locale nel cloud. Questa deve essere invece mappata manualmente utilizzando il file ZoneMapping.yml. È possibile che si verifichino errori di importazione se il nome della zona non è associato a un nome di posizione risorsa esistente.
Per i siti locali con una sola zona e per i siti cloud che hanno una sola risorsa, lo strumento Automated Configuration crea l’associazione corretta, eliminando la necessità di gestire manualmente il file ZoneMapping.yml.
Per i siti locali con più zone o i siti cloud con più posizioni di risorse, il file ZoneMapping.yml deve essere aggiornato manualmente per riflettere la corretta mappatura delle zone locali alle posizioni delle risorse cloud. Questa operazione deve essere eseguita prima di tentare qualsiasi operazione di importazione nel 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 della risorsa come valore.
Ad esempio, un sito Citrix Virtual Apps and Desktops on-premise con una zona primaria denominata “Zone-1” e una zona secondaria denominata “Zone-2” viene migrato a una distribuzione Citrix DaaS con due posizioni risorse cloud appena create denominate “Cloud-RL-1” e “Cloud-RL-2”. In questo caso, ZoneMapping.yml verrà configurato come segue:
Zone-1: Cloud-RL-1
Zone-2: Cloud-RL-2
Nota:
Tra i due punti e il nome della posizione della risorsa deve essere presente uno spazio. Se vengono utilizzati spazi nel nome della zona o della posizione della risorsa, racchiudere il nome tra virgolette.
Connessioni host
Le connessioni host e gli hypervisor associati possono essere esportati e importati utilizzando Automated Configuration.
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 Automated Configuration possa importare correttamente le connessioni host e gli hypervisor nel sito cloud.
Il processo di esportazione crea il file CvadAcSecurity.yml nel percorso %HOMEPATH%\Documents\Citrix\AutoConfig contenente segnaposto per ogni elemento di protezione 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 Manually update the CvadAcSecurity.yml file
HostConn1:
ConnectionType: XenServer
UserName: root
PasswordKey: rootPassword
HostCon2:
ConnectionType: AWS
ApiKey: 78AB6083-EF60-4D26-B2L5-BZ35X00DA5CH
SecretKey: TwBLaaaaaaaaaaaaaaaaaw==
Region: East
Informazioni sulla sicurezza per ciascun hypervisor
Di seguito sono elencate le informazioni di sicurezza necessarie per ciascun tipo di hypervisor.
- XenServer, Hyper-V, VMware
- Nome utente
- Password in chiaro
- Microsoft Azure
- ID sottoscrizione
- ID applicazione
- Segreto applicazione
- Amazon Web Services
- ID account di servizio
- Segreto applicazione
- Regione
Considerazioni speciali sulla sicurezza
Tutte le informazioni di sicurezza vengono inserite come testo non crittografato. Se il testo non crittografato non è consigliato, le connessioni host e gli hypervisor associati possono essere creati manualmente utilizzando l’interfaccia Manage > Full Configuration (Gestisci > Configurazione completa). Le connessioni host e i nomi degli hypervisor devono corrispondere esattamente alle controparti locali in modo che i cataloghi di macchine che utilizzano le connessioni host possano essere importati correttamente.
Attivare i siti
Il Delivery Controller nei siti on-premise e cloud controlla le risorse come i desktop di intermediazione, le applicazioni e il riavvio delle macchine. I problemi si verificano 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 per i Delivery Controller on-premise e cloud gestire lo stesso set di risorse. Tale duplice gestione può comportare l’indisponibilità e l’ingestibilità delle risorse e può essere difficile da diagnosticare.
L’attivazione del sito consente di controllare dove è controllato il sito attivo.
L’attivazione del sito viene gestita utilizzando la modalità di manutenzione del gruppo di consegna. I gruppi di consegna vengono messi 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 sulla registrazione dei VDA o dei cataloghi delle macchine, né la gestisce.
Set-CvadAcSiteActiveStateCloudSet-CvadAcSiteActiveStateOnPrem
Tutti i cmdlet supportano IncludeByName e i ExcludeByName filtri. Questo parametro consente di selezionare quali gruppi di consegna possono modificare la modalità di manutenzione. I gruppi di consegna possono essere modificati in modo selettivo secondo necessità.
Importazione e trasferimento del controllo sul cloud
Di seguito è riportata una descrizione di alto livello su come importare e trasferire il controllo dal sito locale al sito cloud.
- Esportare e importare il sito locale nel cloud. Accertarsi che il parametro
–SiteActivenon sia presente in nessuno dei cmdlet di importazione. Il sito locale è attivo e il sito cloud è inattivo. Per impostazione predefinita, i gruppi di distribuzione del sito cloud sono in modalità di manutenzione. - Verificare il contenuto e la configurazione del cloud.
- Al di fuori delle ore di lavoro, impostare il sito locale su inattivo. Il parametro
–SiteActivedeve essere assente. Tutti i gruppi di consegna in loco sono in modalità di manutenzione.Set-CvadAcSiteActiveStateOnPrem
- Impostare il sito cloud su attivo. Il parametro
–SiteActivedeve essere presente. Nessun gruppo di distribuzione del sito cloud è in modalità di manutenzione.Set-CvadAcSiteActiveStateCloud –SiteActive
- Verificare che il sito cloud sia attivo e che il sito locale sia inattivo.
Trasferire di nuovo il controllo sul sito locale
Per trasferire il controllo dal sito cloud al sito locale:
- Al di fuori delle ore di lavoro, impostare il sito cloud su inattivo. Tutti i gruppi di distribuzione del sito cloud sono in modalità di manutenzione.
Set-CvadAcSiteActiveStateCloud
- Impostare il sito locale su attivo. Nessun gruppo di consegna locale è in modalità di manutenzione.
Set-CvadAcSiteActiveStateOnPrem -SiteActive
Informazioni aggiuntive sull’attivazione del sito
- Se non è prevista la gestione dell’alimentazione per le macchine 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
-SiteActiveaMerge-CvadAcToSite/Import-CvadAcToSiteo eseguireSet-CvadAcSiteActiveStateCloud -SiteActivedopo l’importazione. - Se è prevista la gestione dell’alimentazione delle macchine o vi sono pianificazioni di riavvio, è necessario un processo diverso. Ad esempio, quando si passa da on-premise a cloud in questa situazione, impostare il sito on-premise su inattivo utilizzando
Set-CvadAcSiteActiveStateOnPrem. Quindi, impostare il sito cloud su attivo utilizzandoSet-CvadAcSiteActiveStateCloud -SiteActive. - I cmdlet
Set-CvadAcSiteActiveStateOnPremeSet-CvadAcSiteActiveStateCloudvengono utilizzati anche per invertire il processo. Ad esempio, eseguireSet-CvadAcSiteActiveStateCloudsenza il parametro-SiteActive, quindi eseguireSet-CvadAcSiteActiveStateOnPremcon il parametro-SiteActive.
Informazioni sulla migrazione dei cataloghi con provisioning di Machine Creation Services
Nota:
Questa funzione è disponibile solo nelle versioni 3.0 e successive. Controllare la versione in uso utilizzando
Get-CvadAcStatusin Automated Configuration.
I cataloghi di Machine Creation Services (MCS) creano due diversi tipi di cataloghi:
- Quando le modifiche apportate a una macchina vengono perse/ripristinate (comunemente nel sistema operativo del server, in cui vengono pubblicate le applicazioni), si tratta di un caso d’uso VDI/multisessione in pool
- Quando le modifiche apportate a una macchina vengono conservate durante il riavvio (comunemente nel sistema operativo del client con un utente dedicato); si tratta di un caso d’uso VDI statico
Il tipo di catalogo può essere confermato nel nodo catalogo in Citrix Studio e osservando il valore “Dati utente:” del catalogo.
Nota:
Non è possibile eseguire il backup di MCS dal cloud utilizzando Automated Configuration.
Cataloghi VDI/multisessione in pool
I cataloghi con “Dati utente: Discard” sono cataloghi VDI raggruppati e possono solo migrare l’immagine e la configurazione principali. Le macchine virtuali presenti in questi cataloghi non vengono migrate. Questo perché il ciclo di vita della macchina virtuale viene mantenuto dal sito da cui si sta importando, il che significa che ogni volta che i computer vengono accesi, il suo stato potrebbe cambiare. Ciò rende impossibile l’importazione poiché i dati di importazione per le macchine virtuali perdono rapidamente la sincronizzazione.
Quando si esegue la migrazione di questi cataloghi utilizzando lo strumento, vengono creati i metadati del catalogo e viene avviata la creazione dell’immagine principale, ma non vengono importate macchine.
Poiché la creazione di questo processo richiede più tempo maggiori sono le dimensioni dell’immagine principale, il comando di importazione all’interno dello strumento avvia solo la creazione del catalogo MCS e non attende il completamento. Una volta completata l’importazione, monitorare l’avanzamento della creazione del catalogo utilizzando l’interfaccia di gestione Full Configuration (Configurazione completa) nella distribuzione cloud.
Una volta creata l’immagine principale, è possibile eseguire il provisioning delle macchine. È necessario tenere conto delle considerazioni sulla capacità in quanto l’utilizzo locale potrebbe consumare capacità.
Tutti gli altri oggetti (gruppi di consegna/applicazioni/criteri e così via) che utilizzano quel catalogo possono essere importati e non devono attendere la creazione dell’immagine principale. Al termine della creazione del catalogo, è possibile aggiungere macchine al catalogo importato e quindi gli utenti possono avviare le proprie risorse.
Nota:
Utilizzare gli stessi comandi disponibili nello strumento per effettuare la migrazione dei cataloghi e di tutti gli altri oggetti.
Cataloghi VDI statici
Nota:
Poiché questa operazione comporta l’importazione di dettagli di basso livello archiviati nel database, questo processo deve essere eseguito da una macchina che abbia accesso al database.
I cataloghi VDI statici eseguono la migrazione dell’immagine principale, delle configurazioni e di tutte le macchine virtuali. A differenza di quanto avviene nel caso d’uso dei VDI in pool, non è necessario creare immagini.
I VDA devono essere puntati sul connettore affinché possano registrarsi nel 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 scegliere di lasciare la macchina virtuale e l’account AD. In caso contrario, vengono eliminati e il sito cloud rimarrebbe puntato sulla macchina virtuale eliminata.
In questo articolo
- Perché utilizzare Automated Configuration
- Scaricare Automated Configuration
- Aggiornamento di Automated Configuration
- Limitazioni note
- Oggetti di migrazione supportati
- Ordine di migrazione dei componenti
- Prerequisiti comuni
- Attivare i siti
- Informazioni sulla migrazione dei cataloghi con provisioning di Machine Creation Services