Migrer XenApp 6.x

Important :

La migration déplace les données depuis déploiement antérieur vers une version plus récente. Le processus comprend l’installation de composants plus récents et la création d’un nouveau site, l’exportation de données à partir de l’ancienne batterie, puis l’importation des données vers le nouveau site.

Des scripts de migration Open Source sont disponibles à l’adresse https://github.com/citrix/xa65migrationtool. Toutefois, Citrix ne prend pas en charge ces scripts.

Le reste de cet article contient des informations qui peuvent être utilisées comme référence avec les scripts de migration open source.

Introduction

Vous pouvez utiliser l’outil de migration décrit dans cet article pour migrer de XenApp 6.x vers XenApp 7.6. Vous pouvez ensuite passer de XenApp 7.6 à une version LTSR prise en charge ou à la version actuelle de Citrix Virtual Apps and Desktops ; voir Mettre un déploiement à niveau.

Pour de plus amples informations sur les modifications apportées à l’architecture, aux composants et aux fonctionnalités pour les versions 7.x, consultez Modifications apportées dans la version 7.x.

Outil de migration XenApp 6.x

L’outil de migration XenApp 6.x est une collection de scripts PowerShell contenant des applets de commande qui migrent une stratégie et des données de batterie XenApp 6.x (6.0 ou 6.5). Sur le serveur de Controller XenApp 6.x, vous pouvez exécuter des applets de commande d’exportation qui collectent ces données dans des fichiers XML. Ensuite, depuis le Controller XenApp 7.6, exécutez les applets de commande d’importation qui créent des objets à l’aide des données collectées au cours de l’exportation.

La séquence suivante résume le processus de migration ; des détails sont fournis plus tard.

1. Sur un Controller XenApp 6.0 ou 6.5 :
   1. Importez les modules d’exportation PowerShell.
   2. Exécuter les applets de commande d’exportation pour exporter des stratégies et/ou des données de batterie vers les fichiers XML.
2. Copiez les fichiers XML (et le dossier d’icônes si vous choisissez de ne pas les incorporer dans les fichiers XML lors de l’exportation) dans le Controller XenApp 7.6.
3. Sur un Controller XenApp 7.6 :
   1. Importez les modules d’importation du PowerShell.
   2. Exécutez les applets de commande d’importation pour importer la stratégie et/ou les données de la batterie de serveurs (applications), à l’aide des fichiers XML en entrée.
4. Terminez les étapes de post-migration.

Avant d’exécuter la migration, vous pouvez exporter vos paramètres XenApp 6.x, puis effectuer une importation de l’aperçu sur le site XenApp 7.6. L’aperçu identifie des points d’échec possibles pour vous permettre de résoudre les problèmes avant de procéder à l’importation elle-même. Par exemple, un aperçu peut détecter qu’une application du même nom existe déjà dans le nouveau site XenApp 7.6. Vous pouvez également utiliser les fichiers journaux générés à partir de l’aperçu en tant que guide de migration.

Sauf spécification contraire, le terme 6.x fait référence à XenApp 6.0 ou 6.5.

Pack outil de migration

L’outil de migration contient deux packs séparés et indépendants :

• ReadIMA : contient les fichiers utilisés pour exporter des données depuis votre batterie XenApp 6.x, plus les modules partagés.

  Module ou fichier	Description
  ExportPolicy.psm1	Module de script PowerShell pour l’exportation de stratégies XenApp 6.x vers un fichier XML.
  ExportXAFarm.psm1	Module de script PowerShell pour l’exportation de paramètres de batterie XenApp 6.x vers un fichier XML.
  ExportPolicy.psd1	Fichier manifeste PowerShell pour module de script ExportPolicy.psm1.
  ExportXAFarm.psd1	Fichier manifeste PowerShell pour module de script ExportXAFarm.psm1.
  LogUtilities.psm1	Module de script PowerShell partagé qui contient des fonctions de journalisation.
  XmlUtilities.psd1	Fichier manifeste PowerShell pour le module de script XmlUtilities.psm1.
  XmlUtilities.psm1	Module de script PowerShell partagé qui contient les fonctions XML.

• ImportFMA : contient les fichiers utilisés pour importer des données vers votre batterie XenApp 7.6, plus les modules partagés.

  Module ou fichier	Description
  ImportPolicy.psm1	Module de script PowerShell pour l’importation de stratégies vers XenApp 7.6
  ImportXAFarm.psm1	Module de script PowerShell pour l’importation des applications vers XenApp 7.6.
  ImportPolicy.psd1	Fichier manifeste PowerShell pour module de script ImportPolicy.psm1.
  ImportXAFarm.psd1	Fichier manifeste PowerShell pour module de script ImportXAFarm.psm1.
  PolicyData.xsd	Schéma XML pour les données de stratégie.
  XAFarmData.xsd	Schéma XML pour les données de batterie XenApp.
  LogUtilities.psm1	Module de script PowerShell partagé qui contient des fonctions de journalisation.
  XmlUtilities.psd1	Fichier manifeste PowerShell pour le module de script XmlUtilities.psm1.
  XmlUtilities.psm1	Module de script PowerShell partagé qui contient les fonctions XML.

Limitations

