Documentazione dei prodotti
Citrix DaaS™
Visualizza PDF

Aggiornare il file d

May 4, 2026
Grazie al contributo di: 
C C

Migrare la configurazione a Citrix Cloud™

Lo strumento Automated Configuration Tool (ACT) consente la migrazione della configurazione di Citrix Virtual Apps and Desktops™ (criteri, applicazioni, cataloghi, ruoli di amministratore, 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 “una tantum”. È possibile utilizzarlo per gestire le operazioni cloud quotidiane, ad esempio:

  • Automatizzare il trasferimento dagli account cloud di test o di staging agli 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 un rapido tour di Automated Configuration.

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 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 il Citrix PowerShell SDK. 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 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 aggiunta 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:

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

Passaggi chiave

  1. Scaricare lo strumento Automated Configuration Tool 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 sul 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 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 Automated Configuration

Scaricare e installare lo strumento Automated Configuration da Citrix Downloads.

Aggiornare Automated Configuration

Per evitare 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 di PowerShell.

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

    
Get-CvadAcStatus

<!--NeedCopy-->
      1. Controllare la versione dello strumento rispetto alla versione elencata in Citrix Downloads. La versione più recente dello strumento si trova lì.
      1. Scaricare e installare la versione più recente dello strumento. Non è necessario disinstallare la vecchia versione per aggiornare Automated Configuration.

Nota:

Quando si eseguono i cmdlet per accedere al cloud in Automated Configuration, lo strumento avvisa l’utente quando è disponibile una versione più recente per il download. Per ulteriori informazioni sui cmdlet, consultare Cmdlet dello strumento Automated Configuration.

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 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ò 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-->

È anche possibile creare il file 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

<!--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.

-  # Creato/Aggiornato il 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 della risorsa 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 della risorsa esistente.

-  Se i siti on-premise hanno una sola zona e i siti cloud hanno una sola posizione della risorsa, lo strumento di configurazione automatica effettua 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 della risorsa 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 di 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 vengono utilizzati spazi, racchiudere il nome tra virgolette.

Aggiornare il file di sicurezza per le connessioni host

-  Le connessioni host e i relativi hypervisor 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 affinché 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 maggiori informazioni, consultare [Aggiornare manualmente il file CvadAcSecurity.yml](/en-us/tech-zone/learn/poc-guides/citrix-automated-configuration.html#manually-update-the-cvadacsecurityyml-file)

-  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 locali affinché i cataloghi di macchine che utilizzano le connessioni host possano essere importati correttamente.

-  ## Esportare la configurazione locale di Citrix Virtual Apps and Desktops

-  Utilizzando un comando PowerShell `export`, è possibile esportare la configurazione locale 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](#understand-migrating-machine-creation-services-provisioned-catalogs), Assegnato
-  StoreFront™
-  Gruppi di consegna
-  Criteri di accesso
-  Associazione ambito di amministrazione
-  Criteri di accesso alle applicazioni
-  Criteri di assegnazione
-  Criteri 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 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 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.

In caso di 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 i GPO di dominio e OU che contengono le impostazioni Citrix vengano 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 l’accesso a un VDA, un utente potrebbe vedere che i criteri dei GPO di dominio e OU vengono applicati alla propria sessione. Tuttavia, gli amministratori non possono vedere questi criteri e impostazioni, il che potrebbe generare confusione.
-  ### Ordine di migrazione dei componenti

-  Di seguito sono elencati i componenti e le loro dipendenze. 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 in caso di errore di importazione o unione.
    1. Tag
      • Nessuna pre-dipendenza
    1. Amministrazione delegata
      • Nessuna pre-dipendenza
  1. Connessioni host
    • Informazioni di sicurezza in CvadAcSecurity.yml
  2. Cataloghi macchine
    • Macchine presenti in Active Directory
    • Connessioni host
    • Tag
  3. StoreFront
  4. Gruppi di consegna
    • Macchine presenti in Active Directory
    • Utenti presenti in Active Directory
    • Cataloghi macchine
    • Tag
  5. Gruppi di applicazioni
    • Gruppi di consegna
    • Tag
  6. Applicazioni
    • Gruppi di consegna
    • Gruppi di applicazioni
    • Tag
  7. Criteri di gruppo
    • Gruppi di consegna
    • Tag
  8. Preferenze zona utente

Eseguire un’importazione

  1. Fare doppio clic sull’icona Auto Config. Verrà visualizzata una finestra PowerShell.

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

    
Merge-CvadAcToSite

<!--NeedCopy-->

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

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.

In caso di errori o eccezioni, consultare la sezione Fixups 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.

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 vengono seguiti in tutte le operazioni di importazione:

  1. Leggere il file .yml esportato (stato previsto).
  2. Leggere il cloud (stato attuale).
  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 attuale. Questo determina quali aggiornamenti eseguire.
  5. Eseguire gli aggiornamenti.
  6. Rileggere il cloud (nuovo stato attuale).
  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 attuale con lo stato previsto.
  9. Riportare i risultati del confronto.

Migrazione granulare

Importante:

Per ulteriori informazioni sull’ordine di migrazione dei componenti, consultare 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.
  • I parametri del nome del componente supportati includono i parametri IncludeByName e ExcludeByName e altri.

Per ulteriori informazioni sui parametri e su come utilizzarli, consultare Parametri di migrazione granulare.

Attivare i siti

Il controller di consegna sia nei siti on-premises che cloud controlla 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 on-premises a un sito cloud. È possibile che sia i controller di consegna on-premises che cloud gestiscano lo stesso set di risorse. Tale gestione duale 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 o gestisce la registrazione VDA o i cataloghi di macchine.

  • Set-CvadAcSiteActiveStateCloud
  • Set-CvadAcSiteActiveStateOnPrem

Tutti i cmdlet supportano il filtraggio IncludeByName e 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 on-prem al sito cloud.

  1. Esportare e importare il sito on-premises nel cloud. Assicurarsi che il parametro –SiteActive non sia presente in nessuno dei cmdlet di importazione. Il sito on-premises è 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 on-premises su inattivo. Il parametro –SiteActive deve essere assente. Tutti i gruppi di consegna del sito on-premises 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 on-premises sia inattivo.

Trasferire il controllo al sito on-premises

Per trasferire il controllo dal sito cloud al sito on-premises:

  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 on-premises su attivo. Nessun gruppo di consegna del sito on-prem è 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 on-premises a cloud in questa situazione, impostare il sito on-premises 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 di Configurazione automatizzata.

I cataloghi 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, in cui le applicazioni sono pubblicate) – questo è un caso d’uso VDI in pool / multi-sessione
  • Quando le modifiche apportate a una macchina vengono mantenute 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 “User data:” del catalogo.

Nota:

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

Cataloghi VDI in pool / multi-sessione

I cataloghi con “User data: Discard” 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 desincronizzano 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. Una volta completata l’importazione, monitorare l’avanzamento della creazione del catalogo utilizzando Studio nella distribuzione cloud.

Una volta creata l’immagine principale, è possibile effettuare 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 nello 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 locale, è necessario selezionare leave VM and AD account. 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 da una configurazione locale a un sito cloud, o dalla configurazione cloud a un altro sito cloud, è necessario aggiornare i tag ID sito MCS in caso di VM persistenti in modo che le risorse orfane possano essere rilevate correttamente. A tale scopo, 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 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 delle risorse del catalogo macchine e delle risorse correlate alle VM.
Aggiornare il file d
May 4, 2026
Grazie al contributo di: 
C C
May 4, 2026
Grazie al contributo di: 
C C

In questo articolo

Feedback sito | Your privacy choices footer linkScelte di privacy | Privacy e condizioni legali | Preferenze cookie | Impostazioni di consenso | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.