Category: XenApp

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 🙂

Post to Twitter

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 😉

 

Post to Twitter

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

Post to Twitter

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

Post to Twitter

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 : 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

Problème de désinstallation VDA 7.6

Attention billet Post-it 🙂 .

Si vous rencontrez un problème de désinstallation de VDA 7.6.300 (dans notre cas sur un W2K12 R2 US), il se peut que l’origine de l’erreur provienne d’un problème de droit sur une clé de registre.


VDA_Error1L’erreur lors de la désinstallation du VDA


VDA_Error2Le fichier IcaTS_x64.msi fait des siennes avec un installFaillure (1603)


VDA_Error3Toujours la même erreur qui revient.


Juste avant de googleler la fameuse erreur “IcaTS_x64.msi…….failed with code ‘installFaillure’ (1603). ,  on a regardé du côté des journaux d’événements et nous sommes tombés sur l’eventID 11402 ci-dessous.


VDA_Error4Au moins c’est clair la


Une fois les permissions correctement placées le problème restait présent, seule la suppression de la clé [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\EUEM\LoggedEvents] nous a permis de corriger ce problème de désinstallation de VDA.

VDA_Error5Une fois la clé supprimée

Post to Twitter

Erreur : Internet Explorer has stopped working

Sur un silo de serveurs (Xenapp 6.5 R06, windows 2008 r2 sp1 Us) les applications publiées sous IE (Internet Explorer 9) rencontraient l’erreur ci-dessous :

 

Internet Explorer has stopped working
A problem caused the program to stop working correctly. Please close the program

 

IE_crash01

 

Dans le journal d’evenement “application” on retrouve à chaque crash l’Event ID : 1000

Log Name:      Application
Source:        Application Error
Event ID:      1000
Task Category: (100)
Level:         Error
Description:
Faulting application name: iexplore.exe, version: 8.0.7601.19058, time stamp: 0x563ce980
Faulting module name: PseudoServerInproc2.dll, version: 6.2.0.57, time stamp: 0x4e1c9864
Exception code: 0x80000003
Fault offset: 0x00101eaf
Faulting process id: 0x1990
Faulting application path: C:\Program Files (x86)\Internet Explorer\iexplore.exe
Faulting module path: C:\Program Files (x86)\Citrix\System32\PseudoServerInproc2.dll

 

IE_crash02

 

L’event étant on ne peut plus clair,on a donc  un problème avec la redirection FLASH et plus précisément avec la dll “PseudoServerInproc2.dll”. Dans un premier temps il a fallu rétablir le service asap c’est pourquoi (après quelques recherches) nous avons supprimé la clé ci-dessous (pas besoin de reboot pour la prise en compte).

 

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\
HDXMediaStreamForFlash\iexplore.exe

 

Une fois la clé supprimée les utilisateurs n’ont plus rencontré de crash IE, cependant ça reste la solution “provisoire”, dès que possible on regardera du côté de la CTX141429 .

 

IE_crash03Cette CTX141429 devrait résoudre notre problème 😉

Post to Twitter

Script : Supprimer les comptes non résolu dans XenApp

Comme vous le savez, lorsque vous supprimez des objets utilisateurs ou groupes de votre Active Directory ces derniers restent dans vos applications publiées et vous vous retrouvez avec des objets non résolus affichés comme ci-dessous.

 

DeleteAccAppsNotResolveUn peu de Monsieur Propre ?

 

Supprimer ces objets non résolus est on ne peut plus simple via PowerShell, un Get-XaApplication, une boucle et un remove-XaapplicationAccount et c’est fait 🙂 .

Bien sûr avant l’exécution du script vérifiez que votre DataStore est bien backuper 😉 .

Le script a été testé sur des fermes XenApp 6.5 (US et FR).

 

AppErrorResolveCptMême notre lab passe au Monsieur Propre 🙂

 

DeleteAccAppsNotResolve1
Une fois le script passé  les comptes non résolus ont bien disparus

 

Download_2CleanAppCptNotResolve.ps1

Post to Twitter