Powershell Archive

12

XenApp_Usr7x

Et voilà ça faisait longtemps que nous souhaitions porter XenApp_Usr sur XenApp 7x , pressés par nos collègues de l’admin aujourd’hui c’est chose faite :  XenApp 7x est enfin UP.

Pour rappel nos XenApp_Usr repose intégralement sur du PowerShell (hé oui même la partie graphique, on sait ça c’est pas bien lol).

Le but de XenApp_Usr7x est de pouvoir rapidement retrouver la/les session(s) d’un utilisateur au sein d’une ferme XenApp, mais on ne s’arrête pas là puisque nous avons intégré aussi la recherche d’applications, serveurs, Delivery Group et Machine Catalog.

Lorsque qu’une session est sélectionnée plusieurs informations sont disponibles (dont notamment l’idle time de la session 😉 ).

  • Start time
  • Establishment Time
  • Establishment Duration
  • Idle Time
  • Connected Via IP
  • Connected Via IP
  • Client Adress
  • Client Platform
  • Client Name
  • Receiver Name
  • Receiver IP Address
  • Session Type
  • Application
  • Delivery Group du serveur hébergeant la session
  • Machine Catalog du serveur hébergeant la session
  • Process de la session
  • Gpo(s) de la session

Les actions possibles sur une session sont l’envoi d’un message, le shadowing, le logoff de la session et le kill de process.

XenApp_Usr7x a été validé sur des fermes XenApp 7.6 et 7.12 (DDC en W2k12 et environnement mixte pour les broker machine – W2K8 R2 et W2K12)

Pré-requis :
XenApp_Usr7x peut-être exécuté à partir d’un DDC (W2K12) ou d’un serveur d’admin (W2K12) avec les snap-ins PowerShell XenApp/XenDesktop.

Lors du premier lancement à partir d’un serveur admin il vous faudra entrer un DDC de votre ferme dans le champ DDC puis cliquez sur le bouton Check DDC (le DDC est stocké en dur dans un fichier afin d’éviter de le ressaisir lors des prochains lancements dans C:\Users\username\AppData\Roaming\Ctxblog\XenAppUsr\XenAppUsr7x.txt).

 

Les zones en jaune sont cliquables 😉



Si vous souhaitez rechercher un serveur, une application, un Machine Catalog ou un Delivery Group allez dans le Menu Tools-Search Server/Apps/DG/MC.

Exemple sur la recherche d’un Delivery Group
Cliquez sur le DG souhaité



En prime vous avez même le load du DG 🙂



Exemple sur la recherche d’un serveur


Vos remarques et suggestions sont comme toujours les bienvenues ;).


XenApp_Usr7x.rar

0

Cacher toutes les applications désactivées d’une ferme XenApp 6.5

Histoire d’éviter de devoir renvoyer par mail, lync, telegram and co, nous partageons avec vous un tout petit (vraiment petit 🙂 ) oneliner permettant de cacher toutes les applications désactivées d’une ferme XenApp 6.5 qui ne sont pas cachées (pourquoi vous nous direz, parce que certains désactivent les applications et oublient de les cacher……)

get-xaapplication |?{$_.enabled -eq $False -and $_.HideWhenDisabled -eq $False}|%{set-xaapplication -browsername $_.browsername -HideWhenDisabled $True}

 

0

PowerShell : désactiver les abonnements utilisateur

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 😉 .

0

Windows 2012/2012 R2 : Recréer le listener RDS

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.

 

RecreateRdpListenerVia 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)

 

RecreateRdpListener1Un popup vous demande la confirmation de l’action

 

RecreateRdpListener2Un fois le listener recréé, vous obtenez un message de confirmation

 

 Download_2
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.

0

Script : Supprimer les comptes non résolu dans XenApp

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.

 

DeleteAccAppsNotResolveUn 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).

 

AppErrorResolveCptMême notre lab passe au Monsieur Propre 🙂

 

DeleteAccAppsNotResolve1
Une fois le script passé  les comptes non résolus ont bien disparus

 

