Migrer la configuration vers Citrix Cloud
L’outil de configuration automatisé (ACT) permet la migration de la configuration de Citrix Virtual Apps and Desktops (stratégies, applications, catalogues, rôles d’administrateur, étendues et autres) d’un ou plusieurs sites locaux vers Citrix DaaS hébergé sur Citrix Cloud. Il peut également être utilisé pour faire migrer des informations entre différentes régions ou locataires Cloud.
Cet outil détecte et exporte un ou plusieurs sites locaux sous la forme d’une collection de fichiers de configuration, que vous pouvez éventuellement modifier. La configuration de ces fichiers peut ensuite être importée dans Citrix DaaS. La migration s’effectue par étapes en exécutant l’outil plusieurs fois, ce qui vous permet d’atteindre facilement l’état de configuration souhaité.
L’ACT n’est pas seulement un outil de migration unique. Vous pouvez l’utiliser pour gérer vos opérations cloud quotidiennes, par exemple pour :
- automatiser le transfert des comptes cloud de test ou intermédiaires vers les comptes cloud de production
- Sauvegarde et restauration de votre configuration
- Diviser un environnement cloud en plusieurs clouds
La vidéo suivante (2 minutes) fournit un aperçu rapide de la configuration automatisée.
Pour plus d’informations sur la configuration automatisée, consultez Proof of Concept: Automated Configuration Tool sur Tech Zone.
Pour en savoir plus sur le déplacement de votre déploiement et la préparation de votre configuration locale pour la migration, consultez Deployment Guide: Migrating Citrix Virtual Apps and Desktops from on-premises to Citrix Cloud sur Tech Zone.
Limitations connues
- Les catalogues de machines provisionnés via Machine Creation Services requièrent une attention particulière. Pour plus d’informations sur MCS, consultez Comprendre la migration des catalogues provisionnés par Machine Creation Services.
Conditions préalables à la migration de votre configuration
Pour exporter votre configuration à partir de Citrix Virtual Apps and Desktops, vous avez besoin de la configuration suivante :
- Citrix Virtual Apps and Desktops : version actuelle et précédente ou Citrix Virtual Apps and Desktops, XenApp et XenDesktop LTSR : toutes les versions
- Une machine jointe au domaine avec .NET Framework 4.7.2 ou version ultérieure et le kit SDK Citrix PowerShell. Ceci est automatiquement installé sur le Delivery Controller. (Pour s’exécuter sur une machine autre que le Delivery Controller local, Citrix Studio doit être installé, car Studio installe les composants logiciels enfichables PowerShell appropriés. Le programme d’installation de Studio se trouve sur le support d’installation de Citrix Virtual Apps and Desktops.)
Pour importer votre configuration dans Citrix DaaS, vous devez effectuer les actions suivantes :
- Une machine avec accès à Citrix Cloud. Il n’est pas nécessaire que ce soit un Delivery Controller ou une machine jointe à un domaine.
- Citrix DaaS provisionné.
- Emplacement de ressources actif, avec Connector installé et joint au même domaine que l’installation locale.
- La connectivité aux sites accédant à Citrix Cloud doit être autorisée et disponible. Pour plus d’informations, consultez la section Configuration requise pour le système et la connectivité.
Remarque
La configuration automatisée ne peut pas être installée sur un système Cloud Connector.
Étapes clés
- Téléchargez l’outil de configuration automatisée et vérifiez la configuration système requise. Consultez Télécharger l’outil de configuration automatisée.
- Remplissez le fichier
CustomerInfo.yml
avec les valeursCustomerName
,CustomerID
etSecretKey
générées à partir du portail Citrix Cloud. Consultez Générer les ID client et la clé secrète et Remplir le fichier d’informations client. - Si le site local contient plusieurs zones, mettez à jour le fichier
ZoneMapping.yml
pour mapper les zones aux emplacements de ressources Citrix DaaS. Consultez Remplir le fichier de mappage de zone. - Si le site contient plusieurs connexions hôte, mettez à jour le fichier
CvadAcSecurity.yml
avec les informations de connexion pour chaque type d’hôte à faire migrer vers Citrix DaaS. S’il n’y a qu’une seule connexion hôte, mettez à jour le fichierCvadACSecurity.yml
avec les informations de connexion relatives à la connexion hôte. Consultez Mettre à jour le fichier de sécurité pour les connexions hôtes. - Ouvrez l’ACT et exportez votre site local à l’aide de la commande
Export-CvadAcToFile
. Consultez Objets de migration pris en charge pour obtenir la liste des composants compatibles avec la migration. Pour plus d’informations sur les étapes d’exportation, consultez Exporter la configuration locale. - Importez les composants par étapes à l’aide de la commande
Merge-CvadAcToSite
. Vous pouvez également faire migrer l’ensemble du site en une seule fois. Assurez-vous de faire migrer les composants dans l’ordre répertorié dans Ordre de migration des composants. Pour plus d’informations sur les étapes d’importation, consultez Exécuter une importation. - Activer le site cloud. Consultez la section Activer les sites.
Télécharger l’outil de configuration automatisée
Téléchargez et installez l’outil de configuration automatisée à partir de Téléchargements Citrix.
Mettre à niveau la configuration automatisée
Pour éviter les erreurs de fonctionnalité, utilisez toujours la dernière version disponible de l’ACT.
Pour connaître la version de l’outil, procédez comme suit :
- Double-cliquez sur l’icône Config automatique. Une fenêtre PowerShell s’affiche.
-
Exécutez la commande suivante pour vérifier votre numéro de version.
Get-CvadAcStatus <!--NeedCopy-->
- Vérifiez la version de l’outil par rapport à la version répertoriée dans Téléchargements Citrix. La dernière version de l’outil se trouve sur cette page.
- Téléchargez et installez la dernière version de l’outil. Il n’est pas nécessaire de désinstaller l’ancienne version pour mettre à niveau Configuration automatisée.
Remarque
Lorsque vous exécutez des applets de commande pour accéder au cloud dans la configuration automatisée, l’outil vous avertit lorsqu’une version plus récente est disponible au téléchargement. Pour plus d’informations sur les applets de commande, consultez Applets de commande de l’outil de configuration automatisée.
Générer les ID client et la clé secrète
Pour faire migrer le site local vers Citrix DaaS, remplissez le fichier CustomerInfo.yml
avec les ID client et la clé secrète du portail Citrix Cloud.
Pour récupérer l’ID client, procédez comme suit :
- Connectez-vous à votre compte Citrix Cloud et sélectionnez le client.
- Cliquez sur l’icône de grille et sélectionnez Gestion des identités et des accès.
- Accédez à Accès aux API > Clients sécurisés. L’identifiant client est affiché sur la page.
Pour récupérer l’ID client et la clé secrète,procédez comme suit :
- Sur la page Clients sécurisés, saisissez un nom dans la case. Ce nom est utilisé pour différencier plusieurs ID client et clés secrètes.
- Cliquez sur Créer un client pour créer l’ID client et la clé secrète.
- Copiez l’ID client et la clé secrète dans un emplacement sécurisé et téléchargez le fichier
.csv
contenant ces informations. Utilisez le fichier.csv
pour remplir le fichierCustomerInfo.yml
.
Remarque
- L’ID client et la clé secrète n’expirent pas. S’ils sont compromis, supprimez-les immédiatement à l’aide de l’icône Corbeille et créez-en de nouveaux.
- La clé secrète ne peut pas être récupérée si elle est perdue ou oubliée ; un nouvel ID client et une clé secrète doivent être créés.
Remplir le fichier d’informations client
Le fichier CustomerInfo.yml
évite de devoir fournir des paramètres d’informations client à chaque exécution de l’applet de commande. Toutes les informations client peuvent être remplacées à l’aide des paramètres de l’applet de commande.
Utilisez l’applet de commande New-CvadAcCustomerInfoFile
pour créer le fichier CustomerInfo.yml
.
Important :
Ne modifiez pas manuellement le fichier
CustomerInfo.yml
. Cela peut entraîner des erreurs de mise en forme.
L’applet de commande New-CvadAcCustomerInfoFile
possède les paramètres requis suivants.
- CustomerId : ID client.
- ClientId : ID client créé sur Citrix Cloud.
- Secret : secret du client créé sur Citrix Cloud.
Exemple :
New-CvadAcCustomerInfoFile -CustomerId markhof123 -ClientId 6813EEA6-46CC-4F8A-BC71-539F2DAC5984 -Secret TwBLaaaaaaaaaaaaaaaaaw==
<!--NeedCopy-->
Vous pouvez également créer le fichier CustomerInfo.yml
en utilisant le paramètre SecurityCsvFileSpec
qui pointe vers le fichier security.csv
téléchargé. Vous devez également spécifier le CustomerID.
New-CvadAcCustomerInfoFile -SecurityCsvFileSpec C:\Users\my_user_name\downloads/security.csv -CustomerId markhof123
<!--NeedCopy-->
Utilisez l’applet de commande Set-CvadAcCustomerInfoFile
pour mettre à jour le fichier CustomerInfo.yml
. L’applet de commande modifie uniquement l’ID client.
Set-CvadAcCustomerInfoFile -ClientId C80487EE-7113-49F8-85DD-2CFE30CC398E
<!--NeedCopy-->
Voici un exemple de fichier 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
Remplir le fichier de mappage de zone
Une zone locale est l’équivalent de l’emplacement des ressources cloud. Contrairement aux autres composants du site, vous ne pouvez pas importer automatiquement la zone locale vers le cloud. Le mappage s’effectue manuellement à l’aide du fichier ZoneMapping.yml
. Des échecs d’importation peuvent se produire si le nom de la zone n’est pas associé à un nom d’emplacement de ressources existant.
Si les sites locaux n’ont qu’une seule zone et que les sites cloud n’ont qu’un seul emplacement de ressources, l’outil de configuration automatisée effectue l’association correcte, éliminant ainsi la nécessité de gérer manuellement le fichier ZoneMapping.yml
.
Cependant, si les sites locaux comportent plusieurs zones ou si les sites cloud ont plusieurs emplacements de ressources, mettez à jour manuellement le fichier ZoneMapping.yml
pour refléter le mappage correct des zones locales aux emplacements de ressources cloud.
Le fichier ZoneMapping.yml
se trouve dans %HOMEPATH%\Documents\Citrix\AutoConfig
. Le contenu du fichier .yml
est un dictionnaire avec le nom de la zone comme clé et le nom de l’emplacement des ressources comme valeur.
À titre d’exemple, un site Citrix Virtual Apps and Desktops local avec une zone principale appelée « Zone-1 » et une zone secondaire appelée « Zone-2 » est migré vers un déploiement Citrix DaaS avec deux emplacements de ressources cloud récemment créés appelés « Cloud-RL-1 » et « Cloud-RL-2 ». Dans ce cas, le fichier ZoneMapping.yml serait configuré comme suit :
Zone-1: Cloud-RL-1
Zone-2: Cloud-RL-2
Remarque
Ajoutez un espace entre les deux points et le nom de l’emplacement des ressources. Si des espaces sont utilisés dans le nom de la zone ou de l’emplacement des ressources, placez le nom entre guillemets.
Mettre à jour le fichier de sécurité pour les connexions hôtes
Les connexions hôtes et leurs hyperviseurs associés peuvent être exportés et importés à l’aide de l’‘ACT.
L’ajout d’un hyperviseur à une connexion hôte nécessite des informations de sécurité spécifiques au type d’hyperviseur. Ces informations ne peuvent pas être exportées à partir du site local pour des raisons de sécurité. Vous devez fournir les informations manuellement afin que l’outil de configuration automatisée puisse importer avec succès les connexions hôte et les hyperviseurs sur le site cloud.
Le processus d’exportation crée le fichier CvadAcSecurity.yml
dans %HOMEPATH%\Documents\Citrix\AutoConfig
contenant des espaces réservés pour chaque élément de sécurité nécessaire au type d’hyperviseur spécifique. Vous devez mettre à jour le fichier CvadAcSecurity.yml
avant de l’importer sur le site cloud. Les mises à jour de l’administrateur sont conservées pour plusieurs exportations avec de nouveaux espaces réservés de sécurité ajoutés au besoin. Les éléments de sécurité ne sont jamais supprimés. Pour plus d’informations, voir Mettre à jour manuellement le fichier CvadAcSecurity.yml
HostConn1:
ConnectionType: XenServer
UserName: root
PasswordKey: rootPassword
HostCon2:
ConnectionType: AWS
ApiKey: 78AB6083-EF60-4D26-B2L5-BZ35X00DA5CH
SecretKey: TwBLaaaaaaaaaaaaaaaaaw==
Region: East
Informations de sécurité par hyperviseur
La liste suivante répertorie les informations de sécurité requises pour chaque type d’hyperviseur.
- XenServer, Hyper-V, VMware
- Nom d’utilisateur
- Mot de passe en texte clair
- Microsoft Azure
- ID d’abonnement
- ID de l’application
- Secret d’application
- AWS
- ID du compte de service
- Secret d’application
- Région
Considérations de sécurité particulières
Toutes les informations de sécurité sont saisies sous forme de texte clair. Si le texte en clair n’est pas recommandé, les connexions hôtes et les hyperviseurs associés peuvent être créés manuellement à l’aide de Studio. Les noms de connexions hôte et d’hyperviseur doivent correspondre exactement à leurs homologues locaux afin que les catalogues de machines qui utilisent les connexions hôtes soient importés avec succès.
Exporter une configuration locale Citrix Virtual Apps and Desktops
Vous pouvez utiliser une commande PowerShell export
pour exporter votre configuration locale existante et obtenir les fichiers .yml
nécessaires. Ces fichiers sont utilisés pour importer la configuration souhaitée dans Citrix Cloud.
Objets pris en charge pour la migration
La configuration automatisée prend en charge le déplacement de la configuration des composants suivants :
- Balises
- Administrateur délégué
- Étendues
- Rôles
- Connexions hôte
- Un pool de ressources unique
- Étendues d’administration
- Catalogues de machines
- Étendues d’administration
- Machines
- Accès PC distant, physiques, groupées, provisionnées, MCS, attribuées
- StoreFront
- Groupes de mise à disposition
- Stratégie d’accès
- Association des étendues administrateur
- Stratégie d’accès aux applications
- Stratégie d’attribution
- Stratégie de droit/bureau
- Programmations d’alimentation
- Attente de session
- Pré-démarrage de session
- Programmes de redémarrage
- Balises
- Groupes d’applications
- Association des étendues administrateur
- Groupes de mise à disposition
- Utilisateurs et groupes
- Applications
- Dossiers d’application
- Icônes
- Applications
- FTA configurées par le broker
- Balises
- Stratégies de groupe
- Préférences de zone utilisateur
Exporter la configuration locale
- Double-cliquez sur l’icône Config automatique. Une fenêtre PowerShell s’affiche.
-
Exécutez la commande suivante pour exporter tous les composants. L’exportation de votre configuration locale ne la modifie en aucune façon.
Export-CvadAcToFile <!--NeedCopy-->
Après avoir exécuté une applet de commande pour la première fois, un dossier d’exportation contenant les journaux et les fichiers .yml
de configuration créé. Le dossier se trouve sous %HOMEPATH%\Documents\Citrix\AutoConfig
. Chaque exportation successive crée un sous-dossier. Le dossier parent %HOMEPATH%\Documents\Citrix\AutoConfig
contient toujours les fichiers exportés au cours de l’exportation la plus récente.
Remarque
Si l’outil de configuration automatisée n’est pas installé sur le Delivery Controller, exécutez
import-module Citrix.AutoConfig.Commands
avant d’utiliser l’outil via PowerShell. Cette étape n’est pas nécessaire si vous ouvrez Configuration automatisée à l’aide de l’icône Config automatique.
Si vous rencontrez des erreurs ou des exceptions, consultez la section Fixups du fichier journal.
Importer la configuration dans Citrix DaaS
Important :
- Lors de la migration d’un déploiement local vers le cloud, assurez-vous que les objets de stratégie de groupe de domaine et d’unité d’organisation contenant les paramètres Citrix sont migrés vers le cloud. Citrix Web Studio n’étant pas compatible avec GPMC, les objets de stratégie de groupe de domaine et d’unité d’organisation ne sont pas visibles dans la console Web Studio. Le moteur de stratégie Citrix applique les objets de stratégie de groupe de domaine et d’unité d’organisation sur les VDA et les utilisateurs qui se trouvent dans les domaines et les unités d’organisation. Après s’être connecté à un VDA, un utilisateur peut constater que les stratégies du domaine et des GPO de l’unité d’organisation sont appliquées à sa session. Cependant, les administrateurs ne peuvent pas voir ces stratégies et paramètres, ce qui peut prêter à confusion.
Ordre de migration des composants
Les composants et leurs dépendances sont répertoriés ici. Les dépendances d’un composant doivent être en place avant qu’il puisse être importé ou fusionné. Si une dépendance est manquante, cela peut entraîner l’échec de la commande d’importation ou de fusion. La section Fixups du fichier journal affiche les dépendances manquantes en cas d’échec d’une importation ou d’une fusion.
- Balises
- Aucune pré-dépendance
- Administrateur délégué
- Aucune pré-dépendance
- Connexions hôte
- Informations de sécurité dans CvadAcSecurity.yml
- Catalogues de machines
- Machines présentes dans Active Directory
- Connexions hôte
- Balises
- StoreFront
- Groupes de mise à disposition
- Machines présentes dans Active Directory
- Utilisateurs présents dans Active Directory
- Catalogues de machines
- Balises
- Groupes d’applications
- Groupes de mise à disposition
- Balises
- Applications
- Groupes de mise à disposition
- Groupes d’applications
- Balises
- Stratégies de groupe
- Groupes de mise à disposition
- Balises
- Préférences de zone utilisateur
Exécuter une importation
- Double-cliquez sur l’icône Config automatique. Une fenêtre PowerShell s’affiche.
-
Exécutez la commande suivante pour importer tous les composants.
Merge-CvadAcToSite <!--NeedCopy-->
Comparez l’état attendu avec le nouvel état actuel. Diverses options d’importation contrôlent si les résultats d’importation sont identiques ou un sous-ensemble du site local.
Après avoir exécuté l’applet de commande, un dossier d’exportation contenant les journaux et les fichiers .yml
de configuration est créé. Le dossier se trouve sous %HOMEPATH%\Documents\Citrix\AutoConfig
.
Si vous rencontrez des erreurs ou des exceptions, consultez la section Fixups du fichier journal.
Remarque
Si l’outil de configuration automatisée n’est pas installé sur le Delivery Controller, exécutez
import-module Citrix.AutoConfig.Commands
avant d’utiliser l’outil via PowerShell. Cette étape n’est pas nécessaire si vous ouvrez Configuration automatisée à l’aide de l’icône Config automatique.
Pour revenir à votre configuration Citrix DaaS d’origine, consultez Sauvegarde de la configuration Citrix DaaS.
Comprendre l’opération d’importation
Le processus d’importation est conçu pour effectuer les mises à jour appropriées, appliquer uniquement les mises à jour nécessaires et vérifier que toutes les mises à jour ont été correctement effectuées. Vous trouverez ci-dessous les étapes de toutes les opérations d’importation :
- Consultez le fichier .yml exporté (état attendu).
- Consultez le cloud (état actuel).
- Sauvegardez l’état du cloud avant importation dans les fichiers .yml (la pré-sauvegarde peut être restaurée si nécessaire).
- Évaluez les différences entre l’état attendu et l’état actuel. Cela détermine les mises à jour à effectuer.
- Effectuez les mises à jour.
- Consultez de nouveau le cloud (nouvel état actuel).
- Sauvegardez l’état du cloud post-importation dans les fichiers .yml (la post-sauvegarde peut être restaurée si nécessaire).
- Comparez le nouvel état actuel avec l’état attendu.
- Générez un rapport des résultats de la comparaison.
Migration granulaire
Important :
Pour plus d’informations sur l’ordre de migration des composants, consultez Ordre de migration des composants.
Vous pouvez migrer de manière sélective des composants uniquement ou même des noms de composants uniquement.
- Les paramètres de composants pris en charge incluent
MachineCatalogs
,Balises
et plus encore. - Les paramètres de nom de composant pris en charge incluent, entre autres, les paramètres
IncludeByName
etExcludeByName
.
Pour plus d’informations sur les paramètres et leur utilisation, consultez la rubrique Paramètres de migration granulaire.
Activer des sites
Le Delivery Controller dans les sites locaux et dans le cloud contrôle les ressources telles que la négociation des bureaux, des applications et le redémarrage des machines. Des problèmes se produisent lorsqu’un ensemble commun de ressources est contrôlé par deux sites ou plus. Une telle situation peut se produire lors de la migration d’un site local vers un site cloud. Il est possible pour les Delivery Controller locaux et cloud de gérer le même ensemble de ressources. Avec une telle double gestion, les ressources peuvent devenir indisponibles et ingérables, ce qui peut être difficile à diagnostiquer.
L’activation de site vous permet de contrôler l’endroit où le site actif est contrôlé.
L’activation du site est gérée en utilisant le mode de maintenance du groupe de mise à disposition Les groupes de mise à disposition sont placés en mode maintenance lorsque le site est inactif. Le mode de maintenance est supprimé des groupes de mise à disposition pour les sites actifs.
L’activation du site n’affecte pas et ne gère pas l’enregistrement des VDA ni les catalogues de machines.
Set-CvadAcSiteActiveStateCloud
Set-CvadAcSiteActiveStateOnPrem
Toutes les applets de commande prennent en charge le filtrage avec IncludeByName
et ExcludeByName
. Ce paramètre vous permet de sélectionner les groupes de mise à disposition dont le mode de maintenance peut être modifié. Les groupes de mise à disposition peuvent être modifiés de manière sélective si nécessaire.
Importation et transfert du contrôle vers le cloud
Vous trouverez ci-dessous une description générale sur la façon d’importer et de transférer le contrôle du site local vers le site cloud.
- Exportez et importez le site local dans le cloud. Assurez-vous que le paramètre
–SiteActive
n’est présent sur aucune des applets de commande d’importation. Le site local est actif et le site cloud inactif. Par défaut, les groupes de mise à disposition de sites cloud sont en mode de maintenance. - Vérifiez le contenu et la configuration du cloud.
- Pendant les heures creuses, définir le site local sur inactif. Le paramètre
–SiteActive
doit être absent. Tous les groupes de mise à disposition sur site sont en mode de maintenance.Set-CvadAcSiteActiveStateOnPrem
- Définissez le site cloud sur actif. Le paramètre
–SiteActive
doit être présent. Aucun groupe de mise à disposition de site cloud n’est en mode de maintenance.Set-CvadAcSiteActiveStateCloud –SiteActive
- Vérifiez que le site cloud est actif et que le site local est inactif.
Transférer le contrôle vers le site local
Pour transférer le contrôle du site cloud vers le site local :
- Pendant les heures creuses, définissez le site cloud sur inactif. Tous les groupes de mise à disposition de sites cloud sont en mode de maintenance.
Set-CvadAcSiteActiveStateCloud
- Définissez le site local sur actif. Aucun groupe de mise à disposition local n’est en mode de maintenance.
Set-CvadAcSiteActiveStateOnPrem -SiteActive
Informations supplémentaires sur l’activation du site
- Si l’alimentation d’aucune machine n’est gérée et qu’il n’y a pas de programme de redémarrage (ce qui signifie généralement qu’il n’y a pas de connexion hôte non plus), tous les groupes de mise à disposition cloud peuvent être importés comme actifs. Ajoutez le paramètre
-SiteActive
àMerge-CvadAcToSite
/Import-CvadAcToSite
ou exécutezSet-CvadAcSiteActiveStateCloud -SiteActive
après l’importation. - Si l’alimentation des machines est gérée ou si des redémarrages sont programmés, un processus différent est nécessaire. Par exemple, lors du passage du site local au cloud dans cette situation, définissez le site local sur inactif à l’aide de
Set-CvadAcSiteActiveStateOnPrem
. Ensuite, définissez le site cloud sur actif en utilisantSet-CvadAcSiteActiveStateCloud -SiteActive
. - Les applets de commande
Set-CvadAcSiteActiveStateCloud
etSet-CvadAcSiteActiveStateOnPrem
sont également utilisées pour inverser le processus. Par exemple, exécutezSet-CvadAcSiteActiveStateCloud
sans le paramètre-SiteActive
, puis exécutezSet-CvadAcSiteActiveStateOnPrem
avec le paramètre-SiteActive
.
Comprendre la migration des catalogues provisionnés par Machine Creation Services
Remarque
Cette fonctionnalité n’est disponible que sur les versions 3.0 et ultérieures. Vérifiez votre version en utilisant
Get-CvadAcStatus
dans la configuration automatisée.
Les catalogues Machine Creation Services (MCS) créent deux types de catalogues différents :
- Lorsque les modifications apportées à une machine sont perdues ou annulées (généralement le système d’exploitation du serveur, où les applications sont publiées), il s’agit d’un cas d’utilisation VDI mutualisé/multisession
- Lorsque les modifications apportées à une machine sont conservées lors du redémarrage (généralement OS client avec un utilisateur dédié), il s’agit d’un cas d’utilisation VDI statique
Le type de catalogue peut être confirmé dans le nœud de catalogue de Citrix Studio et en examinant la valeur « Données utilisateur » du catalogue.
Remarque
MCS ne peut pas être sauvegardé depuis le cloud à l’aide de la configuration automatisée.
Catalogues VDI et multi-sessions regroupés
Les catalogues avec la valeur « Données utilisateur : Abandonner » sont des catalogues VDI regroupés et ne peuvent migrer que l’image principale et la configuration. Les machines virtuelles de ces catalogues ne sont pas migrées. Cela s’explique par le fait que le cycle de vie de la machine virtuelle est maintenu par le site à partir duquel vous importez, ce qui signifie que chaque fois que les machines sont allumées, leur état peut changer. Cela rend l’importation impossible car les données d’importation des machines virtuelles sont rapidement désynchronisées.
Lorsque vous migrez ces catalogues à l’aide de l’outil, il crée des métadonnées de catalogue et lance la création de l’image principale, mais aucune machine n’est importée.
Comme ce processus peut prendre un certain temps à être créé en fonction de la taille de l’image principale, la commande d’importation de l’outil démarre uniquement la création du catalogue MCS et n’attend pas qu’elle se termine. Une fois l’importation terminée, surveillez la progression de la création du catalogue à l’aide de Studio dans le déploiement cloud.
Une fois l’image principale créée, vous pouvez provisionner des machines. Tenez compte des considérations de capacité, car votre utilisation locale consommerait des capacités.
Vous pouvez importer tous les divers autres objets (groupes de mise à disposition, applications, stratégies, etc.) qui utilisent ce catalogue sans attendre la création de l’image principale. Lorsque la création du catalogue est terminée, les machines peuvent être ajoutées au catalogue importé, puis les utilisateurs peuvent lancer leurs ressources.
Remarque
Utilisez les mêmes commandes disponibles dans l’outil pour migrer les catalogues et tous les autres objets.
Catalogues VDI statiques
Remarque
Comme cette opération importe des détails de bas niveau qui sont stockés dans la base de données, ce processus doit être exécuté à partir d’une machine disposant d’un accès à la base de données.
Les catalogues VDI statiques migrent l’image principale, les configurations et toutes les machines virtuelles. Contrairement au cas d’utilisation de VDI regroupés, aucune image n’a besoin d’être créée.
Les VDA doivent être dirigés vers le connecteur pour pouvoir s’enregistrer dans le cloud.
Reportez-vous à la section Activation des sites pour activer le site cloud, afin que la planification du redémarrage, la gestion de l’alimentation et les autres éléments soient contrôlés par le cloud.
Une fois la migration terminée, si vous souhaitez supprimer ce catalogue de votre site local, vous devez sélectionner quitter la VM et le compte AD. Sinon, ils sont supprimés et le site cloud pointe vers la machine virtuelle supprimée.
Mettre à jour les balises MCS pour détecter les ressources orphelines après la migration
Après avoir migré une configuration locale vers un site cloud ou votre configuration cloud vers un autre site cloud, vous devez mettre à jour les balises d’identification du site MCS en cas de machines virtuelles persistantes afin que les ressources orphelines puissent être détectées correctement. Pour ce faire, utilisez la commande PowerShell Set-ProvResourceTags
. Actuellement, cette fonctionnalité est applicable à Azure.
Voici le détail des étapes :
-
Mettez à jour les balises d’identité du site MCS du nouveau site Citrix à l’aide de la commande PowerShell
Set-ProvResourceTags
. Par exemple :Set-ProvResourceTags -ProvisioningSchemeUid xxxxx [-VMName <String>] [-VMBatchSize XX] [-ResourceType XX] <!--NeedCopy-->
Or,
Set-ProvResourceTags -ProvisioningSchemeName xxxxx [-VMName <String>] [-VMBatchSize XX] [-ResourceType XX] <!--NeedCopy-->
Les détails des paramètres sont les suivants :
-
ProvisioningSchemeUid
ouProvisioningSchemeName
est un paramètre obligatoire. -
VMName
est un paramètre facultatif. Si aucune valeurVMName
n’est spécifiée, les balises de toutes les machines virtuelles de ce catalogue sont mises à jour. -
VMBatchSize
est un paramètre facultatif pour diviser toutes les machines virtuelles en lots. Si aucune valeurVMBatchSize
n’est spécifiée, la valeur par défaut (10) est appliquée. La plage de valeurs va de 1 à 60. -
ResourceType
peut être l’une des valeurs suivantes :-
MachineCatalog
: pour mettre à jour les balises des ressources du catalogue de machines. -
VirtualMachine
: pour mettre à jour les balises des ressources liées aux VM. -
Tous
: (type de ressource par défaut) : pour mettre à jour les balises du catalogue de machines et des ressources liées aux VM.
-
Dans cet article
- Limitations connues
- Conditions préalables à la migration de votre configuration
- Étapes clés
- Télécharger l’outil de configuration automatisée
- Mettre à niveau la configuration automatisée
- Générer les ID client et la clé secrète
- Remplir le fichier de mappage de zone
- Mettre à jour le fichier de sécurité pour les connexions hôtes
- Exporter une configuration locale Citrix Virtual Apps and Desktops
- Importer la configuration dans Citrix DaaS
- Activer des sites
- Comprendre la migration des catalogues provisionnés par Machine Creation Services
- Mettre à jour les balises MCS pour détecter les ressources orphelines après la migration