> Mobilité > Les changements subtils d’Exchange 2003 SP2

Les changements subtils d’Exchange 2003 SP2

Mobilité - Par Tony Redmond - Publié le 24 juin 2010
email

Au vu de la complexité de Microsoft Exchange Server 2003, il n’est pas surprenant que nombre de changements et corrections de bogues apportés par Microsoft à Exchange passent inaperçus. Cette situation est vraie tant que vous n’êtes pas affecté par un bogue et que vous découvrez qu’il a déjà été résolu par Microsoft. C’est certainement le cas avec Exchange 2003 Service Pack 2 (SP2). Voici l’un des bogues qui peuvent vous avoir échappé.

La structure interne de la base de données Jet qui est au coeur de la banque d’informations (IS) repose sur des pages de 4 Ko. Microsoft prévoit d’augmenter la taille des pages dans Exchange 12 et d’apporter des améliorations supplémentaires afin d’aider son produit serveur à gérer plus efficacement les messages de grande taille. En attendant toutefois, le transit de messages volumineux impose à votre serveur de messagerie de prendre une grande inspiration avant de traiter les données. Dans ce contexte, je définis un message volumineux comme ayant une taille supérieure à 5 Mo ou comme ayant une taille trop importante pour être conservé dans un seul journal des transactions. Il n’est pas rare que les utilisateurs essaient d’envoyer des messages de grande taille, par exemple en joignant le contenu d’un CD complet afin que des amis puissent installer un logiciel spécifique. Le message le plus volumineux que j’ai pu rencontrer avait une taille de 2 Go, mais je ne pense pas qu’il s’agisse du record absolu.

Quoi qu’il en soit, l’envoi d’un message volumineux n’est pas recommandé. Hormis la charge qui en résulte pour la banque d’informations, ce type d’opération peut avoir des effets secondaires. Par exemple, un message peut excéder la valeur maximale d’envoi de messages, telle qu’elle est définie pour l’organisation dans les paramètres globaux des propriétés de remise des messages, comme l’illustre la figure 1. Un message volumineux adressé à des destinataires externes peut excéder la taille de message maximale définie pour le connecteur SMTP. Qui plus est, l’envoi de ce type de message peut dépasser les limites de quota de la boîte aux lettres de l’expéditeur et des boîtes aux lettres des infortunés destinataires.

Les dommages sont encore aggravés lorsqu’Exchange génère un rapport de non-remise (NDR). La banque d’informations transfert le message au service Transport et découvre qu’il excède la limite uniquement après que le service a appliqué le contrôle de limite et a rejeté le message en question. La banque d’informations doit alors envoyer un rapport de non-remise contenant le message à l’expéditeur. Ainsi, un message de 50 Mo refusé pour dépassement de la taille de message globale est traité deux fois par la banque d’informations. Cette situation désastreuse pour les performances pourrait être évitée si un contrôle était effectué plus tôt dans le cycle de transmission.

Le manque de communication entre le serveur Exchange et le client est à l’origine du problème. Les clients ne sont pas suffisamment intelligents pour interroger Exchange sur les limites de taille avant d’envoyer un message et Exchange n’a pas l’intelligence suffisante pour signaler les limites aux clients et refuser les messages qui les dépassent. Exchange 2003 SP1 et le déploiement de mise à jour Exchange 2000 Server post-SP3 résolvent partiellement le problème en faisant en sorte que la banque d’informations contrôle la taille de message et le quota de boîte aux lettres avant d’accepter un nouveau message d’un client MAPI (Messaging API).

Exchange 2003 SP1 contrôle les limites de taille lorsqu’un client essaie d’envoyer un message au serveur. Si Microsoft Office Outlook 2003 ou d’autres clients MAPI s’exécutent en mode connecté, la banque d’informations rejette le message immédiatement. Si Outlook 2003 est en mode Exchange mis en cache (Cached Exchange Mode), la banque d’informations rejette le message avec un rapport de non-remise qu’Outlook reçoit lors de la prochaine récupération des nouveaux messages.

Bien que ce correctif constitue un réel progrès, la banque d’informations doit encore générer un rapport de non-remise pour retourner les messages problématiques aux clients Outlook qui s’exécutent en mode Exchange mis en cache. Néanmoins, une procédure dans Exchange 2003 SP2 permet aux clients d’interroger le serveur concernant les limites de taille de message avant d’essayer d’en envoyer un. Vous pouvez obtenir le même correctif dans la mise à jour post-SP1 la plus récente pour Exchange 2003 ou la mise à jour post-SP3 pour Exchange 2000, les deux étant disponibles auprès du Support technique Microsoft.

Comme Exchange fonctionne en mode client-serveur et que les clients existants ne savent pas interroger le serveur à propos des limites de taille de message, vous devez déployer des clients mis à jour pour aboutir à la solution complète. Aujourd’hui, le seul client capable d’effectuer cette interrogation est Outlook 2003 SP2. Il est peu probable que Microsoft proposera d’intégrer cette fonctionnalité a posteriori sur les autres clients.

Avec des clients et un serveur à jour, Outlook vérifie si un message excède la limite de taille et si sa transmission entraînera un dépassement du quota de boîte aux lettres. Si le quota est dépassé, Outlook indique à l’utilisateur de nettoyer la boîte aux lettres avant toute nouvelle tentative d’envoi du message. L’avantage de ce correctif est qu’il améliore les performances en évitant entièrement les transferts inutiles de messages volumineux à destination et à partir du serveur.

Téléchargez gratuitement cette ressource

Les atouts du XDR face aux attaques modernes

Les atouts du XDR face aux attaques modernes

Agréger et corréler des données issues de plusieurs couches de sécurité permet de détecter et répondre plus rapidement aux menaces, gérer davantage d’alertes et renforcer la sécurité IT. La vague XDR s’accélère, comment en tirer profit ?

Mobilité - Par Tony Redmond - Publié le 24 juin 2010