> Tech > Tâches de fond

Tâches de fond

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Maintenant que vous connaissez les rudiments de la maintenance en arrière-plan et que vous savez à quel moment elle s’exécute, nous pouvons aborder certains détails du processus. Les clients tels que Outlook exploitent largement la capacité d’ESE à générer dynamiquement des index ou des affichages (vues). Par exemple, si vous

Tâches de fond

décidez d’afficher votre Boîte de réception par auteur et non par date, Outlook demande cet affichage à la banque.

Si la banque a généré précédemment cet affichage et l’a placé en cache, la réponse est particulièrement rapide, mais la banque peut traiter rapidement cette demande (via ESE), même si cette dernière porte sur un nouvel affichage. Au fil du temps, la banque accumule de nombreux affichages (chaque dossier dans chaque boîte aux lettres peut en avoir plusieurs) et cette situation n’est pas souhaitable car chaque affichage occupe de l’espace au sein de la base de données et certains sont utilisés une seule fois. Pour gérer les affichages, la banque affecte un délai d’expiration à chacun et gère une table interne appelée table de limite d’âge d’index. Lorsque la maintenance en arrière-plan s’exécute, la banque analyse la table de limite d’âge d’index à la recherche d’affichages dont l’ancienneté est supérieure à 40 jours (8 jours sur les systèmes Exchange Server 5.5) et supprime ceux dont le délai a expiré. Naturellement, chaque fois qu’un utilisateur accède à un affichage, le délai d’expiration est réinitialisé.

La tâche suivante est la maintenance des indicateurs de suppression. La banque gère une liste des messages supprimés (à savoir ceux supprimés par les utilisateurs dans leurs dossiers Eléments supprimés) et une liste des indicateurs de suppression pour ces messages. Cette liste des indicateurs de suppression est particulièrement importante pour les dossiers répliqués, notamment les dossiers publics, car elle fournit à la banque une liste des opérations de suppression de messages qu’elle doit répliquer vers chaque serveur détenant une réplique des dossiers. Une fois la réplication des entrées terminée avec succès, la banque peut supprimer lesdites entrées dans la liste des indicateurs de suppression au cours de la maintenance en arrière-plan.

Lorsqu’un utilisateur supprime un message, la banque définit un indicateur afin de masquer le message au niveau de la boîte aux lettres (autrement dit, la banque effectue une suppression logicielle). L’utilisateur peut récupérer le message à partir du cache des éléments supprimés, ce qui retire l’indicateur de suppression. Pendant la maintenance en arrière- plan, la banque examine chaque message ayant l’indicateur de suppression (l’intégralité du contenu du cache des éléments supprimés) afin de déterminer si la période de conservation du message a expiré. Si c’est le cas, le message est définitivement supprimé de la banque (autrement dit, elle effectue une suppression physique). Vous pouvez définir des périodes de conservation par boîte aux lettres, par banque ou par dossier public, et vous pouvez contrôler ce paramètre globalement via une stratégie de serveur spécifiée par le biais du Gestionnaire système Exchange. La figure Web 2 (www.itpro.fr Club abonnés) présente certaines limites définies sur une banque publique (vous pouvez voir que le délai de conservation des éléments supprimés est de 7 jours).

