XenApp – Page 14

Erreur : [com.citrix.xml.NFuseProtocol.RequestAppData] sur WI 5.3

Lors d’un troubleshooting avec Menhir Two sur des problèmes d’accès à nos WI, nous sommes tombé sur l’event suivant sur une de nos Web Interface :

ID de l’événement : 30110
Une erreur de type IMA avec un ID d’erreur 0x80000001 a été signalée par le service XML Citrix à l’adresse http://ServeurWi/Site/scripts/wpnbr.dll [com.citrix.xml.NFuseProtocol.RequestAppData]. En fonction du serveur exécutant le service XML, de plus amples informations sont disponibles dans le journal des événements du serveur. La transaction de ce service XML Citrix a échoué, mais le service XML n’a pas été supprimé de la liste des services actifs. [ID de journal unique : ad65cd59]

Suivi de l’event 31003 :

ID de l’événement : 31003
Description :Chemin d’accès au site : c:\inetpub\wwwroot\SiteWi.
Aucun des services XML Citrix configurés pour la batterie VotreBatterie n’ont répondu à cette transaction de service XML. [ID de journal unique : 8f5a64b8]

Puis revient l’event 30110 :

ID de l’événement : 30110
Description :Chemin d’accès au site : c:\inetpub\wwwroot\VotreSiteWi.
Une erreur de type IMA avec un ID d’erreur 0x80000001 a été signalée par le service XML Citrix à l’adresse http://ServeurXml:Port/scripts/wpnbr.dll [com.citrix.xml.NFuseProtocol.RequestValidateCredentials]. En fonction du serveur exécutant le service XML, de plus amples informations sont disponibles dans le journal des événements du serveur. La transaction de ce service XML Citrix a échoué, mais le service XML n’a pas été supprimé de la liste des services actifs. [ID de journal unique : 8c20c93a]

Le RequestValidateCredentials est explicite, donc direction nos Xml Broker 🙂 .

Sur un de nos Xml Broker nous retrouvons bien une erreur dans le journal de sécurité (event 4625).

ID de sécurité :                 SERVICE RÉSEAU
Nom du compte :                         XMLBROKER$
Domaine du compte :                   DOMAINE
ID d’ouverture de session :                        0x3e4
Type d’ouverture de session :                                  3
Compte pour lequel l’ouverture de session a échoué :
ID de sécurité :                 NULL SID
Nom du compte :                           Le compte Utilisateur ne pouvant pas s’authentifier
Domaine du compte :                   DOMAINE
Informations sur l’échec :
Raison de l’échec :                         L’utilisateur n’est pas autorisé à ouvrir une session sur cet ordinateur.

Avec la raison de l’échec nous avons une piste, un petit tour sur une DSA.msc, et une petite recherche sur l’objet utilisateur causant problème.

Effectivement notre user ne risquait pas de s’authentifier sur nos XML Broker 🙂

il nous reste a communiquer aux admins qu’on évite ce genre de restriction dans notre environnement sinon ldap389 va pas être content 😉 .

Erreur : Echec d’observation. Code Erreur 120

Si vous rencontrez l’erreur 120 (dans une ferme XenApp 6, Windows 2008 R2 sans sp1 dans notre cas) lors d’une demande d’observation de session utilisateur via une DSC publiée en seamless, et à partir d’un poste muni de deux écrans avec un client online plug-in 12.0/12.1), et bien votre utilisateur va devoir patienter un peu avant votre intervention 🙂 .

L’erreur se produisant uniquement lorsque la DSC est publiée en seamless, une solution (en attendant un fix 😉 ) plutôt sympa est de publier la DSC dans un CDViewver.

Afin de publier votre DSC via un CDViewver, il vous suffit de modifier le fichier default.ica de votre site PNA (et oui nous sommes nostalgique 🙂 ) en rajoutant la ligne suivante (voir aussi notre billet sur ce sujet) :

ConnectionBar=1

