0

Erreur installation VDA : UpmVDAPlugin.msi Failed (1619)

Lors d’un upgrade de VDA 7.6.300 (LTSR) vers un VDA 7.6.1000 (LTSR CU1) sur un serveur W2K8 R2 Sp1 US, on nous a remonté l’erreur ci-dessous :

‘UpmVDAPlugin_x64.msi’ failed with code ‘InstallPackageOpenFailed’ (1619)

 

vda_error1On clique toujours sur « View error détails », mais rarement ça nous dépanne 😉

 

vda_error2
He oui on a cliqué et on n’est pas plus avancé 🙂

 

Au passage ce serveur était membre il y a quelques mois d’une ferme XenApp 6.5 (c’est donc un serveur qui a un certain vécu 😉 ).

Revenons à nos moutons, en regardant les events du serveur nous n’avons rien trouvé, en revanche en ouvrant le fichier de log d’installation du VDA nous avons vite trouvé l’origine du problème.

$ERR$ : XenDesktopSetup:MSI file C:\WINDOWS\TEMP\Ctx-76B9FF05-0423-4B17-974A-6063551BB4B8\Extract\Image-Full\x64\Virtual Desktop Components\UpmVDAPlugin_x64.msi not found on media.

 

Dans un premier temps il faut extraire le fichier « UpmVDAPlugin_x64.msi » du « VDAServerSetup_7.6.1000.exe« , une solution rapide et simple est d’ouvrir le fichier « VDAServerSetup_7.6.1000.exe » avec WinRar (ou 7-zip) et d’extraire le fichier « UpmVDAPlugin_x64.msi » (situé dans ..\Image-Full\x64\Virtual Desktop Components). Il ne reste plus qu’a placer le fichier « UpmVDAPlugin_x64.msi » dans « C:\WINDOWS\TEMP\Ctx-76B9FF05-0423-4B17-974A-6063551BB4B8\Extract\Image-Full\x64\Virtual Desktop Components\ » et de relancer l’installation du VDA.

 

vda_error3Une fois le fichier UpmVDAPlugin_x64.msi copié, l’installation passe sans problème

3

Big news : rachat de NORSKALE

Comme vous le savez nous suivons NORSKALE depuis sa création (voir notre billet de 2012 ici), donc pour ceux qui ne le savent pas encore (pourtant ça a pas mal buzzé) NORSKALE a été racheté par CITRIX (le 08 septembre 2016).

Il était temps que CITRIX réagisse face à la concurrence (notamment VMware avec le rachat d’Immidio en 2015) , nous allons suivre avec attention l’intégration de NORSKALE au sein de l’offre CITRIX 😉 .

,

norskale

 

Au passage Pierre devient « Principal Architect » chez CITRIX (on devrait peut-être plus se croiser du coup 🙂 ).

 

 

cocoricoDésolé on a pas résistez

 

 

0

StoreFront : activez le SSO (Pass-Through) sur le PNAgent

Comme vous le savez sûrement, sous StoreFront la configuration d’un site PNAgent diffère de celle de Web Interface. En effet sous Web Interface il fallait créer un site de type « XenApp Services Sites » alors que sous StoreFront le « site » PNAgent est créé automatiquement dans chaque Store.

 

site_pna1Ça fait Time Machine de voir ce screenshot 🙂

 

site_pna2Pour configurer le PNA sous StoreFront il faut dans votre STORE cliquer sur « Configure XenApp Service Support » puis choisir le « Default store »

 

Bon ok, mais quand on veut faire du SSO on fait comment, (comme d’hab à l’ancienne 😉 ) , direction le dossier C:\inetpub\wwwroot\Citrix\VotreStore puis ouvrez le ficher web.config. Recherchez la chaine logonMethod= »prompt » puis modifiez la en logonMethod= »sson ».

Bien sûr vous pouvez aussi passez par la case PowerShell, voir le billet de nos collègues de chez kylewise.

0

Cacher toutes les applications désactivées d’une ferme XenApp 6.5

Histoire d’éviter de devoir renvoyer par mail, lync, telegram and co, nous partageons avec vous un tout petit (vraiment petit 🙂 ) oneliner permettant de cacher toutes les applications désactivées d’une ferme XenApp 6.5 qui ne sont pas cachées (pourquoi vous nous direz, parce que certains désactivent les applications et oublient de les cacher……)

get-xaapplication |?{$_.enabled -eq $False -and $_.HideWhenDisabled -eq $False}|%{set-xaapplication -browsername $_.browsername -HideWhenDisabled $True}

 

0

StoreFront : désactiver la détection du receiver

Sous StoreFront  (dans notre cas un 3.01…..LTSR oblige) désactivez la détection du receiver se fait via le fichier web.config (dans C:\inetpub\wwwroot\Citrix\VotreStoreWeb\ ), en modifiant la chaine pluginAssistant enabled= »true »  par pluginAssistant enabled= »false ».

Si vos utilisateurs utilisent Chrome (comme vous le savez Chrome ne supporte plus le NPAPI depuis septembre 2015, si vous souhaitez plus d’informations sur NPAPI c’est par ici) comme navigateur il faudra en plus modifier la chaine <protocolHandler enabled= »true » par <protocolHandler enabled= »false », puis enregistrez votre web.config.

Vous pouvez aussi passer par l’outil « Citrix StoreFront GUI » disponible dans la CTX138991 (Attention Citrix StoreFront GUI ne fonctionne pas à partir de la version 3.5 de StoreFront).

 

