Page 5

Citrix Workpspace : A protocol error occured while communicating with the Authentication Service

Si vous rencontrez l’erreur ci-dessous lors de l’ajout de compte dans Citrix Workspace (dans notre cas une version 18.10.20023) et que vous n’avez pas envie de réinstaller votre/vos StoreFront comme le préconise la CTX213052, alors on vous conseille de bypasser la lecture de la CTX213052 et de lire la suite. Dans le cas présent nos StoreFront sont dans une version 1811 soit la 3.17.0.20027 pour être précis. Au passage si vous souhaitez connaitre la version exacte de votre StoreFront, une des manières d’obtenir la version exacte d’un StoreFront est de faire un Get-STFVersion sur un de vos StoreFront.

A protocol error occured while communicating with the Authentication Service

En parcourant le post https://discussions.citrix.com/topic/376304-a-protocol-error-occured-while-communicating-with-the-authentication-service/?page=2 on s’aperçoit qu’il suffit juste de modifier le web.config situé dans C:\inetpub\wwwroot\Citrix\Roaming\web.config (dans le cas ou IIS est installé sur la partition C:) et de supprimer la partie ci–dessous.

<add id=”0b81178e-9f9c-446d-b560-0d4259d007d7″ location=”https://yourserver.yourdomain.local/Citrix/Authentication/auth/v1/token” verifyId=”83121c02-1935-41a7-8219-8af21b61117f” />

Une fois la partie ci-dessus supprimée nous avons pu ajouter un compte dans notre Citrix Workspace. Le problème semble se produire lorsque votre serveur StoreFront a été mis à jour ou installé via l’autorun avec les autres composants de la suite “Citrix Virtual Apps and Desktop”. Lors d’une installation Standalone de StoreFront nous n’avons pas rencontré de problème.

Erreur : La ressource publiée n’est pas actuellement disponible……

Dans un environement Netscaler VPX et XenApp (ha oui c’est vai désolé……”Citrix Virtual Apps and Desktop”) les utilisateurs obtenaient l’erreur ci-dessous lors du lancement d’une application publiée via des StoreFront (eux-même derrière des Netscaler VPX).

La ressource publiée n’est pas actuellement disponible. Contactez votre administrateur systeme pour obtenir de l’aide.
The Published resource is not available currently. Contact your system administrator for further assistance.

Une information interréssante était que les utilisateurs arrivaient à lancer leur application au bout de la deuxième tentavive (voir troisième), ce qui nous amène rapidement à penser à un problème de STA 🙂 et oui on fait ce billet car c’est un classic qu’on oublie avec le temps. En regardant la configuration des STA sur les Netscalers et sur les StoreFront on s’aperçoit que côté Netscaler nous n’avons qu’un serveur STA de renseigné et que côté StoreFront nous avons deux serveurs STA de renseigné avec le “Load balance multiple STA servers” de coché (nous y reviendrons plus tard).

Pour rappel les STA doivent être dans le même ordre côté Netscaler et StorFront et surtout côté StoreFront il ne faut pas cocher le “Load balance multiple STA servers”

une fois l’orde des STA rétabli et le “Load balance multiple STA servers” décoché les utilisateurs ont pu lancer leur applications dès le premier lancement

Un peu de lecture pour plus de compréhenssion sur le fonctionnement du STA entre Netscaler et Storefront : CTX134940

Cisco C220 M5 et SFP 25-G Arista

Récemment nous avons reçu des Cisco CC20 M5 avec des SFP Arista 25-G et bien sûr le côté Plug-and-Play n’a pas fonctionné comme esperé :).

Honnêtement tout le monde s’y attendait chez nous et certains pensaient même à des check de type “Vendor Name” côté Cisco etc.

En échangeant avec une vielle connaissance de chez Cisco (Arnaud Bassaler pour ne pas le citer 😉 ) ce dernier nous indique que Cisco ne fait plus de check hardware sur les SFP depuis ses serveurs, le problème devrait venir de la configuration du FEC qu’il faudrait forcer en “cl74” selon lui.

Direction l’IMC du serveur afin de modifier l’Admin FEC Mode en “cl74” (allez dans Network-Adapter Card MLOM-External Eternet Interface puis cliquez sur l’onglet External Ethernet Interface)