Quelques liens sur l’erreur 120 :
http://zenapp.blogspot.com/2010/12/shadowing-in-xenapp-6.html
http://forums.citrix.com/message.jspa?messageID=1466022

XenApp 6 erreur 3601 – Echec de chargement…..RADESessionSs.dll

Sur un de nos serveurs XenApp 6 fraîchement installé, nous venons de rencontrer l’erreur suivante :

ID de l’événement : 3609
Échec de chargement du module C:\Program Files (x86)\Citrix\System32\Citrix\IMA\SubSystems\RADESessionSs.dll. Erreur IMA_RESULT_FAILURE

Après quelques recherches, nous avons remarqué que notre fichier RadeOffline.dsn (C:\Program Files (x86)\Citrix\Independent Management Architecture) ne contenait pas les infos permettant la connexion sur la base RadeOffline.mdb .

En googlelant nous sommes tombés sur ce post (forum citrix), dans notre cas il a fallu supprimer le contenu du RadeOffline.dsn et le remplacer par :

[ODBC]
DRIVER=Microsoft Access Driver (*.mdb)
PageTimeout=5
MaxBufferSize=2048
FIL=MS AccessDriverId=25
DBQ=C:\Program Files (x86)\Citrix\Independent Management Architecture\RadeOffline.mdb

Une fois le fichier RadeOffline.dsn correctement renseigné nous avons lancé un “dsmaint recreathrade”, puis nous avons pu relancer le service IMA sans erreur.

Disponibilité du HMRTestPack4 pour XenApp 5 (Windows 2003)

Citrix vient de mettre en ligne le HMRTestPack4 (only XenApp5/Windows 2003),.

Le HMRTestPack4 résoud quelques bugs et introduit le support du /Silent de LHCTestAclsUtils.exe

Le HMRTestPack4 est disponible sur la CTX127154, reste plus qu’à mettre à jour vos serveurs qui sont HMRTestPack3 🙂 .

Erreur 25602. Impossible d’obtenir la longueur de la propriété CustomActionData dans la fonction ParseCADProperty

Lors d’une désinstallation d’une PS 4.0 nous avons rencontré l’erreur :
“Erreur 25602. Impossible d’obtenir la longueur de la propriété CustomActionData dans la fonction ParseCADProperty.”
ID 1005 – Souce : MSInstaller

Le serveur sur lequel cette erreur a été rencontrée est un serveur en Windows 2003 enterprise sp2 Fr avec PS 4.0 R06.

Plutôt que de partir dans un troubleshooting compliqué, connectez-vous en admin et en console sur le serveur puis désinstaller la version XenApp, ça pourrait vous éviter un long pèlerinage 🙂 .

Un post sur Citrix.com traite cette erreur (bien que le post soit à la base pour une PS 4.5, dans notre cas il était aussi valable en PS 4.0).

GET-XAServerConfiguration = effet de bord

Nous avons rencontré (toujours avec Menhir Two 😉 ) un effet de bord de la cmdlet “GET-XAServerConfiguration” (en CTP V3 non up to date)

En effet lors de l’appel de la cmdlet, nous obtenions l’erreur suivante : “Failed to read all bytes in a wint value“.

L’effet de bord lui était surprenant (surtout pour un GET 😉 ) :

Et voila plus de serveur de licence au sein de la ferme XenApp 🙁 (cependant si vos serveurs n’ont pas l’héritage d’activé pour la partie serveur de licence, l’effet de bord n’aura aucun impact) .

L’effet de bord est connu (notamment sur ce post sur le forum Citrix Us).

