Archives de catégorie : Non classé

Palette Citrix pour Yed

Je ne sais pas pour vous, mais à chaque fois que je cherche une solution alternative à Microsoft Visio, et bien je tombe toujours sur les mêmes soucis :

  • Les stencils éditeurs tiers ne sont pas présents
  • Les stencils par défaut font trop cheap.

J’ai testé Yed qui est un outil open source vraiment pas mal, qui comporte l’avantage d’être cross platform. Mais comme ses camarades, les icônes ne sont pas terribles. Alors du coup j’ai pris mon courage à deux mains et fait une conversion de stencils Citrix (ce dont j’avais besoin 😊). J’ai récupéré les stencils visio sur le site de Daniel Feller https://virtualfeller.com/tag/visio/

J’espère que ça va vous servir :

Palette-citrix

Yed:

https://www.yworks.com/

voici quelques exemples réalisés avec Yed:

 

 

Remplacer PowerShell ISE par Visual Studio Code

Avec l’arrivée sur Powershell Core 6.0 disponible ici, le nouvel éditeur PowerShell recommandé est Visual Studio Code. Mais certains ont du mal à retrouver leurs petits par rapport à Powershell ISE, alors voici un petit article qui va vous aider à vous y retrouver.

Installation

La source est disponible sur le site https://code.visualstudio.com/  Visual Studio Code est cross platform, il est disponible pour Windows mais aussi MacOs et Linux

Si vous utilisez MacOs ou Linux, il vous faudra installer le PowerShell Core disponible à l’adresse suivante :

https://github.com/PowerShell/PowerShell

Continuer la lecture

LoginPI : Enfin un remplaçant pour edgesight for load testing

LoginPI est un outil qui permet de tester des connexions utilisateurs dans les différents types d’environnement suivant :

  • Citrix StoreFront
  • Citrix Web Interface
  • Direct Desktop
  • Microsoft RDP Connection
  • Vmware Horizon View 5.x
  • Vmware Horizon View 6.x

Avec loginVSI vous pourrez simuler une session complète, avec ouverture de session, ouverture de programmes et personnalisation des actions. Alors bien-sûr, ce n’est pas sans rappeler l’excellant edgesight for load testing, mais hélas, depuis la version de Xenapp/Xendesktop 7.X l’outil est malheureusement plus disponible. L’exemple de configuration que je vais vous montrer concerne uniquement Citrix. 

Le fonctionnement

Dans un premier temps, nous avons un serveur LoginPI qui héberge une base de données avec les différentes configurations, mais aussi l’historique des tests effectués. On y trouve aussi l’interface d’administration. C’est depuis ce serveur que nous préparons les différents scénarios.

Ensuite vous avez les Laucher. Ce sont des machines qui exécuteront les connexions, elles auront le rôle du client.

Les Target sont les serveurs VDI, où les différents scénarios seront joués.

Le tout est utilisé avec un comptes Active Directory qui est créé lors de l’installation de LoginPI

L’installation

Les sources sont disponibles à l’adresse suivante :

https://www.loginvsi.com/downloads

Vous devez aussi disposer d’une base MSSQL, ici j’ai choisi une base SQL EXPRESS 2014

https://www.microsoft.com/en-us/download/details.aspx?id=42299

Exécuter les setups

L’installation se fait

Une fois fini, redémarrer le serveur

Après redémarrage vous pouvez accéder la console web LoginPI

Une fois l’interface de management lancée, vous devez entrer les paramètres de SQL

Entrer les paramètres de sécurités, plus cliquer sur Submit

Après l’application des paramètres, vous pouvez vérifier que la base de données a bien été créé

 

Si vous avez le message suivant à la création de la base de données c’est le serveur LoginPI

 

C’est que le serveur loginPI ne peut pas communiquer avec le sql. Il faut donc autoriser les connexions, aller dans SQL Server Configuration Manager. Puis dans SQL Server Network Configuration sélectionnez le serveur SQL Puis sur TCP/IP sélectionner Properties

Entrer le port pour l’IpV6 ici le port 1422