Il ne reste plus qu’à modifier la valeur de l’Admin FEC mod en “cl74”, si toutefois le link State ne passe pas en Link Up, verifiez côté switch s’il ne faut pas forcer le port (dans notre cas un switch Arista) en “fire-code” ce qui a permis dans notre cas de passer le link du port en Up dans l’IMC.

ESXi 6.5: Erreur lors de l’installation

Lors de l’instalation d’un ESXi 6.5 (sur un Cisco UCS C220 M5) nous avons rencontré l’erreur ci-dessous (hé oui on ne fait pas que du Citrixm 🙂 .

partedUtil failed with message: b”Error: Can’t have a partition outside the disk!nUnable to read partition table for device /vmfs/devices/disk/eui.00a0504658335330\n\n”.

En googlelant nous sommes tombés sur la KB2082806, ce qui nous a amené à faire un Erase du Virtual Drive via la CIMC (Cisco Integrated Management Controller) du server.

Selectionnez le Virtual Drive puis cliquez sur le bouton “Erase Virutal Divre”

Une fois l’erase du “Virtual Drive” réalisé, l’installation a pu être réalisée sans problème.

Director : Alertes Delivery Controller

Suite à une mise à jour de Director de nos Controllers 7.6 vers 7.15, nous avons remarqué une erreur “cosmétique” dans la section Delivery Controller du Dashboard de Director :

Alertes Delivery Controller
Citrix Ad Identity Service

La bonne nouvelle est que tous les Controllers sont impactés 🙂

En fait cette erreur est juste dû au fait que lorsque vous upgradez votre Director 7x à partir du fichier msi directement, il faut passer la commande ci-dessous sur un de vos Controller une fois l’upgrade terminé :

C:\inetpub\wwwroot\Director\tools\DirectorConfig.exe /upgrade

Voila c’est beaucoup mieux

Le pire c’est que c’est bien écrit noir sur blanc 🙂 sur la CTX22476.

Application probing

Apparue dans XenApp/XenDesktop 7.18 (ça c’était avant le renommage en Citrix Virtual App), l’Application probing permet d’automatiser le lancement d’application dans le but de vérifier leur bon lancement. Une fois installée et configurée, le résultat est directement disponible dans Director.

L’installation et la configuration sont très simples et rapides :

Télécharger l’agent Probe : https://www.citrix.com/downloads/citrix-virtual-apps-and-desktops/components/app-probe-agent.html
Installer l’agent Probe (CitrixAppProbeAgent.msi) sur un OS de type windows avec un receiver 4.8 minimum (he oui pas de MacOs ou Linux)
Configurer l’agent probe (il faut un Delivery Controller 7.18 minimum)
Création d’une analyse

On va passer l’étape d’installation et configuration car elles sont dejà très bien documentées chez Citrix et Carl Stalhood.

Maintenant que tout est installé et configuré nous pouvons passer à l’étape de la création d’une analyse. Allez dans Director, cliquez sur l’icone Configuration puis cliquez sur le bouton “Création d’une analyse” (Create Probe).

Une fois les champs renseignés cliquez sur le bouton Enregistrer

En conclusion un bon outil qui devrait évoluer au fil des versions de Citrix Virtual Apps, nous avons listé ci-dessous la liste des points forts et points faibles d’Application Probing.

Points forts :

Installation et configuration rapide
Intégration dans Director
Monitoring d’application publiée

Points faibles :

la partie planification des analyses, en effet on ne peut programmer une analyse qu’une fois par jour. Certains d’entre vous se voient dejà créer plusieurs analyses pour une application et les lancer à différentes heures, oui mais attention car dans les bests practice Citrix ci-dessous tout n’est pas possible (pour l’instant)

L’envoi d’alerte uniquement par mail
Rétention de 7 jours maximum (seulement) dans Director

StoreFront erreur : Cannot complete your request

Si vous rencontrez un jour l’erreur “Cannot complete your request” après l’étape du login dans un StoreFront, on vous invite à vérifier que le certificat présent dans vos StoreFront est bien valide et surtout que le “Chemin d’accès de certification” est complet et sans erreur 😉 .

Dans notre cas ce qui nous a mis sur la piste du certificat est l’event ID 17 présent sur les StoreFront) :

