Powershell – Petite astuce

Il est assez simple d’enrichir un tableau d’objets en y ajoutant une colonne personnalisée.

Etape 1:

Là on est venu greffer une nouvelle colonne ‘Column Name’ à la sortie de Get-Process. Résultat :

Etape 2 :

On va mettre un peu de dynamique dans tout ça et mettre une colonne personnalisée ‘Progress’ affichant une valeur entre 1 et 100, comme pour un pourcentage.

C’est déjà plus sympatique.

Etape 3 :

C’est ici que la magie opère. Souvenez vous que l’expression ( ;e={…}  ) qui définit la valeur de la colonne est censée renvoyer un text, n’importe lequel. Et si j’avais envie que cette colonne m’affiche un pourcentage mais sous une forme plus graphique. Par exemple, au lieu de 68%, on afficherait “68% [ooooooo   ]”, un peu comme une barre de progression. Eh bien, c’est exactement ce que fait la petite fonction que je vous offre aujourd’hui. Tout d’abord, le résultat en image :

Plutôt sympa, non ? Voici le code complet :

La fonction Draw-Percent a trois paramètres :

  • Value : valeur du pourcentage à afficher (entre 0 et 100)
  • Index : facultatif. Définit quel symbole (à choisir parmi o, #, ■, |, -, *)  sera utilisé pour dessiné la barre de progression. Par défaut, c’est le petit carré ■.
  • Width : facultatif. Définit la largeur (en nombre de caractère) de la barre de progression. Par défaut, la taille est de 10 car mais vous pouvez l’élargir si nécessaire.

J’espère que cette petite astuce vous aura plu. Amusez vous bien 🙂

Mise à jour :

Exemple pratique : Get disk Used Space

 

Migration Exchange 2010/2016 – Problèmes atypiques

Je suis actuellement au milieu d’une migration Exchange 2010/2016 et tout se passait globalement bien.

  • Préparation de l’annuaire
  • Installation des nouveaux serveurs Exchange 2016 CU 15
  • Activation de Outlook Anywhere (rpc/http) sur les serveurs Exchange 2010
  • Définition de Outlook Anywhere comme protocole client par défaut (d’abord par gpo, pour évaluation, puis généralisation en utilisant Set-OutlookProvider)

Et la les soucis commencent !

Lors de nos tests, il s’avère que sur certains postes de travail et bien que Outlook Anywhere soit bien le protocole par défaut (le profile utilisateur et un test Autodiscover sur le poste client le confirment), la fenêtre affichant “L’état de la connexion” s’entête à afficher TCP/IP (sur Outlook 2010) ou RPC/TCP (sur Outlook 2013).

D’autres clients pourtant sont bien connectés en RPC/HTTP.

Seconde anomalie, lorsqu’un utilisateur ayant sa boite aux lettres sur Exchange 2010 tente d’ouvrir une session OWA sur un serveur 2016, cela fonctionne pour certains (le processus de proxyfication se déroule correctement et sa boite aux lettres s’affiche) et pas pour d’autres (le formulaire d’authentification s’affiche à nouveau).

Généralement, les problèmes de type authentification sont dus à une mauvaise configuration des paramètres Outlook Anywhere et OWA sur Exchange 2010. Dans notre cas, rien de tout cela. Et ce qui m’intriguait le plus, c’était que la mécanique fonctionnait pour certains utilisateurs et pas pour d’autres. La configuration des serveurs ne pouvait donc pas être en cause.

Après avoir lu au moins 500 articles sur le net, je trouve l’inspiration sur l’excellent blog  https://clintboessen.blogspot.com. Puisque le problème est lié à certains utilisateurs, il est probable que certains attributs de ces derniers soient pour une raison quelconque différents entre deux utilisateurs (ceux pour qui ça fonctionne et les autres).

J’exporte donc l’ensemble des attributs dans un fichier pour chacun des deux utilisateurs et je les compare un à un (en utilisant l’excellent winmerge). Déception, aucune différence notable ne peut expliquer cette différence de comportement.

Je me dis alors que le pb est peut être lié à un des serveurs Exchange 2010. Je me lance dans la même démarche et je compare la totalité des attributs renvoyés par Get-OWAVirtualDirectory pour chacun des deux serveurs :

Et la effectivement, un attribut attire mon attention :

  • Sur le serveur Exchange 2010 #1 – ExtendedProtectionTokenChecking = Allow
  • Sur le serveur Exchange 2010 #2 – ExtendedProtectionTokenChecking = None

Est ce que cette différence pourrait être à l’origine de nos soucis ? Je n’avais encore jamais eu à utiliser ou modifier ce paramètre avant ! Quelques recherches google plus tard, la responsabilité de ExtendedProtectionTokenChecking semble se confirmer. None étant la valeur par défaut, je décide de la fixer sur le premier serveur :

+ IISReset

Je relance mon test OWA et là, miracle, ça fonctionne !

Le problème Outlook Anywhere se règlera de la même manière. Get-OutlookAnywhere | fl sur les deux serveurs montre à nouveau le même paramètre avec des valeurs différentes entre les deux serveurs.

Je fixe à nouveau le paramètre :

+ IISReset

Outlook Anywhere fonctionne désormais parfaitement sur l’ensemble des postes.

Exchange est un produit particulièrement complexe et même avec des années de pratique, il nous arrive encore de caler et d’être surpris par des problèmes qui peuvent parfois sembler insurmontable. Seuls l’acharnement et l’expérience et souvent une petite dose de chance aussi, font qu’on arrive finalement à bout des difficultés.

Surtout, ne baissez jamais les bras 🙂

Bon courage à tous.

 

 

Découvrez les présentations MS Ignite 2018

Découvrez le nouveau Exchange 2019, les environnements Exchange hybrides, le retour d’expérience des plus grands spécialistes Exchange, … Incontournable.

Merci au brillant Michel de Rooij d’avoir compilé pour nous l’essentiel des sessions. Les vidéos des présentations ainsi que les slides powerpoint sont disponibles en libre téléchargement.

Powershell – Générer des messages de test réalistes

Pour bien observer son environnement de messagerie, il est parfois nécessaire de simuler une activité en envoyant des messages de test pour s’assurer du bon fonctionnement des différentes briques de la plate-forme. C’est particulièrement vrai dans un environnement Exchange.

C’est pour répondre à ce type de problématique que j’ai conçu ce script fortement inspiré d’un post de Jeff Hicks que je salue et remercie au passage.

L’utilisation du script repose sur un certain nombre de fichiers mais son fonctionnement reste très simple.

Le répertoire de travail contient :

  • Le script Send-RandomEmails.ps1
  • Un fichier subject.txt qui contient une liste de sujet de messages récupérés dans ma propre boite aux lettres. Je vous encourage évidemment à remplir ce fichier avec des choses qui vous parlent.
  • Un fichier recipients.txt qui contient la liste des destinataires possibles des messages qui seront générés. En étudiant un peu le script, vous verrez que vous pourrez modifier le nombre maximal de destinataires pour chaque message, la manière de définir ces destinataires (en les piochant directement dans votre environnement par exemple avec un simple Get-Mailbox | Select PrimarySmtpAddress, …)
  • Un ensemble de fichier attach_*.*. Ce sont des pièces jointes de différentes taille que j’utilise pour effectuer différents tests, notamment pour tester les restrictions de tailles définies au niveau des connecteurs exchange. J’ai utilisé un des scripts définis dans le billet précédent pour générer des fichiers de différentes tailles.
  • Un ensemble de fichiers body_*.txt contenant des contenus de vrai messages que j’utilise pour donner plus de réalisme à la simulation.

Principe de fonctionnement :

Le script accepte un unique paramètre $count, qui permet de définir le nombre de message à générer et envoyer.

Le script prépare une série de messages pour lesquels :

  • L’expéditeur est choisi de manière aléatoire dans la liste $sender
  • Le ou les destinataires sont choisis de manière aléatoire dans la liste $recipients
  • Le sujet du message est pris de manière aléatoire dans le contenu du fichier subject.txt
  • Le corps du message est pris également de manière aléatoire dans un des fichiers body_*.*
  • Une pièce jointe est choisie dans la liste des fichiers attach_*.*
  • Entre chaque message, le script fait une pause d’un délai aléatoire (défini par la variable $MaxDelay)

Un exemple de message de test reçu :

Le script est disponible ici. N’hésitez pas à commenter et à me faire part de vos propres retour d’expérience.

Powershell – Créer un fichier d’une taille donnée

Hier, nous expliquions comment créer simplement un fichier d’une taille donnée à l’aide de l’utilitaire fsutil de windows.

Aujourd’hui, nous reprenons le même exercice mais en version powershell, en présentant 4 manières différentes (il en existe probablement d’autres) de créer un fichier de taille donnée. Les deux premières méthodes permettent de créer un fichier vide et les deux suivantes un fichier au contenu aléatoire.  Nous n’allons pas nous lancer dans de longues explications mais simplement donner quelques éléments de performances sur les 4 méthodes.

Méthode 1 : Création d’un fichier vide

Temps de création d’un fichier de 5MB : 4,46 ms

Méthode 2 : Création d’un fichier vide ou contenant un même caractère répétitif.

Temps de création d’un fichier de 5MB : 1,212 s

Méthode 3 : Création d’un fichier au contenu aléatoire.

Temps de création d’un fichier de 5MB : 68,66 ms

Méthode 4 : Création d’un fichier au contenu aléatoire.

Temps de création d’un fichier de 5MB : 32,86 ms

L’ensemble des scripts peut être téléchargé ici.

Astuce – Créer un fichier d’une taille donnée

J’ai du dernièrement effectués des tests d’envoi de messages avec des pièces jointes de taille donnée.

Le plus simple semble être de rechercher sur son disque des fichiers dont la taille correspondant à peu à ce qu’on cherche mais on a vite fait de commencer à tourner en rond.

Le plus simple est donc de créer soit même un fichier (vide) dont la taille sera exactement celle souhaitée.

En ligne de commande, exécuter simplement:

et le tour est joué. Vous venez de créer un fichier de 1MB dans le répertoire c:\temp.

Powershell – Monitorer une liste de serveurs

 

Ce script développé dans le cadre d’un projet, permet de monitorer une liste de serveurs web IIS sous Windows. Il pourrait adresser une ferme de serveurs web,  sharepoint ou une infra Exchange.

Il tourne en boucle (rafraichissement des données toutes les 10 sec par defaut) et effectue les tests suivants sur une liste de serveurs figurant dans un fichier servers.txt.

  • Ping
  • Etat du port http
  • Nombre de connexions IIS actives
  • Utilisation Cpu

Ce script doit être considéré comme une base de travail, charge à vous de l’enrichir et d’y ajouter les éléments manquants.

Quelques rappels de base :

Ping  :

La variable $ping renverra $True si l’ordinateur $host est joignable et $False le cas échéant.

Cpu : 

Cette ligne de code récupère la valeur du Compteur de performance “\Processor(_Total)\% Processor Time” qui renseigne sur le taux d’occupation cpu.

La commande de base exécutée sans froufrou sur mon ordinateur donne :

Connections Actives :

Il s’agit du nombre de connections actives sur le serveur web IIS. On récupère pour cela la valeur du Compteur de performance “\Web Service(_Total)\Current Connections”.

Note : le fichier servers.txt doit être présent dans le même répertoire que le script.

Voici le code source complet :

 

Forcepoint remporte le meilleur score de sécurité lors des tests NGFW de NSS Labs

 

Forcepoint annonce que son pare-feu de nouvelle génération (NGFW) a bloqué 99.95% d’attaques lors de tests NGFW 2017 effectués par NSS Labs. En premier lieu, Forcepoint est le seul éditeur à avoir bloqué 100% des attaques émanant de la bibliothèque NSS Labs ; et d’autre part, sur une période de 31 jours de tests en situations réelles, Forcepoint a bloqué 99.89%  des attaques applicatives.

Liens : www.globalsecuritymag.fr, blog.forcepoint.com