Ainsi, vous pouvez utiliser un dossier public afin de conserver du contenu, par exemple un échange de News d’un service NNTP (Network News Transfer Protocol) dont vous souhaitez limiter l’âge systématiquement. Ce faisant, vous imposez un contrôle sur les possibilités de croissance du dossier. Le processus est, pour l’essentiel, similaire dans le cas des messages supprimés dans les dossiers publics. La banque vérifie les messages qui ont expiré et les supprime. Le prochain contrôle porte sur les dossiers publics supprimés qui ont expiré. Par défaut, si vous supprimez un dossier public, la banque crée un indicateur de suppression pour le dossier, afin de donner au mécanisme de réplication du temps pour propager la suppression correctement aux serveurs contenant des répliques. Dans la mesure où, selon certaines circonstances, la réplication peut ne pas s’effectuer rapidement, la banque conserve les indicateurs de suppression par défaut pendant 180 jours. Si la réplication n’a pas propagé l’indicateur de suppression pendant ce laps de temps, votre organisation connaît des problèmes de réplication fondamentaux et quelques indicateurs de suppression erronés constituent le cadet de vos soucis. Pendant la maintenance en arrière-plan, la banque vérifie les indicateurs de suppression de dossier qui ont expiré et supprime un maximum de 500 indicateurs par période de 24 heures.

La banque vérifie aussi les boîtes aux lettres supprimées, lesquelles disposent d’un délai de conservation de 30 jours, et suppriment toutes celles arrivées à expiration. La suppression des dossiers et boîtes aux lettres obsolètes nettoie la structure de tables interne de la base de données et accroît les performances.

La réplication des dossiers publics est perçue comme une sorte de magie noire au sein de la communauté Exchange. Les conflits de dossiers publics peuvent se produire facilement. Par exemple, plusieurs utilisateurs peuvent modifier le même élément dans différentes répliques d’un dossier public ou plusieurs utilisateurs peuvent essayer de sauvegarder simultanément un élément dans la même réplique.

En cas de conflit, la banque envoie un message aux utilisateurs à l’origine du problème afin de leur demander de le résoudre. Entre temps, la banque conserve les différentes versions de l’élément. Si l’utilisateur ne fournit pas de réponse, la banque examine chaque version pendant la maintenance en arrière-plan et résout le problème, généralement en acceptant la version la plus récente. Vous pouvez contrôler par programmation le processus de résolution en manipulant la propriété MAPI PR_RESOLVE_METHOD. La majorité des administrateurs laisseront probablement Exchange utiliser ses propres moyens, mais vous pouvez employer un formulaire personnalisé pour aider à la résolution des conflits. Pour plus d’informations, consultez la page Web Microsoft « Resolving Message Conflicts with Forms » (http://msdn.microsoft. com/library/default.asp?url=/library/en-us/ exchserv/html/ forms_3goj.asp).

La tâche suivante consiste à mettre à jour les versions de serveur pour les banques publiques. Ce processus actualise les informations de version nécessaires à la gestion du dossier de configuration du système. Cela ne génère pas une grande charge de travail et vous ne pouvez pas contrôler le processus. La maintenance en arrière-plan vérifie également si des dossiers de site dupliqués existent dans les banques publiques d’un groupe administratif et supprime tous les doublons détectés.

Notez que la tâche Sécurisation des dossiers du tableau 1 s’applique uniquement aux dossiers publics hébergés sur des sites Exchange 5.5.

Après avoir mis en place une organisation Exchange Server 2003 ou Exchange 2000 Server native, cette tâche n’est plus nécessaire.

La banque utilise un modèle de stockage à instance unique, ce qui signifie qu’elle conserve une copie du contenu du message et utilise des pointeurs vers le contenu dans les boîtes aux lettres des utilisateurs. La banque assure le suivi du nombre de boîtes aux lettres qui ont des pointeurs vers le contenu via un compteur de référence et supprime physiquement le contenu de la base de données lorsque le compteur atteint la valeur zéro. La maintenance en arrièreplan vérifie les messages restants ayant un compteur de référence à la valeur zéro et supprime jusqu’à 50 000 éléments par jour. La banque ne signale pas le nombre d’éléments qu’elle a supprimés. Par conséquent, une croissance importante du nombre des journaux de transactions constitue la seule indication que ce type d’activité est en cours. Si vous constatez que la banque génère plus de journaux que le nombre habituel pendant la période de minuit à 6 h 00 du matin, vous devez envisager d’exécuter Isinteg sur la banque de boîtes aux lettres.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010