Powershell – SmtpDiag

Qui se rappelle encore de ce bon vieux SMTPDIAG.EXE qui si ma mémoire est bonne était livré avec le resource kit de Exchange 2003. Petit utilitaire bien pratique qui permettait de tester les serveurs MX d’un domaine.

Pour l’occasion, je me suis amusé à en faire une petite version Powershell. Je commence déja à trouver ça pratique 🙂

Note : je viens de mettre à jour le script. On a désormais la réponse du serveur et sa géolocalisation.

Vous pouvez télécharger le script sur GitHub.

 

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.

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 :

 

PowerShell – Créer des comptes de test

Ça faisait longtemps que je cherchais et je suis finalement tombé dessus par hasard. Durant nos phases de maquettage nous sommes souvent amené à créer des dizaines voir des centaines d’utilisateurs dans l’annuaire Active Directory. On se retrouve donc avec des utilisateurs user001, user002, … pas très glamour tout ça. Christophe a eu l’idée de créer ces utilisateurs en utilisant un fichier contenant de vrais noms (ceux de 1000 actrices et acteurs) pour donner un peu plus de réalisme à nos plate-formes de test. C’est tout de suite plus fun quand on voit un Al Pacino ou une Monica BELLUCCI dans sa liste d’utilisateurs 🙂

Je vous invite à lui rendre visite sur son excellent blog, vous y trouverez des tas d’autres astuces sympa.

Source : http://my-powershell.fr/active-directory/creer-1000-comptes-de-test.html

PowerShell – Barre de progression

Il y a quelques années, lors d’une migration Exchange, j’ai du réimporté une base de 40 000 contacts dans l’annuaire depuis un fichier CSV. Je peux vous dire que ça prend un certain temps et qu’il peut être particulièrement frustrant de ne pas savoir ou on en est. C’est dans ce genre de situation que l’affichage d’une barre de progression présente tout son intérêt.

La mise en oeuvre en est assez simple comme le prouve le petit exemple qui suit :

La progression de la barre est controlée par le paramètre PercentComplete  qui varie évidemment de 1 à 100. Le paramètre Activity permet de donner un titre à la progression et Status permet de définir un message qui peu varier au fur et à mesure de la progression. Nous avons du mettre un petit temps d’attente de 100ms (Sleep -m 100) pour simuler l’exécution d’un traitement.

 

PowerShell – Generate Mailbox Reports

Ce script de Paul Cunningham (retenez bien ce nom) permet de générer un rapport très détaillé (au format CSV) de la liste des boites aux lettres, avec pour chacune d’elle, la taille (MB), le nombre d’éléments,  le nombre d’éléments supprimés, le quota, … etc, le tout bien entendu proprement formaté et prêt à l’usage. Indispensable à tout administrateur Exchange.

Source : https://practical365.com/