0

XA 6.5 : sessions déconnectées

Récemment on nous a remonté un problème de sessions déconnectées sur des serveurs XA 6.5 R06 US, en regardant sur l’AppCenter de la ferme en question on constate bien les sessions déconnectées.

 

02Une série de sessions déconnectées, observer l’heure du logon (ça donne direct une bonne info)

 

En regardant sur un des serveurs nous avons remarqué que les sessions déconnectées n’étaient pas présentes dans le gestionnaire de tâches et pas d’event côté eventlog)

 

03La bonne nouvelle c’est que tout le monde n’est pas impacté

 

Dans un premier temps nous avons pensé à une fuite mémoire (à tort), et dans pareil cas rien ne vaut un RAMMap.

 

04Ok là tout devient plus clair, toutes les sessions déconnectées ont trois process de lancés (LogonUI.exe, Winlogon.exe et crss.exe.exe)

 

Direction Process Explorer afin d’en savoir plus, en observant un process Winlogon.exe d’une session déconnectée nous avons remarqué via l’onglet Thread que la Dll twi3.dll avait un statut « Wait:UserRequest ».

 

05On touche au but la

 

Un coup de google plus loin nous tombons sur la CTX138197, le point 7 nous explique la cause du problème :
 

Sessions running on single-monitor, aero-enabled Windows client devices can disconnect unexpectedly. The issue can occur when a preview, as part of the Dynamic Window Preview feature, is sent to the client; at that time, a twi3.dll thread can terminate the Winlogon.exe process, which in turn causes the session to disconnect.
To resolve this issue in its entirety, you must install both a XenApp and a Receiver hotfix that contains Fix #LA2858.

 
Après une mise à jour des clients receiver (ils étaient en 3.4) le problème n’est plus réapparu.

 

 

 

6

Test de Remote Display Analyzer (RDAnalyzer)

Dans ce billet nous allons vous présenter un outil que nous utilisons depuis quelques semaines : « Remote Display Analyzer » (by Bram Wolfs et Barry Schiffer). Remote Display Analyzer permet d’analyser et de modifier rapidement les paramètres d’affichage au sein d’une session HDX (et depuis peu RDP) afin de pouvoir comparer le rendu des différents modes d’affichage (idéal pour obtenir une meilleure expérience utilisateur ainsi que lors de séances de troubleshooting). Les modifications effectuées ont un impact temporaire (les paramètres issus des stratégies XenApp reviennent après un logoff/logon).

 

rda_001

 

Première bonne nouvelle, il n’y a pas d’installation, deux binaires sont livrés, un pour HDX et un pour RDS. Deuxième bonne nouvelle une version gratuite est proposée (cette dernière permet l’affichage des paramètres d’affichage en cours), si vous souhaitez passer à la version ++ il faudra passer par la case « DONATE » (honnêtement c’est l’histoire de quelques cafés 😉 ). Le seul prérequis est d’être admin local du serveur sur lequel vous exécutez Remote Display Analyzer (merci à Max pour la remarque).

 

Remote Display Analyzer for HDX :

 

rda_01En version free
Attention en XA 7.11 L’active Encoder ne s’affiche pas (c’est en cours de correction 😉 )

 

rda_02En version ++  ça devient vraiment très intéressant car on a accès aux options permettant de modifier en live les principales options d’affichage d’une session HDX (Mode d’affichage, nombre de frames max, codec de compression)

 

rda_02_01
La partie display

 

rda_02_02
La partie codec pour la compression

 

Remote Display Analyzer for RDP :

 

rda_03_rdsEn version free

 

rda_04_rdsEn version ++

 

De notre point de vue Remote Display Analyzer constitue un excellent outil pour le troubelshooting (portant sur des problématiques d’affichage), en outre il  permet de tester rapidement les différents modes d’affichage possibles pour comparer par exemple l’expérience utilisateur en fonction de vos fermes XenApp,  du type d’accès etc… (bien sûr ce ne sont que des exemples d’autre cas d’usage sont possibles).

Tags: , , ,
8

XenApp 7x : quand c’est « By Design »

Récemment nous avons testé l’API Odata afin de pouvoir interroger la base de monitoring sans passer par des requêtes SQL,  le but étant de faire un export afin d’alimenter un « puits de données »

Dans un premier temps si vous souhaitez en savoir plus sur l’API Odata dans XenApp 7x,  nous vous recommandons la lecture des liens ci-dessous :

Un exemple en Powershell pour consulter la liste des applications publiées d’une ferme XenApp 7x (à exécuter à partir d’un DDC ou remplacer Localhost par le Hostname d’un de vos DDC) :

$AppsNamedata = Invoke-RestMethod -UseDefaultCredentials -URI "http://localhost/Citrix/Monitor/Odata/v2/Data/Applications"
$AppsName = $AppsNamedata.content.properties
$AppsName|Select Name



Dans notre cas et sur la ferme en question nous n’arrivions pas à obtenir la liste des applications publiées.

 

apps_etsComme nous avions testé l’API Odata sur la partie Session et Users avec succès, on comprend vite que la partie Application va poser problème.



En regardant dans la base de Monitoring nous avons constaté que la table Monitor.Application était vide (via un  » Select Top 1000 Rows » sur la Table « Monitor.Application » de votre Base de monitoring).

 

apps_ets_sqlOn comprend mieux pourquoi en passant par « …..Odata/v2/Data/Applications » nous n’obtenions aucun retour



Dans Director lors d’une recherche sur un utilisateur nous obtenions bien la liste des applications lancées au sein des divers sessions.