Download_2CleanAppCptNotResolve.ps1

0

StoreFront 3.x erreur : Impossible de démarrer le bureau…….

Sur un cluster de StoreFront 3.0 (W2K12 US)  nous avons rencontré un problème de lancement d’applications et bureaux publiés  (ferme en XA 7.6 US) avec Internet Explorer (ver 9,10 et11), en effet cela fonctionnait sans problème avec Firefox et Chrome.

SF3Error1On va pas se réconcilier de si tôt avec IE

 


En regardant sur les Storefronts nous avons constaté les Event ID 0 et 28.


SF3Error2

 

Description: Failed to launch the resource ‘………………’ using the Citrix XML Service at address ‘http://VotreServeur/scripts/wpnbr.dll’. The XML service returned error: ‘not-trusted’.

 

SF3Error3

 

Description: The Citrix servers do not trust the server. This message was reported from the XML Service at address http://VotreServeur/scripts/wpnbr.dll [NFuseProtocol.TRequestAddress].


Ce qui nous a mis sur la piste est bien sur le « The Citrix servers do not trust the server », en effet en lancant un Get-BrokerSite sur un de nos Delivery Controller nous avons constaté que la valeur TrusRequestsSentToTheXmlServicePort était à False.


SF3Error4On vous l’accorde ça n’explique pas le fait que ça fonctionne avec d’autres navigateurs

 

Afin d’activer le TrustRequestSentToTheXmlServicePort il faut lancer la commande suivante sur un de vos Delivery Controller : Set-BrokerSite -TrustRequestSentToTheXmlServicePort $True

 

SF3Error5La commande Get-BrokerSite confirme bien que nous sommes en True en TrustRequestSentToTheXmlServicePort

 


SF3Error6
Et oui avant on pouvait setter l’approbation des requêtes XML en policy (exemple sur une ferme en XA 6.5)

 

2

XenApp_Gpupdate v1.1

Mise à jour de XenApp_Gpupdate (ver 1.1).

  • Ajout de la possibilité d’afficher la liste complète des serveurs membres de la ferme (via le bouton « Servers »)
  • Ajout de la possibilité de rechercher un serveur spécifique (via la coche « Search server »)
  • Retour du statut de la commande Gpupdate /force (indique si le process a bien été lancé sur le serveur et si ce dernier est bien fermé.), avec la durée d’exécution (duration) par serveur
  • Correction de bugs mineurs

 

XenApp_GpUpdate_V1.1


Download_2XenApp_Gpupdate.rar

 

Le billet original  sur XenApp_GpUpdate ici.

0

SDK Modification du scope d’exécution

Il y a quelques jours nos scripts de prod (d’une de nos fermes XenApp 6.5 R04)  renvoyaient les informations d’une ferme de qualification, en regardant de plus près nous avons constaté que le scope d’exécution du SDK avait été changé sur un de nos serveurs d’administration.

Un Get-XADefaultComputerName confirma que le scope n’était pas le bon, afin de rétablir le scope sur la ferme d’appartenance du serveur il faut passer par un Set-XADefaultComputerName -ComputerName « VotreServeur ».

Ce billet juste pour souligner qu’un changement de scope ne concerne pas que la session dans laquelle il est lancé mais le serveur en lui-même, l’information étant présente dans la valeur « DefaultComputerName » situé dans [HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\XenAppCommands].

Si vous souhaitez ne pas changer de scope, les cmdlets du SDK permettant de faire du remote avec l’utilisation de l’argument -computername.

16

Supervision de silo serveurs

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 %.

 

XenApp_LoadMonitor1La 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

 

XenApp_LoadMonitor2La vue d’un silo avec la charge de chaque serveur

 

Les pages générées sont compatibles avec Chrome, Firefox et IE (9).

 

Download_2XenApp_LoadMonitor.rar

2

XenApp_Usr : mise à jour 1.4

XenApp_Check passe en 1.4, la liste des ajouts et corrections sont ci-dessous :

  • 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

XenApp_UsrV14

 

Pour télécharger XenaApp_Usr c’est par ici