Mesurer l’occupation d’une baie Pure avec Ansible en pré-requis de la création d’un datastore.

Il y a quelques temps nous avions automatisé (toujours sous ansible) la création de datastore (et donc de LUN) sur tous nos vCenter, cependant on le faisait sans connaître à l’avance l’espace disque utilisé sur la baie de stockage cible (dans notre cas des baies Pure Storage). Nous venons justement d’écrire un yaml permettant de vérifier le pourcentage d’espace disque utilisé sur la baie de stockage cible afin de décider de poursuivre  ou pas le déploiement (lors des pré-check de la création du datastore). La collection purestorage.flasharray permet facilement d’interroger une baie pure via ses différents sous-ensembles ; ici on interroge le sous-ensemble capacity pour obtenir les valeurs des compteurs total_capacity et free_space (en octets) de la baie. Le script ci-dessous permet de retourner le pourcentage d’occupation d’un baie pure.

Les pré-requis (hormis l’installation de la collection purestorage.flasharray) sont les variables :
– fa_url (IP de votre baie pure ou nom dns au format FQDN de préférence)
– api_token (le token pour s’authentifier à la baie)
– usage_threshold_pct (le pourcentage du seuil d’utilisation de la baie)

Concernant le yaml “Check Pure Storage baie”, il est relativement simple. 

  • Task “Collect capacity information on….” nous interrogeons  la baie afin de remonter tous les compteurs du sous-ensemble capacity.
  • Task “Validate Pure capacity payload” permet de valider que la task “Collect capacity information on….” nous a bien remonté les informations que nous souhaitions, si ce n’est pas le cas la task sera en fail avec un message affichant la variable qui n’est pas remontée et une string d’erreur que vous pouvez changer).
  • Task “Display array_result” c’est juste pour afficher le résultat de la task “Collect capacity information on….”, vous pouvez la commenter au besoin.
  • Task “Normalize capacity values to integers (bytes)” créer les variables total_b et free_b 
  • Task “Compute derived values 1″, créer les variables used_b (qui reste en byte), total_gib (total_b que l’on convertit en gigibyte aka “Gib”) et free_gib (free_b que l’on convertie en en gigibyte aka “Gib).
  • Task “Compute derived values 2″, créer les variables used_gib (variable used_b que l’on convertie en gigibyte) et used_pct (used_b / total_b x 100)
  • Task Display values from …. qui affiche les différentes variables
  • Task Abort if usage > {{ usage_threshold_pct }} %, cette la task qui va faill le playblook si pourcentation d’utilisation de la baie est supérieur à la variable usage_threshold_pct.
- name: Check Pure Storage baie 
  hosts: localhost
  
  vars:
    fa_url: "Your_PureStorage.fqdn"
    api_token: "Your_token"
    usage_threshold_pct: 75
  
#######################################
# Collecting data
#######################################
  tasks:

    - name: Collect capacity information on {{ fa_url }}
      purestorage.flasharray.purefa_info:
        gather_subset:
          - capacity
        fa_url: '{{ fa_url }}'
        api_token: '{{ api_token }}'
      register: array_result
      no_log: true  # do not expose the token in the logs
      retries: 3
      delay: 3
      until: array_result is succeeded and (array_result.purefa_info.capacity is defined)

    - name: Validate Pure capacity payload
      assert:
        that:
          - array_result.purefa_info is defined
          - array_result.purefa_info.capacity is defined
          - (array_result.purefa_info.capacity.total_capacity | int) > 0
          - (array_result.purefa_info.capacity.free_space     | int) >= 0
        fail_msg: "Missing/invalid capacity data (total_capacity/free_space)."
        success_msg: "Capacity Pure: payload OK."

    - name : Display array_result
      ansible.builtin.debug:
        msg: '{{ array_result }}'

    - name: Normalize capacity values to integers (bytes)
      ansible.builtin.set_fact:
        total_b: "{{ array_result.purefa_info.capacity.total_capacity | round(2) | int }}"
        free_b:  "{{ array_result.purefa_info.capacity.free_space | round(2) | int }}"
        
    - name: Compute derived values 1
      ansible.builtin.set_fact:
        used_b:  "{{ (total_b | int) - (free_b | int) | round(2) }}"
        total_gib: "{{ ((total_b | int) / gib) | float | round(2) }}"
        free_gib:  "{{ ((free_b  | int) / gib) | float | round(2) }}"


    - name: Compute derived values 2
      ansible.builtin.set_fact:
        used_gib:  "{{ ((used_b  | int) / gib) | float | round(2) }}"
        used_pct:  "{{ (((used_b | float) / (total_b | float)) * 100) | round(2) }}"
      
    - name : Display values from {{ fa_url }}
      ansible.builtin.debug:
        msg: 
          - 'fa_url : {{ fa_url }}'
          - 'used_b : {{ used_b }}'
          - 'total_gib : {{ total_gib }}'
          - 'free_gib : {{ free_gib }} GB'
          - 'used_gib : {{ used_gib }}'
          - 'used_pct : {{ used_pct }} %'

    - name: Abort if usage > {{ usage_threshold_pct }} %
      ansible.builtin.fail:
        msg: "Array usage {{ used_pct }} > {{ usage_threshold_pct }} %. Aborting."
      when: (used_pct | float) > (usage_threshold_pct | float)


