Slow Logon Archive

2

Lenteur ouverture de session : Please wait the for Local Session Manager

Suite à la migration d’un silo d’une ferme Xa 6.5 R06 vers un silo d’une ferme XA 7.6 (LTSR, Vda 7.1000) nous avons constaté (enfin nous et les utilisateurs) des lenteurs au logon des utilisateurs (lenteurs qui n’existaient pas avant en Xa6.5 et qui ne sont pas apparus lors de la migration de la qualif).

Lors du lancement des applications, les utilisateurs restaient bloqués pendant 30 secondes sur le message « Please wait for the local session Manager », et comme on avait déjà rencontré le problème, cette fois nous en avons profité pour faire un billet 😉 .

 


Allô le support informatique, oui votre migration c’est pas mal mais vous livrez le café pendant l’authentification ?

 

Afin de retrouver des temps de logon acceptable il faut (dans notre cas) ajouter deux clés dans la base de registre (HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\GroupPolicy) de chaque serveurs XenApp :

 

[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\GroupPolicy]

« CacheGpoExpireInHours »=dword:00000005

« GpoCacheEnabled »=dword:00000001

 

Redémarrez le service « Citrix Group Policy Engine (merci Fred pour la remarque).

Une fois les deux valeurs ajoutées, les temps de logon sont redescendus sous la barre des 30 secondes.


A l’époque les migration étaient plus faciles 🙂

 

 

 

 

6

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

squelette devant pcun 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 KB973772KB977346KB2409711 et KB977346.

Logon_SchemaSché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)

Logon_Schema1Le 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

 

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

 

Xperf02La trace une fois ouverte

 


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

 

Xperf04Maintenant 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

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

 

Xperf06

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.

 

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

 

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