Si vous recherchez des informations sur qui et quoi monitorer sur vos ferme XenApp, Citrix vient de sortir un white paper fort intéressant : “Operations Guide – Monitoring“.
Category: XenApp
Erreur Sql : Échec de la négociation SSPI avec le code d’erreur 0x8009030c
Sur un serveur Sql 2008 R2 nous avons rencontré l’erreur suivante :
Nom du journal : Application
Source : MSSQLSERVER
ID de l’événement :17806
Description : Échec de la négociation SSPI avec le code d’erreur 0x8009030c, état 14 lors de l’établissement d’une connexion avec une sécurité intégrée ; la connexion a été fermée. Raison : Échec d’AcceptSecurityContext. Le code d’erreur Windows indique la cause de l’erreur. [CLIENT : 10.101.xxx.xxx].
En allant sur le serveur CLIENT (serveur XenApp 6.5) indiqué dans la description de l’event nous avons trouvé l’event suivant :
Source : IMAService
ID de l’événement :3989
Description : Le serveur Citrix XenApp n’a pas pu se connecter au magasin de données. Une erreur ODBC s’est produite lors de la connexion à la base de données : 28000 -> [Microsoft][ODBC SQL Server Driver][SQL Server]Échec de la connexion. La connexion provient d’un domaine non approuvé et ne peut pas être utilisée avec l’authentification Windows.
Nous avons trouvé un article chez SarePoint It Prof qui traite ce type de problème.
Deux solutions sont possibles (celle du registre est à réserver pour un environnement de qualif, sinon ldap389 risque de ne pas être content 😉 ) .
- jouer avec le registre :
- Edit the registry using regedit. (start –> run … Regedit )
- Browse to : HKLM\System\CurrentControlSet\Control\LSA
- Add a DWORD value called “DisableLoopbackCheck”
- Set this value to 1
- Modifier le spn : SetSpn -A MSSQLSvc/sql.mb.local:1433 MB\sql_service
Erreur “Another Version of Microsoft Visual Studio 2008 has been Detected on this System” sur serveur XA 6.5
Sur un serveur XenApp 6.5 nous avons installé Sql 2008 R2 standard (c’est de la qualif 🙂 ), le problème est que l’installation de SSMS (SQL Server Management Studio) n’a pu aboutir.
Dans le journal “application” nous avons trouvé l’event suivant :
Nom du journal :Application
Source : MsiInstaller
ID de l’événement :1013
Description : Product: Microsoft Visual Studio Tools for Applications 2.0 – ENU — Another version of Microsoft Visual Studio 2008 has been detected on this system that must be updated to SP1. Please update all Visual Studio 2008 installations to SP1 level, by visiting Microsoft Update.
La CTX128280 explique comment bypasser cette erreur en renommant la clé HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VS.
Une fois la clé HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VS renommée, nous avons pu installer SSMS (n’oubliez pas de renommer la clé une fois SSMS installé).
EventId 1004 (IIS-W3SVC) sur serveur XenApp 6.0
Lors d’un test sur un serveur de qualif XenApp 6.0 nous avons installer la partie Web Interface (5.4), suite à l’ajout du rôle IIS nous avons rencontré l’event system suivant :
Source : Microsoft-Windows-IIS-W3SVC
ID de l’événement :1004
Le service de publication World Wide Web (service WWW) n’a pas inscrit le préfixe d’URL http://*:80/ pour le site 1. Le site a été désactivé. Le champ des données contient le numéro de l’erreur.
Lors de l’installation de notre ferme de qualif , nous avions (exceptionnellement 🙂 ) laissé le port 80 pour l’Xml, du coup lors de l’installation de IIS le port 80 pour le site par défaut n’était pas disponible.
Effectivement ctxxmlss prend bien le port 80
Changer le port xml est très simple et se fait via la commande ctxxmlss /RXXXX (dans notre cas on affectionne le port 8085).
Le port xml est bien passé sur le 8085
ctxxmlss est bien sur le 8085 désormais
Erreur Dscheck : HostID xxxx has no corresponding MfServer node entry
Suite à un dscheck (dscheck /full servers) sur une de nos fermes (XenApp 5 R06 de 400 serveurs avec un DataStore sql 2005 sur Windows 2003 sp2 ), nous avons remarqué l’erreur suivante :
HostID xxxx has no corresponding MfServer node entry
Après plusieurs dscheck /full servers /clean l’erreur était toujours présente.
Nous avons lancé un Dsview afin de voir si on pouvait résoudre le HostID 5C80 en cherchant dans la partie ServerNeighborhoods-VotreFerme-MFServers.
Comme nous n’avons rien trouvé dans la partie ServerNeighborhoods-VotreFerme-MFServers, nous avons orienté notre recherche vers la partie ServerNeighborhoods-VotreFerme-HostIds.
Nous trouvons et remarquons que le HostId 5C80 a des liens avec d’autres HostId (au passage on ne l’a pas vu du premier coup 🙁 ).
Retour dans la partie ServerNeighborhoods-VotreFerme-MFServers, et là nous trouvons bien les hostId avec les Hostnames associés.
Après avoir sorti les 4 serveurs de la ferme (bien que ces serveurs ne présentaient visiblement aucun problème), la commande dscheck /full servers /clean a cette fois-ci bien supprimé le HostId récalcitrant (5C80 dans notre cas).
Une fois le Host Id supprimé nous avons pu ré-intégrer les quatres serveurs dans la ferme puis passer un dscheck /full servers qui n’a remonté aucune erreur 🙂 .
On vous passe les différentes étapes de troubleshooting, dsview (mais avec les yeux fermés les premières fois), tentative de lecture du DataStore (mais bon vu que la base n’est pas de type relationnelle on se savait mal parti), import du DS dans une batterie de test et suppression des objets, etc..etc.. En bref un moumoutage en bonne et due forme 🙂 .
Script : Désactivation SpeedScreen via les MFCOM
Dans une de nos fermes de prod (XenApp 5 R06 sur Windows 2003 Sp2 Fr), nous avons eu besoin de désactiver l’accélération de navigation HDX 3D (SpeedScreen) sur un silo applicatif.
Nous avons réalisé un script wsf (ça faisait longtemps qu’on n’avait pas mis les mains dans les MFCOM 🙂 ) afin de pouvoir désactiver dans un premier temps l’héritage des paramètres de la batterie (puisque dans notre cas le SpeedScreen était paramétré au niveau de la batterie), puis de désactiver l’accélération de navigation HDX 3D (le script filtre les serveurs en fonction du hostname, voir ligne 67 du script).
Une fois les infos trouvées sur la bible des MFCOM, la lecture est lourde mais à chaque fois payante 🙂 .
Avant le script
Après le script
SpeedScreen_Disable.wsf
XenApp_Check compatible XenApp 6
XenApp_Check est désormais comptatible XenApp 6 🙂 et disponible ici .
Le code est fonctionnel mais pas encore optimisé 
.
Le fonctionnement reste identique à XenApp_check pour XA5, à la différence qu’il faut configurer le mode policy via les lignes 58 et 64 du script XenApp_CheckXA6.ps1
Les principales étapes entre le login dans une WI et le lancement d’une application.
Par pur hasard nous sommes tombés aujourd’hui sur la CTX129585.
Cette CTX énumère les principales étapes entre le login sur une Web Interface et le lancement d’une application via la Web Interface (dans un environnement XenApp 6, bien que la plupart des étapes restent valables sous XenApp 5 par exemple), idéal pour comprendre les interactions entres les Web Interface, xml broker, Domaine Controleur, Zone date collector etc… 🙂 .
RecreateLHC sur plusieurs serveurs
MAJ : 04/03/2012
Version 1.1
Ajout de la compatibilité 64 bits
—————————————
Dans ce billet un petit script qui permet de faire des RecreateLhc sur plusieurs serveurs avec un fichier de log, permettant de vérifier chaque étape du RecreateLhc sur chaque server.
Utilisation du script Ctx_RecreateLHC.vbs :
- Créer dans le répertoire ou est situé Ctx_RecreateLHC.vbs un fichier nommé “servers.txt” et rentrer le nom des serveurs où sera recrée la LHC.
- Double cliquer sur Ctx_RecreateLHC.vbs
- Un fichier de log au format html sera créé dans le répertoire d’exécution de Ctx_RecreateLHC.vbs
Le détails des actions du script est contenu dans le fichier log (arrêt service IMA et de ses dépendences, vérification de la taille de la base LHC, dsmaint recreatelhc, vérification de la taille de la base LHC (après RecreateLhc), démarrage des dépendances du service IMA et du service IMA)
Le script fonctionne sur des fermes XenApp 5/6 sous windows 2003/2008 (32/64 bits) (prochaine étape XenApp 6/6.5 🙂 ).
La CTX759510 préconise elle de son côté, de faire un recreatelhc sur tous les serveurs membre d’une ferme après un DSCHECK /clean (de notre côté nous procédons par vague de serveurs)
If you must clean the farm data store, using the DSCHECK utility, you should then rebuild the LHC on each of the servers in your farm, once the data store has been cleaned.
Ctx_RecreateLHC.vbs
Erreur Web Interface : Certaines de vos ressources n’ont pas été reconnectées.
Sur une de nos Web Interface (Windows 2003 Sp2 Fr, WI 5.3), nos utilisateurs rencontraient le message suivant après l’authentification :
Certaines de vos ressources n’ont pas été reconnectées. Si ce message n’apparaît pas durant vos sessions, contactez votre administrateur système.
Sur le serveur hébergeant la Web Interface, nous avions l’erreur suivante :
ID de l’événement : 31007
Source : Citrix Web Interface
Description :
Chemin d’accès au site : c:\inetpub\wwwroot\Votre Site Wi.
Les licences des serveurs Citrix ne leur permettent pas de prendre en charge le contrôle de l’espace de travail. Ce message a été signalé depuis le service XML à l’adresse http://votre XmlBroker:8085/scripts/wpnbr.dll [com.citrix.xml.NFuseProtocol.RequestReconnectSessionData]. [ID de journal unique : f22dc6c8]
L’event étant explicite, direction l’XMLBroker en question sur lequel nous trouvons l’event suivant :
Type de l’événement : Erreur
Source de l’événement : MetaFrame
ID de l’événement : 9014
Description :
Les licences requises par cette édition de Citrix Presentation Server ne sont pas présentes sur le serveur de licences VotreServerDeLicence.
Le telnet sur notre serveur de licence (port 27000) étant ok et le serveur de licence ne présentant pas de problème, nous avons regardé du côté du fichier de cache de licence du serveur XmlBroker.
Après avoir renommé le fichier MPS-WSXICA_MPS-WSXICA.ini (fichier de cache licence) , le problème et l’event avaient disparu.