XenApp – Page 9

Problème pour forcer l’adresse Ip dans un launch.ica

Toujours dans la série post-it (rentrée des classes oblige), récemment nous avons rencontré un problème pour forcer l’adresse IP serveur dans un launch.ica via une WebInterface 5.4 (2003 sp1 us).
Dans pareil cas on se tourne rapidement vers le webinterface.conf du site afin de modifier l’addressResolutionType pour forcer le type de résolution (dns-port, dns, ipv4-port, ipv4).

Dans notre cas le WebInterface.conf était configuré pour présenter des adresses dns (configuration par défaut)

Pour le coup normal que les launch.ica présentent des adresses dns, cependant une fois le webinterface.conf modifié (addressResolutionType=ipv4-port) afin de présenter des adresses Ip nos launch.ica présentaient toujours des adresses dns.

Après un moumoutage (french expression very famous 🙂 ) de 20 mn, direction les propriétés de la ferme (XenApp 5 R07, 2003 sp1 us) dans la partie XenApp-General la coche XML Service DNS address Resolution était coché .

Sous XenApp5

Sous XenApp 6.5 (dans stratégie ordinateur-Paramètre du serveur)

Une fois l’XML service DNS adress resolution décoché nous obtenons bien une adresse en Ip dans le launch.ica

Script : déplacer un ou plusieur dossier serveur avec ses objets

Comme vous le savez, il n’est pas possible dans l’AppCenter de déplacer un dossier (ou plusieurs dossiers) contenant des objets vers un autre dossier, la seule façon de le faire est de passer par la case scripting 🙂 .

Dans notre exemple , nous souhaitons déplacer tous les dossiers (ces derniers n’ont pas de sous-dossiers) contenus dans le dossier Silo1 à la racine du dossier Serveurs.

Nous avons donc mis en place un script PowerShell permettant ce type de déplacement.

Avant d’exécuter le script il vous faudra au préalable modifier les lignes 4 et 5 afin d’indiquer le chemin des dossiers à déplacer ($FolderSearch) et leurs destination ($FolderDest).

Une fois les dossiers déplacés

Ctx_MoveSrvFolders.ps1

Problème mappage de clavier Mac sur un mstsc publiée

Ce billet tient plus du post-it que du billet (on vous prévient 😉 ).

