Les boîtes aux lettres sur une base de données sont mises en quarantaine dans un environnement avec System Center Operations Manager

Article d’origine publié le jeudi 28 juin 2012

Mise à jour le 03/07/12 : ajout d’informations à la section Solution de contournement.

Nous allons discuter ici d’un problème observé récemment dans CSS, selon lequel de nombreuses boîtes aux lettres de la même base de données sont mises en quarantaine sans raison apparente. Si vous inspectez le journal des applications, vous constaterez la présence de nombreux événements 10018 dont le texte fournit les informations suivantes.

Nom du journal : Application
Source : MSExchangeIS
ID d’événement : 10018
Catégorie de tâche : Général
Niveau : Erreur
Description :
La boîte aux lettres de l’utilisateur <guid>: /o=Contoso /ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserMailbox a été mise en quarantaine. L’accès à cette boîte aux lettres sera restreint aux connexions administratives durant les 6 prochaines heures.

De plus, l’ID d’événement 5410 suivant apparaît dans le journal des événements Microsoft-Exchange-Troubleshooters/Operational pour chaque boîte aux lettres mise en quarantaine par l’outil de dépannage d’espace de base de données :

Nom du journal : Microsoft-Exchange-Troubleshooters/Operational
Source : espace de base de données
ID d’événement : 5410
Niveau : avertissement
Mots clés : classique
Description :
L’outil de dépannage d’espace de base de données a mis en quarantaine la boîte aux lettres <guid> dans la base de données <nom_BD>.

L’essentiel est dans la dernière phrase : « L’outil de dépannage d’espace de base de données ». Dans les environnements où System Center Operations Manager a été déployé, un Analyseur est en place par défaut pour vérifier l’espace disque libre pour les volumes de bases de données et de journaux. Cet analyseur utilise le script PowerShell Troubleshoot-DatabaseSpace.ps1, qui est fourni avec Exchange 2010 par défaut. Pour en savoir plus sur le script Troubleshoot-DatabaseSpace.ps1, voir l’article TechNet suivant :

Gérer la croissance des journaux des bases de données à l’aide du script Troubleshoot-DatabaseSpace.ps1 dans l’environnement de ligne de commande Exchange Management Shell
https://technet.microsoft.com/en-us/library/ff477617.aspx

L’équipe System Center a récemment publié le Service Pack 2 pour le pack d’administration Exchange. Entre autres choses, ce Service Pack ajuste une valeur de délai d’expiration pour l’exécution du script. Avant lui, ce délai d’expiration était de 300 secondes et le analyseur était configuré pour un déclenchement toutes les cinq minutes. Cela signifie que dans de nombreuses grandes organisations, le délai d’expiration du script était presque certain d’être atteint, d’où une exécution incomplète du script. Après l’installation de la mise à niveau, le nouveau délai d’expiration est de 1200 secondes. Par ailleurs, l’analyseur s’exécute une fois par heure plutôt que toutes les cinq minutes. En conséquence, l’outil de dépannage exécute maintenant en toute fiabilité du code qu’il n’exécutait pas avant la mise à jour vers le SP2. Ceci lui a permis de trouver un bogue dans le compteur perfmon de la banque d’informations utilisé par l’outil de dépannage pour déterminer le taux de génération d’octets de journal pour la base de données (le taux perfmon peut dépasser 1,0E+19 octets/heure). Lorsque le taux horaire estimé de génération de journal dépasse la capacité d’espace disque libre restant sur le volume de base de données ou de journal, l’outil de dépannage commence à mettre les boîtes aux lettres en quarantaine afin d’empêcher que la génération de journal ne consomme tout l’espace libre et ne provoque le démontage de la base de données. L’outil de dépannage semble rencontrer cette condition lorsque le compteur perfmon a une valeur erronée (ce compteur est mis à jour toutes les minutes et ne doit pas avoir de valeur erronée pendant plus d’une minute). Le problème n’est donc pas fréquent, mais peut se présenter selon des probabilités moyennes.

Que cela signifie-t-il pour vous ?

Comme mentionné dans l’article TechNet, la principale fonction du script est d’effectuer le suivi du taux de génération de journal et de vérifier l’espace disque libre pour les volumes de bases de données et de journaux. Quand le script s’exécute, il utilise un compteur perfmon de banque d’informations pour déterminer le taux de génération de journal et calcule si, avec le taux actuel, le disque aura un espace insuffisant dans les délais spécifiés (la valeur par défaut est 12 heures) et, dans l’affirmative, il commence éventuellement à mettre les boîtes aux lettres en quarantaine (jusqu’à 150 à la fois). Il peut aussi éventuellement mettre les boîtes aux lettres en quarantaine quand le pourcentage d’espace disque libre tombe en dessous d’une valeur spécifiée. Le pourcentage d’espace disque libre par défaut utilisé est de 25 %. Pour mettre les boîtes aux lettres en quarantaine lorsque l’une de ces conditions est remplie, le paramètre –Quarantine doit être passé au script.

