Migrer la configuration vers Citrix Cloud
Pourquoi utiliser la configuration automatisée
Les administrateurs informatiques chargés d’environnements volumineux ou complexes trouvent souvent les migrations fastidieuses. Ils finissent souvent par écrire leurs propres outils pour accomplir cette tâche avec succès, car ils ont tendance à être spécifiques à leurs cas d’utilisation.
Citrix souhaite faciliter ce processus en automatisant le processus de migration à l’aide de l’outil de configuration automatisée. Les administrateurs peuvent facilement tester les configurations actuelles dans Citrix Cloud et profiter des avantages offerts par Citrix DaaS (anciennement Citrix Virtual Apps and Desktops Service) tout en conservant leurs environnements actuels intacts. Il n’y a pas non plus d’impact sur l’utilisateur final, car la configuration automatisée fonctionne de manière transparente en arrière-plan. Ces avantages incluent une charge administrative réduite lorsque Citrix gère une partie du back-end et du plan de contrôle, des mises à jour automatiques et personnalisables des composants Citrix Cloud, etc.
Citrix utilise la configuration standard du secteur comme code pour fournir un mécanisme permettant d’automatiser les processus de migration. La configuration automatisée détecte et exporte un ou plusieurs sites locaux sous la forme d’un ensemble de fichiers de configuration. La configuration de ces fichiers peut ensuite être importée dans Citrix DaaS.
La configuration automatisée permet également aux administrateurs de fusionner plusieurs sites locaux en un seul site, tout en évitant les collisions de noms. Les administrateurs peuvent contrôler si la configuration sur site ou dans le cloud contrôle les ressources.
La configuration automatisée n’est pas seulement un outil de migration ponctuelle, mais elle peut également automatiser votre configuration quotidienne dans Citrix Cloud. Le déplacement de votre configuration Citrix DaaS peut être bénéfique pour de nombreuses raisons :
- Synchronisation de votre site de la phase de test ou de pré-production à la production
- Sauvegarde et restauration de votre configuration
- Atteindre les limites de ressources
- Migration d’une région à une autre
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.
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.
Important :
Pour éviter les erreurs de fonctionnalité, utilisez toujours la dernière version disponible de la configuration automatisée.
Mise à niveau de la configuration automatisée
Lorsque vous exécutez des applets de commande qui accèdent au cloud dans Configuration automatisée, l’outil vous avertit lorsqu’une version plus récente est disponible.
Vous pouvez vous assurer que vous disposez de la dernière version en suivant les étapes ci-dessous :
- 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 - Vérifiez la version de votre outil par rapport à la version répertoriée dans l’alerte ou sur 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 :
L’alerte apparaît chaque fois que vous exécutez une cmdlet qui accède au cloud. Pour plus d’informations sur les applets de commande, consultez Applets de commande de l’outil de configuration automatisée.
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 Présentation de la migration des catalogues provisionnés Machine Creation Services.
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
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
Conditions préalables communes
Voici quelques prérequis communs qui sont nécessaires au bon fonctionnement de la configuration automatisée. Ces conditions préalables sont utilisées à la fois dans les migrations sur site vers cloud et cloud vers cloud.
Génération des ID client et de la clé secrète
Avant de commencer votre migration à l’aide de la configuration automatisée, vous avez besoin de votre ID client Citrix Cloud et vous devez créer un ID client et une clé secrète pour importer votre configuration dans Citrix Cloud. Toutes les applets de commande accédant au cloud nécessitent ces valeurs.
Les étapes suivantes vous permettent de récupérer l’ID client et de créer l’ID client et la clé secrète.
Pour récupérer l’ID client, procédez comme suit :
-
Connectez-vous à votre compte Citrix Cloud et sélectionnez le client.
-
Cliquez sur le menu hamburger, puis sélectionnez Gestion des identités et des accès dans le menu déroulant.
-
L’ID client se trouve sur la page Gestion des identités et des accès.
Pour récupérer l’ID client et la clé secrète :
-
Sur la page Gestion des identités et des accès, cliquez sur l’onglet Accès aux API.
-
Entrez un nom dans la zone. 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.
-
La boîte de dialogue suivante s’affiche lorsque vous avez réussi à créer l’ID client et la clé secrète. Veillez à copier les deux valeurs dans un emplacement sécurisé et de télécharger le fichier .csv contenant ces informations. Le fichier .csv peut être utilisé pour créer le fichier CustomerInfo.yml.
-
L’ID client et la clé secrète sont créés avec succès.
Placez ces valeurs dans un emplacement sécurisé et ne les partagez qu’avec les membres de l’entreprise de confiance qui ont besoin d’accéder à l’outil ou aux API Rest cloud. 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.
Remarque :
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.
Remplissage du fichier d’informations client
L’utilisation du fichier CustomerInfo.yml élimine la nécessité de fournir des paramètres d’informations client lors de l’exécution de chaque applet de commande. Toutes les informations client peuvent être remplacées à l’aide des paramètres de l’applet de commande.
Créez le fichier CustomerInfo.yml à l’aide de l’applet de commande New-CvadAcCustomerInfoFile.
Important :
Ne modifiez pas manuellement le fichier CustomerInfo.yml. Cela peut entraîner des erreurs de mise en forme.
New-CvadAcCustomerInfoFile comporte les paramètres requis suivants.
- CustomerId : ID client.
- ClientId : ID client créé sur Citrix Cloud.
- Secret : secret du client créé sur Citrix Cloud.
New-CvadAcCustomerInfoFile -CustomerId markhof123 -ClientId 6813EEA6-46CC-4F8A-BC71-539F2DAC5984 -Secret TwBLaaaaaaaaaaaaaaaaaw==
Vous pouvez également créer le fichier CustomerInfo.yml à l’aide du 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
Mettez à jour le fichier CustomerInfo.yml à l’aide de l’applet de commande Set-CvadAcCustomerInfoFile. L’applet de commande modifie uniquement l’ID client.
Set-CvadAcCustomerInfoFile -ClientId C80487EE-7113-49F8-85DD-2CFE30CC398E
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
Remplissage du fichier de mappage de zones
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. Elle doit être mappée 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.
Pour les sites locaux n’ayant qu’une zone et les sites cloud qu’un seul emplacement de ressources, l’outil Configuration automatisée établit l’association correcte, éliminant ainsi la nécessité de gérer manuellement le fichier ZoneMapping.yml.
Pour les sites locaux comportant plusieurs zones ou sites cloud ayant plusieurs emplacements de ressources, le fichier ZoneMapping.yml doit être mis à jour manuellement pour refléter le mappage correct des zones locales aux emplacements de ressources cloud. Cette opération doit être effectuée avant de tenter une opération d’importation dans le cloud.
Le fichier ZoneMapping.yml se trouve sous %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 de 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 nouvellement 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 :
Les deux-points et le nom de l’emplacement de ressources doivent être séparés par un espace. Si des espaces sont utilisés dans le nom de la zone ou de l’emplacement des ressources, placez le nom entre guillemets.
Connexions hôte
Les connexions hôtes et les hyperviseurs associés peuvent être exportés et importés à l’aide de la configuration automatisée.
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 sous %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 l’importation dans 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
- Amazon Web Services
- 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.
Activation 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-CvadAcSiteActiveStateCloudSet-CvadAcSiteActiveStateOnPrem
Toutes les applets de commande prennent en charge le ExcludeByName filtrage et IncludeByName. 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
–SiteActiven’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
–SiteActivedoit ê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
–SiteActivedoit ê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.
Transfert du 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
-SiteActiveàMerge-CvadAcToSite/Import-CvadAcToSiteou exécutezSet-CvadAcSiteActiveStateCloud -SiteActiveaprè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, lorsque vous passez d’un 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 à l’aide deSet-CvadAcSiteActiveStateCloud -SiteActive. - Les applets de commande
Set-CvadAcSiteActiveStateCloudetSet-CvadAcSiteActiveStateOnPremsont également utilisées pour inverser le processus. Par exemple, exécutezSet-CvadAcSiteActiveStateCloudsans le paramètre-SiteActive, puis exécutezSet-CvadAcSiteActiveStateOnPremavec le paramètre-SiteActive.
Présentation de la migration des catalogues provisionnés 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-CvadAcStatusdans 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 avec OS de serveur, où les applications sont publiées), il s’agit d’un cas d’utilisation VDI regroupé/multi-session
- 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. Les considérations relatives à la capacité doivent être prises en compte, car votre utilisation sur site consomme de la capacité.
Tous les autres objets (groupes de mise à disposition, applications, stratégies, etc.) qui utilisent ce catalogue peuvent être importés 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 choisir de quitter la machine virtuelle 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 cela, utilisez la commande PowerShell Set-ProvResourceTags. Actuellement, cette fonctionnalité est applicable à Azure.
Voici le détail des étapes :
-
Mettez à jour les balises d’identification du site MCS à partir 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-->Ou
Set-ProvResourceTags -ProvisioningSchemeName xxxxx [-VMName <String>] [-VMBatchSize XX] [-ResourceType XX] <!--NeedCopy-->
Les détails des paramètres sont les suivants :
-
ProvisioningSchemeUidouProvisioningSchemeNameest un paramètre obligatoire. -
VMNameest un paramètre facultatif. Si aucun paramètreVMNamen’est spécifié, les balises de toutes les machines virtuelles de ce catalogue de machines sont mises à jour. -
VMBatchSizeest un paramètre facultatif permettant de diviser toutes les machines virtuelles en lots. Si aucun paramètreVMBatchSizen’est spécifié, la valeur par défaut (10) est appliquée. La plage est comprise entre 1 et 60. -
ResourceTypepeut être l’un des types suivants :-
MachineCatalog: pour mettre à jour les balises des ressources du catalogue de machines. -
VirtualMachine: pour mettre à jour les balises des ressources liées à la VM. -
All: (ResourceType par défaut) pour mettre à jour les balises du catalogue de machines et des ressources associées à la VM.
-
Dans cet article
- Pourquoi utiliser la configuration automatisée
- Télécharger l’outil de configuration automatisée
- Mise à niveau de la configuration automatisée
- Limitations connues
- Objets pris en charge pour la migration
- Ordre de migration des composants
- Conditions préalables communes
- Activation des sites
- Présentation de la migration des catalogues provisionnés Machine Creation Services
- Mettre à jour les balises MCS pour détecter les ressources orphelines après la migration