Publication du Remote Assistance

Comme vous le savez, en XenApp 6.5 le shadowing sur des sessions multi-écran cause problème (voir CTX125693), l’utilisation de MSRA (Microsoft Remote Assistance) permet de palier cette problématique (la seule contrainte est de connaitre à l’avance le nom du serveur hébergeant la session que l’on souhaite observer, ce qui est peu pratique à l’usage).

Au départ on souhaitait mettre en place une GUI permettant de faire du MSRA sans avoir à chercher où se trouve la session de l’utilisateur, en googlelant nous sommes tombés sur l’excellent script de nos collègues de DEPTIVE qui avait déjà (depuis 2012) mis en place un PowerShell  permettant de rechercher un session ICA/RDP (le tout via une GUI) au sein d’une ferme et de lancer sur cette session un MSRA.

Nous avons juste rajouté/modifié les éléments ci-dessous afin qu’ils correspondent un peu plus à notre besoin :

  • Teste si le snapin Citrix est bien chargé
  • Si le champ username est vide le script n’affiche plus toutes les sessions ica/rdp ouvertes dans la ferme mais une erreur indiquant qu’il faut renseigner le champ username
  • Le bouton Connect est désactivé tant qu’une session n’est pas trouvée dans la ferme XenApp en cours
  • Ajout de la colonne application publiée (afin de bien cibler la session de l’utilisateur)
  • Ajout d’un compteur comptabilisant le nombre de sessions trouvées pour un utilisateur
  • Ajout du nom de la ferme en cours

 

MSRA_Script

 

MSRA_Script1Sur des grandes ferme avec what mille CCU on evite l’affichage de toutes les sessions de la ferme si on clique sur le bouton Search et que le champ username est vide

 

MSRA_Script2Rien de transcandant dans nos modifications mais c’est pratique 🙂

 

 

Si vous publiez le script sur un serveur avant l’agent EdgeSight installé alors n’oubliez pas d’exclure le process “msra.exe” dans l’agent EdgeSight  (voir CTX131271).

 

EdgeSightExcluRsaSi vous souhaitez le reg pour l’importation c’est juste en dessous

 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\rskcore]

“UviProcessList”=”rotatelogs.exe;msra.exe”

 

Pour plus d’information sur le Remote Assistance (et pour l’activer) c’est par ici.

Au passage pour ajouter le Remote Assistance sur un serveur en PowerShell :

import-module servermanager;get-windowsfeature "Remote-Assistance"|?{$_.installed -eq $False}|%{Add-WindowsFeature "Remote-Assistance"} 

 

Quelques liens  sur la configuration de Remote Assistance  :

 

 

Download_2RemoteAssistance.ps1

Post to Twitter

Mise à jour de XenApp_Check : 2.5

MAJ :19/09/2014

La version XA5 passe en 2.5

 


 

Déjà plus d’un an depuis la dernière mise à jour de XenApp_Check (436 jours exactement), on ne vous fera pas le coup du “comme le temps passe vite” mais pas loin 😉 .

Dans cette mise à jour  nous avons ajouté une section “UPM version” qui permet de vérifier si les agents UPM sont UpToDate (par rapport à la version que vous avez validée ) au sein de vos fermes et une section “Section statut” affichant les sections désactivées”.

La version UPM de référence dans XenApp_Check est la “5.0.0.111” (modifiable via la variable $UPMVer)
Nous avons aussi corrigé divers bugs mineurs et amélioré le temps d’exécution du script (réduction d’environ 15 % du temps d’exécution) en changeant le check WMI  (on passe par un socket.TcpClient sur le port 135).

 

XenApp_Check_2_5

 

Seule la version XA6 passe en version 2.5, la version XA5 sera très prochainement mise à jour.

Désormais les fichiers XenApp_CheckXA6.ps1 et le fichier Ctx_FunctionXa6.ps1 sont regroupés au sein d’un fichier rar.

Comme d’habitude vos remarques et suggestions sont les bienvenues.

 

XenApp_Check_GraphMerci pour les DL 😉


Le billet sur XenApp_Check

Post to Twitter

Vérifier la version UPM des serveurs membres d’une ferme XenApp