• Les paramètres de stratégie ne sont pas tous importés ; veuillez consulter la section Paramètres de stratégie non importés. Les paramètres qui ne sont pas pris en charge sont ignorés et affichés dans le fichier journal.
• Bien que tous les détails d’application soient collectés dans le fichier XML de sortie lors de l’opération d’exportation, seules les applications installées sur le serveur sont importées dans le site XenApp 7.6. Les bureaux, le contenu et la plupart des applications publiés livrés en streaming ne sont pas pris en charge (voir les paramètres de l’applet de commande Import-XAFarm dans Étapes détaillées : importer les données pour les exceptions).
• Les serveurs d’applications ne sont pas importés.
• La plupart des propriétés d’application ne sont pas importées en raison des différences entre les technologies XenApp 6.x Independent Management Architecture (IMA) et XenApp 7.6 FlexCast Management Architecture (FMA) ; voir Mappage des propriétés d’application.
• Un groupe de mise à disposition est créé lors de l’importation. Voir Utilisation avancée pour plus de détails sur l’utilisation des paramètres pour filtrer les éléments importés.
• Seuls les paramètres de stratégie Citrix créés avec la console de gestion AppCenter sont importés, les paramètres de stratégie Citrix créés avec les Objets de stratégie de groupe (GPO) Windows ne sont pas importés.
• Les scripts de migration sont uniquement conçus pour les migrations de XenApp 6.x à XenApp 7.6.
• Les dossiers imbriqués contenant plus de cinq niveaux ne sont pas pris en charge par Studio et ne seront pas importés. Si votre structure de dossier d’applications contient plus de cinq niveaux, réduisez le nombre de dossiers imbriqués avant l’importation.

Considérations de sécurité

Les fichiers XML créés par les scripts d’exportation peuvent contenir des informations confidentielles sur votre environnement et votre organisation, telles que des noms d’utilisateurs, des noms de serveur et autres données de batteries, d’applications et de configuration de stratégies XenApp. Stockez et gérez ces fichiers dans des environnements sécurisés.

Lisez attentivement les fichiers XML avant de les utiliser comme entrée pour l’importation des stratégies et des applications pour vous assurer qu’ils ne contiennent pas de modifications non autorisées.

Les attributions des objets de stratégie (anciennement connus sous le nom de filtres de stratégie) contrôlent la manière dont les stratégies sont appliquées. Après avoir importé les stratégies, vérifiez l’attribution des objets de chaque stratégie pour vous assurer qu’il n’existe aucune faille de sécurité résultant de l’importation. Les différents groupes d’utilisateurs, d’adresses IP ou de noms de client peuvent être appliqués à la stratégie après l’importation. Les paramètres autoriser/refuser peuvent avoir différentes significations après l’importation.

Journalisation et gestion des erreurs

Les scripts fournissent une journalisation complète qui effectue le suivi de toutes les exécutions de l’applet de commande, des messages d’information, des résultats d’exécution de l’applet de commande, des avertissements et des erreurs.

• L’utilisation de la plupart des applets de commande PowerShell Citrix est journalisée. Toutes les applets de commande PowerShell des scripts d’importation qui créent de nouveaux objets de site sont journalisées.
• La progression de l’exécution du script est journalisée, y compris les objets en cours de traitement.
• Les actions principales qui affectent l’état du flux sont journalisées, y compris les flux effectués à partir de la ligne de commande.
• Tous les messages imprimés dans la console sont journalisés, y compris les avertissements et les erreurs.
• Chaque ligne est horodatée à la milliseconde près.

Citrix vous recommande de spécifier un fichier journal lorsque vous exécutez chacune des applets de commande d’importation et d’exportation.

Si vous ne spécifiez pas un nom de fichier journal, celui-ci est stocké dans le dossier de base de l’utilisateur actuel (spécifié dans la variable $HOME de PowerShell) si ce dossier existe ; sinon, il est placé dans le dossier d’exécution du script courant. Le nom de journal par défaut est « XFarmAAAAMMJJHHmmSS-xxxxxx » où les six derniers chiffres constituent un nombre aléatoire.

Par défaut, toutes les informations de progression sont affichées. Pour supprimer l’affichage, spécifiez le paramètre NoDetails dans l’applet de commande d’exportation et d’importation.

En général, un script arrête l’exécution lorsqu’une erreur est détectée, et vous pouvez réexécuter l’applet de commande après la suppression des conditions d’erreurs.

Les conditions qui ne sont pas considérées comme des erreurs sont journalisées ; la plupart sont considérées comme des avertissements et l’exécution du script continue. Par exemple, des types d’applications non pris en charge sont considérés comme des avertissements et ne sont pas importés. Les applications qui existent déjà dans le site XenApp 7.6 ne sont pas importées. Les paramètres de stratégie qui sont déconseillés dans XenApp 7.6 ne sont pas importés.

La migration des scripts utilise la plupart des applets de commande PowerShell, et toutes les erreurs possibles peuvent ne pas être journalisées. Pour de plus amples informations sur la journalisation, utilisez les fonctionnalités de journalisation du PowerShell. Par exemple, les transcriptions du PowerShell journalisent tout ce qui est imprimé à l’écran. Pour plus d’informations, consultez l’aide des applets de commande Start-Transcript et Stop-Transcript.

Configuration requise, préparation et meilleures pratiques

Pour effectuer la migration, vous devez utiliser le Kit de développement logiciel de Citrix XenApp 6.5. Téléchargez ce SDK à partir de https://www.citrix.com/downloads/xenapp/sdks/powershell-sdk.html.

Consultez la totalité de cet article avant de commencer une migration.

Vous devez connaître les concepts de base sur la stratégie d’exécution, les modules, les applets de commande et les scripts PowerShell. Bien que des connaissances complètes liées aux scripts ne soient pas requises, vous devez comprendre les applets de commande que vous exécutez. Utilisez l’applet de commande Get-Help pour afficher l’aide de chaque applet de commande de migration avant de l’exécuter. Par exemple : Get-Help -full Import-XAFarm.

Spécifiez un fichier journal sur la ligne de commande et vérifiez toujours le fichier journal après l’exécution d’une applet de commande. Si un script échoue, vérifiez et corrigez les erreurs dans le fichier journal, puis réexécutez l’applet de commande.

À savoir

• Pour optimiser la mise à disposition d’applications pendant l’exécution de deux déploiements (la batterie XenApp 6.x et le nouveau site XenApp 7.6), vous pouvez regrouper les deux déploiements dans StoreFront ou l’Interface Web. Consultez la documentation eDocs pour votre version de StoreFront ou de l’Interface.