Si vous rencontrez un problème de mappage de clavier (un “à” la place d’un “@” par exemple) avec votre mac (dans notre cas avec un receiver 11.8.0 (241823) en lançant un mstsc publié (sur un serveur 2003), alors direction la CTX110281 .

Une fois le clavier paramétré sur “Sur cet ordinateur” (On this computer) le mappage fonctionne sans problème.

Une solution est de créer un fichier .rdp et mettre à 0 le keyboardhook (keyboardhook:i:0, ce qui va forcer le Keyboard sur “On this computer”), puis de publier le mstsc avec le fichier rdp précédemment paramétré.

Script : Check XML Broker

Comme vous le savez le rôle XML Broker est important au sein d’une ferme XenApp, et à ce titre un check de ce dernier est très fortement recommandé (si vous souhaitez en savoir plus sur les interactions entres une Web-Interface et un XML Broker alors direction la CX122877).

Un schéma simplifié d’une architecture XenApp (issus de support.citrix.com)

Il existe nativement des solutions permettant de checker les XML Brokers (Netscaler et F5 par exemple), mais si comme nous dans votre infra le matériel acheté et “censé” faire ce check ne le fait pas et que l’affaire tourne en rond, alors il vous reste la solution scripting (afin de laisser le temps au fameux matériel de pouvoir répondre au besoin 🙂 ).

Avant de scripter il faut déjà comprendre ce qu’il faut envoyer à l’XML Broker et ce qu’il doit nous répondre, ce type d’infos se trouve dans le pdf “Health Checking Citrix Services with Advanced Monitors from the NetScaler Application Switch ” (dont nous vous recommandons la lecture), en page 12 nous trouvons la requete HTTP à envoyer à l’xml broker ainsi que la réponse si tout est ok

La requête Http (au format xml), avec comme application publiée “Notepad_Netscaler” pour le check :

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE NFuseProtocol SYSTEM “NFuse.dtd”>
<NFuseProtocol version=”4.1″>
<RequestAddress>
<Flags>no-load-bias</Flags> ###
<Name>
<AppName>Notepad_Netscaler</AppName>
</Name>
</RequestAddress>
</NFuseProtocol>

La réponse de l’XML Broker si tout est ok :

<?xml version=”1.0″ encoding=”UTF-8″ ?>
<!DOCTYPE NFuseProtocol SYSTEM “NFuse.dtd”>
<NFuseProtocol version=”4.1″>
<ResponseAddress>
<ServerAddress addresstype=”dot”>5.214.10.251</ServerAddress>
<ServerType>win32</ServerType>
<ConnectionType>tcp</ConnectionType>
<ClientType>ica30</ClientType>
<TicketTag>IMAHostId:13093</TicketTag>
<FarmLoadHint>0</FarmLoadHint>
</ResponseAddress>
</NFuseProtocol>

Comme indiqué en page 13 du pdf, ce qui nous intéresse dans la réponse de l’XML Broker est la partie <TicketTag>, donc si tout va bien on obtient un TicketTag, inversement si la requête échoue nous n’avons pas de TicketTag dans la réponse.

Exemple de réponse sans TicketTag (pour le test nous avions désactiver l’application Notepad_Netscaler)

Afin que le check passe bien il faut s’assurer que (toujours page 12 du pdf) :

L’IMA est bien fonctionnel sur l’XML Broker checker
La LHC de l’XML Broker est valide
L’IMA est fonctionnel sur le ZDC
La base de donnée dynamique du ZDC est valide
Avoir un serveur XenApp disponible pour l’application publiée (dans notre cas “notepad”)
Le service XML de l’XML Broker fonctionne correctement

Concernant le script nous nous sommes inspirés des scripts trouvés sur http://stackoverflow.com (Powershell API Post Variable to Ducksboard et powershell http post REST API basic authentication).

Au passage nous avons rajouté un envoi de mail en cas d’échec sur un XML Broker (à terme nous enverrons une trape snmp).

Dans notre production nous avons mis en place le script Check_Xml.ps1 en tache planifiée (toutes les 5 mn 7/24).

Si vous recevez ce type de mail…. rien ne va plus (mais au moins vous êtes au courant 😉 )

Check_Xml.ps1

Charge serveur bloqué sur 10000

Aujourd’hui nous sommes tombés (avec notre collègue Corvette man) sur un problème de charge à 10000 sur un serveur XenApp 6.5 (Sp1 R01 US), au passage le serveur n’avait aucun calculateur de type maintenance.

Le calculateur de charge affecté sur ce serveur prenait en compte la CPU/Mémoire et le nombre de session, aucun de ces 3 critères (ni-même l’indice de charge) ne permettait de définir une charge à 10000.

En regardant de plus près nous avons remarqué qu’il manquait des compteurs dans le perfmon du serveur (‘erreur : Unable to add these counters).

En googlelant nous sommes tombés sur la KB2554336 qui corrige ce type de problème.

Nous avons effectué les actions suivantes (vu qu’aucun compteurs n’étaient désactivés) :

Allez dans le menu Démarrer-Executé et lancer la commande c:\windows\system32\lodctr /R

Allez dans le menu Démarrer-Executé et lancer la commande c:\windows\sysWOW64\lodctr /R

Allez dans le menu Démarrer-Executé et lancer la commande WINMGMT.EXE /RESYNCPERF

Redemarrer le service Windows Management Instrumentation service

Redémarrer le service ImaService

Une fois ces étapes réalisées, les compteurs perfmon manquants étaient disponibles et notre serveur a retrouvé sa charge réel.

Mise à jour de XenApp_Check : 2.3

Ajout de la section Server(s) Load, cette section regroupe les serveurs dont la charge est supérieure à 9998.

Vous pouvez désactiver cette section via le script XenApp_Check.ps1 en mettant à FALSE la variable $Check_Ctx_SrvLoad.

Les serveurs dont le calculateur de charge correspond à celui configuré dans la variable $LoadEval_Check(calculateur de charge de maintenance configuré via le script XenApp_Check.ps1) sont exclus de cette section.

Le billet sur XenApp_Check

Script : Supprimer/Restaurer les applications publiées d’un serveur

Pour diverses raisons vous pouvez avoir besoin de supprimer toutes les applications publiées d’un serveur (voir notre billet sur ce sujet), cependant vous ne souhaitez peut-être pas laisser ce serveur “ad vitam æternam” sans ses applications publiées.

Nous avons donc modifié le script de notre précédent billet afin de sauvegarder au préalable toutes les applications du serveur (avant la suppression), ainsi que la possibilité d’ajouter les applications précédemment supprimées du serveur.

Les applications sont sauvegardées dans un répertoire backup (le choix du backup vs juste le nom des applis dans un fichier texte tient juste dans le “au cas ou”)

Reste plus qu’à 🙂

Apps_DepublishRepublish.ps1

Script : Application d’un calculateur de charge en fonction du type de serveur

Récemment dans plusieurs fermes XenApp 6.5 R01 nous avons eu besoin d’appliquer un calculateur de charge (Load Evaluator) sur tous les serveurs dont le calculateur de charge est “Défaut” (et on en avait un max 🙂 ) .

Au passage nous en profitons pour appliquer un calculateur de charge en fonction du type de serveur (Virtuel ou physique).

Dans notre cas les calculateurs de charges sont paramétrés via des Groupes de taches (Worker Groups), un pour les serveurs virtuels et un pour les serveurs physiques.

Comme d’hab ça passe par un script Powershell.

Pré-requis :
– Deux calculateurs de charge configurés en fonction du type de serveur (Virtuel ou Physique)
– Deux stratégies ordinateur, chacune pointant sur un des calculateurs de charge.
– Deux groupes de taches permettant le filtrage des stratégies

Xa6_AttribLE.ps1

Xa5_AttribLE.ps1
Pour XenApp 5 (le script reste le même sans les parties Worker Groups et GPupdate)

Afficher la liste des applications publiées pour un utilisateur en Powershell

——————
15/05/2013
——————
Le script utilise désormais le Token-Groups (merci Pierre pour l’info 😉 ) pour la recherche de groupes d’un utilisateur.
L’avantage du Token-Groups est que nous n’avons plus besoin d’utiliser des recherches récursives, l’attribut (qui est un attribut calculé) contient la liste de tous les SID des groupes (ainsi que les groupes imbriqués) ce qui améliore grandement les temps de recherche :).
Le script affiche la liste des applications publiées pour un utilisateur (un fichier texte contenant la liste des applications publiée pour un utilisateur est également disponible dans le répertoire racine du script).

