XenApp – Page 7

Vérifier l’ouverture du port IMA

Récemment du jour au lendemain certains de nos utilisateurs rencontraient le message d’erreur ci-dessous en cliquant sur une application publiée via une Web Interface (dans notre cas une 5.4 Us).

” Une erreur s’est produite lors de l’établissement de la connexion requise”.

Error_Xml_WI Vu que seul un silo était impacté, le premier réflexe a été de vérifier si le port IMA était bien ouvert entre nos XML Broker et les serveurs du silo concerné, et effectivement le 2512 n’était plus ouvert 😉

Afin de palier ce type de situation, nous avons mis en place un PowerShell qui va checker que le port 2512 (port par défaut, cependant le script va vérifier le port IMA au cas ou 😉 ) est ouvert (avec un timeout de 1000 milliseconds, au delà on considère que le port IMA n’est pas ouvert), avec un tableau récapitulatif des serveurs non joignables sur le port IMA.

Au préalable il vous faudra installer le SDK Powershell (XenApp 5, XenApp 6x)sur vos XML Broker.

Une petite visite chez nos collègues du réseau ? 🙂

Vérifier les classes WMI des serveurs membres d’une ferme XenApp

Généralement lorsque vous rencontrez une erreur WMI vous avez un ou plusieurs événements dans les journaux Windows, et bien ça c’est quand tout va bien 🙂 .

Dans le cas présent nous avions une application “Premium” 7/24 (en gros si elle tombe vous avez les cinq continents au tel avec des mots diplomatiques) qui refusait de se lancer sur deux serveurs sur dix. Le listener ICA était ok sur les deux serveurs (publication/connexion sur un notepad ok), en regardant le launcher de la fameuse appli, on se rend compte que le batch, lance un vbs qui lui lance son petit frère qui lui-même appelle sa tante…bref à un moment il y a une requête WMI qui échoue et pas de log applicative .

Bon ok c’est exagéré 🙂

En lançant la requête localement sur un des serveurs incriminés on s’est aperçu que la couche WMI était corrompu (pour la réparer voir notre billet “Erreur WMI : Espace de noms non valide…..“.

Afin d’anticiper ce type de problème nous avons mis en place un PowerShell qui va checker si les namespace “root\default” et “root\citrix” répondent bien sur tous les serveurs membres d’une ferme XenApp.

Au passage avant le test de Namspace on teste si le port TCP 135 est bien ouvert (sur un timeout de 1000 millisecondes) histoire de ne pas se prendre des timeouts de fou dans sur les serveurs situé dans des DMZ ou autre).

On va aussi en profiter pour intégrer ce check WMI dans XenAppCheck 😉

WmiCheckNameSpace.ps1

Retrouver le mot de passe d’un compte de service IMA

Si vous n’avez pas de coffre fort numérique (un bon Keepass et vous n’aurez plus d’excuse) et que vous avez perdu le mot de passe du compte de service IMA , et bien tout n’est pas perdu 😉 .

En googlelant nous sommes tombés sur le billet de Remko Weijnen “Decoding Citrix IMA Datastore Password“, du coup on teste direct le binaire (CtxImaPass.exe).

Bon ok on savait le hash perfectible mais à ce point

Pour info le compte de service IMA et le mot de passe associé se trouve dans les valeurs ci-dessous :

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\Datastore\L$ImaDBUsername
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\Datastore\L$ImaDBPassword

Forcer une barre de tâche (Pinned Bar) en GPP

Au sein d’un bureau publié sous XenApp 6.5 R03 on nous a demandé de forcer une barre de tâche custom (Word, Excel, PowerPoint et Outlook), plusieurs solutions sont possibles comme un script ou une bonne GPP 😉 (et oui nativement en 2008 R2 on ne peut pas le faire).

La barre de tache souhaitée

Chez notre client actuel le sujet du logon script étant sensible nous sommes donc passés par une GPP.

Les étapes sont très simples :

Au sein d’une session, customisez votre barre de tâche (l’idéal est de le faire au sein de votre session et sur un serveur pouvant exécuter un gpmc.msc)
Recopiez les raccourcis de la barre de tâche (%APPDATA%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar) dans un share accessible à tous les utilisateurs (en lecture)
Créez une GPO (Ex : CTX_XA65_Forced_PinnedBar)
Modifiez la GPO précédemment créée, Configuration utilisateur-Préférence-Paramètre Windows-Registre, clique droit sur Registre, Nouveau élément de registre, dans le champ “Chemin d’accès de la clé”, allez dans HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Taskband” puis choisissez Favorites.