• Les données de l’icône d’application sont gérées de deux manières différentes :

  • si vous spécifiez le paramètre EmbedIconData dans l’applet de commande Export-XAFarm, les données de l’icône d’application exportées sont incorporées dans le fichier XML de sortie.

  • Si vous ne spécifiez pas le paramètre EmbedIconData dans l’applet de commande Export-XAFarm, les données de l’icône d’application exportées sont stockées dans un dossier nommé en ajoutant la chaîne « -icons » au nom de base du fichier XML de sortie. Par exemple, si le paramètre XmlOutputFile est « FarmData.xml », le dossier « FarmData-icons » est alors créé pour stocker les icônes de l’application.

    Les fichiers de données des icônes dans ce dossier sont des fichiers .txt qui sont nommés à l’aide du nom de navigateur de l’application publiée (bien que les fichiers soient des fichiers .txt, les données stockées sont des données d’icône binaires codées, qui peuvent être lues par le script d’importation pour recréer l’icône de l’application). Lors de l’opération d’importation, si le dossier d’icône ne se trouve pas dans le même emplacement que le fichier XML d’importation, des icônes génériques sont utilisées pour chaque application importée.

• Les noms des modules de script, des fichiers manifestes, des modules partagés et des applets de commande sont similaires. Utilisez la saisie semi-automatique avec précaution afin d’éviter des erreurs. Par exemple, Export-XAFarm est une applet de commande. ExportXAFarm.psd1 et ExportXAFarm.psm1 sont des fichiers qui ne peuvent pas être exécutés.
• Dans les sections détaillées ci-dessous, la plupart des valeurs de paramètre de affichent les guillemets. Ceux-ci sont facultatifs pour les chaînes à mot unique.

Pour exporter depuis le serveur XenApp 6.x

• L’exportation doit être exécutée sur un serveur XenApp 6.x configuré avec le mode de serveur Controller et hôte de session (plus couramment appelé Controller).
• Pour exécuter les applets de commande d’exportation, vous devez être un administrateur XenApp avec la permission de lecture des objets. Vous devez également disposer de suffisamment de permissions Windows pour exécuter des scripts PowerShell ; les procédures détaillées ci-dessous contiennent les instructions.
• Vérifiez que la batterie XenApp 6.x se trouve dans un état d’intégrité normal avant de procéder à l’exportation. Sauvegardez la base de données de la batterie. Vérifiez l’intégrité de la batterie à l’aide de l’utilitaire Citrix IMA Helper (CTX133983). À partir de l’onglet du magasin de données IMA, exécutez une vérification de base (puis utilisez l’option DSCheck pour résoudre les entrées non valides). La résolution des problèmes avant d’effectuer la migration vous aide à empêcher les échecs d’exportation. Par exemple, si un serveur n’a pas été correctement supprimé de la batterie, il se peut que ses données soient conservées dans la base de données, ce qui peut entraîner l’échec des applets de commande dans le script d’exportation (par exemple, Get-XAServer -ZoneName). Si les applets de commande échouent, le script échoue.
• Vous pouvez exécuter les applets de commande d’exportation sur une batterie de serveurs en direct qui possède des connexions utilisateur actives ; les scripts d’exportation ne lisent que la configuration statique de la batterie et les données de stratégie.

Pour effectuer l’importation vers le serveur XenApp 7.6

• Vous pouvez importer des données vers les déploiements XenApp 7.6 (et sur les versions ultérieures prises en charge). Vous devez installer un Controller XenApp 7.6 et Studio, puis créer un site avant d’importer les données que vous avez exportées depuis la batterie XenApp 6.x. Bien que les VDA ne soient pas nécessaires pour importer des paramètres, Ils autorisent les types de fichiers d’application à être mis à disposition.
• Pour exécuter les applets de commande d’importation XenApp, vous devez être un administrateur XenApp avec autorisation de lecture et de création des objets. Un administrateur complet possède ces autorisations. Vous devez également disposer de suffisamment de permissions Windows pour exécuter des scripts PowerShell ; les procédures détaillées ci-dessous contiennent les instructions.
• Aucune autre connexion utilisateur ne doit être active lors d’une importation. Les scripts d’importation créent beaucoup de nouveaux objets et des dysfonctionnements peuvent se produire si les autres utilisateurs modifient la configuration en même temps.

N’oubliez pas que vous pouvez exporter des données, puis utiliser le paramètre -Preview avec les applets de commande d’importation pour voir ce qui se passe réellement durant une importation, mais sans importer quoi que ce soit. Les journaux indiquent exactement ce qui se passe durant une importation réelle ; si des erreurs se produisent, vous pouvez les résoudre avant de démarrer une importation réelle.

Étapes détaillées : exporter des données

Effectuez les étapes suivantes pour l’exportation de données à partir d’un Controller XenApp 6.x vers des fichiers XML.

1. Téléchargez le pack de l’outil de migration XAMigration.zip à partir du site de téléchargement de Citrix. Par commodité, placez-le dans un partage de fichiers réseau pouvant être accédé par la batterie XenApp 6.x et le site XenApp 7.6. Décompressez le fichier XAMigration.zip dans le partage de fichiers du réseau. Deux fichiers zip devraient être présents : ReadIMA.zip et ImportFMA.zip.

2. Ouvrez une session sur le Controller XenApp 6.x en tant qu’administrateur XenApp avec au moins une autorisation en lecture seule et une autorisation Windows pour exécuter des scripts PowerShell.

3. Copiez ReadIMA.zip depuis le partage de fichiers du réseau vers un ControllerXenApp 6.x. Décompressez et extrayez ReadIMA.zip sur le Controller dans un dossier (par exemple : C:\XAMigration).

4. Ouvrez une console PowerShell et définissez le répertoire courant à l’emplacement du script. Par exemple : cd C:\XAMigration.

