XenApp – Page 3

XenApp_Usr7x

MAJ : V1.15 – 17/04/2017

Possibilité de rajouter plusieurs DDC (un DDC par ligne) via le menu « Tools-Modify DDC » afin de pouvoir passer d’une ferme à une autre sans relancer XenApp_Usr7x (afin de prendre en compte la mise à jour des DDC il faut aller dans le Menu « Tools-Refresh DDC »)
Détection de l’OS sur lequel est lancé XenApp_Usr7x (Windows 2012 mini)
Les actions d’activation/désactivation d’application et de mise en maintenance de serveur sont désormais enregistrées dans la base de loging
Le type de licence Citrix et leur nombre sont disponibles dans le formulaire « Farm Info »
Un test de ping est réalisé sur chaque serveur appeler via le formulaire « Server », le résultat du ping est affiché dans le formulaire « Server »
La liste des utilisateurs connectés sur un serveur est disponible dans le formulaire « Server »
Export des Applications et Serveurs au format csv via le menu « Tools-Export »
– L’export des applications comprend les items : ApplicationName, PublishedName, BrowserName, Name, AdminFolderName, ClientFolder, CommandLineExecutable, CommandLineArguments, Description, Enabled, Visible
– L’export des serveurs comprend les items : DNSName, Name, MachineName, DesktopGroupName, CatalogName, FunctionalLevel, IPAddress , OSType, RegistrationState, ZoneName

Et voilà ça faisait longtemps que nous souhaitions porter XenApp_Usr sur XenApp 7x , pressés par nos collègues de l’admin aujourd’hui c’est chose faite : XenApp 7x est enfin UP.

Pour rappel nos XenApp_Usr repose intégralement sur du PowerShell (hé oui même la partie graphique, on sait ça c’est pas bien lol).

Le but de XenApp_Usr7x est de pouvoir rapidement retrouver la/les session(s) d’un utilisateur au sein d’une ferme XenApp, mais on ne s’arrête pas là puisque nous avons intégré aussi la recherche d’applications, serveurs, Delivery Group et Machine Catalog.

Lorsque qu’une session est sélectionnée plusieurs informations sont disponibles (dont notamment l’idle time de la session 😉 ).

Start time
Establishment Time
Establishment Duration
Idle Time
Connected Via IP
Connected Via IP
Client Adress
Client Platform
Client Name
Receiver Name
Receiver IP Address
Session Type
Application
Delivery Group du serveur hébergeant la session
Machine Catalog du serveur hébergeant la session
Process de la session
Gpo(s) de la session

Les actions possibles sur une session sont l’envoi d’un message, le shadowing, le logoff de la session et le kill de process.

XenApp_Usr7x a été validé sur des fermes XenApp 7.6 et 7.12 (DDC en W2k12 et environnement mixte pour les broker machine – W2K8 R2 et W2K12)

Pré-requis :
XenApp_Usr7x peut-être exécuté à partir d’un DDC (W2K12) ou d’un serveur d’admin (W2K12) avec les snap-ins PowerShell XenApp/XenDesktop.

Lors du premier lancement à partir d’un serveur admin il vous faudra entrer un DDC de votre ferme dans le champ DDC puis cliquez sur le bouton Check DDC (le DDC est stocké en dur dans un fichier afin d’éviter de le ressaisir lors des prochains lancements dans C:\Users\username\AppData\Roaming\Ctxblog\XenAppUsr\XenAppUsr7x.txt).

Les zones en jaune sont cliquables 😉

Si vous souhaitez rechercher un serveur, une application, un Machine Catalog ou un Delivery Group allez dans le Menu Tools-Search Server/Apps/DG/MC.

Exemple sur la recherche d’un Delivery Group
Cliquez sur le DG souhaité

En prime vous avez même le load du DG 🙂

Exemple sur la recherche d’un serveur

Vos remarques et suggestions sont comme toujours les bienvenues ;).

XenApp_Usr7x.rar

MAJ : V1.1 – 03/03/2017

Possibilité de copier dans le clipboard les informations de Session, Serveur, Machine Catalog, Delivery Group, Application via le bouton Clipboard situé en bas à gauche des formulaires concernés.
Lorsqu’un serveur est registered dans le formulaire Serveur, le champ statut est vert (orange lorsque le serveur est unregistered)
Possibilité d’afficher les propriétés d’un serveur à partir d’un Machine Catalog ou d’un Delivery Group Mise en maintenance d’un serveur à partir du formulaire Serveur
Possibilité de désactiver/Activer une application à partir du formulaire Application Surbrillance en bleu des champs cliquables lors du passage de la souris
Gpo(s)computer disponibles dans le formulaire Serveur
Compteur des sessions trouvées lors de la recherche

Exceed : Problème de Seamless

