Comme ce n’est pas vraiment documenté (voir pas du tout), on vous met la ligne de commande pour désactiver en PowerShell les abonnements utilisateur (Disable User Subscription) d’un magasin (Store) dans StoreFront.
Set-DSLockedDownStore -SiteId “1” -VirtualPath “/Citrix/VotreStore” -IsLockedDown $True
Bon on vous l’avoue, c’est pour aussi l’avoir sous la main pour une prochaine fois 😉 .
Fini le bon vieux temps où l’on pouvait recréer le listener RDP via une GUI. Sous Windows 2012/2012 R2 il faut désormais passer par la case registre.
Histoire de ne pas faire d’import de registre le jour J, on s’est fait une GUI via un script Powershell (he oui encore du winform 🙂 ) afin de pouvoir recréer un listener RDP sous un serveur Windows 2012/2012 R2 (pour l’instant seul Windows 2012/2012 R2 sont concernés).
Une fois lancé le script vous permet de connaitre l’état du listener RDP, son port et si ce dernier répond bien à un socket TCP.
Via un qwinsta nous avons l’état du listener RDP (et plus si vous avez d’autres listeners)
Cliquez sur le bouton “Recreate Rdp listener” pour récréer le listener RDP (un backup du listener est réalisé dans le répertoire d’exécution du script)
Un popup vous demande la confirmation de l’action
Un fois le listener recréé, vous obtenez un message de confirmation
RecreateRdpListener.rar
Si vous souhaitez passer par la case registre pour recréer un listener RDP 2012/2012R2 , la KB de dell “How to recreate or add an additional RDP Listener in Windows Server 2012 and 2012 R2” vous aidera dans votre démarche.
Comme vous le savez, lorsque vous supprimez des objets utilisateurs ou groupes de votre Active Directory ces derniers restent dans vos applications publiées et vous vous retrouvez avec des objets non résolus affichés comme ci-dessous.
Un peu de Monsieur Propre ?
Supprimer ces objets non résolus est on ne peut plus simple via PowerShell, un Get-XaApplication, une boucle et un remove-XaapplicationAccount et c’est fait 🙂 .
Bien sûr avant l’exécution du script vérifiez que votre DataStore est bien backuper 😉 .
Le script a été testé sur des fermes XenApp 6.5 (US et FR).
Même notre lab passe au Monsieur Propre 🙂
Une fois le script passé les comptes non résolus ont bien disparus
CleanAppCptNotResolve.ps1
Si vous souhaitez ajouter des hosts dans Zabbix il n’y a pas trente six solutions :
L’import via un fichier XML ressort comme la plus rapide, simple et pratique des solutions à mettre en place, c’est pourquoi nous avons donc écrit un script PowerShell permettant de générer un fichier XML issu d’une liste de Hosts préalablement renseignés au sein d’un fichier à plat.
Prérequis :
Le script va récupérer l’IP de chaque Host (les hosts n’ayant pas d’IP sont exclus volontairement), afin de permettre une fois les Hosts importés d’interroger les clients Zabbix via leurs IP ou leur nom DNS.
Une fois le script exécuté, un fichier “Zabbix_Import_Srv.xml” est créé à la racine du dossier où se trouve le script “Zabbix_Import_Host.ps1”.
Il ne reste plus qu’à importer dans Zabbix (et aussi dans MonitorX 😉 ) vos Hosts (le script a été testé avec Zabbix ver 2.4).
Dans Zabbix allez dans l’onglet Configuration, puis cliquez sur Host et cliquez sur le bouton Import.
Cliquez sur le bouton Choisissez un fichier
Sélectionnez le fichier “Zabbix_Import_Srv.xml” précédemment créé
Cliquez sur le bouton Import
Un bandeau sur fond vert confirme le succès de l’import
Zabbix_Import_Host.rar
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
Dans cette mise à jour, nous avons corrigé quelques bugs mineurs et rajouté les fonctionnalités ci-dessous :
Nos collègues ont bien apprécié la partie Gpos applied 😉
Pour télécharger XenaApp_Usr c’est par ici
XenApp_Check pour XA 6 passe en 2.6, dans cette mise à jour nous avons modifié le check du nombre de serveur(s) publié(s) au sein d’une application afin que ce dernier prenne en compte les Groupes de tâches (Worker Groups).
Toutes les applications n’ayant qu’un seul serveur de publié en direct ou via les Worker Groups seront regroupées dans la section (section « Server in Application(s)).
Plus d’excuse pour les publications via les Worker Groups .
Le billet concernant XenApp_Check est ici .
XenApp_CheckXA6 2.6 (XenApp 6.x)
XenApp_CheckXA6.rar
————————————————————————————————————
MAJ : 23/03/2015
V1.4
————————————————————————————————————
MAJ : 22/12/2014
V1.3
————————————————————————————————————
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 :
A cela nous avons ajouté la possibilité d’effectuer les actions ci-dessous :
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.
XenApp_Usr.rar
———————————————————
MAJ : 24/11/2014
V1.1
Correction de bugs mineurs
Ajout de la charge serveur (Load server)
———————————————————
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 :
Sur 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
Rien 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).
Si 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 :
RemoteAssistance.ps1
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).
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.
Merci pour les DL 😉