L’analyseur utilisé par SCOM 2007 et versions ultérieures utilise le paramètre Quarantine par défaut et il n’existe aucune option prise en charge pour changer cela car le pack d’administration est scellé. Cela signifie que si l’espace disque libre pour le volume de base de données ou de journal tombe en dessous de 25 % ET que le calcul du taux de génération de journal indique qu’il consommera l’espace disque restant dans les 12 prochaines heures, les utilisateurs les plus intensifs seront mis en quarantaine. Quand une base de données contient de nombreuses boîtes aux lettres, cela veut dire qu’une grande quantité d’entre elles peuvent être mises en quarantaine durant une courte période.

Que pouvez-vous faire ?

Il est évident que la mise en quarantaine de nombreuses boîtes aux lettres n’est pas un comportement souhaité, car cela entraîne une durée d’immobilisation pour les utilisateurs concernés. Mais cela vaut toujours mieux que l’alternative, à savoir le démontage de la base de données entière suite à un manque d’espace disque, qui entraînera une durée d’immobilisation pour tous les utilisateurs de cette base de données. Bien que les boîtes aux lettres mises en quarantaine puissent être libérées manuellement en supprimant leur GUID du Registre , cette solution n’est pas optimale car lors de la prochaine exécution de l’analyseur, les mêmes boîtes aux lettres risquent de se retrouver de nouveau en quarantaine.

Les boîtes aux lettres en quarantaine sont identifiées à l’emplacement suivant :

Hkey_Local_Machine\SYSTEM\CurrentControlSet\Services\MSexchangeIS\Servername\Private-<D Bguid>\Quarantined Mailboxes\ {GUID_boîte_aux_lettres}

Nous souhaitons vous assurer que nous sommes conscients de cette situation et que nous faisons tous les efforts nécessaires pour mettre en œuvre un correctif. En attendant que nous ayons identifié le meilleur moyen de résoudre ce problème, vous trouverez ci-dessous une solution de contournement qui peut être appliquée pour empêcher la mise en quarantaine des boîtes aux lettres. Entre temps, et afin d’empêcher que d’autres clients ne rencontrent ce problème, nous avons momentanément retiré le SP2 du pack d’administration Exchange 2010 du Centre de téléchargement.

Solution de contournement

Créez une solution de remplacement afin de désactiver les analyseurs qui vérifient l’espace disque libre. Ceci empêchera purement et simplement l’exécution du fichier Troubleshoot-DatabaseSpace.ps1.

Lors de la création de remplacements, il est préférable de placer ceux-ci dans un nouveau pack d’administration réservé aux personnalisations dans System Center Operations Manager. Cela vous permet de gérer facilement et rapidement vos remplacements ou autres paramètres personnalisés. Si vous n’avez pas encore de pack d’administration à cet effet, vous pouvez en créer un en procédant comme suit :

1. Dans la console Opérateur, cliquez sur le bouton Administration. Dans le volet Administration, cliquez avec le bouton droit sur Packs d’administration, puis cliquez sur Créer un pack d’administration. L’Assistant Créer un pack d’administrationapparaît.
2. Dans la page Propriétés générales, tapez un nom pour le pack d’administration dans Nom, le numéro de version correct dans Version et une brève description dans Description. Cliquez sur Suivant puis sur Créer.

Après avoir désigné un pack d’administration pour les remplacements, vous devez créer ceux-ci pour les quatre analyseurs mentionnés ci-dessous :

Dans System Center Operations Manager, accédez au module Création, puis à Analyseurs sous Objets du pack d’administration. Les analyseurs peuvent être désactivés en définissant un Remplacement et en choisissant de désactiver l’Analyseur pour tous les objets de la classe Database Copy DB Logical Disk Space (comme illustré ci-dessous) :

Cliquez sur la case en regard de Activé , puis modifiez la valeur de remplacement en sélectionnant Faux : .

Dans la même boîte de dialogue Propriétés du remplacement, sélectionnez le pack d’administration désigné pour les personnalisations.

À l’heure actuelle, nous pensons que si vous êtes affecté par la mise en quarantaine des boîtes aux lettres, l’option consistant à désactiver les Analyseurs est l’unique solution de contournement disponible. Nous sommes conscients du fait que cela risque d’empêcher les administrateurs de recevoir des alertes quand l’espace disque est faible, mais nous estimons qu’il s’agit de la meilleure option pour empêcher la mise en quarantaine des boîtes aux lettres tant qu’un correctif n’aura pas été publié.

Notez que lorsque l’espace disque de la base de données est faible, une alerte est tout de même reçue quand le lecteur de journaux de transactions coexiste avec la base de données, puisque cette alerte est générée par une règle différente purement basée sur perfmon.

Ben Winzenz, Kevin Carker

Ce billet de blog a été traduit de l’anglais. La version originale est disponible à la page Mailboxes on a database are Quarantined in an environment with System Center Operations Manager