Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Identifier la version du client qui se connecte a une boite mail Exchange 2003

 

Bien que ce sujet puisse sembler dépassé, il peut en réalité encore servir aujourd’hui précisément dans le cadre d’une migration Exchange 2003 vers Exchange 2010 (par exemple pour ne migrer que les utilisateurs disposant d’une version d’Outlook supérieure ou égale à la 2007).

Il n’est pas possible de retrouver cette information directement à l’aide d’un cmdlet Powershell pré-existant, mais une requête WMI (classe Exchange_Logon du namespace root\MicrosoftExchangev2) exécutée via Powershell le permet :

Get-wmiobject -class Exchange_Logon -Namespace ROOT\MicrosoftExchangev2 -ComputerName ServerA -filter "LoggedOnUserAccount != ‘NT AUTHORITY\\SYSTEM’" | select-object MailboxDisplayName,ClientVersion

La commande précédente permet donc de lister la version du client utilisée par chaque utilisateur pour se connecter.
On remarque qu’elle est nécessairement ciblée sur un serveur Exchange 2003 spécifique (-ComputerName ServerA).

Cependant, dans le cas où Exchange est configuré en cluster, il faut obligatoirement interroger le noeud actif pour obtenir cette information.
Il peut donc s’avérer utile de retrouver quel est le nœud actif d’un cluster à l’aide d’un script, encore une fois via WMI et Powershell (classe mscluster_nodetoactivegroup du namespace root\mscluster) puisque là non plus, Powershell ne permet pas nativement de retrouver cette information :

Get-WmiObject –ComputerName NomVirtuelduCluster –Namespace\root\mscluster –class mscluster_nodetoactivegroup  | select groupcomponent,partcomponent

image

Afin de ne conserver de ce résultat que la partie qui nous intéresse, à savoir le nom du noeud actif à proprement parler, on utilise la commande suivante :

$activenode = (( Get-WmiObject -ComputerName $myLegacyExchangeCluster -Namespace root\mscluster -Class mscluster_nodetoactivegroup -ErrorAction SilentlyContinue | Where-Object { $_.PartComponent -like "*Exchange Group*" } ).GroupComponent ).Split(‘"’)[1]

Il ne reste alors plus qu’à réintégrer cette valeur à la première commande via le paramètre  –ComputerName $activenode afin d’obtenir un fonctionnement automatisé.

SCOM 2007 R2 : Les découvertes ne fonctionnent pas et une erreur “Workflow Initialization Failed to start a workflow that runs a process or script” revient en boucle

Lors du déploiement d’un management pack dont les découvertes sont basées sur des scripts locaux (par exemple Exchange 2010) dans SCOM 2007 R2 dans un environnement où les serveurs sont protégés par McAfee VirusScan Enterprise, les services concernés ne sont pas découverts et leur état n’apparait donc pas dans l’écran Supervision de SCOM.

En parallèle, des processus cscript.exe tournent sans fin sur les serveurs concernés et des alertes « Workflow Initialization Failed to start a workflow that runs a process or script » remontent dans SCOM :

clip_image002_thumb2

Des erreurs cscript.exe sont également enregistrées dans l’Application Event Log de Windows sur les serveurs où se trouvent les services et applications qui devraient être découverts :

Event ID 1000
Faulting application name: cscript.exe. version: 5.8.7600.16385. time stamp:
0x4a5bc670 Faulting module name: ScriptSn.20110218083735.dll_unloaded.
version: 0.0.0.0. time stamp: 0x4d2ce466
Exception code: 0xc0000005 Fault offset: 0x6ff7466a Faulting process id:
0xbdc Faulting application start time: 0xcscript.exe0 Faulting application
path: cscript.exe1 Faulting module path: cscript.exe2 Report Id: cscript.exe3

Ce problème est lié au module ScriptScan de McAfee VSE en version 8.8 qui se comporte de façon assez inattendue : lorsqu’il est désactivé, il empêche malgré tout l’exécution des scripts (dont ceux nécessaires à la détection des composants que SCOM cherche à monitorer) et ce même si les exclusions adéquates sont positionnées.

Trois solutions sont alors disponibles :

  • Activer le module ScriptScan
  • Complètement désinstaller la fonctionnalité ScriptScan en désenregsitrant la dll SCRIPTSN.dll sur chaque serveur :
    cd "C:\Program Files\Common Files\McAfee\SystemCore"
    regsvr32.exe /u SCRIPTSN.dll
  • Déployer la version 8.8 patch 1 mise à disposition par McAfee.

C’est bien entendu cette dernière solution qu’il faudra privilégier. Pour plus de détails sur ce blocage, McAfee a également publié une KB à ce sujet : https://kc.mcafee.com/corporate/index?page=content&id=KB71660

EXCHANGE 2010 – Session Telnet

Avec certains système de messagerie nous pouvons envoyer un

message en utilisant une session “telnet” avec la syntaxe suivante:

220 monserveur.fr Microsoft ESMTP MAIL Service ready at Wed, 9 May
helo
250 monserveur.fr Hello [10.10.10.10]
mail from: john@track.ru
250 2.1.0 Sender OK
rcpt to: p.fedan@mondomaine.fr
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
subject: Test email using telnet
Ceci est un test.
.
250 2.6.0 7b45f718-0d0c-42fd-b2f4-dd3607bb334b@monserveur.fr

On remarque qu’avec Exchange 2010 le destinataire et le corps du

message sont vides !

image

La syntaxe utilisée doit être la suivante:

220 monserveur.fr Microsoft ESMTP MAIL Service ready at Wed, 9 May
helo
250 monserveur.fr Hello [10.10.10.10]
mail from: john@track.ru
250 2.1.0 Sender OK
rcpt to: p.fedan@mondomaine.fr
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
to: p.fedan@mondomaine.fr         ######## Ajouter le champ “to”
Subject: test 2 email using telnet   ####### Insérer un saut de ligne

Ceci est un test.

.
250 2.6.0 <6a990d2b-9118-4e5c-8c4d-a7b70b382813@monserveur.fr

L’expéditeur et le corps du message seront présent:

image