Powershell – Page 5

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

Problème d’application de stratégies Citrix (via l’Appcenter)

Sur un serveur XenApp 6.5 R01 US nous avions un problème d’application de Calculateur de charge (via les policy Citrix de l’Appcenter), en regardant dans les logs du serveur nous avons constaté la présence de l’event ID 1091.

Log Name: System
Source: Microsoft-Windows-GroupPolicy
Event ID: 1091
Level: Warning
Description:
Windows could not record the Resultant Set of Policy (RSoP) information for the Group Policy extension <Citrix Group Policy>. Group Policy settings successfully applied to the computer or user; however, management tools may not report accurately.

Un rsop sur le serveur en question

La CTX130116 traite ce type de problème, en effet dans notre cas les fichiers Rsop.gpf et Rollback.gpf avaient bien une taille de 0 Ko.
Une fois les fichiers Rsop.gpf et Rollback.gpf (ainsi que les répertoires contenus dans %PROGRAMDATA%\Citrix\GroupPolicy) supprimés (associé à un gpupdate /force) l’application des policy Citrix s’est faite sans problème.

Afin de vérifier que nous n’avons pas d’autres serveurs rencontrant le même problème d’application de policy Citrix, nous avons mis en place un script PowerShell listant les serveurs XenApp ayant des fichiers Rsop.gpf et Rollback.gpf avec une taille de 0 Ko.

Lui il est bon pour un delete de fichier Rsop.gpf et Rollback.gpf 🙂

CheckGpfFileCtxPolicy.ps1

PowerShell : Graphique des CCU d’une application publiée

Dans ce billet et juste pour le fun, un script PowerShell permettant de “grapher” les CCU d’une application publiée.

On vous l’a dit cacti on aime 😉
Tester sur une Ferme en XA 6.5 R01 Us, via une tâche planifiée et à la mano.