5. Vérifiez la stratégie d’exécution de script en exécutant Get-ExecutionPolicy.

6. Définissez la stratégie d’exécution de script sur RemoteSigned au minimum pour autoriser les scripts à être exécutés. Par exemple : Set-ExecutionPolicy RemoteSigned.

7. Importez les fichiers de définition des modules ExportPolicy.psd1 et ExportXAFarm.psd1 : Import-Module .\\ExportPolicy.psd1 et Import-Module .\\ExportXAFarm.psd1.

   À savoir

   • Si vous souhaitez uniquement exporter des données de stratégie, vous ne pouvez importer que le fichier de définition du module ExportPolicy.psd1. De même, si vous souhaitez uniquement exporter des données de la batterie, importez uniquement ExportXAFarm.psd1.
   • L’importation des fichiers de définition de module ajoute également les composants enfichables PowerShell requis.
   • N’importez pas les fichiers de script .psm1.

8. Pour exporter les données de stratégie et les données de batterie, exécutez les applets de commande suivantes.

Données de stratégie : exécutez Export-Policy.

Exemple : l’applet de commande suivante exporte des informations de stratégie pour le fichier XML appelé MyPolicies.xml. L’opération est journalisée dans le fichier appelé MyPolicies.log.

Export-Policy -XmlOutputFile ".\MyPolicies.XML" -LogFile ".\MyPolicies.Log"

Données de batterie : exécutez Export-XAFarm.

Exemple : l’applet de commande suivante exporte les informations sur la batterie vers le fichier XML nommé MyFarm.xml. L’opération est journalisée sur le fichier MyFarm.log. Un dossier nommé « MyFarm-icons » est créé pour stocker les fichiers de données de l’icône de l’application ; ce dossier se trouve au même emplacement que MyFarm.XML.

Export-XAFarm -XmlOutputFile ".\MyFarm.XML" -LogFile ".\MyFarm.Log"

Une fois les scripts d’exportation terminés, les fichiers XML spécifiés sur la ligne de commande contiennent la stratégie et les données de la batterie XenApp. Les fichiers de l’icône de l’application contiennent des fichiers de données d’icône, et le fichier journal indique ce qui s’est passé lors de l’exportation.

Étapes détaillées : importer les données

N’oubliez pas que vous pouvez exécuter une importation d’aperçu (en émettant l’applet de commande Import-Policy ou Import-XAFarm avec le paramètre Preview) et consultez les fichiers journaux avant d’effectuer une importation.

Effectuez les étapes suivantes pour importer des données vers un site XenApp 7.6, en utilisant les fichiers XML générés lors de l’exportation.

1. Ouvrez une session sur le Controller XenApp 7.6 en tant qu’administrateur possédant des permissions en lecture et écriture et des permissions Windows pour exécuter des scripts PowerShell.

2. Si vous n’avez pas décompressé le pack de l’outil de migration XAMigration sur le partage de fichiers réseau, faites-le maintenant. Copiez ImportFMA.zip depuis le partage de fichiers du réseau vers un Controller XenApp 7.6. Décompressez et extrayez ImportFMA.zip sur le contrôleur dans un dossier (par exemple : C:\XAMigration).

3. Copiez les fichiers XML (les fichiers de sortie générés lors de l’exportation) depuis le Controller XenApp 6.x vers le même emplacement sur le Controller XenApp 7.6 sur lequel vous avez extrait les fichiers ImportFMA.zip.

   Si vous choisissez de ne pas incorporer les données de l’icône d’application dans le fichier de sortie XML lorsque vous exécutez l’applet de commande Export-XAFarm, assurez-vous de copier le dossier et les fichiers de données d’icône sur le même emplacement sur le Controller XenApp 7.6 que le fichier XML de sortie contenant les données de l’application et les fichiers ImportFMA.zip extraits.

4. Ouvrez une console PowerShell et définissez le répertoire courant à l’emplacement du script : cd C:\XAMigration.
5. Vérifiez la stratégie d’exécution de script en exécutant Get-ExecutionPolicy.
6. Définissez la stratégie d’exécution de script sur RemoteSigned au minimum pour autoriser les scripts à être exécutés. Par exemple : Set-ExecutionPolicy RemoteSigned.

7. Importez les fichiers de définition de module PowerShell ImportPolicy.psd1 et ImportXAFarm.psd1 : Import-Module .\\ImportPolicy.psd1 et Import-Module .\\ImportXAFarm.psd1.

   À savoir :

   • Si vous souhaitez uniquement importer des données de stratégie, vous ne pouvez importer que le module et les fichiers de définition de module ImportPolicy.psd1. De même, si vous souhaitez uniquement importer des données de batterie, importez uniquement ImportXAFarm.psd1.
   • L’importation des fichiers de définition de module ajoute également les composants enfichables PowerShell requis.
   • N’importez pas les fichiers de script .psm1.
8. Pour importer les données de stratégie et les données d’application, exécutez les applets de commande suivantes.

Données de stratégie : exécutez Import-Policy, en spécifiant le fichier XML contenant les données de stratégie exportées.

Exemple : l’applet de commande suivante importe des données de stratégie à partir du fichier XML nommé MyPolicies.xml. L’opération est journalisée dans le fichier appelé MyPolicies.log.

Import-Policy -XmlInputFile ".\MyPolicies.XML" -LogFile ".\MyPolicies.Log"

Applications : exécutez Import-XAFarm, en spécifiant un fichier journal et le fichier XML contenant les données de la batterie exportées.

Exemple : l’applet de commande suivante importe des applications à partir du fichier XML appelé MyFarm.xml. L’opération est journalisée dans le fichier appelé MyFarm.log.

Import-XAFarm -XmlInputFile ".\MyFarm.XML" -LogFile ".\MyFarm.Log"

Une fois l’importation terminée, effectuez les tâches de post-migration.

