3 votes

Comment surveiller l'utilisation d'Exchange 2003 ?

Nous avons été chargés de surveiller l'utilisation d'Exchange 2003, mais il ne semble pas y avoir de composant de rapport intégré à Exchange 2003 Standard. Cela signifie-t-il qu'il faut utiliser des services de rapports tiers ou puis-je utiliser des puits d'événements ou des journaux pour envoyer les données d'utilisation au serveur SQL pour un traitement différé ?

Les domaines que j'aimerais le plus connaître sont les suivants :

  1. Nombre de messages envoyés/reçus par l'utilisateur et dans son ensemble.
  2. Combien de messages non lus dans la boîte de réception des utilisateurs.
  3. Temps de connexion (remarque : BackupExec se " connecte " aux boîtes aux lettres)

Je suis également ouvert aux suggestions de bons indicateurs pour mesurer l'adoption des fonctionnalités par les utilisateurs finaux, par exemple le nombre de contacts, d'éléments de calendrier, de demandes de réunion, de notes, etc. dans la boutique.


Solution

J'ai choisi d'utiliser PowerShell pour collecter les statistiques d'Exchange, car en passant à Exchange 2007 et à PowerShell 2.0, il y a plus d'options pour collecter les données, et je peux m'appuyer sur les bases existantes.

Le script s'exécute à 0400 tous les jours et repose sur un serveur SQL 2005/2008 et LogParser étant installé sur un serveur ayant accès aux journaux de suivi des messages Exchange.

Nombre de messages envoyés/reçus

J'ai construit la ligne de commande en utilisant LogParser.exe puis je l'ai transposée dans l'objet COM que j'utilise dans le script de powershell dans la fonction suivante :

function Execute-LogParserQueryToSQL([string] $Query)
{
    Write-Host $Query

    $LogParser = New-Object -com MSUtil.LogQuery

    $Input = New-Object -comObject MSUtil.LogQuery.W3CInputFormat

    $Output = New-Object -comObject MSUtil.LogQuery.SQLOutputFormat
    $Output.server = "<your server>"
    $Output.database = "<your database>"
    $Output.username = "<your username>"
    $Output.Password = "<your password>"

    $Result = $LogParser.ExecuteBatch($Query, $Input, $Output)

    return $Result
}

La fonction qui parcourt en boucle tous les journaux créés hier ou avant (peut en faire plusieurs au cas où elle ne fonctionnerait pas un jour pour une raison quelconque) supprime ensuite le fichier journal. Si vous utilisez le suivi des messages dans un autre but, ne supprimez pas le fichier journal, utilisez un autre mécanisme pour le "marquer comme utilisé".

function Execute-SentReceivedSummary()
{
    $TodaysLog = ("{0}.log" -f,(Get-Date -f yyyyMMdd))
    $MessageTrackingDir = "D:\Exchange\Logs\PORSCHE.log"
    $LogsToParse = Get-ChildItem -Path $MessageTrackingDir
    $SentEmailQuery = "SELECT Date,Sender-Address AS Account,Count(*) AS Count INTO DailySentEmailByUser FROM '{0}' WHERE Event-ID=1027 GROUP BY Sender-Address,Date"
    $ReceivedEmailQuery = "SELECT Date,Recipient-Address AS Account,Count(*) AS Count INTO DailyReceivedEmailByUser FROM '{0}' WHERE Event-ID=1028 GROUP BY Recipient-Address,Date"

    foreach ($Log in $LogsToParse)
    {
        if ($Log.ToString() -ne $TodaysLog)
        {
            $Query = ($SentEmailQuery -f,$Log.FullName)
            Execute-LogParserQueryToSQL $Query

            $Query = ($ReceivedEmailQuery -f,$Log.FullName)
            Execute-LogParserQueryToSQL $Query

            Remove-Item $Log.FullName
        }
    }

    return $true
}

Combien de messages non lus dans la boîte de réception de l'utilisateur ?

Finalement, nous avons décidé que la taille totale et le nombre d'éléments dans la boîte aux lettres constituaient une mesure plus utile. Certains membres du personnel avaient un nombre considérable de messages non lus mais consultaient leur courrier électronique tous les jours (généralement parce qu'il s'agissait d'e-mails de type FYI et que l'objet leur disait tout ce qu'ils avaient besoin de savoir).