La solution est de mettre à jour les Cmdlet (au préalable il vous faut désinstaller le CTP (Command Technology Preview), puis installer la dernière version CTP (dans notre cas celle du 13/01/11)

Une fois les Cmdlets à jour la commande GET-XAServerConfiguration fonctionne nickel et sans aucun effet de bord.

Erreur : Le Serveur n’a pas réussi à allouer de la mémoire paginée du pool système car celui-ci est vide.

Sur des serveurs (2003 Fr Sp2) membre de ferme XenApp 5 R06 ou XenApp 4.5 R01, nous avons rencontré des erreurs de type “Le Serveur n’a pas réussi à allouer de la mémoire paginée du pool système car celui-ci est vide” (Source : Srv – Id : 2020).

Les conséquences de cette erreur sur les serveurs en question étaient :

Impossibilité d’ouvrir une mmc
Task manager indisponible
Accès impossible aux propriétés system
Erreurs RPC
Freez de l’OS

En googlelant nous sommes tombés (avec Menhir Two) sur la KB27560 (voir aussi la KB923360) qui explique que ce problème peut se produire avec les versions 7.00, 7.01, 7.02, 7.03 ou 8.0 de Norton Antivirus installées sur des DC en Windows 2000 Server (dans notre cas nous étions en 8.1.0.821 avec un moteur d’analyse en 4.2.0.7 et pas sur des DC).

La résolution s’est faite en désinstallant la version 8.1.0.821 de Norton anti-virus et en passant à la version SEP11 (il ne reste plus qu’a scripter tout ça 🙂 ).

Best Practices pour les administrateurs XenApp

Citrix vient de mettre en ligne (15/12/2010) la CTX127574 “Best Practices for XenApp Administrators”.

La CTX127574 comprend les 10 Best Pratcices minimum à mettre en place lors de l’installation d’une ferme XenApp.

Mettre en place une sauvegarde régulière du DataStore (CTX677542)
Mettre en place une ferme XenApp de qualification
Se maintenir informer des mises à jour et correctifs pouvant s’appliquer à votre environnement (CTX120842 et CTX127228)
Mettre en place une gestion du changement (Faire une recherche “Journalisation de la configuration” sur Citrix Edocs)
Mise en place d’une (ou plusieurs) stratégie d’impression (CTX111967, CTX126093 et CTX119815)
Se familiariser avec les outils de débogage (CTX122827 et CTX126294)
Se familiariser avec les dump mémoire (KB254649, CTX105888 et CTX466627)
Comprendre les notions de Zone(s) et Zone Data Collector (faire une recherche “Zones” sur Citrix Edocs et lire la CTX126335)
Monitorer la ferme XenApp (faire une recherche “Health Monitoring and Recovery” sur Citrix Edocs et lire la CTX107935)
S’assurer que les utilisateurs se connectent à la ferme XenApp avec un client correctement configuré et à jour ( (faire une recherche “Receiver and Plug-in” sur Citrix Edocs)

Lenteur lors de la “négociation des capacités…” d’une connection ica

Si lors de connexion ICA on vous remonte des lenteurs lors de la négociation des capacités, le problème pourrait venir d’un certificat Terminal Service qui serait endommagé sur un de vos serveurs XenApp.

Dans notre cas nous avons supprimé les valeurs de registre ci-dessous puis rebooté le serveur XenApp en question afin qu’un certificat soit régénéré.

Les valeurs de registre à supprimer se trouvent dans HKLM\System\CurrentControlSet\Services\TermService\Parameters :

Certificate
X 509 Certificate
X 509 Certificate ID

Une fois le reboot effectué les clés seront recrées.

PNA et SSO sur un serveur Terminal Server

Une fonction très pratique du PNA est la fonction SSO (Single Sign-On).

L’avantage du SSO est que si vous publiez un bureau sur un serveur XenApp avec un PNA et le SSO activé, les utilisateurs obtiendront la liste des applications publiées via leur PNA et cela sans authentification.

Imaginons maintenant que vous souhaitez activer le SSO d’un PNA sur un serveur “Terminal Serveur” (sans couche XenApp), là vous aurez l’agréable surprise de constater que cela ne fonctionne qu’en mode console.

En effet le SSO du PNA ne fonctionne sur un serveur Terminal Server, que si la couche XenApp est installée, sympa la Feature 😉 .

Ce fonctionnement n’est pas un bug, la CTX108808 en témoigne.

Cette Feature ne semble pas être connue de tous et nous remercions tout ceux qui ont participé à cette “discutions” 🙂 .