Tâches d’après migration

Après l’importation réussie des stratégies XenApp 6.x et des paramètres de batterie dans un site XenApp 7.6, utilisez les instructions suivantes pour vous assurer que les données ont été importées correctement.

Stratégies et paramètres de stratégie

L’importation des stratégies est fondamentalement une opération de copie, à l’exception des paramètres et des stratégies obsolètes qui ne sont pas importés. La vérification post-migration implique essentiellement la comparaison des deux côtés.

1. Le fichier journal répertorie toutes les stratégies et tous les paramètres importés et ignorés. Tout d’abord, consultez le fichier journal et identifiez les paramètres et les stratégies qui n’ont pas été importés.

2. Comparez les stratégies XenApp 6.x avec les stratégies importées dans XenApp 7.6. Les valeurs des paramètres doivent rester les mêmes (à l’exception des paramètres de stratégie obsolètes, comme indiqué dans l’étape suivante).

   • Si vous disposez d’un petit nombre de stratégies, vous pouvez réaliser une comparaison visuelle côte à côte des stratégies affichées dans l’AppCenter de XenApp 6.x et des stratégies affichées dans Studio de XenApp 7.6.
   • Si vous disposez d’un nombre important de stratégies, une comparaison visuelle peut ne pas être possible. Dans de tels cas, utilisez l’applet de commande d’exportation de la stratégie (Export-Policy) pour exporter les stratégies XenApp 7.6 vers un fichier XML différent, puis utilisez un outil de comparaison de texte (comme windiff) pour comparer les données de ce fichier aux données du fichier XML utilisé lors de l’exportation de la stratégie à partir de XenApp 6.x.

3. Utilisez les informations dans la section Paramètres de stratégie non importés pour déterminer ce qui peut avoir changé lors de l’importation. Si une stratégie XenApp 6.x contient uniquement des paramètres obsolètes, comme une stratégie totale, elle n’est pas importée. Par exemple, si une stratégie XenApp 6.x ne contient que des paramètres de test HMR, cette stratégie est totalement ignorée, car il n’existe pas de paramètre équivalent pris en charge dans XenApp 7.6.

   Certains paramètres de stratégie XenApp 6.x ne sont plus pris en charge, mais les fonctionnalités équivalentes sont implémentées dans XenApp 7.6. Par exemple, dans XenApp 7.6, vous pouvez configurer un programme de redémarrage pour les machines avec OS de serveur en modifiant un groupe de mise à disposition ; cette fonctionnalité a été précédemment implémentée au travers des paramètres de stratégie.

4. Vérifiez et confirmez la manière dont les filtres sont appliqués à votre site XenApp 7.6 par rapport à leur utilisation dans XenApp 6.x ; des différences significatives entre la batterie XenApp 6.x et le site XenApp 7.6 pourraient changer l’effet des filtres.

Filtres

Examinez attentivement les filtres pour chaque stratégie. Des modifications peuvent être nécessaires pour assurer qu’ils fonctionnent toujours dans XenApp 7.6 comme initialement prévu dans XenApp 6.x.

Pour récapituler, les filtres qui impliquent les modifications de l’utilisateur de domaine requièrent le plus d’attention si la batterie XenApp 6.x et le site XenApp 7.6 se trouvent dans des domaines différents. Étant donné que le script d’importation utilise uniquement des chaînes de noms de domaine et d’utilisateur pour résoudre les utilisateurs dans le nouveau domaine, certains comptes peuvent être résolus et d’autres non. Bien qu’il n’existe qu’un risque infime que des domaines et utilisateurs différents aient le même nom, vous devriez vérifier ces filtres attentivement pour vous assurer qu’ils contiennent des valeurs correctes.

Applications

Les scripts d’importation d’application n’importent pas simplement des applications ; ils créent également des objets, tels que des groupes de mise à disposition. Si l’importation de l’application implique plusieurs itérations, les hiérarchies de dossier d’application originales peuvent changer de manière significative.

1. Tout d’abord, consultez les fichiers journaux de migration qui contiennent des informations sur les applications qui ont été importées, les applications qui ont été ignorées et les applets de commande qui ont été utilisées pour créer les applications.

2. Pour chaque application :

   • Vérifiez visuellement pour vous assurer que les propriétés de base ont été conservées lors de l’importation. Utilisez les informations sous Mappage des propriétés d’application pour déterminer les propriétés qui ont été importées sans être modifiées, qui n’ont pas été importées ou qui ont été initialisées à l’aide des données d’applications XenApp 6.x.
   • Vérifiez la liste des utilisateurs. Le script d’importation importe automatiquement la liste explicite des utilisateurs dans la liste de visibilité de limite de l’application dans XenApp 7.6. Vérifiez pour vous assurer que la liste reste la même.

3. Les serveurs d’applications ne sont pas importés. Cela signifie qu’aucune des applications importées n’est accessible à cet instant. Les groupes de mise à disposition qui contiennent ces applications doivent se voir attribuer les catalogues de machines qui contiennent les machines qui possèdent les images exécutables des applications publiées. Pour chaque application :

   • Assurez-vous que le nom de l’exécutable et le répertoire de travail pointent vers un exécutable qui existe sur les machines attribuées au groupe de mise à disposition (via les catalogues de machines).
   • Vérifiez un paramètre de ligne de commande (qui peut être quoi que ce soit, tel qu’un nom de fichier, une variable d’environnement ou un nom d’exécutable). Vérifiez que le paramètre est valide pour toutes les machines des catalogues de machines attribués au groupe de mise à disposition.

Fichiers journaux

Les fichiers journaux sont les ressources de référence les plus importantes pour une importation et une exportation. C’est pourquoi les fichiers journaux existants ne sont pas remplacés par défaut, et les noms de fichier journal par défaut sont uniques.

