Masquer le rapport d’erreur


Que celui d’entre vous qui n’a jamais vu cette boîte de dialogue qui propose d’envoyer un rapport d’erreur à Microsoft cesse immédiatement la lecture de ce billet. Pour les autres, que vous soyez parmi ceux qui les transmettent régulièrement comme ceux qui souhaiteraient pouvoir faire définitivement disparaître cette proposition, vous pouvez poursuivre.

Si vous utilisez System Center Operations Manager, sachez que vous disposez des moyens de mettre en œuvre un serveur de collecte de ces rapports dans le module appelé Agentless Exception Monitoring ou AEM.

Si vous avez acquis Microsoft Desktop Optimization Pack for Software Assurance (MDOP) vous disposez de Microsoft System Center Desktop Error Monitoring (DEM) qui vous permet également de collecter les rapports à l’intérieur de votre organisation.

Pour les aspects commerciaux de ces deux produits, contactez votre interlocuteur habituel pour les licences Microsoft.

Si vous souhaitez masquer toute apparition de cette boîte de dialogue, les stratégies “Afficher les notifications d’erreur” pour Windows XP et Windows Server 2003 et “Ne pas afficher l’interface utilisateur pour les erreurs critiques” pour Windows Vista et ultérieurs permettent de masquer le message. Ce réglage est utilisable que vous souhaitiez ou non transmettre le rapport ou le collecter sur votre propre serveur avant de le transmettre ou non à Microsoft.

Afficher les notifications d'erreur

Ne pas afficher l'interface utilisateur pour les erreurs critiques

Si l’intérêt de ces rapports vous échappe, il faut imaginer l’analyse de Microsoft sur l’ensemble des rapports transmis. Si votre poste rencontre un problème que jamais aucun autre ordinateur n’a rencontré, il est fort à parier que le problème risque de ne pas être traité avec une très grosse priorité par Microsoft. En revanche, les problèmes les plus fréquents font l’objet de traitements plus rapides et attentifs, voire peuvent être transmis à un éditeur tiers ou un autre intervenant tel qu’un fournisseur d’accès à Internet.

Cette démarche que Microsoft utilise pour fixer les priorités peut également s’appliquer à l’intérieur de votre parc : les problèmes remontés par une grosse majorité de vos ordinateurs devraient vous mettre en alerte pour tenter de trouver une solution qui impactent une bonne partie de vos utilisateurs. Imaginons, par exemple, que vous constatiez qu’une très ancienne version d’un logiciel provoque plus de 80% des rapports d’erreur collectés, vous devriez accélérer la migration de cette ancienne version vers une version plus récente qui, probablement, ne provoquera pas les mêmes erreurs.

J’espère vous avoir convaincu, mais s’il vous reste des interrogations, n’hésitez pas…

Comments (1)

  1. Yann Gainche says:

    Salut Stéphane.

    Merci pour cette info. Pour en avoir discuté avec d'autres MVP, ces fonctions sont utilisés aux US et en ASIE, peut être en Grande Bretagne. En France, il y a encore un manque de maturité des entreprises pour utiliser Operation Manager dans l'analyse des erreurs fatales provoquées par les applications. C'est peut-être aussi dû à un manque de maturité des consultants ;). Pour ma part, je me heurte, chez les grands comptes,  qui ont plusieurs forêts AD sans relation d'approbation avec OpsMgr dans une forêt et les utilisateurs dans une autre, à une difficulté d'implémentation. En effet, AEM ne fonctionne pas au travers des Gateways Operations Manager.

    Cordialement,

    Yann