Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Exchange 2010 / SCOM : Erreur après la désactivation de l’agent de scripting

Introduction

Dans un précédent article, nous avons découvert l’agent de scripting dans Exchange (http://blog.piservices.fr/post/Exchange-Decouverte-de-lagent-de-scripting.aspx). Pour rappel, cela permet  les fonctionnalités de base des cmdlets Exchange. Ainsi, on peut par exemple ajouter automatiquement une boîte d’archive au moment de la création de sa boîte aux lettres. Pour que cette opération fonctionne, il faut activer l’agent de scripting via la cmdlet “Enable-CmdletExtensionAgent”.

Cependant, si vous êtes amenés à désactiver cet agent ultérieurement, vous pouvez rencontrer de nombreuses erreurs avec l’event ID “6” dans le journal “MSExchange Management”.

Event

Ces erreurs peuvent être normales, lorsqu’un administrateur Exchange s’est trompé dans la syntaxe d’une cmdlet Powershell.

Contexte

Dans certaines situations ces erreurs sont à l’origine du mauvais  fonctionnement d’un composant tiers. En l’occurrence, comme nous allons le voir ici, il s’agit de System Center Operations Manager (SCOM). En effet, le Management Pack SCOM d’Exchange lance de nombreuses cmdlets afin d’effectuer des tests de vérification d’intégrité de l’infrastructure Exchange. A cause, de cette erreur, la supervision de l’infrastructure Exchange peut ne plus être opérationnelle.

Explication

Si on affiche l’erreur au format XML dans l’observateur d’événements, on obtient plus de détails :

 

Il est indiqué qu’Exchange ne trouve pas le fichier de configuration de l’agent de scripting : “File is not found: ‘D:\Program Files\Microsoft\Exchange Server\V14\Bin\CmdletExtensionAgents\ScriptingAgentConfig.xml’”.

Cependant, si l’agent de scripting a été désactivé, il n’y a aucune raison qu’il soit utilisé. Pour rappel, le fichier de configuration ne doit être présent que si l’agent de scripting est démarré. Il est à noter que même si ce fichier est présent, l’erreur continue d’apparaître. Le message indiqué dans l’erreur n’est donc pas pertinent. En réalité, il s’avère que le service “Exchange Monitoring” ne prend pas en compte le changement de configuration. Il est utilisé par le management pack SCOM et permet d’executer toutes les cmdlets de diagnostics comme “Test-PopConnectivity”, “Test-MRSHealth”, “Test-ReplicationHealth”, …

Résolution

Pour résoudre cette erreur, il suffit de redémarrer le service « Exchange Monitoring« . Ainsi, la configuration des cmdlets extensions agents sera correctement prise en compte. 

Exchange Monitoring Service

Pour information, ce service peut être redémarré sans incidence.

NB : Il faut redémarrer ce service sur tous les serveurs de l’organisation Exchange car l’opération d’activation/désactivation de l’agent de scripting se fait sur la totalité de ceux-ci.

SCOM 2012 – Réinitialiser automatiquement le moniteur lorsque l’alerte correspondante est fermée manuellement

 

Une problématique très commune dans la gestion quotidienne d’une infrastructure SCOM est la cloture par un opérateur humain d’alertes générées par un moniteur : dans ce cas, le moniteur reste dans son état warning ou critical mais l’alerte n’est plus présente et n’est jamais re-générée, empêchant donc les opérateurs de s’apercevoir du problème.

La bonne pratique est bien entendu de résoudre le problème à l’origine de l’alerte, ce qui permettra au moniteur de revenir à son état Healthy et donc à l’alerte de se cloturer automatiquement.

Afin de se prémunir contre ce genre de problème, il est possible de déclencher une action automatique qui vérifiera si une alerte cloturée l’a été par un compte autre que “System” a été générée par un moniteur : le cas échéant, un script réinitialisera le moniteur à l’origine de l’alerte, de facon à ce qu’il puisse repasser en critical ou warning et que l’alerte soit régénérée au passage.

Ce genre de solution est réalisable à l’aide d’Orchestrator ( http://stefanroth.net/2012/05/05/reset-monitor-using-scom-2012-and-orchestrator-a-must-have-runbook/ ) ou d’outils tiers comme Green Machine ( http://blogs.technet.com/b/timhe/archive/2014/07/25/greenmachine-2012.aspx )  mais j’ai ici préféré une approche réalisable sans produit autre que SCOM.

 

Commençons par créer le script qui réalisera les tâches décrites ci-dessus. Il devra être présent dans le même répertoire sur tous les serveurs membres du management pool Notification.
Je me suis très largement inspiré du script de de Stefan Roth pour cette étape, en l’adaptant aux contraintes du mode de fonctionnement retenu. Pensez à modifier scom01 par le nom de votre serveur SCOM :

#checkresetmonitoralert.ps1

Param($alertid)

# Import Operations Manager Module and create Connection
Import-Module OperationsManager;
New-SCOMManagementGroupConnection scom01;

$alerts = Get-SCOMAlert -Id $alertid | where { ($_.ismonitoralert -eq $true) -and ($_.resolvedby -ne "System") }

foreach ($alert in $alerts)

{

# Get IDs
$mrid = $alert.monitoringruleid
$mcid = $alert.monitoringclassid
$moid = $alert.monitoringobjectid

# Get Objects
$monitor = Get-SCOMMonitor -id $mrid
$monitoringclass = Get-SCOMClass -id $mcid
$monitoringobject = Get-SCOMMonitoringobject -class $monitoringclass | where {$_.id -eq $moid}

# Reset Monitor
$monitoringobject | foreach{$_.ResetMonitoringState($monitor)}

}

Nous allons ensuite créer un ensemble de règles de Notification (Channel,Subscriber,Subscription) qui nous permettront d’appeler ce script à chaque fois qu’une alerte est clôturée.
D’abord le Channel, qui sera de type Command :

clip_image002_thumb[2]

Indiquez un nom explicite et une description :

clip_image004_thumb[1]

Dans le champ Full path of the command file, indiquer le chemin vers l’executable de powershell. Il s’agit par défaut de C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Dans le champ Command line parameters, indiquer les paramètres suivants (pensez à remplacer le chemin du script par le chemin où se trouvera le script dans votre cas) :
-Command "& ‘"D:\chemin\vers\script\checkresetmonitor.ps1"’" -alertid ‘$Data/Context/DataItem/AlertId$’ -computerPrincipalName ‘$Data/Context/DataItem/ManagedEntityDisplayName$’

Dans le champ Startup folder indiquer le chemin du dossier où se trouve le script.

clip_image006_thumb[1]

Cliquez sur Finish puis sur Close

clip_image008_thumb[1]

 

Créons ensuite le Subscriber :

Indiquez un nom (le même que pour le Channel, par exemple) :

clip_image010_thumb[1]

Laissez coché Always send notifications

clip_image012_thumb[1]

Cliquez sur Add

clip_image014_thumb[1]

Indiquez un nom (toujours le même…)

clip_image016_thumb[1]

Dans la liste Channel Type, indiquez Command. Dans la liste Command Channel, sélectionnez le channel créé précédemment.

clip_image018_thumb[1]

Laissez coché Always send notification

clip_image020_thumb[1]

Cliquez sur Finish

clip_image022_thumb[1]

 

Il reste à créer la Subscription.

Indiquez un nom (oui, encore le même).
Cochez with specific resolution state et indiquez l’état Closed (255)

clip_image024_thumb[1]

clip_image040_thumb[2]

Cliquez sur Add

clip_image026_thumb[1]

Ajoutez le Subscriber précédemment créé et cliquez sur OK

image_thumb[2]

Cliquez sur Next

clip_image030_thumb[1]

Cliquez sur Add

clip_image032_thumb[1]

Ajoutez le Channel précédemment créé et cliquez sur OK

image_thumb[4]

Cliquez sur OK

clip_image036_thumb[2]

Cliquez sur Finish

clip_image038_thumb[1]

 

Désormais, toutes les alertes qui seront cloturées seront analysées par le script powershell, qui réinitialisera le moniteur correspondant au besoin.

Quelques commandes Powershell utiles pour Exchange

Contexte

Avec les cmdlets de base d’Exchange il est relativement simple d’obtenir certaines informations. Mais il est possible d’aller beaucoup plus loin dans le traitement de ces informations en combinant plusieurs cmdlet Exchange.

Les différentes commandes ci-dessous sont des cas concrets que j’ai eu à gérer au quotidien dans l’exploitation d’Exchange 2010.

Cmdlets

Rechercher un mail sur tous vos serveurs HUB à la fois :

Get-TransportServer SRV-EXCH-HUB-0* | Get-MessageTrackingLog -ResultSize Unlimited -Start "06/02/2014 19:00:00" -End "06/03/2014 01:00:00" –Sender “mon-adresse-mail@mon-domaine.fr”

Voir tous les droits sur une BAL :

Get-MailboxPermission login-bal | Where {$_.user -notlike "S-1-5*"} | Sort user | FT user,AccessRights,IsInherited –a

Voir les droits Send-As d’une BAL :

Get-Mailbox login-bal | Get-ADPermission | Where {($_.ExtendedRights -like “*Send-As*”) -and -not ($_.User -like “NT AUTHORITY\SELF”) -and ($_.User -notlike "S-1-5*")} | FT user,identity,IsInherited –a

Voir les statistiques des appareils ActiveSync d’un utilisateur :

Get-ActiveSyncDevice –mailbox login-bal | Get-ActiveSyncDeviceStatistics | Fl DeviceModel,DeviceType,FirstSyncTime,LastSyncAttemptTime,LastSuccessSync

Voir les BAL déconnectées d’un serveur :

Get-MailboxDatabase EXC-MDB-001 | Get-MailboxStatistics  | Where { $_.DisconnectDate -ne $null } | Select DisplayName,MailboxGuid,Database,DisconnectDate,DisconnectReason

Obtenir le top 5 de toutes les files d’attentes de vos HUB :

Get-TransportServer SRV-EXCH-HUB-0* | Get-Queue | Sort MessageCount -desc  | Select QueueIdentity,NextHopDomain,MessageCount,LastError -First 5

Voir les rôles Exchange d’un utilisateur :

Get-ManagementRoleAssignment -GetEffectiveUsers | ?{$_.EffectiveUserName -eq "Amaury AUSSIERE"} | Select Role

Voir d’un coup d’œil l’état de migration d’une liste d’utilisateurs d’un fichier CSV :

Import-Csv D:\MBXtoQuarantaine.csv -Delimiter ";" | %{Get-MoveRequestStatistics $_.samaccountname} | Group status | Select name,count

Obtenir la taille de plusieurs BAL (exemple : BAL de journalisation) avec un avertissement si dépassement d’un seuil :

Get-Mailbox BAL-Journalisation_* | Sort name | Get-MailboxStatistics | Select-Object DisplayName,@{Name="TotalSize(MB)"; Expression={$_.TotalItemSize.Value.tomb()}},@{Name="Warning?"; Expression={if($_.TotalItemSize.Value.tomb() -gt 500){"Warning!"}}}| ft –a

Vérifier les différentes URL d’un serveur CAS :

$monserveur = “SRV-EXCH-CAS-001”
Get-ClientAccessServer $monserveur | Get-ActiveSyncVirtualDirectory | fl server,*lur*
Get-ClientAccessServer $monserveur | Get-ClientAccessServer | fl server,*lur*
Get-ClientAccessServer $monserveur | Get-EcpVirtualDirectory | fl server,*lur*
Get-ClientAccessServer $monserveur | Get-OabVirtualDirectory | fl server,*lur*
Get-ClientAccessServer $monserveur | Get-OwaVirtualDirectory | fl server,*lur*
Get-ClientAccessServer $monserveur | Get-WebServicesVirtualDirectory | fl server,*lur*
Get-ClientAccessServer $monserveur | Get-AutodiscoverVirtualDirectory | fl server,*lur*

Vérifier les interfaces réseaux utilisées pour les réplications au travers d’un DAG :

Get-MailboxDatabase EXC-MDB-001 | Sort name | Get-MailboxDatabaseCopyStatus -ConnectionStatus | Select Name,MailboxServer,DatabaseName,OutgoingConnections,IncomingLogCopyingNetwork | Sort MailboxServer,DatabaseName

Conclusion

Au travers de ces quelques commandes Powershell, vous obtiendrez des informations pertinentes et rapidement sur l’état des serveurs Exchange.

Libre à vous de les adapter suivant vos besoins et votre environnement, le but étant de vous donner des idées pour votre administration au quotidien ou pour vos scripts.