Comme indiqué dans Journalisation et gestion des erreurs, si vous choisissez d’utiliser la couverture de journalisation supplémentaire avec les applets de commande PowerShell Start-Transcript et Stop-Transcript (qui enregistrent tout ce que vous tapez et imprimez dans la console), cette sortie ainsi que le fichier journal, fournit une référence complète de l’activité d’importation et d’exportation.

À l’aide des horodatages des fichiers journaux, vous pouvez effectuer un diagnostic de certains problèmes. Par exemple, si une exportation ou une importation a été exécutée pour une très longue durée, vous pouvez déterminer si une connexion de base de données défaillante ou la résolution des comptes utilisateur a pris plus de temps.

Les commandes enregistrées dans les fichiers journaux vous indiquent également la manière dont certains objets sont lus ou créés. Par exemple, pour créer un groupe de mise à disposition, plusieurs commandes sont exécutées non seulement pour créer l’objet de groupe de mise à disposition, mais également d’autres objets, tels que les règles de stratégie d’accès qui permettent l’attribution d’objets d’application au groupe de mise à disposition.

Le fichier journal peut également être utilisé pour diagnostiquer une exportation ou une importation en échec. En général, les dernières lignes du fichier journal indiquent ce qui a causé l’échec, le message d’erreur d’échec est également enregistré dans le fichier journal. Ensemble avec le fichier XML, le fichier journal peut être utilisé pour déterminer l’objet impliqué dans l’échec.

Après avoir vérifié et effectué le test de la migration, vous pouvez :

1. Effectuez la mise à niveau de vos serveurs de tâches XenApp 6.5 vers des Virtual Delivery Agents (VDA) actuels en exécutant le programme d’installation 7.6 sur le serveur, qui supprime le logiciel XenApp 6.5 puis installe automatiquement un VDA courant. Consultez la section Mettre à niveau une tâche XenApp 6.5 vers un VDA pour OS Windows Server pour des instructions.

   Pour les serveurs de tâches XenApp 6.0, vous devez désinstaller manuellement le logiciel XenApp 6.0 du serveur. Vous pouvez alors utiliser le programme d’installation 7.6 pour installer le VDA courant. Vous ne pouvez pas utiliser le programme d’installation 7.6 pour supprimer automatiquement le logiciel XenApp 6.0.

2. Dans Studio, dans le nouveau site XenApp, créez des catalogues de machines (ou modifiez des catalogues existants) pour les tâches mises à niveau.

3. Ajouter les machines mises à niveau du catalogue de machines aux groupes de mise à disposition contenant les applications installées sur ces VDA pour système d’exploitation Windows Server.

Utilisation avancée

Par défaut, l’applet de commande Export-Policy exporte toutes les données de stratégie dans un fichier XML. De même, Export-XAFarm exporte les données de la batterie dans un fichier XML. Vous pouvez utiliser des paramètres de ligne de commande pour contrôler de manière plus avancée quels éléments sont exportés et importés.

Exporter les applications partiellement

Si vous possédez un grand nombre d’applications et souhaitez contrôler combien sont exportées dans le fichier XML, utilisez les paramètres suivants :

• AppLimit : spécifie le nombre d’applications à exporter.
• SkipApps : spécifie le nombre d’applications à ignorer avant d’exporter les applications suivantes.

Vous pouvez utiliser ces deux paramètres pour exporter de grandes quantités d’applications par segments gérables. Par exemple, la première fois que vous exécutez Export-XAFarm, vous souhaitez exporter uniquement les 200 premières applications, vous spécifiez ainsi cette valeur dans le paramètre AppLimit.

Export-XAFarm -XmlOutputFile "Apps1-200.xml"

La prochaine fois que vous exécutez Export-XAFarm, vous souhaitez exporter les 100 applications suivantes, et vous utilisez le paramètre SkipApps pour ignorer les applications que vous avez déjà exporté (les 200 premières), et le paramètre AppLimit pour exporter les 100 applications suivantes.

Export-XAFarm -XmlOutputFile "Apps201-300.xml" -AppLimit "100" -SkipApps "200"

Ne pas exporter certains objets

Certains objets peuvent être ignorés et n’ont donc pas besoin d’être exportés, plus particulièrement les objets qui ne sont pas importés ; voir Paramètres de stratégie non importés et Mappage des propriétés d’application. Utilisez les paramètres suivants pour empêcher l’exportation des objets inutiles :

• IgnoreAdmins : ne pas exporter les objets de l’administrateur
• IgnoreServers : ne pas exporter les objets du serveur
• IgnoreZones : ne pas exporter les objets de zone
• IgnoreOthers : ne pas exporter la journalisation de la configuration, le calculateur de charge, la stratégie d’équilibrage de charge, le pilote d’imprimante et les objets des groupes de tâches
• IgnoreApps : ne pas exporter les applications ; cela vous permet d’exporter d’autres données dans un fichier de sortie XML, puis d’exécuter l’exportation à nouveau pour exporter des applications vers un fichier de sortie XML différent.

Vous pouvez également utiliser ces paramètres pour résoudre les problèmes qui pourraient provoquer l’échec de l’exportation. Par exemple, si vous possédez un serveur erroné dans une zone, il se peut que la zone d’exportation échoue ; si vous incluez le paramètre IgnoreZones, l’exportation continue avec d’autres objets.

Noms de groupe de mise à disposition

Si vous ne souhaitez pas placer toutes vos applications dans un seul groupe de mise à disposition (par exemple, car elles sont accédées par différents utilisateurs et publiées sur différents serveurs), vous pouvez exécuter Import-XAFarm plusieurs fois, en spécifiant différentes applications et un groupe de mise à disposition différent à chaque fois. Bien que vous puissiez utiliser les applets de commande PowerShell pour déplacer les applications d’un groupe de mise à disposition à un autre après la migration, l’importation de manière sélective vers des groupes de mise à disposition uniques peut réduire ou éliminer l’effort de déplacement des applications ultérieurement.