Dans IPAII entrer le port par défaut 1433

Puis pour l’AD Setup, entrer les paramètres nécessaires :

  • Base OU : C’est l’endroit où l’OU LoginPI sera créé
  • Usermane : le format de l’utilisateur
  • Password : Le mot de passe des utilisateurs créés
  • Domain(FQDN) : le nom de domain
  • Nombre of Users : le nombre d’utilisateurs qui sera créé

Quand vous allez cliquer sur « Generate Script ». Un script powershell sera généré.

Enregistrer le Script PowerShell

Il vous faudra l’exécuter sur un serveur qui a le module powershell ActiveDirectory

Exécuter le script

Vous pouvez, une fois finie, vous pouvez vérifier que l’OU a bien été créé

Quand la configuration est terminée, pensez à ajouter la licence, comme ci-dessous :

Pour des questions pratiques, nous partageons le répertoire Login PI, cette étape n’est pas obligatoire

J’autorise le groupe LoginPI créé précédemment par le script powershell sur le répertoire LoginPI, cette étape n’est pas obligatoire

Je fais la même chose pour les droits NTFS

Installation sur launcher

Les binaires d’installation du launcher sont disponibles dans le répertoire d’installation de loginVSI

Cliquer sur Next

Accepter les termes de la licence, puis cliquer sur Next

Sélectionnez le répertoire d’installation, puis cliquer sur Next

Entrer l’adresse du serveur avec le port de communication, puis cliquer sur Next

Cliquer sur Install

Une fois terminé cliquer sur Finish

Vous pouvez exécuter le launcher

Pour que le launcher soit autorisé, il faut l’approuver sur la console LoginPI. On y reviendra par la suite.

Configuration

Avant de commencer vous avez besoin de créer un profil, plusieurs types de scénarios sont disponibles, ici j’utilise le Storefront

Puis cliquer sur Save

Dans l’onglet, Launchers Overview, vous avez accès aux sources, c’est aussi là que vous approuvez les Launcher.

Vous pouvez les approuver en cliquant sur l’icône Verte comme ci-dessous

Le Launcher est validé

Dans le log du launcher, vous pouvez valider qu’il est bien approuvé

Dans Worload settings, vous pouvez configurer les différents scénarios, et l’environnement de d’execution

Il faut maintenant configurer la connections, dans connections, sélectionnez « Create connection »

Renseigner les différents paramètres :

  • Connection name : le nom de la connexion
  • Timeout in Seconds : le temps d’expiration de la connections
  • Enabled : activation de la connections après validation des paramètres
  • StoreFront URL : Ici ce sera l’adresse de Store
  • Resource : C’est le nom du Delivery Group ou du bureau, attention cela dépend de votre version de Xendesktop

Une fois complété, cliqué sur Save

Une fois les paramètres configurés, il faut associer des utilisateurs . Ce sont ces utilisateurs virtuels qui exécuteront la session. Cliquer sur l’icône avec le « petit bonhomme bleu » comme ci-dessous pour accéder aux paramètres

Ajoutez le compte, puis cliquer sur save. C’est le compte qui a été créé par le script Powershell qui ajoute les compte dans l’Active Directory. Pensez en parallèle à donner les droits de connexion à ce compte

Une fois ajouté, cliquer sur Close

Pour finir, nous allons créer un Job, sélectionnez Create Job

Dans les paramètres :

  • Name : Le nom du job
  • Date la date de début du job et son expiration
  • Time : Dans quelle tranche horaire le job est joué. Cela peut être pratique par exemple pour jouer un scénario pendant des heures de travail par exemple 7h – 17h
  • Interval in minutes : C’est l’intervalle entre les lancements de scénario, je vous conseille de ne pas mettre un temps exécution trop court
  • Enabled : Activation du job

Une fois finit, il est disponible dans la liste des jobs

Le reporting et l’exécution des scénarios :

Il ne reste plus qu’à regarder le scénario se jouer

Dans Login PI, nous avons la possibilité d’avoir un Dashboard où l’on peut retrouver les performances d’ouverture des applications, que les sessions s’ouvrent bien.