Récemment nous avons rencontré un problème de Seamless avec l’application Exceed (dans notre cas la version 14.0 et sur des environnements XenApp 6.5 et 7.6), l’application Exceed (process exceed.exe) passait en mode fenêtré sans raison et action particulière des utilisateurs, une fois l’application en mode fenêtré il n’était plus possible de repasser en mode Seamless. Afin de reproduire le problème nous avions publié le process Exceed et joué avec la combinaison de touche SHIFT+F2 (qui permet de passer du mode Seamless vers le mode fenêtré et vice-versa)

Lors du lancement de l’application Exceed est bien en Seamless

Une fois le passage en mode fenêtré, il est impossible de repasser en Seamless

Afin de résoudre cette problématique nous avons du mettre en place une policy forçant le “Maximum allowed color depth” à 16 bits ” sur le silo hébergeant l’application Exceed.

Une fois le “Maximum allowed color depth” forcé en 16 bits le process Exceed.exe repasse bien en mode Seamless sans problème

Error Studio : Server.fqdn cannot be added to this Catalog as it has the wrong machine type

Pour bien terminer l’année 2016 nous avons rencontré une erreur lors de l’ajout d’un host linux dans un Catalog XenApp 7.12

Server.fqdn cannot be added to this Catalog as it has the wrong machine type

elle se termine bien l’année 2016 🙂

Côté Powershell on n’a pas retrouvé le host en question (via un Get-BrokerMachine), par contre dans la base de donnée nous avons constaté que ce dernier était présent via son nom dns et son SID dans les tables [chb_State].[WorkerNames] et [chb_Config].[WorkerIndex].

Supprimez la ligne contenant le DNSName posant problème

Supprimez la ligne contenant le SID posant problème

Une fois les entrées SID et DnsName supprimées nous avons pu rajouter le Host dans le Catalog.

Ça fonctionne mieux après notre nettoyage.

Une fois le bureau Linux publié ça donne ça 😉 .

Test : ControlUp Logon Simulator

Toujours dans la série des tools gratuits, dans ce billet nous allons vous présentez “ControlUp Logon Simulator“. Comme vous l’avez deviné (pour ceux qui connaissent ControlUp, pour les autres c’est l’occasion de faire connaissance avec nos amis de ControlUp), ControlUp Logon Simulator vient tout droit de chez… ControlUp 🙂 .

ControlUp Logon Simulator permet de simuler la connexion (XenApp/XenDesktop) d’un utilisateur sur une application publiée (ou un dekstop), la connexion va du Netscaler/StoreFront au lancement de l’application.

He oui ça gère même une connexion via un Netscaler 😉

Téléchargez ControlUp Logon Simulator (dans notre cas la v1.3.0)

Les prérequis :

ControlUp Logon Simulator

Microsoft Windows 7 ( nous avons testé avec du W2K8 R2 et W2K12)
Ne pas être admin local (dans la session ou vous souhaitez lancer ControlUp Logon Simulator)
.Net Framework 4.6.1
Citrix Receiver 4.x

StoreFront/XenApp/XenDesktop

Citrix Storefront 2.0 minimum
Citrix XenApp 6.5, XenDesktop/XenApp 7.x

L’installation est simple et se résume en trois étapes :

Cliquez sur le bouton Next

Cliquez sur le bouton Close

Reste à lancer ControlUp Logon Simulator et à le configurer (montre en main il faut 2/3 mn).

Au passage vous pouvez aussi lancer ControlUp Logon Simulator en ligne de commande via la commande (c’est un exemple) : controluplogonsim.exe /noeula /s /config=c:\YourFolder\settings.xml (le fichier .xml est à créer au préalable via la GUI en enregistrant votre configuration).

Configurez ControlUp Logon Simulator
Dans notre cas nous sommes passés directement sur un StoreFront (3.5), cependant ControlUp Logon Simulator gère aussi les tests via un Netscaler.

Et voila 😉

Vous pouvez avoir le détail de chaque test via l’onglet Summary, en cliquant sur un test (oui on a un test en failed 😉 )

Si vous souhaitez remonter des alertes via votre outil de monitoring favori comme par exemple ControlUp (via les Triggers d’incident de ControlUp, voir page 10 de l’admin guide) ou Zabbix 🙂 , c’est tout à fait possible vu que ControlUp Logon Simulator génère des events dans le journal application.

En conclusion que du bonheur 😉 .

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.

Une 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)

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

Ok 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”.

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

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.

Comme 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).

On 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_plt Avec des licences Platinum on se sent tout de suite plus à l’aise 🙂

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

Ça va être juste pour passer en Platinum 🙂

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

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

On 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’

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.

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

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

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

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_error1 On clique toujours sur “View error détails”, mais rarement ça nous dépanne 😉

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.

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

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}