• Utilisez l’applet de commande Import-XAFarm avec le paramètre DeliveryGroupName. Le script crée le groupe de mise à disposition spécifié s’il n’existe pas.

• Utilisez les paramètres suivants dans les expressions régulières pour filtrer les applications devant être importées dans le groupe de mise à disposition, en fonction du dossier, du groupe de tâches, du compte utilisateur et/ou des noms de serveurs. Il est recommandé d’entourer l’expression régulière de guillemets simples ou doubles. Pour plus d’informations sur les expressions régulières, voir https://docs.microsoft.com/en-us/dotnet/standard/base-types/regular-expressions?redirectedfrom=MSDN.

  • MatchWorkerGroup et NotMatchWorkerGroup : par exemple, pour les applications publiées vers des groupes de tâches, l’applet de commande suivante importe des applications dans le groupe de tâches appelé « applications de productivité » vers un groupe de mise à disposition XenApp 7.6 du même nom.

    Import-XAFarm –XmlInputFile XAFarm.xml –LogFile XAFarmImport.log –MatchWorkerGroup ‘Productivity Apps’ –DeliveryGroupName ‘Productivity Apps’

  • MatchFolder et NotMatchFolder : par exemple, pour les applications organisées dans des dossiers d’application, l’applet de commande suivante importe des applications dans le dossier nommé « applications de productivité » dans un groupe de mise à disposition XenApp 7.6 du même nom.

    Import-XAFarm –XmlInputFile XAFarm.xml –LogFile XAFarmImport.log –MatchFolder ‘Productivity Apps’ –DeliveryGroupName ‘Productivity Apps’

    Par exemple, l’applet de commande suivante importe des applications dans tout dossier dont le nom contient « MS Office Apps » dans le groupe de mise à disposition par défaut.

    Import-XAFarm -XmlInputFile .\TheFarmApps.XML -MatchFolder ".*/MS Office Apps/.*"

  • MatchAccount et NotMatchAccount : par exemple, pour les applications publiées vers des utilisateurs ou des groupes d’utilisateurs Active Directory, l’applet de commande suivante importe des applications publiées vers le groupe d’utilisateurs nommé « groupe Finance » vers un groupe de mise à disposition XenApp 7.6 appelé « Finance ».

    Import-XAFarm –XmlInputFile XAFarm.xml –LogFile XAFarmImport.log –MatchAccount ‘DOMAIN\\Finance Group’ –DeliveryGroupName ‘Finance’

  • MatchServer et NotMatchServer : par exemple, pour les applications organisées sur des serveurs, l’applet de commande suivante importe les applications associées au serveur qui n’est pas nommé « Courant » dans un groupe de mise à disposition XenApp appelé « Ancienne génération ».

    Import-XAFarm -XmlInputFile XAFarm.xml -LogFile XAFarmImport.log -NotMatchServer 'Current' -DeliveryGroupName 'Legacy'

Personnalisation

Les programmeurs PowerShell peuvent créer leurs propres outils. Par exemple, vous pouvez utiliser le script d’exportation en tant qu’outil d’inventaire pour le suivi des modifications dans une batterie XenApp 6.x. Vous pouvez également modifier les fichiers XSD (ou créer vos propres fichiers XSD) pour stocker des données supplémentaires ou des données dans des formats différents dans les fichiers XML. Vous pouvez spécifier un fichier XSD non défaut avec chacune des applets de commande d’importation.

Bien que vous puissiez modifier les fichiers de script pour répondre à des besoins de migration spécifiques ou avancés, la prise en charge est limitée aux scripts dans leur état non modifié. Le support technique Citrix vous recommande de rétablir les scripts non modifiés pour déterminer le comportement attendu et fournir de l’assistance, le cas échéant.

Résolution des problèmes

• Si vous utilisez PowerShell version 2.0 et que vous avez ajouté le composant logiciel enfichable du fournisseur PowerShell de stratégie de groupe Citrix ou le composant logiciel enfichable de l’outil Citrix Common Commands à l’aide de l’applet de commande Add-PSSnapIn, vous pouvez voir le message d’erreur « La référence d’objet n’est pas définie à une instance d’un objet » lorsque vous exécutez les applets de commande d’importation ou d’exportation. Cette erreur n’affecte pas l’exécution du script et peut être ignorée.
• Évitez d’ajouter ou de supprimer le composant logiciel enfichable du fournisseur PowerShell de stratégie de groupe Citrix dans la même session de console dans laquelle les modules de script d’importation et d’exportation sont utilisés, car ces modules de script ajoutent automatiquement le composant logiciel enfichable. Si vous ajoutez ou supprimez le composant logiciel enfichable séparément, il se peut que vous aperceviez les erreurs suivantes :
  • « A drive with the name ‘LocalGpo’ already exists (Un lecteur appelé ‘LocalGpo’ existe déjà) ». Cette erreur s’affiche lorsque le composant logiciel enfichable est ajouté deux fois ; le composant tente de monter le lecteur LocalGpo lorsqu’il est chargé, puis signale l’erreur.
  • « A parameter cannot be found that matches parameter name ‘Controller’ (Un paramètre qui correspond au nom de paramètre ‘Controller’ est introuvable) ». Cette erreur s’affiche lorsque le composant logiciel enfichable n’a pas été ajouté, mais que le script tente de monter le lecteur. Le script ne sait pas que le composant logiciel enfichable a été supprimé. Fermez la console et démarrez une nouvelle session. Dans la nouvelle session, importez les modules de script ; n’ajoutez pas ou ne supprimez pas le composant logiciel enfichable séparément.