SF_Conf_GUIPour les plus fainéants 😉

 

2

StoreFront : Cannot start app

Si vous rencontrez l’erreur « Cannot start app……….. » lors du lancement d’application publiée via un StoreFront, nous vous conseillons d’aller voir du côté des serveurs hébergeant l’application en question (car pour le coup c’est comme en XenApp 6.5, même symptôme même conséquence, voir la fin du billet si vous n’êtes pas patient).

 

VdaError01Ça fait toujours plaisir ce type de message 😉

 

Au passage sur nos DDC l’event 1101 confirme que l’application n’a pu être lancée pour les utilisateurs.

Log Name:      Application
Source:        Citrix Broker Service
Event ID:      1101
User:          NETWORK SERVICE
Computer:
Description:
The Citrix Broker Service failed to broker a connection for user “domain\user” to resource ‘Dxdiag’. The Citrix Broker Service cannot find any available virtual machines.


VdaError03Bien sur le Dxdiag est pour l’exemple 😉



Sur les serveurs hébergeant l’application nous avons constaté l’event 1039.

Log Name:      Application
Source:        Citrix Desktop Service
Event ID:      1039
Computer:
Description:
The Citrix Desktop Service failed to initialize a performance counter. Load management associated with this counter will be disabled.

 

VdaError02C’est la que nous comprenons l’origine du problème

 

En regardant dans Studio nous avons constaté que les serveurs en question avaient un load de 10000 sans raison apparente.

VdaError04Quelques recherche plus loin, nous sommes contents de tomber sur un de nos billets « Charge serveur bloqué sur 10000 » 🙂

 

Allez sur vos serveurs XenApp et lancez un coup de « lodctr.exe /r », cela va permettre de recréer manuellement les valeurs de la bibliothèque du compteur de Performance.

VdaError05
Une fois la commande lodctr.exe /r  passée les applications  étaient à nouveau disponibles.

 

Au passage ces serveurs XenApp étaient issues d’une migration XenApp 6.5 vers une de nos fermes XenApp 7.6 LTSR, du coup on va rajouter un check perfmon après la migration de serveur 🙂 .

 

2

StoreFront : afficher le nom (displayname) des applications sans troncage

il peut arriver dans certaines productions que le nom des applications soit à rallonge, dans ce cas la StoreFront va automatiquement tronquer le nom de l’application si ce dernier dépasse les 17 caractères.

 

SF_Apps_Full_Displayname1On a pas le droit d’avoir le DisplayName en entier, on a payé pourtant 🙂

 

Pour afficher le nom des applications en entier il vous faudra modifier le fichier C:\inetpub\wwwroot\Citrix\VotreSotreWeb\receiver\js\ctxs.webui.min_35BC18E54FFE70CC.js (attention, selon la version de StoreFront la suite numérique peut varier).

 

Une fois le fichier ctxs.webui.min_35BC18E54FFE70CC.js ouvert, modifiez la ligne ci-dessous :

c = CTXS.UI.useSmallTiles() ? 120 : 140;

par

c = CTXS.UI.useSmallTiles() ? 120 : 240;

 

Enregistrez le fichier ctxs.webui.min_35BC18E54FFE70CC.js.

 

SF_Apps_Full_Displayname2
C’est plus lisible du coup 😉

 

Nous avons testé cette modification avec des StoreFront 3.01 et 3.5.

 

Attention si le nom de vos applications (DisplayName) ne comporte pas d’espace (hé oui on a eu le cas) il n’y aura pas de retour à ligne dans StoreFront.

0

PowerShell : désactiver les abonnements utilisateur

Comme ce n’est pas vraiment documenté (voir pas du tout), on vous met la ligne de commande pour désactiver en PowerShell les abonnements utilisateur (Disable User Subscription) d’un magasin (Store) dans StoreFront.

Set-DSLockedDownStore  -SiteId « 1 » -VirtualPath « /Citrix/VotreStore » -IsLockedDown $True

Bon on vous l’avoue, c’est pour aussi l’avoir sous la main pour une prochaine fois 😉 .

2

Erreur Web Interface : Invalid URI: The hostname could not be parsed.

Quoi de plus énervant que de retrouver des journaux Windows pollués d’erreurs à ne plus en finir, c’est dans ce contexte que nous avons trouvé certaines Web Interface.

 

Les Web Interface en questions (Windows 2008 Us R2, Web Interface 5.4) généraient l’Event ID 21002 toutes les 3 secondes :

Log Name:      Application
Source:        Citrix Web Interface
Event ID:      21002
Task Category: None
Level:         Error
Keywords:      Classic
Description:
Site path: C:\inetpub\wwwroot\Citrix\Site1.
Critical server error: System.UriFormatException: Invalid URI: The hostname could not be parsed.

 

Event21002_01Il ne reste plus qu’à trouver la source

Event21002_02Inutile de nous faire le coup du « mais où est ton Logstash, ElasticSearch et Kibana ou mieux ton SexiLog pour Citrix » 🙂

Event21002_03Un Wireshark après nous avons trouvé la cause, un cluster de F5 qui monitorait un Site Webi via un GET /Citrix/Site1/auth/login.aspx.

Event21002_04Une fois le monitor corrigé (via un Get sur le site webi  /Citrix/Site1, sans auth/login.aspx) par nos collègues F5.