Citrix Virtual Apps and Desktops

Migrer la configuration vers Citrix Cloud™

L’outil de configuration automatisée (ACT) permet la migration de la configuration de Citrix Virtual Apps and Desktops™ (stratégies, applications, catalogues, rôles d’administrateur, étendues et autres) depuis un ou plusieurs sites sur site vers Citrix DaaS hébergé sur Citrix Cloud. Il peut également être utilisé pour migrer des informations entre différentes régions ou locataires Cloud.

Cet outil découvre et exporte un ou plusieurs sites sur site sous forme de 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, vous permettant d’atteindre facilement l’état de configuration souhaité.

ACT n’est pas seulement un outil de migration unique. Vous pouvez l’utiliser pour gérer vos opérations cloud quotidiennes, telles que :

  • Automatiser le transfert des comptes cloud de test ou de pré-production vers les comptes cloud de production
  • Sauvegarder et restaurer votre configuration
  • Diviser un environnement cloud en plusieurs clouds

La vidéo suivante de 2 minutes offre une présentation rapide de la configuration automatisée.

Pour plus d’informations sur la configuration automatisée, consultez Preuve de concept : Outil de configuration automatisée sur Tech Zone.

Pour un examen plus approfondi du déplacement de votre déploiement et de la préparation de votre configuration sur site pour la migration, consultez Guide de déploiement : Migration de Citrix Virtual Apps and Desktops du site vers Citrix Cloud sur Tech Zone.

Limitations connues

Prérequis pour la migration de votre configuration