Dans l’exemple ci-dessous nous avons fixé volontairement la variable “usage_threshold_pct” à 35 afin d’afficher le message d’erreur “Array usage 37.63 > 35 %. Aborting.” et d’arrêter le playbook.

Ci-dessous le résultat sur une baie dont le taux d’occupation est de 37,63 %. 

il ne reste plus qu’a insérer cette vérification  dans nos pré-check de création de datastore  🙂 .

Post to Twitter

Script : Supprimer les applications d’un utilisateur ou d’un groupe

Dans Citrix Virtual and Desktops supprimer un utilisateur ou un groupe de toutes ses applications ou bureaux publiés peut vite s’averer fastidieux.

Le fameux Testdf1 qui nous suit depuis tant d’années 🙂

Comme on est sympa on ne va pas vous laisser supprimer à la mano tous ces utilisateurs/groupes. Le script Powershell “Xa7x_Unpublished” va juste vous demander de rentrer le nom de l’utilisateur ou groupe que vous souhaitez supprimer (ou visualiser) des applications et bureau publiés.

  1. Lancez le script
  2. Entrez le nom de l’utilisateur ou groupe
  3. Entrer 1 si vous souhaitez supprimer l’utisateur/groupe ou 2 si vous souhaitez uniquement visualiser le resultat
  4. Un fichier de log ( Xa7x_Unpublished.log) est disponible dans le répertoire d’exécution du script.

Le script en mode affichage

Le script en mode suppression


Post to Twitter

XenApp : création d’applications en masse

Ca nous est tous arrivé un jour de se retrouver devant LA fameuse demande de création d’applications en masse (dans notre cas plus 300 applications one shoot).

En plein match de la coupe du monde, 300 applis à créer, avec 300 tickets différents bien sûr 🙂

 

Le script powershell joint à ce billet permet la création des applications “en masse”, avec les utilisateurs/groupes et l’icone associée au binaire de publication (sauf si votre chemin applicatif est un bacth, script etc..). Là où c’est pratique c’est que le script repose sur un fichier de configuration (format csv) dans lesquel vos productions applicatives vont rentrer toutes les informations nécessaires à la création des applications (sinon c’est à vous de le faire 😉 ).

En argument lors du lancement vous pouvez indiquez un Delivery Controller (exemple : Xa7x_CreateApps.ps1 MonDeliveryController), en l’absence d’argument le script considère que le serveur local est un Delivery Controller.

 


XA7x_CreateApps.zip

 

 

 

 

Post to Twitter

XenApp_Usr

————————————————————————————————————
MAJ : 23/03/2015
V1.4

  • 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

————————————————————————————————————

MAJ : 22/12/2014
V1.3

  • Correction de bugs mineurs
  • Ajout de la section “Gpo Applied”
  • Possibilité d’exporter la Gpo sélectionnée au format HTML (il faut comme pré-requis que le  Module GroupPolicy soit installé sur même le serveur que XenApp_Usr)
  • Possibilité d’exporter toutes informations de la session courante dans un fichier texte

————————————————————————————————————

