Installation de XenApp / XenDesktop 7.12

XenApp & XenDesktop sont disponibles en version 7.12 depuis le 6 Décembre. La 7.11 mettait déjà fortement l’accès sur la compatibilité de MCS avec Windows Azure (notamment), je vous propose de faire un peu le tour des nouveautés que l’on peut retrouver dans cette toute récente mise à jour.

• Améliorations du Local Host Cache Technology qui doit permettre de maintenir les accès aux bureau et desktops même lorsque le Delivery Controller a perdu l’accès à la base de données (pendant 5 minutes et pour des environnements de moins de 6 000 utilisateurs) ;
• Plus de granularité dans la gestion des Apps et des Desktops ;
• Optimisation des cycles de redémarrage lorsque vous devez maintenir / mettre à jour certains composants de votre infrastructure ;
• Améliorations de Citrix Director dont l’historique est désormais d’un mois complet pour le plus bas niveau de licences Enterprise ;
• …

Pour voir la description des nouveautés, vous pouvez consulter cet article sur le blog officiel de Citrix (en anglais).

Même si depuis la toute première version 7.0, la méthode d’installation ne change pas beaucoup, je vous propose de revoir comment installer les différents composants sur une petite infrastructure XenApp 7.12.

Etape 0 – Rappel des composants

Souvenez-vous nous l’avions déjà vu dans un précédent article, mais voici un rappel des différents composants qui interviennent dans une infra XenApp / XenDesktop 7 :

• Delivery Controller : le « chef d’orchestre« , qui se connecte aux bases de données SQL, opère MCS, et gère nos serveurs VDA et VDI….
• Virtual Delivery Agent (VDA), il en existe de 2 types en fonction de si vous souhaitez provisionner un serveur de type XenApp ou un bureau XenDesktop :
  • VDA – Server OS (pour XenApp)
  • VDA – Desktop OS (pour XenDesktop)
• Citrix Director : le composant qui présente diverses statistiques et données de monitoring (c’est un peu le remplaçant de EdgeSight même s’il n’est pas encore tout à fait à la hauteur de ce dernier).
• Citrix License Server : pas de changement, c’est celui qui dispose des licences et les attribue ;
• Citrix StoreFront : le portail web qui permet aux utilisateur de visualiser et d’accéder à leurs ressources ;
• Citrix Studio : console de management permettant de réaliser toutes les actions admin sur le Delivery Controller.

Et les autres composants : Universal Print Server (gestion des impressions), Federated Authentication Service, Self-Service Password Reset, Citrix NetScaler (Access Gateway) que je ne vais pas évoquer dans cet article.

Etape 1 – Installation des différents rôles

Pour ce premier article, on est parti pour une installation minimale de type XenApp sur un nombre limité de VM. Je suppose que vous avez tout ce qu’il vous faut en termes de domaine AD – je ne vais mentionner que les composants Citrix.

• 1 VM pour le Delivery Controller, StoreFront, Director, Studio (bref, on mutualise pas mal de composants, en PROD vous sépareriez sans aucun doute le Delivery Controller et le StoreFront au minimum),
• 1 VM pour le serveur de licences (car je mutualise tous mes rôles de licensing sur cette même VM : CAL RDS, Citrix, etc.),
• 1 VM pour jouer le rôle de notre VDA et héberger nos applications XenApp,
• 1 VM pour le NetScaler Gateway (mais ça on le verra dans un prochain article).

Précisons que toutes ces VM sont sous Windows Server 2016 et que vous disposez bien entendu d’un domaine AD. Commençons par notre première VM. Démarrez depuis l’ISO officiel XenApp / XenDesktop 7.12.

(Attention, l’article pourrait être assez long à charger du fait du nombre d’images).

Choisissez XenDesktop (que vous souhaitiez faire uniquement du XenApp ou du XenDesktop et/ou les 2). Cette différence n’est que marketing.

Installez le rôle Delivery Controller.

Next.

Sur notre première VM, on mutualise la plupart des rôles pour ce test. Vous pouvez même y ajouter le License Server (surtout si vous n’avez pas de licences car vous serez de toute façon en évaluation pendant 30 jours et le composant ne servira donc à rien).

Next.

Je vous parlais de mutualisation pour ce test – nous allons également utiliser SQL Server Express 2014 SP2 qui sera également mutualisé sur cette même première VM (dans un contexte de prod, vous utiliseriez sans aucun doute une VM distincte voir un cluster ou du Always-On).

Si vous utilisez le firewall de Windows, les ouvertures de flux vont être réalisées automatiquement (et sinon, c’est pareil – les règles seront ajoutées aussi) ! 🙂 – Puis, Next.

Cliquez sur Install.

L’installation est terminée pour l’ensemble des composants. Nous pouvons cliquer sur Finish. La console Citrix Studio va démarrer et nous allons pouvoir configurer notre infrastructure (Site XenDesktop).

Avant d’aller plus loin, vous devez soit installer le rôle Citrix License sur la même VM ou bien comme pour mon cas personnel, l’installer sur une autre machine. Pour ce faire, relancer l’assistant d’installation et sélectionnez uniquement ce composant pour procéder à son installation (aucune capture vu que c’est très simple, Next, Next, Next).

Etape 2 – Création de notre Site XenDesktop

La console Citrix Studio démarre automatiquement. Nous allons pouvoir configurer notre (ferme) Site XenDesktop. 🙂