Toujours dans la GPO allez dans Configuration utilisateur-Préférence-Paramètre Windows-Fichier puis ajoutez les fichiers précédemment copiés dans votre share.

En l’état nous avons une Barre de tâche avec nos nouvelles icônes et les icônes par défaut (Gestionnaire de Serveur et PowerShell)

Pour supprimer les icônes par défaut nous avons choisi de passer par les permissions NTFS (ok c’est la version dure on vous l’accorde) afin de retirer les droits aux utilisateurs (on ne laisse que les administrateurs), Dans la GPO allez dans Configuration ordinateur-Stratégie-Paramètre Windows-Paramètres de sécurité-Système de fichier, puis ajoutez les trois entrées ci-dessus.

%AllUsersProfile%\Microsoft\Windows\Start Menu\Programs\Accessories\Windows PowerShell\Windows PowerShell.lnk
%AllUsersProfile%\Microsoft\Windows\Start Menu\Programs\Administrative Tools\Server Manager.lnk
%AllUsersProfile%\Microsoft\Windows\Start Menu\Programs\Administrative Tools\Windows PowerShell Modules.lnk

Au passage on vous donne la GPO (il vous faudra juste changer le path des icônes de la barre de tâche) 😉

Force_Pinned_Bar

Lenteur d’ouverture de session

Il y a quelques semaines nous avons traité un problème de lenteur d’ouverture de session (SBSL : Slow Boot Slow Logon) sur des fermes XenApp 6.0 (Us) et XenApp 6.5 R03 (Us), les temps d’ouverture des applications publiées prenaient en moyenne 45 secondes au lieu des 25/30 habituels (bien que ce temps soit déjà un peu au dessus d’une bonne ouverture de session) .

un utilisateur patient ou résigné ? les deux ?

Dans un premier temps il convient de vérifier que les serveurs XenApp ont bien les hotfix conseillés par Citrix via la CTX129229 (regarder aussi la CTX133873 qui traite des problèmes de lenteur d’ouverture de session avec des RODC) ainsi que les KB suivantes KB973772, KB977346, KB2409711 et KB977346.

Schéma des étapes précédent le lancement d’une application publiée via une Web Interface

Dans un second temps nous allons prendre une trace d’ouverture de session causant problème avec Xperf 4.1.6512 (on aurait pu prendre la 6.3.9600 au passage 😉 ).

Pour plus d’info sur Xperf c’est juste en dessous :

Pour lancer une trace Xperf (nous passons l’installation d’Xperf qui est une suite de Next Next Next) nous avons lancé la ligne de commande ci-dessous :

xperf -on base+latency+dispatcher+NetworkTrace+Registry+FileIO -stackWalk CSwitch+ReadyThread+ThreadCreate+Profile -BufferSize 128 -start UserTrace -on “Microsoft-Windows-Shell-Core+Microsoft-Windows-Wininit+Microsoft-Windows-Folder Redirection+Microsoft-Windows-User Profiles Service+Microsoft-Windows-GroupPolicy+Microsoft-Windows-Winlogon+Microsoft-Windows-Security-Kerberos+Microsoft-Windows-User Profiles General+e5ba83f6-07d0-46b1-8bc7-7e669a1d31dc+63b530f8-29c9-4880-a5b4-b8179096e7b8+2f07e2ee-15db-40f1-90ef-9d7ba282188a” -BufferSize 1024 -MinBuffers 64 -MaxBuffers 128 -MaxFile 1024

Une fois la trace lancée, il vous faut lancer une application publiée sur un serveur (de préférence avec aucun utilisateur dessus). Dès l’application publiée lancée, vous pouvez arrêter la trace.

Pour arrêter la trace Xperf :

xperf -stop -stop UserTrace -d merged.etl

Les problèmes de lenteur d’ouverture de session peuvent avoir plusieurs origines comme (liste non exhaustive) :