Comme nous ne voulions que des données réelles (datant de 24 heures maximum), je devais tronquer le tableau avant d'insérer de nouvelles données :

function Truncate-TotalsTable()
{
    $SqlConnection = new-object system.data.oledb.oledbconnection
    $SqlConnection.connectionstring = "<your connect string>"
    $SqlConnection.open()
    $Query = "TRUNCATE TABLE TotalsTable"
    $SqlCommand = New-Object system.data.oledb.oledbcommand
    $SqlCommand.connection = $SqlConnection
    $SqlCommand.commandtext = $Query
    $SqlCommand.executenonquery()
    $SqlConnection.close()

    return $true;
}

Ensuite, nous utilisons WMI pour extraire les données du serveur Exchange et les pousser dans SQL :

function Execute-MailboxTotalsQuery()
{
    $Result = Truncate-TotalsTable

    $Count = 0;

    $SqlConnection = new-object system.data.oledb.oledbconnection
    $SqlConnection.connectionstring = "<your connect string>"
    $SqlConnection.open()

    $MailboxReport = Get-Wmiobject -class Exchange_Mailbox -Namespace ROOT\MicrosoftExchangev2 -ComputerName <your exchange server>

    foreach ($Mailbox in $MailboxReport)
    {
        $MailboxDN = $Mailbox.MailboxDisplayName
        $TotalItems = [int]$Mailbox.TotalItems
        $TotalSize = [int]$Mailbox.Size

        $MailboxDN = $MailboxDN -replace "'","''"

        $Query = [String]::Format("INSERT TotalsTable Values ('{0}',{1},{2})",$MailboxDN, $TotalItems, $TotalSize)

        $SqlCommand = New-Object system.data.oledb.oledbcommand
        $SqlCommand.connection = $SqlConnection
        $SqlCommand.commandtext = $Query
        $Result = $SqlCommand.executenonquery()
    $Count = $Count + $Result
    }

    $SqlConnection.close()

    return $Count;
}

Temps de connexion

Après avoir utilisé LogParser pour examiner le journal des événements de sécurité, les résultats que nous avons obtenus n'étaient pas très utiles. L'ID de l'événement que nous recherchions était 540, ce qui couvrait à la fois les connexions Outlook et OWA (et d'autres connexions), nous avons décidé que la quantité de travail nécessaire pour mettre en œuvre cette solution ne valait pas le retour. Ceci est en partie dû au fait qu'il faudrait analyser et filtrer par corps de message pour isoler les différents types de connexion au-delà de l'événement 540.

Je suis ouvert aux suggestions et aux soumissions d'autres scripts PowerShell utiles.

0 votes

Génial, Richard ! Merci de partager. J'ai été assez évasif en ce qui concerne PowerShell, mais ceux-ci semblent être des scripts vraiment utiles et une grande utilisation des facilités fournies par Microsoft. Je vais leur donner une chance !

0 votes