Durant notre troubleshooting nous avions constaté sur d’autres fermes XenApp (7.6 LTSR CU1/CU2) et XenApp 7.11) que la Table Monitor.Application sur leurs bases de monitoring respectives était bien peuplée.

Après de nombreux check check SQL, XenApp et traces Wireshark nous avons constaté que les serveurs de Licence Citrix étaient différents entre les fermes qui remontaient bien les applications dans la table Monitor.Application et les fermes qui ne remontaient aucune information dans la table Monitor.Application.

En fait le problème n’est pas un problème mais plutôt un truc du style « C’est by design », en version Platinum les informations concernant les applications sont bien remontées dans la table Monitor.Application et en version Enterprise rien n’est remontées côté Applications.

 

apps_pltAvec des licences Platinum on se sent tout de suite plus à l’aise 🙂

 

apps_plt_sqlLa base de monitoring ou pointe une de nos fermes en Platinum

 

Durant nos tests (sur une ferme XenApp 7.6 LTSR US) nous avons constaté que toutes les informations étaient facilement consultables et exportables sauf la partie Application  qui est contenue dans « http://localhost/Citrix/Monitor/Odata/v2/Data/Applications »



Après le coup de la rétention de 7 jours dans Director (en licence Enterprise), on a le coup de la Table Monitor.Application vide en licence Enterprise 🙂 .

pasdesousÇa va être juste pour passer en Platinum 🙂

Tags: , ,
0

CUGC Français

On entend souvent dire que la  communauté Citrix Française organise peu d’événements (au passage un grand bravo à ILKI qui depuis des années organise chaque année les Rencontres des virtualisations avec des speakers mondialement reconnus), et bien en voici un supplémentaire : The French Citrix User Group Community.

 

cugc

 

Le premier CUGC est prévu pour le Mercredi 9 novembre 2016 à 18:00 au « Le Réservoir » (16 rue de la forge Royale 75011 Paris)

Pour vous inscrire c’est par ici, venez nombreux ça sera une occasion supplémentaire de se réunir, échanger, partager et de boire un verre d’eau avec de la mousse dessus 🙂 .

 

cugc2
Tout est dit 😉

Tags:
0

Erreur désinstallation VDA

Lors d’une désinstallation d’un VDA 7.6.300 nous avons rencontré l’erreur ci-dessous :

Removal of MSI Product ‘CitrixHDXWMIProvider-x64.msi’ ………………….. failed with code ‘InstallFailure’ (1603).

 

vda_error_wmi01En ce moment c’est une constante le 1603 🙂

Le fichier de log et les events du serveur ne donnant rien, nous avons extrait le msi CitrixHDXWMIProvider-x64.msi puis tenté une installation à la mano.

 

vda_error_wmi02On sy attendait, mais ce qui nous intéresse ce sont les logs du msi

 

Direction le fichier de log (dans notre cas : C:\Users\UserName\Local Settings\Temp\Number\Citrix\XenDesktop Installer\MSI Log Files)

 

MSI (c) (94:44) [16:36:42:043]: Windows Installer installed the product. Product Name: Citrix HDX WMI Provider – x64 7.6.300.7024. Product Version: 7.6.300.7024. Product Language: 1036. Manufacturer: Citrix Systems, Inc.. Installation success or error status: 1603

Property(N): Rollback_Uninstall_MOFRegister.A447AE13_47F3_442C_8854_837BF7E37D1A = c:\Program Files (x86)\Citrix\System32\citrix.hdx.wmi.provider.mof
Property(N): MOFUnregister.A447AE13_47F3_442C_8854_837BF7E37D1A = c:\Program Files (x86)\Citrix\System32\citrix.hdx.wmi.provider_delete.mof

 

La lecture du fichier de log nous apporte une information intéressante concernant la suppression des fichiers .mof, donc direction une console PowerShell afin de vérifier ce qui reste de WMI côté Citrix via la commande : gwmi -Namespace root -class __Namespace -Filter « name = ‘citrix’

 

vda_error_wmi03

 

Nous allons y aller à la brute en supprimant le Namespace « Citrix » via la commande :  gwmi -Namespace root -class __Namespace -Filter « name = ‘citrix’| Remove-WmiObject

Une fois le Namespace Citrix supprimé, l’installation du msi CitrixHDXWMIProvider-x64.msi se termine sans erreur.


vda_error_wmi04Ca c’est bon, il ne reste plus qu’a relancer la suppression du VDA 7.6300 😉

 

Tags: , ,
1

Receiver : Erreur de client inconnue 0

Suite à une mise à jour de client Receiver 3.4.300.10 vers 4.4.0.8014 sur des serveurs XenApp 6.5 R06 (W2K8 R2 sp1 Us), certains de nos utilisateurs nous ont remonté une erreur lors de connexion sur des bureaux publiés (se connecter à un bureau publié via un bureau publié….. ça se passe de commentaire 🙂 ) .

The connection to « Desktop……….. » failed with status (Unknow client error 0).

La connexion à « Desktop……….. » a échoué avec l’état (Erreur de client inconnue : 0) .

 

error_receiver02Comment ça Unknow 🙂


Afin de bypasser cette erreur il faut supprimer la valeur ci-dessous :


HKEY_CURRENT_USER\Software\CITRIX\Program Neighborhood Agent\Resource Cache


On va être honnêtes avec vous, ça a pris pas mal de temps avant d’arriver sur cette valeur 🙂 .

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}