Comme vous le voyez, l’ensemble des options de Citrix Studio et StoreFront sont disponibles sur la partie gauche. Nous allons commencer par créer notre Site XenDesktop. Cliquez sur Deliver…

Donnez un nom à votre Site XD et choisissez la seconde option. Le principe du choix sur le type de Site est le suivant, si vous choisissez A fully configured, production-ready Site, vous devez avoir d’ores et déjà provisionné vos hôtes où la manière dont vous allez générer vos serveurs VDA ou VDI car vous devrez les renseignez plus tard (ce n’est pas mon cas, car je prévois de le faire plus loin dans le tuto c’est pourquoi je choisi cette seconde option).

Nous allons choisir de créer automatiquement nos BDD sur le SQL Express qui a été installé précédemment. Rien à faire, cliquez sur Next.

Référencez le FQDN de votre serveur de licences (soit sur une autre VM – c’est mon cas) ou sur la même VM et dans ce cas adaptez le choix du FQDN en conséquence.

Cliquez sur Finish.

Etape 4 – Installation de notre serveur VDA

Connectez-vous sur l’autre VM qui va jouer le rôle du VDA et démarrez l’ISO de XenApp / XenDesktop 7.12. Nous allons installer l’agent VDA – for Server OS.

A cette étape, vous devez veiller à rattacher votre serveur VDA au Delivery Controller que vous avez généré précédemment. Renseignez donc le FQDN du serveur correspondant, testez la connexion et si c’est OK cliquez sur Add. Puis, Next.

Utilisez les options par défaut.

Comme d’hab, les ouvertures de flux seront réalisées automatiquement.

Cliquez sur Install.

Vous devrez probablement redémarrer au moins une fois votre VM durant l’installation. Patientez.

Notre serveur VDA est prêt. Laissez le restart une dernière fois et repassons sur notre Delivery Controller pour poursuivre la configuration.

Etape 3 – Configuration de notre Site XenDesktop (machine catalog, delivery group et publication)

Nous allons créer un premier Machine Catalog dans lequel nous allons ajouter notre serveur VDA que nous venons de préparer.

Create a new Machine Catalog.

Il s’agit bien d’un serveur avec le VDA – Server OS.

Notre machine n’est pas managée par un MCS ou autre. Elle a été provisionnée manuellement par nous.

Cliquez sur Add Computers et recherchez le nom de la machine que nous avons précédemment provisionnée et qui dispose de l’agent VDA. Puis, cliquez sur Next.

Définissez un nom pour votre nouveau Machine Catalog et cliquez sur Finish pour le créer avec la VM que nous avons préparé.

Nous allons maintenant créer un nouveau Delivery Group et publier quelques applications ainsi qu’un Desktop XenApp. Pour cela, cliquez sur Create a new Delivery Group.

Assignez le précédent Machine Catalog à votre Delivery Group en cliquant sur le + (dans notre cas, nous n’avons qu’1 seule machine au sein de ce catalog mais nous pourrions en assigner un nombre précis).

Choisissez éventuellement un groupe AD de test dont les utilisateurs seront utilisés à exécuter les ressources du Delivery Group (ou utilisez l’option tout utilisateur authentifié).

Publier automatiquement des applications en les sélectionnant avec l’option From start menu. L’avantage de cette option c’est que le Delivery Controller va détecter automatiquement quelles sont les applications installées sur le serveur VDA et nous n’aurons alors plus qu’à les sélectionner pour les publier (plutôt que d’aller chercher le chemin précis vers l’exécutable, etc.).

Si vous le souhaitez, vous pouvez également publier un bureau XenApp.

Terminez en choisissant un nom et une description pour votre Delivery Group.

Si nous résumons un peu :

• Notre infra est créée à l’exception du portail StoreFront que nous n’avons pas encore configuré. Notre Delivery Controller et notre serveur VDA sont installés et configurés.
• Nous avons un Machine Catalog et un Delivery Group avec du contenu publié et disponible (apps & desktop). Vous pouvez d’ailleurs les voir en cliquant dans la console Citrix Studio sur le noeud Applications.
• Nous n’utilisons pas les options AppDisks, Hosting, AppDNA, Zones ou App-V publishing pour ce test. Et globalement l’ensemble des autres options peuvent être conservées avec les réglages par défaut. Administrators c’est pour gérer vos les privilèges et les utilisateurs qui auront accès à la console Citrix Studio. Et Policies permet de créer des stratégies Citrix avancées (nous utiliserons les options par défaut pour l’instant).

Il nous reste donc à configurer notre portail StoreFront ! 🙂

Etape 4 – Configuration de notre portail web StoreFront

Si vous réalisez une installation mutualisée, sachez que le StoreFront se configure automatiquement (certes en HTTP). Il n’y a donc rien à faire – notre Store Citrix est déjà prêt.

Pour vous en rendrez compte, naviguez sur l’URL suivante : http://fqdn-StoreFront/Citrix/StoreWeb. Vous devriez avoir une mire d’identification et une fois identifié vous devriez visualiser le contenu que nous avons choisi de rendre accessible pour notre Delivery Group.

Pour l’instant, si vous avez configuré toutes ces VM sur un réseau interne, il ne vous sera pas possible d’accéder à votre infrastructure depuis l’extérieur de ce réseau (à moins d’ouvrir de nombreux flux vers le Delivery Controller mais aussi vers le serveur VDA).

Dans un prochain article, nous verrons ensemble comment y adjoindre un NetScaler Gateway afin que tous nos flux soient imbriqués dans un échange HTTPS classique. 🙂