XenApp – Page 5

StoreFront 3.x erreur : Impossible de démarrer le bureau…….

Sur un cluster de StoreFront 3.0 (W2K12 US) nous avons rencontré un problème de lancement d’applications et bureaux publiés (ferme en XA 7.6 US) avec Internet Explorer (ver 9,10 et11), en effet cela fonctionnait sans problème avec Firefox et Chrome.

On va pas se réconcilier de si tôt avec IE

En regardant sur les Storefronts nous avons constaté les Event ID 0 et 28.

Description: Failed to launch the resource ‘………………’ using the Citrix XML Service at address ‘http://VotreServeur/scripts/wpnbr.dll’. The XML service returned error: ‘not-trusted’.

Description: The Citrix servers do not trust the server. This message was reported from the XML Service at address http://VotreServeur/scripts/wpnbr.dll [NFuseProtocol.TRequestAddress].

Ce qui nous a mis sur la piste est bien sur le “The Citrix servers do not trust the server”, en effet en lancant un Get-BrokerSite sur un de nos Delivery Controller nous avons constaté que la valeur TrusRequestsSentToTheXmlServicePort était à False.

SF3Error4 On vous l’accorde ça n’explique pas le fait que ça fonctionne avec d’autres navigateurs

Afin d’activer le TrustRequestSentToTheXmlServicePort il faut lancer la commande suivante sur un de vos Delivery Controller : Set-BrokerSite -TrustRequestSentToTheXmlServicePort $True

La commande Get-BrokerSite confirme bien que nous sommes en True en TrustRequestSentToTheXmlServicePort

Et oui avant on pouvait setter l’approbation des requêtes XML en policy (exemple sur une ferme en XA 6.5)

Erreur : Please wait for the Local Session Manager

Au détours d’une visite cordiale chez nos collègues de l’admin nous avons rencontré un problème de lancement d’application/bureau sur une des fermes XenApp 7.6 (US).

Les utilisateurs rencontraient l’erreur “Please wait for the local Session Manager” lors du lancement d’une application, et restaient bloqués sur l’écran “Welcome” lors du lancement d’un bureau publié.

Un problème sur les profiles ?

En regardant dans Director on a remarqué des erreurs de licence lors des tentatives de connexion des utilisateurs.

C’est sur que s’il n’y a pas de licences ça ne va pas le faire

Direction Studio, et vérification du licensing 😉 .

Ça confirme le problème de licence 😉 (une mise à jour des licences ayant été faite)

Une fois le modèle de licence changé les utilisateurs ne rencontraient plus de problèmes pour lancer leurs applications/bureaux

Soyez indulgent avec les screenshots (fait dans l’urgence 😉 ).

Une histoire de route

Lors d’une installation d’une nouvelle ferme XenApp 7.6 (Wk2K12 R2 US) nous avons rencontré l’erreur “XDDS:17647403” lors de la Connection (Add Connection and Ressources) à un de nos vCenter (5.1.0).

Ca fait un bail qu’on avait pas une ferme XenApp à la mano

Un peu plus de détails sur notre erreur

En regardant l’erreur de plus près on constate que le vCenter n’est pas joignable :