Bien que le résultat soit old school, c’est propre et ne nécessite aucune installation (hormis le Chart Controls for Microsoft .NET Framework 3.5 🙂 .

Pré-requis :

Installer le Chart Controls for Microsoft .NET Framework 3.5
Remplacer la valeur de la variable $App par celle de votre application dans le script XenApp_Chart.ps1
Via une tâche planifiée, exécuter le script XenApp_Chart.ps1 (ou à la mano juste pour tester 🙂 ).

XenApp_Chart.ps1

La partie graphique du script est fortement inspirée du billet “Tutorial: PowerShell and Microsoft Chart Controls (or How To Spice Up Your Reports)” de ByteCookie.

Afficher les applications dont le BrowserName est différent du DisplayName

Si vous souhaitez afficher la liste des applications dont le BrowersName n’est pas identique au DisplayName, exécutez la ligne de commande PowerShell ci-dessous (gare aux surprises 🙂 ).

Ho la belle bleu 🙂

get-xaapplication|%{if($_.DisplayName -ne $_.BrowserName){write-host $_.DisplayName "-" $_.BrowserName;$count++}};write-host "Count:" $Count

Supprimer un utilisateur “indésirable” de ses applications publiées

Que celui qui n’a jamais publié une application à un utilisateur “directement” lève sa souris 🙂 .

Le problème est qu’il arrive qu’on oublie des fois\souvent de supprimer la/les publication(s) de l’utilisateur en question et dans le temps la situation ne s’améliore pas.

Si vous souhaitez supprimer toutes les applications publiées d’un utilisateur configuré en dur, la commande PowerShell ci-dessous vous aidera dans votre démarche.

$User="YourUser";Get-XAapplicationreport *|?{$_.Accounts -eq $User}|%($_){Remove-XAApplicationAccount $_ $User;write-host $_ ": $User was removed"}

Vérifiez si un utilisateur fait bien parti d’un groupe de publication

Dans une infra AD un peu “cossu”, il peut arriver que le groupe de publication contienne des groupes imbriqués dans d’autres groupes imbriqués etc.. etc… 🙂 ……….et tout ça dans une profondeur assez “intéressante” (une trentaine d’imbriquation dans notre cas).

Quand les collègues doivent vérifier rapidement si un utilisateur fait bien partie d’un groupe de publication ça peut devenir un peu… laborieux.

En PowerShell c’est simple et rapide :

Get-ADGroupMember -Identity "YourGroup" -Server "YourDC" -recursive | % {if ($_.name -eq "YourUser") {write-host "User found"}}

Au passage si vous souhaitez en savoir plus sur les limitations Active Directory c’est par ici.

Supprimer toutes les applications publiées d’un serveur

En PowerShell (testé sous XenApp 6x) ça tient sur une ligne :

$Server=Read-Host "Enter Server Name";get-xaapplication -servername $Server | Foreach ($_) {write-host $_.DisplayName ; Remove-XAApplicationServer -BrowserName $_ -ServerNames $Server}

Avant

Après

Erreur : The Citrix System Monitoring Agent cannot contact the Citrix End User Experience Monitor….

Le contexte : Plusieurs fermes (4.5 R06/5 R06 en 32/64 bits et XA6.0/6.5 R01 le tout en us), au sein de ces fermes des serveurs rencontraient l’erreur :

Event Source: Citrix System Monitoring Agent
Event ID: 109
Description: The Citrix System Monitoring Agent cannot contact the Citrix End User Experience Monitor. EUEM data will not be collected. Contact Citrix Support.

La cause vient du fait que les serveurs n’ont pas d’accès à internet alors que le service “Citrix End User Experiencing Monitoring” tente de se connecter à crl.microsoft.com afin de valider un certificat.

La CTX120846 permet de contourner ce problème en créant un fichier “SemsService.exe.config”sur chaque serveurs rencontrant le problème dans “c:\Program Files\ Citrix\ EUEM\Service\”.

Le contenu du fichier “SemsService.exe.config” :

<? xml version = “1.0” encoding = “utf-8”>
<configuration> <runtime>
<generatePublisherEvidence enabled=”false” />
</ runtime>
</ configuration>

Il existe aussi la solution GPO qui consiste à désactiver la mise à jour automatique des certificats racines 🙂 .

Mais car il y a un mais dans notre cas 😉 , l’activation de ce setting n’est pas possible dans l’immédiat, donc direction un script powershell qui va copier le fichier SemsService.exe.config sur l’ensemble des serveurs d’une ferme.

Le script EdgeSightCopySemsService_exe_config.ps1 check l’Os archicture de chaque serveur et test si le répertoire c:\Program Files\ Citrix\ EUEM\Service\ (ou c:\Program Files (x86)\ Citrix\ EUEM\Service\) existe, puis vérifie que le fichier “SemsService.exe.config” n’est pas déjà présent, s’il n’est pas présent il le copie sur le serveur.

Rentrer en ligne 6 dans le script le share où se trouve le fichier SemsService.exe.config dans votre infra.

EdgeSightCopySemsService_exe_config.ps1

En attendant de passer ça en GPO faute de mieux ça fera l’affaire 🙂 .

Pour en savoir un peu plus sur l’EUEM c’est par ici.

Script : recherche de version agent Edgesight

Récemment nous avons eu besoin d’extraire des listes de serveurs au sein de fermes XA6.5, n’ayant pas la version de l’agent EdgeSight de référence ainsi que les serveurs n’ayant pas d’agent EdgeSight installé.

Nous avons donc écrit un script powershell permettant de remonter ces informations dans un fichier htm.

Au préalable il faut renseigner la version de l’agent EdgeSight validé dans votre production ligne 11 du script.

Dans notre cas une 5.4.0.5107 que notre collègue Net2Sys affectionne 😉

11 serveurs n’ont pas d’agent et un n’est pas à jour.
C’est paradoxal mais on évite de passer par EdgeSight pour la version des agents 🙂

Installation silencieuse du SDK powershell XenApp 6.5

Sur un de nos serveurs d’infra XenApp 6.5 nous avons eu besoin d’installer le Citrix.GroupPolicy.Commands (afin de pouvoir importer/exporter des policies, voir la CTX128625 pour de plus amples informations) avec en pré-requis le SDK Powershell XenApp 6.5 (au passage si vous chercher un SDK pour XenApp : SDK XenApp ).

Nous avons écrit un script permettant d’installer en unattended le SDK powershell XenApp 6.5 et le Citrix.GroupPolicy.Commands.

Au préalable télécharger le SDK Powershell XenApp 6.5 puis extraire son contenu (via 7-Zip par exemple), puis télécharger le Citrix.GroupPolicy.Commands et le copier dans le dossier setup du SDK.

Renseignez la variable $msiPath (mettre le chemin menant au dossier setup du SDK), puis exécuter le script sur le serveur en question.

$msiPath = "\\PATH_SDK\Setup\"
 $msi = @(($msipath+"Citrix.Common.Commands.Install_x64.msi"), ($msipath+"Citrix.XenApp.Commands.Client.Install_x64.msi"), ($msipath+"Citrix.XenApp.Server.Sdk_x64.msi"), ($msipath+"CitrixGroupPolicyManagement_x64.msi"))

foreach($_ in $msi)
 {Start-Process -FilePath msiexec -ArgumentList /i, $_, /qb- -Wait
 Write-Host "$msi"
 }

import-module ($MsiPath+"Citrix.GroupPolicy.Commands")

Il est aussi possible de passer par un invoke-command à la place du Start-Process pour une installation en remote, le /qb- c’est juste qu’on aime bien voir les progressbar lors des installations 🙂 .