Les latences de connexions, le temps d’ouverture de session, le journal des alertes.

On peut avoir un vrai suivi des connexions

Login PI est un super outil pour avoir un monitoring de sa production. Cela permet vraiment de suivre les applications et le comportement des machines VDI

 

 

Powershell: Cacher l’exécution d’un script powershell

Si vous voulez cacher l’exécution d’un script powershell ou même d’un programme, voici une méthode simple. Pour cela on va passer par un script vbs. En effet l’interpréteur wscript, n’affiche pas de fenêtre d’exécution par défaut, contrairement à l’interpréteur cscript ou powershell. L’intérêt c’est que l’utilisateur ne voit pas l’exécution d’un script ou processus quel qu’il soit. Cela peut être utile pour cache un script de démarrage, une tache planifiée, une publication CITRIX ou RDS.

Pour nos tests on va utiliser un script en powershell pour afficher une fenêtre toute simple :

Voici ce qu’on veut cacher l’interpréteur powershell avec son fond bleu disgracieux :hide-powershell1-4

Continuer la lecture

vCenter Server Appliance 6.0: activation du SSH

Si pendant l’installation de vCenter Server Appliance vous avez oublié d’activer le SSH Login, qui s’active pendant l’installation au moment de Network Settings:

Vcenter_appliance_Shh_1sur10

Voici deux méthodes pour l’activer :
Par l’interface web :
Depuis le client web dans home, aller dans System Configuration

Vcenter_appliance_Shh_2sur10

Puis sur le node de votre Vcenter, faite un clic droit puis sélectionner « Edit Setting … »

Vcenter_appliance_Shh_3sur10

Ici vous pouvez la connexion SSH en cochant la case Enable SSH login et en cliquant sur OK

Vcenter_appliance_Shh_4sur10

Depuis la console locale
Connecté vous depuis la console de votre Appliance :

Vcenter_appliance_Shh_5sur10

Puis pour ouvrir une session appuyer sur Atl+F1

Vcenter_appliance_Shh_6sur10

Puis connectez-vous

Vcenter_appliance_Shh_7sur10

Pour vérifier l’état du SSH utiliser la commande

Vcenter_appliance_Shh_8sur10Pour activer le SSH utiliser la commande :

Vcenter_appliance_Shh_9sur10Maintenant votre accès SSH est actif :

Vcenter_appliance_Shh_10sur10

 

 

 

 

 

Powershell : remonter les utilisateurs par processus Query-app

Souvent quand on fait un audit d’un environnement nous avons besoin d’avoir les informations, combien d’utilisateurs utilisent une application serveur, par exemple dans une session Remote desktop ou Citrix. Selon la version du système de publication utilisé, bureau ou application les outils sont différents. Là je vous propose une fonction universelle qui vous permettra d’avoir une remontée sur tout système. Dans cette fonction nous aurons en entrée ordinateur requeté et application, puis en sortie ordinateur, application, utilisateur, mémoire utilisé, à quelle heure l’application à démarrer, l’heure de la requête et le chemin où se trouve l’application.

Dans un premier temps nous allons utiliser le WMI avec la classe Win32_Process

Exemple sur un processus :

get-app-1sur11

get-app-2sur11

Continuer la lecture

Powershell test de version de Hyper-V

Alors cette semaine je suis tombé sur un problème simple, savoir quelle version d’Hyper-V est présente sur le serveur. J’avais besoin de ce contrôle car selon la version d’Hyper-V j’aurai une création différente de ma VM. Par exemple une VM Linux n’a pas les mêmes besoins qu’une VM Windows Server 2012. Alors nous avons plusieurs solutions
La première est de vérifier la version du service de gestion d’ordinateurs virtuels

pw_hp_ver1sur10

Là on peut faire d’une pierre deux coups car on connaît la version d’Hyper-V et si le service est bien présent :

pw_hp_ver2sur10

La seconde en WMI(celle que nous utiliserons ici) et de faire une requête au niveau classe Win32_operatingSystem puis je récupère par exemple la propriété versioninfo puis Version exemple ci-dessous :