GPOs
Login Script
Mappage de périphérique(s)
Profil (taille, type de profil)
Redirection de dossiers
Problème WMI et SMB
Application publiées (temps d’ouverture de l’application)

Le problème devrait se situer dans une de ces étapes 😉

A partir du serveur où a été installé Xperf, allez dans le menu démarrer-Programs-Microsoft Windows Performance Toolkit puis lancer Performance Analyzer

Ouvrez la trace précédemment réalisée

La trace une fois ouverte

Dans la section Winlogon, on s’aperçoit que la partie GPCLIENT prend plus de 8 secondes (une première piste)

Maintenant on va dans la section Process afin de faire un export des process et de trouver le PID de notre logon script
Clique droit puis Export full Table

Une fois le login script trouvé on relève son PID

Afin d’afficher la durée de notre logon script dans la section Winlogon il faut faire un clique droit Overlay graph-CPU Sampling by Process et on clique sur le PID du logon script.

La lecture de la trace fait apparaître deux problèmes, l’application des GPO qui prend 8 secondes avec un logon script qui en prend presque 13, ce qui est pénalisant dans notre cas puisque le Run logon scripts synchronously est activé (Exécuter les scripts d’ouverture de session simultanément) ce qui force l’exécution du logon script avant le lancement de l’application publiée.

Avec nos 8 secondes nous sommes au dessus des 7 secondes maximum 🙂
Voir le billet Optimizing Group Policy Performance

Nous avons donc deux axes d’amélioration qu’il va falloir traiter rapidement, un GPLCIENT trop long et un logon script qui prend son temps.

quelques liens traitant des problèmes de type SBSL :

Erreur IMAService EventId 4007

Lors d’une migration entre deux fermes XenApp 6.5 R03 Fr, un de nos serveurs n’arrivait plus à démarrer son service IMA.

Dans le journal system nous avons retrouvé l’erreur ci-dessous :

Log Name: System
Source: IMAService
Event ID: 4007
Description:
Le service Citrix Independent Management Architecture (IMA) se ferme. Le fichier DSN n’a pas pu être mis à jour avec les informations récupérées depuis la stratégie de groupe. Erreur : 80000001h Fichier DSN : mf20.dsn Entrée DSN : DATABASE Paramètre de stratégie : VotreFerme Confirmez que le service réseau possède des permissions en écriture dans le fichier DSN.

Le problème venait de la valeur “DataSourceName” situé dans “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA”, cette dernière étant vide ça ne risquait pas de fonctionner.

Une fois la valeur DataSourceName renseignée, l’IMA redémarre sans problème

La CTX105292 traite au passage ce type de problème

Installation de XenApp 7.5

Depuis le 26 mars 2014 XenApp 7.5 est disponible, et bien sur l’installation sur notre labs était une étape incontournable 🙂 .

L’installation a été réalisé sur un 2008 R2 sp 1 Fr (on vous entends déjà ” quoi c’est pas du 2012 ” 🙂 ).

XA75_01 On est parti from scratch 🙂

Cliquez sur bouton “Démarrer” en face de XenApp….

Cliquez sur “Delivery Controller”

Accepter les termes du contrat puis cliquez sur le bouton “Suivant”

Cliquez sur le bouton “Suivant” (nous avions déjà un serveur de licence et un StoreFront)

Cliquez sur le bouton “Suivant”

Cliquez sur le bouton “Installer”

Cliquez sur le bouton “Terminer”

A l’issus de l’installation de XenApp 7.5 le Citrix Studio se lance de lui-même.

Cliquez sur “Mettre des applications et des bureaux à la disposition de vos utilisateurs”

Renseigner le nom du site puis cliquer sur le bouton “suivant”

Cliquez sur le bouton “Suivant”

Cliquer sur le bouton “Ok”

Cliquez sur le bouton Confirmer

Choisissez vos licences puis cliquez sur le bouton “Suivant”

Renseignez les informations concernant votre hyperviseur favori puis cliquez sur le bouton “Suivant”

Si vous obtenez cette erreur, rajoutez le certificat de votre VCenter sur le serveur puis cliquez sur le bouton “Fermer”

Renseigner les champs de la ressource, cluster et réseaux puis cliquez sur le bouton “Suivant”

Sélectionner votre stockage puis cliquez sur le bouton “Suivant”