• Lors de l’importation des modules, si vous cliquez avec le bouton droit sur un fichier .psd1 et sélectionnez Ouvrir ou Ouvrir avec PowerShell, la fenêtre de la console PowerShell s’ouvre et se ferme rapidement jusqu’à ce que vous arrêtiez le processus. Pour éviter cette erreur, saisissez le nom de module du script PowerShell directement dans la fenêtre de la console PowerShell (par exemple, Import-Module .\\ExportPolicy.psd1)).
• Si vous recevez une erreur de permission lors de l’exécution d’une importation ou exportation, assurez-vous que vous êtes un administrateur XenApp avec permission de lecture des objets (pour l’exportation) ou de lecture et de création des objets (pour l’importation). Vous devez également disposer de suffisamment de permissions Windows pour exécuter des scripts PowerShell.
• Si une exportation échoue, vérifiez que la batterie XenApp 6.x se trouve dans un état d’intégrité normal en exécutant les outils DSMAINT et DSCHECK sur le serveur Controller XenApp 6.x.
• Si vous exécutez un aperçu de l’importation, puis ultérieurement exécutez les applets de commande d’importation pour une migration, mais découvrez que rien n’a été importé, vérifiez que vous avez supprimé le paramètre Preview des applets de commande d’importation.

Paramètres de stratégie non importés

Les paramètres de stratégie ordinateur et utilisateur suivants ne sont pas importés, car ils ne sont plus pris en charge. Veuillez noter que les stratégies non filtrées ne sont jamais importées. Les fonctionnalités et composants qui prennent en charge ces paramètres ont été remplacés par de nouvelles technologies/nouveaux composants ou elles ne s’appliquent plus à cause de modifications apportées à l’architecture et à la plate-forme.

Paramètres de stratégie Ordinateur non importés

• Type d’accès des connexions
• Niveau du serveur de gestion UC
• Résolution d’adresse DNS
• Farm name
• Mise en cache d’icône complète
• Contrôle de l’intégrité, Tests de contrôle de l’intégrité
• Nom d’hôte du serveur de licences, port du serveur de licences
• Limiter les sessions utilisateur, Limite sur les sessions administrateur
• Nom du calculateur de charge
• Journalisation des événements des limites d’ouvertures de session
• Pourcentage maximal de serveurs avec contrôle de l’ouverture de session
• Optimisation de la mémoire, Liste d’exclusion d’applications pour l’optimisation de mémoire, Intervalle d’optimisation de la mémoire, Programme d’optimisation de mémoire : jour du mois, Programme d’optimisation de mémoire : jour de la semaine, Programme d’optimisation de mémoire : heure
• Approbation de client d’applications en mode déconnecté, Journalisation des événements des applications en mode déconnecté, Période de validité de la licence d’applications en mode déconnecté, Utilisateurs d’applications en mode déconnecté
• Demander le mot de passe
• Avertissement de redémarrage personnalisé, Texte d’avertissement de redémarrage personnalisé, Horaire de désactivation des ouvertures de session pour le redémarrage, Fréquence de programmation du redémarrage, Intervalle de randomisation du programme de redémarrage, Date de début de la programmation du redémarrage, Horaire de programmation du redémarrage, Intervalle d’avertissement de redémarrage, Horaire de début de l’avertissement de redémarrage, Avertissement du redémarrage auprès des utilisateurs, Redémarrages programmés
• Observation *
• Requêtes d’approbation XML (configurées dans StoreFront)
• Filtrage d’adaptateur d’adresse IP virtuelle, Liste de programmes de compatibilité d’adresse IP virtuelle, Compatibilité d’adresse IP virtuelle améliorée, Liste de programmes d’adresses de l’adaptateur de filtre d’adresse IP virtuelle
• Nom de charge de travail
• Édition de produit XenApp, Modèle de produit XenApp
• Port du service XML

* Remplacé(s) par l’Assistance à distance Windows

Paramètres de stratégie Utilisateur non importés

• Connecter automatiquement les ports COM du client, Connecter automatiquement les ports LPT du client
• Redirection de port COM client, Redirection de port LPT client
• Noms des imprimantes clientes
• Limite d’ouvertures de session simultanées
• Entrée depuis des connexions observées *
• Intervalle d’horloge de déconnexion de persistance, Intervalle d’horloge de fin de persistance
• Journaliser les tentatives d’observation *
• Notifier l’utilisateur de connexions observées en attente *
• Intervalle d’horloge de déconnexion de pré-lancement, Intervalle d’horloge de fin de pré-lancement
• Importance de session
• Single Sign-On, Magasin central Single Sign-On
• Utilisateurs qui peuvent observer d’autres utilisateurs, Utilisateurs qui ne peuvent pas observer d’autres utilisateurs *

* Remplacé(s) par l’Assistance à distance Windows

Types d’application non importés

Les types d’application suivants ne sont pas importés.

• Bureaux de serveur
• Contenu
• Applications livrées en streaming (App-V est la nouvelle méthode utilisée pour les applications livrées en streaming)

Mappage des propriétés d’application

Le script d’importation des données de la batterie importe uniquement des applications. Les propriétés d’application suivantes sont importées sans modification.

IMA et FMA possèdent des restrictions différentes sur la longueur du nom de dossier. Dans IMA, la limite du nom de dossier est de 256 caractères ; la limite FMA est de 64 caractères. Lors de l’importation, les applications possédant un chemin d’accès contenant un nom de dossier de plus de 64 caractères sont ignorées. La limite s’applique uniquement au nom du dossier dans le chemin d’accès au dossier ; le chemin d’accès entier vers le dossier peut être plus long que les limites notées. Pour éviter que des applications soient ignorées lors de l’importation, Citrix vous recommande de vérifier la longueur du nom de dossier d’application et de la raccourcir, si nécessaire, avant l’exportation.

Les propriétés d’applications suivantes sont initialisées ou non initialisées par défaut, ou définies sur des valeurs fournies dans les données XenApp 6.x :

Les propriétés d’application suivantes sont partiellement migrées :

Les propriétés de XenApp 6.x suivantes ne sont pas importées :