Error Id: XDDS:17647403
Exception:
Citrix.Console.Common.CitrixAggregateException One or more parallel operations failed
at Citrix.Console.Common.CitrixParallel.InternalForEach[TIn](IEnumerable`1 items, Action`1 operation, Int32 maxSimultaneous)
at Citrix.Console.PowerShellSdk.HypervisorService.Scripts.TestHypervisorConnectionScript.RunScript()
at Citrix.Console.PowerShellInteraction.PowerShellScript`1.Run()
at Citrix.Console.Hypervisors.UI.Pages.HypervisorDetailsPageViewModelBase.ValidatePage()
at Citrix.Console.CommonControls.Wizard.PageContainerViewModel.<>c__DisplayClass3.<ValidateAndMoveToPage>b__2()
DesktopStudio_PowerShellHistory : TestHypervisorConnectionScript
…….
…….
DesktopStudio_ErrorId : HypervisorNotContactable

Effectivement on constate qu’un telnet sur le port 443 à destination de notre vCenter ne passe pas à partir du futur Controller (DDC).

En regardant de plus près (pour être honnête on vous passe les différentes étapes qui nous ont amené là) nous avons constaté dans une trace Wireshark que l’IP de notre Vcenter n’apparaissait pas, vu que nous avons deux cartes réseaux sur notre VM (une pour le backup sur une VLAN différent et l’autre pour la prod) nous changeons l’interface dans Wireshark et relançons une trace et nous constatons que l’IP de notre Vcenter apparaît bien dans notre trace.

En lançant un route print nous constatons que ça ne risquait pas de fonctionner notre histoire :), au passage on vous conseille NetRouteView pour afficher via une GUI les routes d’un serveur.

On constate que la destination 0.0.0.0 à deux routes avec chacune un carte réseau différente renseignée.

Une fois la route 0.0.0.0 pointant sur la carte réseau de backup supprimée nous avons pu joindre notre vCenter (au passage, en comparant avec d’autres serveurs seules les nouveaux serveurs livrés avait ce problème de route).

On va allez papoter avec la DDE 🙂

Zabbix : Template XenApp 7.x

Cela faisait longtemps qu’on en parlait, cette fois on s’y est collé 🙂 .

Nous avons donc mis en place un template Zabbix orienté XenApp 7.x permettant une supervision et un monitoring de base (comprenant les parties OS et Citrix)

Le template regroupe trois templates :

Template Windows 2012
Template DDC
Template Worker

Les graphs cpu, mémoire, swap et disque sont disponibles via l’écran screen de chaque host

Items Template Windows 2012 :

Agent ping
Free disk space %
Free swap space
Incoming network traffic (sur toutes les cartes)
Outgoing network traffic (sur toutes les cartes)
Memory_usage
Memory_usage %
Port 135MSRPC
Port 139NetBIOS-ssn
Port 445NetBIOS-ssn
Processor % Load
Service DNS Client
Service Group Policy Client
Service Local Session Manager
Service Netlogon
Service Print Spooler
Service Remote Procedure Call (RPC)
Service RPC Endpoint Mapper
Service Security Accounts Manager
Service Server
Service User Profile Service
Service Windows Event Log
Service Windows Management Instrumentation
Service Windows Time
Service Workstation
Swap space (total)
Swap space used
System uptime
Total disk space
Total memory
Used disk space

Items Citrix XA_XD 7.x Worker :

Service Citrix Stack Control Service
Service Citrix Smart Card Service
Service Citrix Services Manager
Service Citrix Pvs for VMs agent
Service Citrix Profile Management
Service Citrix Print Manager Service
Service Citrix MultiTouch Redirection Service
Service Citrix Mobile Receiver Virtual Channel
Service Citrix Location and Sensor Virtual Channel Service
Service Citrix HDX MediaStream for Flash Service
Service Citrix Group Policy Engine
Service Citrix End User Experiencing Monitoring
Service Citrix Encryption Service
Service Citrix Diagnostic Facility COM Server
Service Citrix Device Redirector Service
Service Citrix Desktop Service
VDA Total sessions
VDA Total Desktop sessions
VDA Total App sessions

Items Citrix XA_XD 7.x DDC :

Citrix Database connected
Service Citrix Storefront Service
Service Citrix Storefront Privileged Administration Service
Service Citrix Monitor Service
Service Citrix Machine Creation Service
Service Citrix Host Service
Service Citrix Environment Test Service
Service Citrix Diagnostic Facility COM Server
Service Citrix Delegated Administration Service
Service Citrix Configuration Service
Service Citrix Configuration Logging Service
Service Citrix Broker Service
Service Citrix Analytics
Service Citrix AD Identity Service

Vous pouvez aussi importer ce template dans MonitorX .

Zabbix_Template_XaXd_7x.xml

XenApp_Gpupdate v1.1

Mise à jour de XenApp_Gpupdate (ver 1.1).

Ajout de la possibilité d’afficher la liste complète des serveurs membres de la ferme (via le bouton “Servers”)
Ajout de la possibilité de rechercher un serveur spécifique (via la coche “Search server”)
Retour du statut de la commande Gpupdate /force (indique si le process a bien été lancé sur le serveur et si ce dernier est bien fermé.), avec la durée d’exécution (duration) par serveur
Correction de bugs mineurs

XenApp_Gpupdate.rar

Le billet original sur XenApp_GpUpdate ici.

MonitorX (us version)

MonitorX is a Zabbix non-official appliance dedicated to “XenApp” (which uses the XenApp 6.5 template). It allows you to monitor your XenApp 6.5 environment, including your Web Interface/StoreFront/NetScaler 10.x.

The appliance runs on a Debian Wheezy 7.8 (2 vCPU, 4Gb RAM and 40Gb thin provisioned disk), configured to use DHCP with the following modules:

apache2
mysql-server + mysql-client
php5-mysql libapache2-mod-php5
phpmyadmin
zabbix 2.4.4
zabbix agent 2.2.7

Continue reading “MonitorX (us version)”

MonitorX (fr version)

MonitorX est une appliance non officielle ZABBIX dédiée “XenApp” (qui reprend notamment le template XenApp 6.5), permettant rapidement et simplement de superviser/Monitorer un environnement XenApp 6.5 (avec ses Webi /StoreFront/Netscaler 10x. ).

L’appliance repose sur une Debian Wheezy 7.8, (2 Vcpu, 4Go de ram et 40 Go de DD en thin) en DHCP (le mot de passe root est “password!01” on vous conseille fortement de le changer) avec les modules ci-dessous :

apache2
mysql-server + mysql-client
php5-mysql libapache2-mod-php5
phpmyadmin
zabbix 2.4.4
zabbix agent 2.2.7

Au préalable, si vous ne connaissez pas ZABBIX , nous vous conseillons d’aller faire un tour sur http://www.zabbix.com et http://www.monitoring-fr.org/solutions/zabbix/.

Dans un premier temps, veuillez décompacter le fichier MonitorX.rar (607 Mo), une fois décompacté vous obtenez deux dossiers :

Le dossier OVA qui contient l’ova à importer
Le dossier Zabbix_agent qui contient l’agent zabbix windows (avec le script permettant l’installation de l’agent et le service associé)

Installation de l’appliance :

Importez dans votre hyperviseur favori l’ova “MonitorX.ova” (dans notre cas Esxi 5.5)
Configurez la partie IP si vous ne souhaitez pas rester en DHCP (attention si vous changez le nom du Hostname (ZAB01 par défaut), pensez à changer aussi le nom du hostname dans Zabbix, voir en fin de billet)
1. Connectez-vous en SSH (via PuTTY par exemple et choisissez le menu 5) via le compte root (mot de passe : password!01)

Les fans de Sexilog auront reconnu le SexiMenu que nous avons adapté à MonitorX 🙂

Lancez dans un navigateur l’url “http://IpMonitorX”

MonitorX_acceuile_Zabbix Renseignez les champs Username (admin) et Password (zabbix)

Activation du serveur Zabbix :

Allez dans Configuration-Host

Cliquez sur Disabled afin d’activer la supervision/monitoring serveur Zabbix

Ajout des hosts :

Déploiement de l’agent Zabbix sur vos serveurs XenApp
1. Copiez le répertoire “Zabbix_Agent_Install” sur un serveur d’administration de votre ferme XenApp.
2. Exécutez dans une console PowerShell le script “Zabbix_Agent_Install.ps1”.
3. Via le menu vous pourrez :
  – Modifiez l’IP du server Zabbix (renseigné dans le fichier zabbix_agentd.win.conf)
  – Déployez l’agent Zabbix sur tous les serveurs membres de la ferme XenApp en cours
  – Ouvrir et modifiez le fichier contenant la liste des serveurs sur lesquels vous souhaitez déployer l’agent Zabbix ( si vous ne souhaitez pas déployer l’agent Zabbix sur tous les serveurs membres de la ferme XenApp en cours)
  – Déployez l’agent Zabbix sur les serveurs inscrits dans le fichier Servers.txt

La première étape est de changer l’IP du serveur Zabbix configuré par l’IP de votre serveur MonitorX (menu 1)
Une fois le déploiement terminé, un fichier de log (StatutAgentInstall.txt) est disponible dans le dossier Zabbix_Agent_Install.

Ajoutez vos hosts dans Zabbix
1. Via le discovery rule “XenApp_Discover” (allez dans Configuration-Discovery, modifiez le range IP de la règle “XenApp_Discover”, activez la règle et cliquez sur Update).
2. Ajoutez les hosts manuellement (pour les courageux 🙂 )
  - Ajoutez les hosts XenApp dans le groupe “GRP_Citrix_XenApp_6.5”
  - Associez les hosts XenApp au template “TPL_Citrix_XenApp_6.5”
  - Associez les hosts de type Webi/StoreFront (Windows 2008 R2) au template “TPL_Windows_IIS_7.5”

Si vous utilisez Edgesight (plus pour très longtemps 😉 ) ou UPM il vous faudra activez les items dans le template “TPL_Citrix_XenApp_6.5”.
Allez Dans l’onglet Configuration-Template , puis cliquez sur TPL_Citrix_XenApp_6.5 et allez dans Items.

Cliquez sur Disabled afin d’activer les items

Renommez le serveur dans Zabbix (Si vous avez renommé le serveur MonitorX):

Connectez-vous en SSH sur le serveur MonitorX
Lancez la commande “vi /etc/zabbix/web/zabbix.conf.php”

Modifiez le nom du serveur Zabbix ($ZBX_SERVER = ‘ZAB01’; et $ZBX_SERVER_NAME = ‘ZAB01’; ) et enregistrez le fichier (commande vi “:wq”), pour les réfractaires au “vi” vous pouvez passer par WinSCP.

Si vous ne renommez pas le Hostname dans Zabbix vous obtiendrez l’erreur ci-dessous :

Zabbix server is not running: the information displayed may not be current

Pas d’inquiétude cependant, ce message dans le cas présent n’a pas d’impact sur les mises à jour des hosts ou autres

Administrer la base Zabbix
http://IpMonitorX/phpmyadmin ( root/password!01)

Et voila ce que ça donne 🙂 .

Les graphiques par host (onglet screen de chaque host)

Le graphique des CCU de la ferme XenApp (Onglet Monitoring-Screens)

MonitorX.rar

SDK Modification du scope d’exécution

Il y a quelques jours nos scripts de prod (d’une de nos fermes XenApp 6.5 R04) renvoyaient les informations d’une ferme de qualification, en regardant de plus près nous avons constaté que le scope d’exécution du SDK avait été changé sur un de nos serveurs d’administration.

Un Get-XADefaultComputerName confirma que le scope n’était pas le bon, afin de rétablir le scope sur la ferme d’appartenance du serveur il faut passer par un Set-XADefaultComputerName -ComputerName “VotreServeur”.

Ce billet juste pour souligner qu’un changement de scope ne concerne pas que la session dans laquelle il est lancé mais le serveur en lui-même, l’information étant présente dans la valeur “DefaultComputerName” situé dans [HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\XenAppCommands].

Si vous souhaitez ne pas changer de scope, les cmdlets du SDK permettant de faire du remote avec l’utilisation de l’argument -computername.

Supervision de silo serveurs

Comme vous le savez chez nous la supervision (et le monitoring) XenApp c’est une religion, c’est pourquoi au détour d’une discussion avec notre collègue Corvette_Man (à qui nous devons l’idée originale de ce billet) l’idée d’une supervision global des silos (serveurs) d’une ferme XenApp nous est venue.

Le but de cette démarche est double, premièrement permettre à la Citrix team d’avoir une vision des silos avec leur taux d’utilisation et deuxièmement offrir aux équipes applicatives une vue de leurs silos respectifs avec le taux d’utilisation.

Nous avons donc mis en place un script PowerShell permettant d’afficher une page html au sein de laquelle sont regroupés tous les silos de serveurs (ayant au moins un serveur). La disponibilité de ces silos est exprimée en pourcentage au travers d’un graphique (le pourcentage est issu du total de la charge des serveurs du silo) , un clic sur un silo déclenche l’ouverture d’une page html regroupant la totalité des serveurs membres du silo avec leur charge respective.

Le script tourne au travers d’une boucle s’exécutant toutes les 5 mn (à adapté selon vos besoin, de notre côté le script tourne via une tache planifiée), Les graphiques sont issus de justGage.com (justGage est basé sur la librairie Raphaël).

L’avantage de justGage est qu’il est personnalisable, rapide et facile à mettre en place. Le graphique change de couleur en fonction de la valeur entrée dans le graphique, vert en dessous de 34 %, jaune de 34 % jusqu’à 66 % et rouge à partir de 67 %.

La vue globale d’une ferme XenApp 6.5
Le chiffre à côté du pourcentage de chaque silo correspond aux nombre de serveurs membre du silo

La vue d’un silo avec la charge de chaque serveur

Les pages générées sont compatibles avec Chrome, Firefox et IE (9).

XenApp_LoadMonitor.rar

XenApp_Usr : mise à jour 1.4

XenApp_Check passe en 1.4, la liste des ajouts et corrections sont ci-dessous :

Rajout du refresh des sessions lors d’un logoff
La progressBar change de couleur en fonction de la charge du serveur hébergeant la session (vert de 0 à 5999, orange de 6000 à 8499 et rouge à partir de 8500)
Le champ username accepte la validation via la touche Entrée (Enter)
Refresh des process lorsqu’un process est tué via le bouton Stop
Correction de divers bug mineurs

Pour télécharger XenaApp_Usr c’est par ici