C’est quoi XenApp_Usr  ? 🙂

C’est un script PowerShell que nous avons mis en place et qui permet via une GUI de retrouver la ou les session(s) d’un utilisateur au sein d’une ferme XenApp.

Un fois la ou les sessions retrouvée(s), il suffit de sélectionner une session afin que les informations ci-dessous s’affichent dans la GUI :

  • Nom et version de la ferme XenApp
  • Application publiée
  • Serveur sur lequel la session est connectée
  • Etat de la session
  • Version du client ICA
  • Type de client
  • Nom du client
  •  IP du client
  • Date et heure de la connexion
  • Imprimantes de la session
  • Processus  lancés dans la session
  • Afficher la bande passante de la session ICA
  • Afficher la latence de la session ICA

A cela nous avons ajouté la possibilité d’effectuer les actions ci-dessous :

  • Fermer la session
  • Lancer un remote assistance sur la session
  • Stopper un process de la session

 

XenApp_UsrV1 Ok la GUI fait un peu année 90 🙂

 

XenApp_Usr a été validé sur des fermes XenApp 6.5 R01, R03 et R04 (us et fr), la consommation mémoire est d’environ 60 Mo ( 🙁 faudra qu’on regarde pour diminuer ça).

Vos remarques et suggestions sont les bienvenues (au passage nous avons volontairement éviter les Splash Screen et Progress Bar).

Pour l’instant (et vu que le code n’est pas encore présentable) on ne livre que le ps1 compilé en binaire, la version ps1 arrive asap .

Au passage la GUI a été réalisée avec Powershell Studio de Sapien.

 

Download_2XenApp_Usr.rar

 

———————————————————
MAJ : 24/11/2014
V1.1
Correction de bugs mineurs
Ajout de la charge serveur (Load server)
———————————————————

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

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

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

Créer une alerte sur les GPO Citrix modifiées.


Dans les infras où la délégation est “forte” (dans le cas présent les GPOs),  il est important (pour ne pas dire obligatoire) de mettre en place des alertes permettant d’informer les administrateurs qu’une ou plusieurs GPOs ont été modifiée(s).  L’un des avantages de ce type d’alerte est de permettre à l’ensemble des admins  d’avoir le même niveau de connaissance sur les  modifications apportées aux GPO.

dontTouchEn amont on pourrait aussi mettre ça, histoire que tout le monde ait le même niveau de connaissance 🙂

En PowerShell la cmdlet GET-GPO avec son attribut ModificationTime associé à un filtre sur le DisplayName (Ctx dans notre cas) permet de filtré facilement les GPOs  venant d’être modifiées,  le résultat étant envoyé par mail en html.

GPOs_Modified
Le script remonte toute les GPOs dont le DisplayName contient la chaîne “Ctx” et qui ont été modifier durant les trois dernières heures.
A l’ancienne en tache planifiée ça fera l’affaire 😉  .

 

Download_2Check_Gpo_Modified.ps1

Post to Twitter

Rechercher un EventId au sein d’une ferme XenApp

Il arrive lors de troubleshooting que l’on souhaite connaître la présence (ou pas)  d’un EventId au sein des divers silo d’une ferme XenApp (ce qui permettra par la suite d’appliquer le correctif sur les silos impactés et au passage de faire une petite comm 😉 ).

Dans le cas présent il s’agissait de connaitre la liste des silos (avec leurs serveurs) rencontrant l’EventId 6005 (nous ferons très prochainement un billet sur cet EventId) afin de pouvoir appliquer la GPO corrigeant le problème sur les serveurs concernés.

On utilise la cmdlet Get-EventLog afin  de retrouver l’EventID recherché (avec un filtre -Newest 500, suffisant pour constater ou pas la présence de l’EventId durant les derniers jours).

Au préalable modifier la valeur “6005” (et/ou changer le type de journal dans lequel vous allez effectuer votre recherche) par celui recherché en ligne 8 du script.

SearchEventXenAppFarm1

SearchEventXenAppFarm

La liste des silo Impactés est affichée dans la colonne FolderPath

  

Download_2Search_Event_XenApp.ps1

Cela exclue pas  l’utilisation d’un bon vieux Syslog ou un Graylog2 😉

Post to Twitter