Toujours dans l’idée d’avoir des serveurs XenApp les plus ISO possible, cette fois-ci nous nous sommes penchés sur la/les version(s)s d’UPM (Universal Profil Manager) installée(s) au sein de nos différentes fermes XenApp.

 

SepagoHé oui à la base UPM  c’était SepagoProfile (écrit en C++ et multithreadé s’il vous plait 😉  ),  Citrix ayant racheté SepagoProfile  à SEPAGO en Mai 2008)

Le script disponible dans ce billet permet donc de vérifier la version UPM (via WMI, il faut donc que le port TCP 135 soit ouvert sur les serveurs)  installée sur tous les serveurs membres d’une ferme XenApp.
Afin de vérifier la version UPM installée sur chaque serveur, le script va rechercher dans  toutes les subkeys de “SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\” si l’une des valeurs “DisplayName” contient la chaîne de caractère  “Citrix Profile Management” si c’est la cas, le script va lire la valeur “DisplayVersion” afin de déterminer la version UPM installée et vérifier si cette dernière correspond ou pas à la version recherchée et validée dans votre environnement, dans notre cas la 5.0.0.111 (Variable $UPMVer en ligne 17 du script).

 

UPM_CheckOn n’est pas si mal sur cette ferme, juste un serveur sans UPM et un avec une ancienne version, reste à faire un check de la DMZ 😉 .

 