pw_hp_ver3sur10

Ou aussi avec WinRm

pw_hp_ver4sur10

Ensuite on peut en déduire par le numéro de version avec les 2 premiers chiffres :

NuméroVersion
6.0Hyper-V 2008
6.1Hyper-V 2008 R2
6.2Hyper-V 2012
6.3Hyper-V 2012R2
10.0.10586Hyper-V 2016 ou Hyper-V Windows 10

Et bien oui on est sur la même version du noyau en Windows Server 2016 TP4 et Windows 10. Surprise 😛 . En fait c’est lié à la virtualisation imbriquer. J’explique ici pourquoi: Windows 10 Build 10565 : La virtualisation imbriquée

pw_hp_ver5sur10

Moi dans le fond ça me ne dérange pas mais ça ne me dit pas tout ça si le rôle Hyper-V est installé. Je vais connaitre uniquement par cette méthode la version du système d’exploitation.
Bon là encore une fois je pourrais attaquer la classe WMI pour avoir l’information. Alors je pourrai utiliser la classe Win32_ServerFeature

pw_hp_ver6sur10

La seule chose c’est que la classe WMI Win32_ServerFeature n’existe pas sur Windows 10 et moi j’aime bien les scripts font papa maman 😀
Par contre on peut utiliser un test sur compteur de performance Hyper-V, et bien oui si le rôle n’est pas installé la classe WMI ne sera présente. Par exemple on peut utiliser la class Win32_PerfFormattedData_HvStats_HyperVHypervisor
Voilà un exemple pour une machine sans Hyper-V, nous avons un code retour d’erreur

pw_hp_ver7sur10

Avec une machine avec Hyper-V

pw_hp_ver8sur10

Là il va falloir dégainer le try et le catch :

Voilà deux exemples :

Hyper-V non présent :

pw_hp_ver9sur10

Hyper-V présent :

pw_hp_ver10sur10

J’ai ajouté trois tests. Avant l’exécution du code je vérifie si la machine est bien en ligne avec un Ping, ensuite les accès WMI sont bien possibles et pour finir on recherche si le compteur de performance Hyper-V est bien présent.

Pour le ping tout est expliqué ici:

Powershell teste de vérifications : Première partie Ping

Exemple:

pw_hp_verBonus

 

Filmer en Gif une partie de l’écran screentogif

Voici un petit outil pratique qui vous permettra d’enregistrer une partie de filmer une zone de votre écran puis d’enregistrer l’animation au format Gif. Si vous aussi vous êtes comme moi et que vous écrivez souvent des procédures électroniques, cet outil est fait pour vous. C’est screentogif:

http://screentogif.codeplex.com/

screentogif

voici un exemple avec une utilisation de la commande powershell Get-Unique, ici on s’en sert pour remonter un processus unique avec Get-Process:

screentogif

 

 

 

 

 

Powershell teste de vérifications : Première partie Ping

En général avant d’exécuter un script nous avons besoin d’exécuter différents tests, par exemple est ce qu’un élément est bien en ligne, le service WMI répond ou un port ouvert. Cela évite de mauvaises surprises dans les scripts.

Voici une longue série sur les différents tests à faire avant d’exécuter un script. Cette première partie traitera du test de la connexion avec le Ping (ICMP)

Pour faire un ping cela se passe avec Test-Connection

powershell_test_1sur7

Afin de l’optimiser nous pouvons faire un seul test au lieu de 4 avec le paramètre -Count 1

powershell_test_2sur7

Continuer la lecture

Windows Server 2016 Hyper-V : Powershell Direct

Quesque Powershell Direct:

Powershell Direct est une nouvelle méthode d’accès à distance d’une machine virtuelle. Powershell Direct utilise la couche virtualisation et non la couche réseau, ce qui évite tout problème de configuration firewall ou bien de Vlan.

Cette méthode ajoute 2 paramètres aux commandes Enter-PsSession et Invoke-Command:

Continuer la lecture