Cliquez sur le bouton “Suivant” (sauf si vous souhaitez faire de l’App-V)

Cliquer sur le bouton “Terminer”

Dans le prochain billet on détaillera l’ajout d’un serveur XenApp avec ses applications publiées.

Identifier les applications avec un seul serveur

Un petit script pour identifier rapidement les applications publiées ayant un seul serveur.

$OriginalColor=$Host.UI.RawUI.ForegroundColor;get-xaapplicationReport *|Sort DisplayName|Format-Table -Property DisplayName,@{label="Serveur";Expression={If($_.ServerNames.count -le 1) {$Host.ui.rawui.ForegroundColor="Red";$_.ServerNames.count}Else{ $Host.ui.rawui.foregroundcolor="Yellow";$_.ServerNames.count}}};$Host.UI.RawUI.ForegroundColor=$OriginalColor

Les applications avec un seul serveur apparaissent en rouge 😉

Pour rappel dans XenAppCheck vous avez aussi la liste des applications avec un seul serveur.

Test de ControlUp 3

Il y a un peu plus d’un an nous avions testé ControlUp 1.0 (voir billet), la version 3.0 (3.0.1.399 dans notre cas) vient de sortir et autant vous dire Smart-X a passé la vitesse supérieure 😉 .

Nos tests ont été effectués sur un serveur 2008 R2 sp1 Fr, et comme d’habitude l’installation et la prise en main de ControlUp sont déconcertantes de facilité.

Les ajouts de fonctionnalités (et améliorations) les plus importantes que nous avons constaté durant notre test :

Ajout d’une section Incidents
Possibilité de monitorer les services
Possibilité d’exécuter des scripts en remote
Ajout de colonnes Citrix supplémentaires dans la section Computer
Ajout d’actions de diagnostics sur les computers
Support . Net Framework 4.5
Ajout personnalisé d’events log
Possibilité de changer la priorité d’un processus
Affichage de la latence ICA dans la section computer
Ajout d’un magasin de mot de passe

L’installation se fait via une une suite de popup

Cliquez sur le bouton Continuer

Choississez “I Accept the agreement”
Cliquez sur le bouton Continuer

Rentrez le nom de votre organisation
Cliquez sur le bouton Continuer

Dans un premier on garde les triggers par défaut
Cliquez sur le bouton Yes

On vous avait prévenu, l’installation est une formalité 😉 .

En moins de 5 mn (installation comprise) on est déjà au sein de la console de ControllUp

Dans un premier temps il faut rajouter les serveurs membre de/des ferme(s) XenApp dans la console ControlUpp.

L’installation de l’agent (port 40705 par défaut) se fait en remote via la console ControlUpp (ainsi que la désinstallation), l’installation par lot est bien sur possible (il est aussi possible de télécharger l’agent et de le déployer par d’autres outils).

Vous avez la possibilité via la console ControUp de configurer le ControlUp Monitor afin de créer un service qui permettra le monitoring en continu.

On vous conseille ce mode si vous souhaitez une mise en place pour du 24/7

Dans la suite du billet nous allons énumérer quelques unes des nombreuses fonctionnalités de ControlUp.

Dans la console vous avez la possibilité de modifier la liste des colonnes et donc de personnaliser le monitoring (avec des settings xenapp, xendesktop)

Il est possible d’ajouter des triggers (sur des événements Windows, des process démarrés, des arrêts de serveur etc..) en plus de ceux déjà configurés

La liste des actions possibles sur un host (Le “Script Based Actions” est notre préféré 😉 )

La liste des actions possibles sur une session

La fonction Incidents permet d’obtenir rapidement un état des incidents avec un historique

Il est possible de rajouter des scripts réalisés par Smart-X ou bien les vôtres (bat, vbs et PowerShell 😉

La configuration de la console ControlUp se trouve dans C:\Users\VotreUser\AppData\Roaming\ControlUp et HKEY_CURRENT_USER\Software\Smart-X\ControlUp.

En résumé ControlUp permet de mettre en place un monitoring rapide et efficace de vos fermes XenApp, de plus Yoni est à l’écoute de la communauté Citrix et certains d’entre eux sont impliqués directement dans le projet (Shawn Bass, Jarian Gibson et Shane Kleinert) 🙂 .

Au passage la version Basic est toujours free