Le blog technique

J’ai récemment été confronté à une situation complexe sur une architecture Symantec Messaging Gateway composée de trois nœuds :

• Deux boitiers scanners
• Un boitier control center

Le boitier control center était hors service (interface Web inaccessible); or, au même moment l’un de deux boitiers scanner était victime d’un problème de remise de messages (files d’attente Inbound et Outbound avec plusieurs milliers de messages en attente de traitement).

Dans ce cas de figure la seule méthode disponible pour administrer le boitier scanner (en l’absence de l’interface Web habituellement disponible sur le control center) consiste à prendre en la main en mode console (soit physiquement sur le serveur, soit à distance avec un client SSH comme putty).

Dans ce cas de figure, les trois commandes les plus importantes pour gérer les files d’attente sont les suivantes :

• mta-control qui permet de gérer les files d’attente et de reconfigurer la pile MTA
• monitor qui permet d’afficher le statut des files d’attente ainsi que le nombre de mail dans chaque file
• service qui est une commande Linux standard permettant de redémarrer les services (dont le service MTA)

Voici quelques exemples de commandes :

mta-control pause-mode status (permet d’afficher le statut de la pile MTA)

mta-control pause-mode pause-accept (reconfigure la pile MTA pour ne plus accepter les nouveaux messages; les messages toujours en file sont scannés, puis envoyés)

mta-control pause-mode resume-accept (permet de revenir en arrière)

monitor mta (permet d’afficher l’état des différentes files; i_qmsgs correspond au nombre de message dans la file Inbound, o_qmsgs correspond au nombre de message dans la file Outbound et enfin d_qmsgs correspond au nombre de messages dans la file Delivery)

mta-control delivery flush (permet de forcer la réémission des messages bloqués dans la file d’attente Delivery)

service mta restart (permet de redémarrer le service MTA)

La problématique

J’ai récemment rencontré la problématique suivante sur un serveur TMG 2010 SP2 : suite à des problèmes matériels (plantages répétés du serveur) le service pare-feu refuse de démarrer.

La base de données AD LDS étant toujours accessible, il est toujours possible de se connecter à la console TMG et donc je réalise un export de la configuration de la ferme de serveurs.

Le dépannage du problème de démarrage sur le service TMG semblant complexe à résoudre décision est prise de désinstaller TMG, puis de le réinstaller et enfin d’importer la configuration précédemment sauvegardée au format XML.

Lors de l’import de la configuration sur le serveur fraichement réinstallé, l’erreur suivante s’est produite dans l’assistant d’importation de TMG :

Import Failed

The value specified for the parameter Scope is not valid for standalone mode.

Résolution apportée

La solution apportée n’est pas une solution très académique est plutôt à classer dans la catégorie des contournements :

Pour résoudre l’ensemble des balises Scope ont été supprimées manuellement dans le fichier de configuration à l’aide d’un éditeur de fichier XML (ici Notepad++).

La balise complète a été supprimée à chaque fois.

Suite à cette modification l’importation s’est terminée correctement et l’ensemble des services et des règles ont pu repartir en production.

Ce problème étant très spécifique je suppose que l’erreur rencontrée était due à la présence d’un reliquat de configuration ISA Server 2006 dans le fichier XML précédemment exporté.