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 :
A l’époque les migration étaient plus faciles 🙂
