Author: ctxblog

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}

 

Post to Twitter

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 😉

 

Post to Twitter

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 🙂 .

 

Post to Twitter

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.

Post to Twitter

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 😉 .

Post to Twitter

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.

Post to Twitter

StoreFront : An error has occured during the all server configuration update process

Une feature bien pratique sous StoreFront est bien-sûr le “Propagate Changes” qui permet comme son nom l’indique de propager les modification d’un StoreFront sur l’ensemble d’un Server Group. Mais voilà il peut arriver que la propagation s’enrhume 🙂 .

SF3-error1La bonne nouvelle est qu’on a un event qui va nous mettre sur la root cause (voir plus bas)

 

Dans le cas présent nous avons un serveur groupe de trois StoreFront (W2k12 R2 US, StoreFront 3.0.1.56 -hé oui c’est une infra LTSR 😉 ), lors de propagation (au préalable les serveurs ont bien été ajoutés au serveur group mais la propagation n’avait pas fonctionné) nous avions systématiquement l’event 31 sur le serveur StoreFront où nous lancions la propagration.

Log Name:      Citrix Delivery Services
Source:        Citrix Configuration Replication Service
Event ID:      31
Level:         Error
Description:
An error has occured during the all server configuration update process.
Citrix.DeliveryServices.ConfigurationReplication.Exceptions.ServerUpdateConfigurationException, Citrix.DeliveryServices.ConfigurationReplication, Version=3.0.0.0, Culture=neutral, PublicKeyToken=e8b77d454fa2a856
An error occurred running the command: ‘Add-DSFeatureInstances’
<Data>An error has occured during the all server configuration update process.
An error occurred running the command: ‘Add-DSFeatureInstances’
The feature data is out of date
At line:1 char:1
+ Add-DSWebReceiver -SiteId 1 -VirtualPath /Citrix/StoreWeb -AppPool ‘Citrix  …
RemoteEndpoint: net.tcp://YourServer/Citrix/ConfigurationReplication

Nous comprenons que nous avons donc un problème avec le Site StoreWeb sur les deux autres StoreFront, en regardant de plus près ces StoreFront ont subi un Clear-DSConfiguration et visiblement tout ne s’est pas supprimé durant le “reset factory” (voir la CTX200239 pour de plus amples informations sur le reset factory).

Dans IIS, nous avons constaté que dans L’Application Pools, L’application “Citrix Receiver for web” avait encore le Virtual Path “StoreWeb” de bindé.
Afin de supprimer le Virtual Path StoreWeb, nous avons créé une application TEST puis nous avons déplacé le Virtual Path StoreWeb dans cette nouvelle application et enfin nous avons supprimé l’application TEST.

 

SF3-error2Il ne reste plus qu’à supprimer le Virtual Path en cause 😉

 

Une fois ces actions réalisées le “Propagate Changes” passait sans problème.

 

SF3-error3Le mot « vert » vient du latin virĭdis, qui veut dire « vert » (voir ici) 🙂

 

Post to Twitter

Windows 2012/2012 R2 : Recréer le listener RDS

Fini le bon vieux temps où l’on pouvait recréer le listener RDP via une GUI. Sous Windows 2012/2012 R2 il faut désormais passer par la case registre.

Histoire de ne pas faire d’import de registre le jour J, on s’est fait une GUI via un script Powershell (he oui encore du winform 🙂 ) afin de pouvoir recréer un listener RDP sous un serveur Windows 2012/2012 R2 (pour l’instant seul Windows 2012/2012 R2 sont concernés).

Une fois lancé le script vous permet de connaitre l’état du listener RDP, son port et si ce dernier répond bien à un socket TCP.

 

RecreateRdpListenerVia un qwinsta nous avons l’état du listener RDP (et plus si vous avez d’autres listeners)
Cliquez sur le bouton “Recreate Rdp listener” pour récréer le listener RDP (un backup du listener est réalisé dans le répertoire d’exécution du script)

 

RecreateRdpListener1Un popup vous demande la confirmation de l’action

 

RecreateRdpListener2Un fois le listener recréé, vous obtenez un message de confirmation

 

 Download_2
RecreateRdpListener.rar

 

Si vous souhaitez passer par la case registre pour recréer un listener RDP 2012/2012R2 , la KB de dell “How to recreate or add an additional RDP Listener in Windows Server 2012 and 2012 R2” vous aidera dans votre démarche.

Post to Twitter

Citrix HDX Engine a cessé de fonctionner

Suite à un déploiement de receiver 4.4.0.8014, notre support nous a remonté un problème de connexion entre un de nos utilisateurs et une ferme XenApp 5.0 Fr.

 

14_4HDXerror12Ok ok on ferme le programme 🙂

 

Sur le poste de l’utilisateur l’event 1000 ci-dessous nous a permis de résoudre rapidement l’incident notamment la partie “Chemin d’accès du module défaillant: C:PROGRA~2\CITRIX\ICACLI~\gfxrender.dll“.

 

14_4HDXerror11Un event comme on les aimes 😉 .

 

Pour rappel Gfxrender.dll permet le décodage matériel via le client 4.4 (14.4), du coup afin de rétablir le service pour notre utilisateur nous avons désactivé la partie “Client graphics settings” via une GPO filtrée sur le poste de l’utilisateur du poste de l’utilisateur (en attendant un correctif de chez Citrix).

 

14_4HDXerror1

Une fois le “Client graphics setting” désactivé l’accès à l’application hébergé sur une ferme XenApp 5 était de nouveau possible.

 

Si vous souhaitez en savoir plus sur le décodage matériel nous vous conseillons la lecture du post Improved User Experience: Hardware Decoding for Citrix Windows Receiver.

Post to Twitter