Log Name: Citrix Delivery Services
Source: Citrix Receiver for Web
Event ID: 17
Description:
Failed to run discovery
Citrix.Web.DeliveryServicesProxy.ConfigLoader.DiscoveryServiceException, ReceiverWebConfigLoader, Version=3.15.0.0, Culture=neutral, PublicKeyToken=null
An error occurred while contacting the Discovery Service
…

System.Net.WebException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
Url: https://127.0.0.1/Citrix/UT09/discovery
ExceptionStatus: TrustFailure

Au moins c’est clair 🙂 .

Dans le cas présent c’est une suite de problèmes sur la PKI (dont un mémorable rennomage…..) qui a généré un certifcat assez roccambolesque lors du renouvellement du certificat des StoreFront.

Une fois la PKI et les certificats restaurés tout est revenu à la normale.

Nous sommes partagés par regarder Gaston Lagaff ou faire un Cludeo.

Ok pour le Cluedo, on veut trouver le coupable 🙂

Netscaler vpx : consommation excesive de cpu dans Vcenter

Suite à la migration de Netscaler Vpx en 12.1.48.13 nous avons remarqué que ces derniers consommaient anormalement de la cpu dans Vcenter (avec des hosts en ESXi 6.0).

Tranquille le Vpx 🙂

En googlelant nous sommes tombé sur la CTX22955 qui explique que depuis la version 12.0 (vpx) le CPU yielding est désactivé.

Tout est dit…

Afin d’activer le CPU yeilding il faut vous connecter en ssh (ou console) sur votre Vpx et passer la commande ci-dessous.

set ns vpxparam -cpuyield YES

Reste à verifier que ça nous rend bien la cpu côté Hyperviseur

On pensait que c’était l’effet canicule mais non 🙂

Netscaler : champ utilisateur/mot de passe manquant

Suite à un upgrade de netscaler 11.1 vers 12.1.4813 les champs utilisateur et mot de passe avaient disparu de la page d’accueil de la CAG (index.html).

Le premier qui arrive à se loguer gagne une boisson jaune 🙂

Dans pareille condition le mieux est d’ouvrir le developper de votre browser favori (dans notre cas c’est Chrome).

On constate que nous avons une erreur dans l’onglet Sources et deux erreurs 404 dans la console (en bas du deuxième screenshot).

Les erreurs 404 donnent deja un bon indice 🙂 .

Un clic sur une des erreurs nous renvoie dans l’onglet Network, encore un clic sur l’erreur (en bas à gauche) permet d’afficher une preview et donc le path du fichier manquant.

L’avantage du developper est que même sans notion de dev on arrive rapidement à trouver l’orgine d’une erreur.

Maintenant que nous connaissons l’origine du problème il ne reste plus qu’à aller en ssh sur un de nos netscaler dans le dossier ” /var/netscaler/logon/themes/Ctxblog/resources”.

Ok donc tous les fichiers de langages ont une extension .xml1 au lieu de .xml.

Afin de renommer tous les fichiers ayant l’exention .xml1 en .xml on passe la commande ci-dessous.

for f in *.xml1; do mv — “$f” “${f%.xml1}.xml”; done

Il ne reste plus qu’a vérifier que ça a bien corrigé notre problème

On va pouvoir retourner sur le transat 🙂

XenApp : création d’applications en masse

Ca nous est tous arrivé un jour de se retrouver devant LA fameuse demande de création d’applications en masse (dans notre cas plus 300 applications one shoot).

En plein match de la coupe du monde, 300 applis à créer, avec 300 tickets différents bien sûr 🙂

Le script powershell joint à ce billet permet la création des applications “en masse”, avec les utilisateurs/groupes et l’icone associée au binaire de publication (sauf si votre chemin applicatif est un bacth, script etc..). Là où c’est pratique c’est que le script repose sur un fichier de configuration (format csv) dans lesquel vos productions applicatives vont rentrer toutes les informations nécessaires à la création des applications (sinon c’est à vous de le faire 😉 ).

En argument lors du lancement vous pouvez indiquez un Delivery Controller (exemple : Xa7x_CreateApps.ps1 MonDeliveryController), en l’absence d’argument le script considère que le serveur local est un Delivery Controller.

XA7x_CreateApps.zip