Pour exporter votre configuration depuis Citrix Virtual Apps™ and Desktops, vous avez besoin de :

  • Citrix Virtual Apps and Desktops : version actuelle et son prédécesseur immédiat ou Citrix Virtual Apps and Desktops, XenApp and XenDesktop® LTSR : toutes les versions
  • Une machine jointe à un domaine avec .NET Framework 4.7.2 ou version ultérieure et le SDK Citrix PowerShell. Ceci est automatiquement installé sur le Delivery Controller. (Pour exécuter sur une machine autre que le Delivery Controller sur site, Citrix Studio doit être installé, car Studio installe les modules complémentaires PowerShell corrects. 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 avez besoin de :

  • Une machine ayant accès à Citrix Cloud. Il ne s’agit pas nécessairement d’un Delivery Controller™ ou d’une machine jointe à un domaine.
  • Citrix DaaS provisionné.
  • Un emplacement de ressources actif avec Connector installé et joint au même domaine que la configuration sur site.
  • La connectivité aux sites accédant à Citrix Cloud doit être autorisée et disponible. Pour plus d’informations, consultez Exigences système et de connectivité.

Remarque :

La configuration automatisée ne peut pas être installée sur un système Cloud Connector.

Étapes clés

  1. Téléchargez l’outil de configuration automatisée et examinez les exigences système. Consultez Télécharger la configuration automatisée.
  2. Renseignez le fichier CustomerInfo.yml avec vos valeurs CustomerName, CustomerID et SecretKey générées à partir du portail Citrix Cloud. Consultez Générer l’ID client, l’ID client et la clé secrète et Renseigner le fichier d’informations client.
  3. Si le site sur site contient plusieurs zones, mettez à jour le fichier ZoneMapping.yml pour mapper les zones aux emplacements de ressources Citrix DaaS. Consultez Renseigner le fichier de mappage de zones.
  4. Si le site contient plusieurs connexions d’hébergement, mettez à jour le fichier CvadAcSecurity.yml avec les informations de connexion pour chaque type d’hôte migrant vers Citrix DaaS. S’il n’y a qu’une seule connexion d’hôte, mettez à jour le fichier CvadACSecurity.yml avec les informations de connexion pour la connexion d’hôte. Consultez Mettre à jour le fichier de sécurité pour les connexions d’hôte.
  5. Ouvrez ACT et exportez votre site sur site à l’aide de la commande Export-CvadAcToFile. Consultez Objets de migration pris en charge pour la liste des composants pris en charge pour la migration. Pour plus d’informations sur les étapes d’exportation, consultez Exporter la configuration sur site.
  6. Importez les composants par étapes à l’aide de la commande Merge-CvadAcToSite. Vous pouvez également migrer l’intégralité du site en une seule fois. Assurez-vous de migrer les composants dans l’ordre indiqué dans Ordre de migration des composants. Pour plus d’informations sur les étapes d’importation, consultez Exécuter une importation.
  7. Activez le site cloud. Consultez Activer les sites.

Télécharger la configuration automatisée

Téléchargez et installez l’outil de configuration automatisée depuis Citrix Downloads.

Mettre à niveau la configuration automatisée

Pour éviter les erreurs de fonctionnalité, utilisez toujours la dernière version disponible d’ACT.

Pour connaître la version de votre outil, procédez comme suit :

  1. Double-cliquez sur l’icône Auto Config. Une fenêtre PowerShell apparaît.
  2. Exécutez la commande suivante pour vérifier votre numéro de version.

    Get-CvadAcStatus
    <!--NeedCopy-->
    
  3. Vérifiez la version de votre outil par rapport à la version répertoriée dans Citrix Downloads. La dernière version de l’outil s’y trouve.
  4. Téléchargez et installez la dernière version de l’outil. Vous n’avez pas besoin de désinstaller l’ancienne version pour mettre à niveau la configuration automatisée.

Remarque :

Lorsque vous exécutez des cmdlets pour accéder au cloud dans la configuration automatisée, l’outil vous avertit lorsqu’une nouvelle version est disponible au téléchargement. Pour plus d’informations sur les cmdlets, consultez Cmdlets de l’outil de configuration automatisée.

Générer l’ID client, l’ID client et la clé secrète

Pour migrer le site sur site vers Citrix DaaS, renseignez le fichier CustomerInfo.yml avec l’ID client, l’ID de client et la clé secrète du portail Citrix Cloud.

Pour récupérer l’ID client :

  1. Connectez-vous à votre compte Citrix Cloud et sélectionnez le client.
  2. Cliquez sur l’icône de la grille et sélectionnez Gestion des identités et des accès.
  3. Accédez à Accès API > Clients sécurisés. L’ID client s’affiche sur la page.

Pour récupérer l’ID de client et la clé secrète :

  1. Sur la page Clients sécurisés, saisissez un nom dans la zone. Ce nom permet de différencier plusieurs ID de client et clés secrètes.
  2. Cliquez sur Créer un client pour créer l’ID de client et la clé secrète.
  3. Copiez l’ID de 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 renseigner le fichier CustomerInfo.yml.

Remarque :

  • L’ID de 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 de client et une nouvelle clé secrète doivent être créés.

Renseigner le fichier d’informations client

Le fichier CustomerInfo.yml élimine la nécessité de fournir des paramètres d’informations client à chaque exécution de la cmdlet. Toute information client peut être remplacée à l’aide des paramètres de la cmdlet.

Utilisez la cmdlet New-CvadAcCustomerInfoFile pour créer le fichier CustomerInfo.yml.

Important :

Ne modifiez pas manuellement le fichier CustomerInfo.yml. Cela pourrait entraîner des erreurs de formatage involontaires.

La cmdlet New-CvadAcCustomerInfoFile possède les paramètres obligatoires suivants.

  • CustomerId : ID du client.
  • ClientId : ID de client du client créé sur Citrix Cloud.
  • Secret : clé secrète du client créée 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 à 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
<!--NeedCopy-->

Utilisez la cmdlet Set-CvadAcCustomerInfoFile pour mettre à jour le fichier CustomerInfo.yml. Cette cmdlet ne modifie que l’ID de client.

Set-CvadAcCustomerInfoFile -ClientId C80487EE-7113-49F8-85DD-2CFE30CC398E
<!--NeedCopy-->

Voici un exemple de fichier CustomerInfo.yml.

            # Créé/Mis à jour le 2020/01/29 16:46:47
            CustomerId: ‘markhof123’
            ClientId: ‘6713FEA6-46CC-4F8A-BC71-539F2DDK5384’
            Secret: ‘TwBLaaabbbaaaaaaaaaaw==’
            Environment: Production
            AltRootUrl: ‘’
            StopOnError: False
            AlternateFolder: ‘’
            Locale: ‘fr-fr’
            Editor: ‘C:\Program Files\Notepad++\notepad++.exe’
            Confirm: True
            DisplayLog: True

Renseigner le fichier de mappage de zones

Une zone sur site est l’équivalent de l’emplacement de ressource cloud. Contrairement aux autres composants de site, vous ne pouvez pas importer automatiquement la zone sur site 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 ressource existant.

Si les sites sur site n’ont qu’une seule zone et les sites cloud n’ont qu’un seul emplacement de ressource, l’outil de configuration automatisée établit l’association correcte, éliminant ainsi la nécessité de gérer manuellement le fichier ZoneMapping.yml.

Toutefois, si les sites sur site ont plusieurs zones ou si les sites cloud ont plusieurs emplacements de ressource, mettez à jour manuellement le fichier ZoneMapping.yml pour refléter le mappage correct des zones sur site aux emplacements de ressource cloud.

Le fichier ZoneMapping.yml se trouve dans %HOMEPATH%\Documents\Citrix\AutoConfig. Le contenu du fichier .yml est un dictionnaire où le nom de la zone est la clé et le nom de l’emplacement de ressource est la valeur.

Par exemple, un site Citrix Virtual Apps and Desktops sur site 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 ressource 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 :

Ajoutez un espace entre les deux points et le nom de l’emplacement de ressource. Si des espaces sont utilisés dans le nom de la zone ou de l’emplacement de ressource, mettez le nom entre guillemets.

Mettre à jour le fichier de sécurité pour les connexions d’hôte

Les connexions d’hôte et leurs hyperviseurs associés peuvent être exportées et importées à l’aide d’ACT.

L’ajout d’un hyperviseur à une connexion d’hôte nécessite des informations de sécurité spécifiques au type d’hyperviseur. Ces informations ne peuvent pas être exportées depuis le site local pour des raisons de sécurité. Vous devez fournir manuellement ces informations afin qu’Automated Configuration puisse importer avec succès les connexions d’hôte et les hyperviseurs vers 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 pour le type d’hyperviseur spécifique. Vous devez mettre à jour le fichier CvadAcSecurity.yml avant l’importation vers le site cloud. Les mises à jour de l’administrateur sont conservées lors de plusieurs exportations avec de nouveaux espaces réservés de sécurité ajoutés si nécessaire. Les éléments de sécurité ne sont jamais supprimés. Pour plus d’informations, consultez 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 clair
  • Microsoft Azure
    • ID d’abonnement
    • ID d’application
    • Secret d’application
  • AWS
    • ID de compte de service
    • Secret d’application
    • Région

Considérations de sécurité spéciales

Toutes les informations de sécurité sont saisies en clair. Si le texte en clair n’est pas recommandé, les connexions d’hôte et les hyperviseurs associés peuvent être créés manuellement à l’aide de Studio. Les noms des connexions d’hôte et des hyperviseurs doivent correspondre exactement à leurs équivalents locaux afin que les catalogues de machines qui utilisent les connexions d’hôte puissent être importés avec succès.

Exporter votre configuration Citrix Virtual Apps and Desktops locale

À l’aide d’une commande PowerShell export, vous pouvez exporter votre configuration locale existante et obtenir les fichiers .yml nécessaires. Ces fichiers sont utilisés pour importer votre configuration souhaitée dans Citrix Cloud.

Objets de migration pris en charge

Automated Configuration prend en charge le déplacement de la configuration des composants suivants :

  • Balises
  • Administration déléguée
    • Portées
    • Rôles
  • Connexions d’hôte
    • Un seul pool de ressources
    • Portées d’administration
  • Catalogues de machines
    • Portées d’administration
    • Machines
    • Accès PC distant, physique, en pool, provisionné, MCS, attribué
  • StoreFront™
  • Groupes de mise à disposition
    • Stratégie d’accès
    • Association de portée d’administration
    • Stratégie d’accès aux applications
    • Stratégie d’attribution
    • Stratégie d’autorisation/de bureau
    • Planifications d’alimentation
    • Persistance de session
    • Pré-lancement de session
    • Planifications de redémarrage
    • Balises
  • Groupes d’applications
    • Association de portée d’administration
    • Groupes de mise à disposition
    • Utilisateurs et groupes
  • Applications
    • Dossiers d’applications
    • Icônes
    • Applications
    • FTA configurés par le Broker
    • Balises
  • Stratégies de groupe
  • Préférences de zone utilisateur

Exporter la configuration locale

  1. Double-cliquez sur l’icône Auto Config. Une fenêtre PowerShell apparaît.
  2. Exécutez la commande suivante pour exporter tous les composants. L’exportation de votre configuration locale ne la modifie en aucun cas.

    Export-CvadAcToFile
    <!--NeedCopy-->
    

Après avoir exécuté une cmdlet pour la première fois, un dossier d’exportation contenant les fichiers de configuration .yml et les journaux est créé. Le dossier se trouve à l’emplacement %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 de l’exportation la plus récente.

Remarque :

Si Automated Configuration 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 Automated Configuration à l’aide de l’icône Auto Config.

Si vous rencontrez des erreurs ou des exceptions, consultez la section Correctifs dans le fichier journal.

Importer votre configuration dans Citrix DaaS

Important :

  • Lors de la migration d’un déploiement local vers le cloud, assurez-vous que les GPO de domaine et d’unité d’organisation (OU) qui contiennent les paramètres Citrix sont migrés vers le cloud. Citrix Web Studio™ ne prend pas en charge GPMC et par conséquent, les GPO de domaine et d’unité d’organisation ne sont pas visibles dans Web Studio. Le moteur de stratégie Citrix applique les GPO de domaine et d’unité d’organisation aux VDA et aux 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 des GPO de domaine et d’unité d’organisation sont appliquées à sa session. Cependant, les administrateurs ne peuvent pas voir ces stratégies et paramètres, ce qui pourrait entraîner des confusions.

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 ne 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 Correctifs du fichier journal affiche les dépendances manquantes si une importation ou une fusion échoue.

  1. Balises
    • Aucune pré-dépendance
  2. Administration déléguée
    • Aucune pré-dépendance
  3. Connexions d’hôte
    • Informations de sécurité dans CvadAcSecurity.yml
  4. Catalogues de machines
    • Machines présentes dans Active Directory
    • Connexions d’hôte
    • Balises
  5. StoreFront
  6. Groupes de mise à disposition
    • Machines présentes dans Active Directory
    • Utilisateurs présents dans Active Directory
    • Catalogues de machines
    • Balises
  7. Groupes d’applications
    • Groupes de mise à disposition
    • Balises
  8. Applications
    • Groupes de mise à disposition
    • Groupes d’applications
    • Balises
  9. Stratégies de groupe
    • Groupes de mise à disposition
    • Balises
  10. Préférences de zone utilisateur

Exécuter une importation

  1. Double-cliquez sur l’icône Auto Config. Une fenêtre PowerShell apparaît.
  2. Exécutez la commande suivante pour importer tous les composants.

    Merge-CvadAcToSite
    <!--NeedCopy-->
    

Vérifiez l’état attendu avec le nouvel état actuel. Diverses options d’importation contrôlent si les résultats de l’importation sont identiques ou un sous-ensemble du site sur site.

Après l’exécution de la cmdlet, un dossier d’exportation contenant les fichiers de configuration .yml et les journaux est créé. Le dossier se trouve à l’emplacement %HOMEPATH%\Documents\Citrix\AutoConfig.

Si vous rencontrez des erreurs ou des exceptions, consultez la section Correctifs dans le fichier journal.

Remarque :

Si la configuration automatisée n’est pas installée 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 la configuration automatisée à l’aide de l’icône Auto Config.

Pour revenir à votre configuration Citrix DaaS d’origine, consultez Sauvegarde de votre configuration Citrix DaaS.

-  ### Comprendre l'opération d'importation

Le processus d’importation est conçu pour effectuer des mises à jour précises, n’effectuer que les mises à jour nécessaires et vérifier que toutes les mises à jour ont été correctement effectuées. Les étapes suivantes sont suivies dans toutes les opérations d’importation :

  1. Lisez le fichier .yml exporté (état attendu).
  2. Lisez le cloud (état actuel).
  3. Sauvegardez l’état du cloud avant l’importation dans des fichiers .yml (la sauvegarde préalable peut être restaurée si nécessaire).
  4. Évaluez les différences entre l’état attendu et l’état actuel. Cela détermine les mises à jour à effectuer.
  5. Effectuez les mises à jour.
  6. Relisez le cloud (nouvel état actuel).
  7. Sauvegardez l’état du cloud après l’importation dans des fichiers .yml (la sauvegarde post-importation peut être restaurée si nécessaire).
  8. Comparez le nouvel état actuel avec l’état attendu.
  9. Signalez les 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 sélectivement uniquement des composants ou même uniquement des noms de composants.

  • Les paramètres de composant pris en charge incluent MachineCatalogs, Tags, et d’autres.
  • Les paramètres de nom de composant pris en charge incluent les paramètres IncludeByName et ExcludeByName, et d’autres.

Pour plus d’informations sur les paramètres et leur utilisation, consultez Paramètres de migration granulaire.

Activer les sites

Le Delivery Controller, qu’il soit sur site ou dans le cloud, contrôle des ressources telles que le courtage de bureaux, d’applications et le redémarrage de machines. Des problèmes surviennent 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 sur site vers un site cloud. Il est possible que les Delivery Controllers sur site et cloud gèrent le même ensemble de ressources. Une telle double gestion peut entraîner l’indisponibilité et l’ingérabilité des ressources, et peut être difficile à diagnostiquer.

L’activation de site vous permet de contrôler l’emplacement où le site actif est géré.

L’activation de site est gérée à l’aide du mode de maintenance des groupes de mise à disposition. Les groupes de mise à disposition sont placés en mode de maintenance lorsque le site est inactif. Le mode de maintenance est supprimé des groupes de mise à disposition pour les sites actifs.

L’activation de site n’affecte ni ne gère l’enregistrement des VDA ou les catalogues de machines.

  • Set-CvadAcSiteActiveStateCloud
  • Set-CvadAcSiteActiveStateOnPrem

Toutes les cmdlets prennent en charge le filtrage 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 sélectivement selon les besoins.

Importation et transfert du contrôle vers le cloud

La description suivante est un aperçu général de la manière d’importer et de transférer le contrôle du site sur site vers le site cloud.

  1. Exportez et importez le site sur site vers le cloud. Assurez-vous que le paramètre –SiteActive n’est présent sur aucune des cmdlets d’importation. Le site sur site est actif et le site cloud est inactif. Par défaut, les groupes de mise à disposition du site cloud sont en mode de maintenance.
  2. Vérifiez le contenu et la configuration du cloud.
  3. Pendant les heures creuses, définissez le site sur site comme inactif. Le paramètre –SiteActive doit être absent. Tous les groupes de mise à disposition du site sur site sont en mode de maintenance.
    • Set-CvadAcSiteActiveStateOnPrem
  4. Définissez le site cloud comme actif. Le paramètre –SiteActive doit être présent. Aucun groupe de mise à disposition du site cloud n’est en mode de maintenance.
    • Set-CvadAcSiteActiveStateCloud –SiteActive
  5. Vérifiez que le site cloud est actif et que le site sur site est inactif.

Transférer le contrôle vers le site sur site

Pour transférer le contrôle du site cloud vers le site sur site :

  1. Pendant les heures creuses, définissez le site cloud comme inactif. Tous les groupes de mise à disposition du site cloud sont en mode de maintenance.
    • Set-CvadAcSiteActiveStateCloud
  2. Définissez le site sur site comme actif. Aucun groupe de mise à disposition du site sur site n’est en mode de maintenance.
    • Set-CvadAcSiteActiveStateOnPrem -SiteActive

Informations supplémentaires sur l’activation de site

  • Si aucune machine n’est gérée par l’alimentation et qu’il n’y a pas de planifications de redémarrage (ce qui signifie généralement qu’il n’y a pas non plus de connexions d’hôte), tous les groupes de mise à disposition cloud peuvent être importés comme actifs. Ajoutez -SiteActive à Merge-CvadAcToSite/Import-CvadAcToSite ou exécutez Set-CvadAcSiteActiveStateCloud -SiteActive après l’importation.
  • Si les machines sont gérées par l’alimentation ou s’il existe des planifications de redémarrage, un processus différent est nécessaire. Par exemple, lors du passage du site sur site au cloud dans cette situation, définissez le site sur site comme inactif à l’aide de Set-CvadAcSiteActiveStateOnPrem. Ensuite, définissez le site cloud comme actif à l’aide de Set-CvadAcSiteActiveStateCloud -SiteActive.
  • Les cmdlets Set-CvadAcSiteActiveStateCloud et Set-CvadAcSiteActiveStateOnPrem sont également utilisées pour inverser le processus. Par exemple, exécutez Set-CvadAcSiteActiveStateCloud sans le paramètre -SiteActive, puis exécutez Set-CvadAcSiteActiveStateOnPrem avec le paramètre -SiteActive.

Comprendre la migration des catalogues provisionnés par Machine Creation Services

Remarque :

Cette fonctionnalité est disponible uniquement sur les versions 3.0 et ultérieures. Vérifiez votre version à l’aide de Get-CvadAcStatus dans Automated Configuration.

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 un système d’exploitation serveur, où les applications sont publiées) – il s’agit d’un cas d’utilisation VDI en pool / multi-session
  • Lorsque les modifications apportées à une machine sont conservées après un redémarrage (généralement un système d’exploitation 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 en examinant la valeur « Données utilisateur : » du catalogue.

Remarque :

MCS ne peut pas être sauvegardé depuis le cloud à l’aide d’Automated Configuration.

Catalogues VDI en pool / multi-session

Les catalogues avec « Données utilisateur : Ignorer » sont des catalogues VDI en pool et ne peuvent migrer que l’image principale et la configuration. Les machines virtuelles de ces catalogues ne sont pas migrées. Cela est dû au fait que le cycle de vie de la machine virtuelle est géré par le site d’où vous importez, ce qui signifie qu’à chaque démarrage des machines, leur état peut changer. Cela rend l’importation impossible car les données d’importation des machines virtuelles se désynchronisent rapidement.

Lorsque vous migrez ces catalogues à l’aide de l’outil, celui-ci crée les métadonnées du catalogue et lance la création de l’image principale, mais aucune machine n’est importée.

Étant donné que ce processus peut prendre un certain temps en fonction de la taille de l’image principale, la commande d’importation de l’outil ne fait que démarrer 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 vous auriez de la capacité consommée par votre utilisation sur site.

Tous les autres objets (groupes de mise à disposition, applications, stratégies, etc.) qui utilisent ce catalogue peuvent être importés et n’ont pas besoin d’attendre la création de l’image principale. Une fois le catalogue créé, des 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 :

Étant donné que cette opération importe des détails de bas niveau stockés dans la base de données, ce processus doit être exécuté à partir d’une machine ayant 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 VDI en pool, aucune image n’a besoin d’être créée.

Les VDA doivent être dirigés vers le connecteur pour qu’ils puissent s’enregistrer auprès du cloud.

Reportez-vous à la section Activation des sites pour activer le site cloud, afin que le calendrier de redémarrage, la gestion de l’alimentation et d’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 sur site, vous devez sélectionner conserver la machine virtuelle et le compte AD. Sinon, ils sont supprimés et le site cloud pointerait 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é d’une configuration sur site vers un site cloud, ou de votre configuration cloud vers un autre site cloud, vous devez mettre à jour les balises d’ID de site MCS dans le 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.

Les étapes détaillées sont les suivantes :

  1. Mettez à jour les balises d’ID de 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-->
    

    Ou,

    Set-ProvResourceTags -ProvisioningSchemeName xxxxx  [-VMName <String>] [-VMBatchSize XX] [-ResourceType XX]
    <!--NeedCopy-->
    

Les détails des paramètres sont les suivants :

  • ProvisioningSchemeUid ou ProvisioningSchemeName est un paramètre obligatoire.
  • VMName est un paramètre facultatif. Si aucun VMName n’est spécifié, les balises de toutes les machines virtuelles de ce catalogue de machines sont mises à jour.
  • VMBatchSize est un paramètre facultatif pour diviser toutes les machines virtuelles en lots. Si aucun VMBatchSize n’est spécifié, la valeur par défaut (10) est appliquée. La plage est de 1 à 60.
  • ResourceType peut être l’un des suivants :

    • MachineCatalog : Pour la mise à jour des balises des ressources du catalogue de machines.
    • VirtualMachine : Pour la mise à jour des balises des ressources liées aux machines virtuelles.
    • All : (ResourceType par défaut) : Pour la mise à jour des balises des ressources du catalogue de machines et des ressources liées aux machines virtuelles.