Heureusement pour moi, je suis un programmeur (dans l'âme) employé en tant que Sys. J'ai donc pris plaisir à mettre en place ces scripts, je me suis longtemps tenu à l'écart de PowerShell, c'est le premier projet pour lequel il a vraiment du sens.

2voto

John Gardeniers Points 27097

Je ne sais pas si vous pouvez faire tout ce que vous voulez mais il y a une variété de était pour créer des scripts pour extraire des données d'Exchange. Dans mon cas, je suis seulement intéressé par le nombre de messages et la taille totale de chaque boîte aux lettres. Un scripts Perl qui s'exécute chaque nuit recueille ces informations et les enregistre dans une base de données MySQL. Il utilise ensuite les données de la base pour générer une feuille de calcul Excel avec des graphiques pour chaque boîte aux lettres, plus le total. Tout cela a été fait à partir d'exemples que j'ai trouvés sur Internet. Il existe sans doute des offres commerciales pour faire des choses similaires, mais une heure ou deux de script est plus rentable (pour moi) et me donne une solution ouverte que je peux modifier ou compléter selon mes besoins.

0 votes

Merci John, Pourriez-vous me donner plus de détails sur la façon dont votre script Perl tire des informations de Exchange ? WebDAV ou y a-t-il un autre moyen ?

1 votes

J'ai aseptisé un script pour que vous l'ayez, et que vous puissiez le développer selon vos besoins. Le code n'est pas joli, étant bricolé comme il l'était. Le truc Excel a en fait commencé sa vie comme un script VBS. jardiniers.com/files/ChartMailboxes.zip

0 votes

Merci, c'est utile, je fais des progrès pour le faire fonctionner dans PowerShell 1.0. J'en posterai plus lorsque j'aurai terminé.

1voto

Evan Anderson Points 140581

Je ne connais pas de programme standard qui fasse ce dont vous parlez. Vous pourriez script divers mécanismes de collecte de données et faire un rapport sur ces données comme bon vous semble, mais vous parlez d'une solution assez "personnalisée".

  1. Vous pouvez l'obtenir à partir des journaux de "Message Tracking". Les fichiers journaux sont en texte ASCII, et les différents identifiants d'événements sont listés ici : http://support.microsoft.com/kb/821905 Je fonctionne généralement avec le "Message Tracking" activé dans toutes mes installations de production, de toute façon, juste parce que c'est trop pratique pour ne pas l'avoir activé. Il y a un léger impact sur les performances, mais je pense que cela en vaut la peine.

  2. Cela pourrait être scénarisé. Vous auriez besoin d'exécuter le script en tant qu'utilisateur qui a les droits d'ouvrir chaque boîte aux lettres utilisateur. (Vous pourriez supprimer les ennuyeux ACE "Deny - Receive As" placés à la racine de l'organisation, mais sachez que les packs de services et les mises à jour pourraient les restaurer. I toujours supprimer ces ACEs ennuyeux de toute façon - un "Administrateur" devrait être capable d'ouvrir n'importe quelle boîte aux lettres). Ce serait un peu un script amusant à écrire, mais je n'ai pas le temps aujourd'hui. Les utilisateurs pourraient créer des règles côté serveur qui détourneraient les messages non lus dans d'autres dossiers, de sorte que cela pourrait ne pas vous donner une métrique précise.

  3. Pour cela, vous devrez analyser le journal de sécurité de l'ordinateur ou des ordinateurs d'Exchange Server. Si vous voulez ignorer les "ouvertures de session" de Backup Exec, vous devrez le faire là aussi. (Pourquoi Backup Exec se "connecte-t-il", de toute façon ? Faites-vous une sauvegarde "au niveau de la brique" ? Ick... Je les évite à tout prix. Si j'ai besoin de restaurer un élément dans E2K8, je restaure simplement une sauvegarde de niveau page de la base de données dans un RSG). L'attribut "dernière connexion" que le magasin d'information maintient est à valeur unique, donc la seule autre façon de l'obtenir, à part l'analyse du journal de sécurité, serait de "sonder" cette valeur. Cela serait très inefficace.

Si vous n'y avez pas encore pensé, je suivrais la taille de la boîte aux lettres et le nombre d'éléments (pour calculer la taille moyenne par élément). J'ai surpris des "abus" de l'espace "précieux" d'Exchange IS de cette façon dans le passé. Maintenant que la norme E2K3 a une limite de 72 Go pour le stockage, ce n'est plus un si gros problème. Malgré cela, cela peut vous renseigner sur les habitudes d'utilisation de vos utilisateurs.

On dirait que ce serait un système amusant à mettre en place !

0 votes

Bon, j'ai réussi à extraire le total des messages envoyés et le total des messages reçus par utilisateur à partir des journaux de suivi des messages en utilisant Log Parser 2.2, je travaille sur l'envoi vers SQL 2005 puis je vais probablement l'exporter vers Excel chaque fois que quelqu'un demande les statistiques. Les journaux de BackupExec pour faire une sauvegarde de niveau brique oui afin que nous puissions utiliser la méthode de récupération granulaire. BackupExec 12 ne prend pas en charge la restauration vers RSG pour Exchange 2003 (allez savoir pourquoi !).

0 votes

Je vais devoir vérifier que Backup Exec 12 et l'absence de support RSG. J'utilise les RSG chaque fois que j'ai besoin de restaurer des éléments individuels (ce qui est assez rare, heureusement) et cette fonctionnalité me manquerait !

0 votes

J'étais assez mécontent que ce ne soit pas possible, mais du côté de Symantecs, la case à cocher indique (Requiert Exchange 2007 ou supérieur). Le serveur de médias va être mis hors service et remplacé par un nouveau serveur avec BackupExec 12.5 pour la prise en charge de SQL 2008.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X