search_apps_users.ps1

——————
27/03/2013
——————

Récemment on nous a demandé de sortir la liste de toutes les applications publiées pour un utilisateur (dans une ferme en XenApp 6.5 R01).

Donc direction PowerShell 🙂

Nous avons mis en place un script permettant d’afficher la liste de toutes les applications publiées d’un utilisateur dans une ferme (que l’application soit publiée en direct ou via un groupe, concernant le groupe la recherche dans le groupe est récurisve).

Concernant la recherche récursive cette dernière se fait en DotNet (.Net 3.5 sp1 requis dans notre cas).

Au départ nous étions partis avec la cmdlet Get-ADGroupMember mais nous avons vite rencontré la limitation du MaxGroupOrMemberEntries (à 5000, bien que cette valeur soit modifiable via le fichier Microsoft.ActiveDirectory.WebServices.exe.config sur les DC). Il est aussi possible de faire la recherche en ADSI ou via les cmdlet Quest (mais on avait pas envie 🙂 ).

Avant d’exécuter le script modifier en ligne 19 la valeur de la variable $DC par un de vos DC (un DC prévu pour l’exécution de script par exemple).

Une fois le script passé, nous avons constaté en prod (bien qu’on s’en doutait au vu des nombreuses imbrications de groupes) que certaines applications étaient publiées plusieurs fois pour un même utilisateur.

Merci à VmDude pour le trick du bind sur un DC spécifique en DotNet .

On constate que certaines applications sont publiées directement sur le compte du user au passage

DisplayAllAppsForSpecificUser.ps1

Mise à jour de XenApp_Check : 2.2

Ajout de la section Citrix HotFix missing, permettant de vérifier la présence d’un HotFix Citrix sur chaque serveur membre de la ferme XenApp (XA5/6x).
Par défaut cette section est activée, vous pouvez la désactiver via le fichier XenApp_Check.ps1 en mettant à FALSE la variable $Check_Ctx_HotFix.

Si vous souhaitez changer version du HotFix Citrix recherché (la modification se fait dans le fichier XenApp_CheckXAx.ps1) :
– Pour XenApp6.0/6.5 changer la valeur de la variable $Ctx_HotFixXA60 (pour XenApp 6.0) ou $Ctx_HotFixXA65 (pour XenApp 6.5).
– Pour XenApp 5 changer les valeur de la variable $Ctx_HotFixXA5_32 (pour les OS 32bits) et/ou $Ctx_HotFixXA5_64 (pour les OS 64 bits).

Reste plus qu’à leur installer le HotFix validé par vos soins

Si le message LHC error or CtxHotFix not Installed apparait dans la colonne Citrix HotFix, soit le HotFix n’est pas installé soit la LHC est corrompu

Le billet sur XenApp_Check