Bien sur on va rajouter le check de la version UPM dans XenAppCheck  (ça fait un bail qu’on ne l’a pas mis à jour d’ailleurs 🙂 .

 

Download_2CheckVer_UPM.ps1

 

Vous avez aussi la possibilité de lancer le script en mode verbose en rajouter l’argument -Verbose ( CheckVer_UPM.ps1 -Verbose)

Post to Twitter

Vérifier l’ouverture du port IMA

Récemment du jour au lendemain certains de nos utilisateurs rencontraient  le message d’erreur ci-dessous en cliquant sur une application publiée via une Web Interface (dans notre cas une 5.4 Us).

” Une erreur s’est produite lors de l’établissement de la connexion requise”.

Error_Xml_WIVu que seul un silo était impacté, le premier réflexe a été de vérifier si le port IMA était bien ouvert entre nos XML Broker  et les serveurs du silo concerné, et effectivement le 2512 n’était plus ouvert 😉

Afin de palier ce type de situation, nous avons mis en place un PowerShell qui va checker que le port 2512 (port par défaut, cependant le script va vérifier le port IMA au cas ou 😉 ) est ouvert (avec un timeout de 1000 milliseconds, au delà on considère que le port IMA n’est pas ouvert), avec un tableau récapitulatif des serveurs non joignables sur le port IMA.

Au préalable il vous faudra installer le  SDK Powershell (XenApp 5XenApp 6x)sur vos XML Broker.

 

IMA_Check_PortUne petite visite chez nos collègues du réseau ? 🙂

 

Download_2

Post to Twitter

Visualiser la bande passante d’une session ICA

Il arrive qu’on nous demande quelle est la taille de la bande passante de telle ou telle session ICA, le plus simple, en l’absence d’outils de type EdgeSight, est de passer par Perfmon (compteur ICA-Session : Bande passante de session – sortie et Bande passante de session – entrée), cependant le “problème” avec Perfmon est qu’il faut à chaque fois préciser le serveur et la session que vous souhaitez visualiser, c’est pourquoi on a mis en place un script PowerShell permettant de visualiser rapidement la consommation de bande passante d’une session ICA.


Ica_BandWith02
On peut aussi afficher toutes les sessions par contre à lire 🙂

 

Lors de l’exécution du script il vous sera demandé de rentrer le nom du serveur, le SessionId (la liste vous sera proposée une fois le nom du serveur rentré) et la durée d’analyse (un sample étant égal à 2 secondes).

 

Ica_BandWith01Bon ok une visualisation sur 20 secondes c’est léger 😉

Ica_BandWith03Un export en csv est disponible dans le répertoire courant histoire de faire un beau graph 😉

 

Le script a été testé sur des fermes XenApp 6.5 Us et Fr (le pré-requis est la présence du PowerShell SDK XenApp 6.5 sur le serveur exécutant le script)

 

ICA_BandwithICA_Bandwith.ps1

Post to Twitter

Identifier les applications avec un seul serveur

Un petit script pour identifier rapidement les applications publiées ayant un seul serveur.

$OriginalColor=$Host.UI.RawUI.ForegroundColor;get-xaapplicationReport *|Sort DisplayName|Format-Table -Property DisplayName,@{label="Serveur";Expression={If($_.ServerNames.count -le 1) {$Host.ui.rawui.ForegroundColor="Red";$_.ServerNames.count}Else{ $Host.ui.rawui.foregroundcolor="Yellow";$_.ServerNames.count}}};$Host.UI.RawUI.ForegroundColor=$OriginalColor

Ctx_App_SrvCountLes applications avec un seul serveur apparaissent en rouge 😉 

 

Pour rappel dans XenAppCheck vous avez aussi la liste des applications avec un seul serveur.

Ctx_App_SrvCount1

Post to Twitter

Test de ControlUp 3

Il y a un peu plus d’un an nous avions testé ControlUp 1.0 (voir billet), la version 3.0 (3.0.1.399 dans notre cas) vient  de sortir  et autant vous dire Smart-X a passé la vitesse supérieure 😉 .

Nos tests ont été effectués sur un serveur 2008 R2 sp1 Fr, et comme d’habitude l’installation et la prise en main de ControlUp sont déconcertantes de facilité.

Les ajouts de fonctionnalités (et améliorations) les plus importantes que nous avons constaté durant notre test :

  • Ajout d’une section Incidents
  • Possibilité de monitorer les services
  • Possibilité d’exécuter des scripts en remote
  • Ajout de colonnes Citrix supplémentaires dans la section Computer
  • Ajout d’actions de diagnostics sur les computers
  • Support . Net Framework 4.5 
  • Ajout personnalisé d’events log
  • Possibilité de changer la priorité d’un processus
  • Affichage de la latence ICA dans la section computer
  • Ajout d’un magasin de mot de passe

L’installation se fait via une une suite de popup

ControlUp_Install01Cliquez sur le bouton Continuer

ControlUp_Install02Choississez “I Accept the agreement”
Cliquez sur le bouton Continuer

ControlUp_Install03Rentrez le nom de votre organisation
Cliquez sur le bouton Continuer

ControlUp_Install04
ControlUp_Install05Dans un premier on garde les triggers par défaut
Cliquez sur le bouton Yes

 

On vous avait prévenu, l’installation est une formalité 😉 .

ControlUp_Install08

 

ControlUp_Install09En moins de 5 mn (installation comprise) on est déjà au sein de la console de ControllUp

Dans un premier temps il faut rajouter les serveurs membre de/des ferme(s) XenApp dans la console ControlUpp.

 

 L’installation de l’agent (port 40705 par défaut) se fait en remote via la console ControlUpp (ainsi que la désinstallation), l’installation par lot est bien sur possible (il est aussi possible de télécharger l’agent et de le déployer par d’autres outils).

ControlUp_Install07

 

 

Vous avez la possibilité via la console ControUp de configurer le ControlUp Monitor afin de créer un service qui permettra le monitoring en continu.

ControlUp_Install092On vous conseille ce mode si vous souhaitez une mise en place pour du 24/7

 

Dans la suite du billet nous allons énumérer quelques  unes des nombreuses fonctionnalités de ControlUp.

ControlUp_Install093 Dans la console vous avez la possibilité de modifier la liste des colonnes et donc de personnaliser le monitoring (avec des settings xenapp, xendesktop)

 

ControlUp_Install094Il est possible d’ajouter des triggers (sur des événements Windows, des process démarrés, des arrêts de serveur etc..) en plus de ceux déjà configurés

 

ControlUp_Install095La liste des actions possibles sur un host (Le “Script Based Actions” est notre préféré 😉 )

 

ControlUp_Install097La liste des actions possibles sur une session



ControlUp_Install096La fonction Incidents permet d’obtenir rapidement un état des incidents avec un historique

 

ControlUp_Install099Il est possible de rajouter des scripts réalisés par Smart-X ou bien les vôtres (bat, vbs et PowerShell   😉

La configuration de la console ControlUp se trouve dans C:\Users\VotreUser\AppData\Roaming\ControlUp et HKEY_CURRENT_USER\Software\Smart-X\ControlUp.

En résumé ControlUp permet de mettre en place un monitoring rapide et efficace de vos fermes XenApp, de plus Yoni est à l’écoute de la communauté Citrix et certains d’entre eux sont impliqués directement dans le projet  (Shawn Bass, Jarian Gibson et Shane Kleinert)  🙂 .

 

ControlUp_Install0991Au passage la version Basic est toujours free

 

 

 

 

 

Post to Twitter

Rechercher une application dans plusieurs fermes XenApp

Si vous souhaitez connaitre la/les fermes publiant  une application  (par exemple word, excel ou bien une application comprenant une chaîne de caractère “TEST” 😉 ) le script contenu dans ce billet devrait vous intéresser.

Les pré-requis sont que les serveurs entrés dans la variable $Serveurs aient le PowerShell SDK d’installer (XenApp 5, XenApp 6x) et que le port TCP 2513 soit ouvert entre le serveur exécutant le script et le(s) serveurs ayant  le sdk installé (bien sur on ne peut attaquer une ferme XenApp 6x à partir d’un serveur XenApp 5 et vice-versa 😉  .

Modifier la variable $Serveurs (ligne trois du script) la liste des serveurs (un par ferme XenApp) permettant de se connecter avec les différentes fermes XenApp.


Apps_Search_All_Farm

23 Applications publiées réparties sur trois fermes XenApp 6.5 ayant dans leur  browsername la chaîne de caractère “TEST”  😉

 Download_2SearchAppFarms.ps1

Post to Twitter

Supprimer les applications désactivées


Depuis quelques temps les rapports issus de nos XenApp_Check remontaient un nombre croissant d’applications désactivées sur nos fermes XenApp 5 et 6x  (Recette, Qualification et Production).

AppDisable0452 applications désactivées sur une ferme XenApp 5 R07

 

Vu que ces applications restaient désactivées dans le temps (plus de 30 jours) nous avons mis en place un script PowerShell permettant de supprimer toutes (sauf les applications ayant dans le champs description la chaîne de caractère #NOT_DELETE#) les applications désactivées d’une ferme.

Les actions du script :

  • Sauvegarde dans le répertoire courant des applications désactivées
  • Suppression des applications désactivées (hors application ayant dans le champs description la chaîne de caractère #NOT_DELETE#)
  • Suppression des sauvegardes supérieur à 180 jours (dans le répertoire courant)

     

Apps_Delete54 applications (soit deux de plus en l’espace d’une journée) en moins  dans une de nos fermes XenApp 5 R07

 

AppDisable01Le Get-XaApplication prenait 5,40 secondes pour 580 applis dans la ferme

 

AppDisable02On tombe  à 4,64 secondes une fois les 54 applications supprimés 😉

 

Pour restaurer une application lancez la ligne de commande ci-dessous :

import-Clixml "\\YourPath\Backup\App.xml"|New-XAApplication

 

Download_2
App_DisableDelete.ps1

Post to Twitter

Comparer les OUs enfants de deux OUs parents

Logiquement dans toute production XenApp (ou autre) on a une production ISO à la qualification, cependant il peut arriver au fil du temps que la réalité soit un peu différente 🙂 .

Afin de mettre en évidence les silos applicatifs n’ayant pas de Qualif (ou pas de Prod) nous avons mis en place un PowerShell qui compare les OUs de Prod et de Qualif de nos différentes fermes XenApp.

 

Ou_XenApp

 

En général la qualif XenApp est sur une Ad de Qualif et la Prod XenApp sur une Ad de Prod, mais (car il y a toujours un mais dans certaines missions) dans le cas présent la qualif et la prod sont sur l’AD de prod 🙂 .

En ligne 1 il faut adapter le contenu de la variable $Vers en fonction de votre nomenclature.
Les OUs parents sont à renseigner en ligne 13 et 16 du script (vous pouvez aussi supprimer la variable $Vers et le Foreach en ligne 3 et31 si vous ne souhaitez checker qu’une seule version XenApp)

CompareOuSur notre lab on est presque ISO 🙂

 

Download_2Compare_Ou_ProdQualif.ps1

Post to Twitter