ctxblog – Page 15

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

Rechercher une application dans plusieurs fermes XenApp

Si vous souhaitez connaitre la/les fermes publiant une application (par exemple word, excel ou bien une application comprenant une chaîne de caractère “TEST” 😉 ) le script contenu dans ce billet devrait vous intéresser.

Les pré-requis sont que les serveurs entrés dans la variable $Serveurs aient le PowerShell SDK d’installer (XenApp 5, XenApp 6x) et que le port TCP 2513 soit ouvert entre le serveur exécutant le script et le(s) serveurs ayant le sdk installé (bien sur on ne peut attaquer une ferme XenApp 6x à partir d’un serveur XenApp 5 et vice-versa 😉 .

Modifier la variable $Serveurs (ligne trois du script) la liste des serveurs (un par ferme XenApp) permettant de se connecter avec les différentes fermes XenApp.

23 Applications publiées réparties sur trois fermes XenApp 6.5 ayant dans leur browsername la chaîne de caractère “TEST” 😉

SearchAppFarms.ps1

Supprimer les applications désactivées

Depuis quelques temps les rapports issus de nos XenApp_Check remontaient un nombre croissant d’applications désactivées sur nos fermes XenApp 5 et 6x (Recette, Qualification et Production).

52 applications désactivées sur une ferme XenApp 5 R07

Vu que ces applications restaient désactivées dans le temps (plus de 30 jours) nous avons mis en place un script PowerShell permettant de supprimer toutes (sauf les applications ayant dans le champs description la chaîne de caractère #NOT_DELETE#) les applications désactivées d’une ferme.

Les actions du script :

Sauvegarde dans le répertoire courant des applications désactivées
Suppression des applications désactivées (hors application ayant dans le champs description la chaîne de caractère #NOT_DELETE#)
Suppression des sauvegardes supérieur à 180 jours (dans le répertoire courant)

54 applications (soit deux de plus en l’espace d’une journée) en moins dans une de nos fermes XenApp 5 R07

Le Get-XaApplication prenait 5,40 secondes pour 580 applis dans la ferme

On tombe à 4,64 secondes une fois les 54 applications supprimés 😉

Pour restaurer une application lancez la ligne de commande ci-dessous :

import-Clixml "\\YourPath\Backup\App.xml"|New-XAApplication

App_DisableDelete.ps1

Retour “Qfarm /load” vide…. Le retour

Nous revoilà avec un problème de commande Qfarm /Load (voir notre billet “Retour «Qfarm /load vide“) qui ne retourne aucune charge serveur dans l’une de nos fermes (XA65 R01 US Sp1).

Comme le Qfarm /load ne retournait rien, nous sommes passés par un Get-XaServerLoad qui nous a retourné l’erreur :

Get-XaServerLoad : Exception has been trown by the target of an invocation

On comprend que l’un de nos serveurs XenApp ne répond pas correctement au Get-XaServerLoad

Afin de trouver le serveur en question on lance un “Get-XAserver|%{Get-XAServerLoad $_.Servername}“, Ce qui nous a permis de trouver le serveur qui ne répondait pas au Get-XAServerLoad.

On test un Qfarm /load Serveur1 (remplacez Server1 par votre serveur) qui nous répond que l’IMA n’est pas disponible (tout du moins pour cette requête)

Une fois sur le serveur en question nous rencontrons l’event Event ID 3609 “Failed to load plugin C:\Program Files (x86)\Citrix\System32\Citrix\IMA\SubSystems\ImaAppSs.dll with error IMA_RESULT_WRITE_TO_LOG_FAILED” qui nous amène à la CTX134504.

La lecture de la CTX134504 met en évidence que le problème vient du CitrixLogServer COM+ qui ne repond pas.

Du coup direction le Service des composants (comexp.msc), en développant Console Root-Component Services-Computer-COM+Application nous tombons sur l’erreur :

An error occurred while processing the last operation. Error code 8007042C – The dependency service or group failed to start

Ok ça risque pas de fonctionner la 🙂

En regardant les dépendances du Service Application système COM+ ( COM+ System Application) nous constatons que le service Système d’événement COM+ (System Event Notification Service ) était désactivé. Une fois le service service Système d’événement COM+ activé et démarré le Qfarm /load retournait bien les valeurs de charge de tous les serveurs membre de la ferme.

Check des services XenApp 6.5

Suite à une campagne de patchs MS, un nombre important de serveurs XenApp (60 sur 700) avait des services XenApp (et non XenApp comme le spooler par exemple) non démarrés (RadeSvc, CtxSmartCardSvc, cpsvc) sur une de nos fermes XenApp 6.5 R01 Us.

Vu que les services démarraient sans problème manuellement sur plusieurs serveurs et ne tombaient pas une fois démarré (et qu’il fallait rendre le service ASAP), nous sommes passés par la case PowserShell afin de checker l’état des services XenApp (les principaux) et de démarrer les services qui ne l’étaient pas (on a bien sûr gardé quelques serveurs sous le coude histoire de comprendre ce qui a bien pu se passer).

Deux serveurs sur deux dans notre lab ont des services arrêtés (que fait le pilotage 🙂 ).

En relançant le script on constate que les services ont bien été démarrés.

CheckServiceXenApp.ps1