> Tech > Delete aged status messages

Delete aged status messages

Tech - Par Renaud ROSSET - Publié le 13 avril 2011
email


Cette tâche efface les messages de statut et d’audit (ils sont contenus dans dbo.StatusMessages). Elle présente la particularité de ne pas exposer tous les paramètres de son fonctionnement. En effet, elle s’appuie sur deux « Status filter rules » qui sont « write audit message and specify

Delete aged status messages

the period after which the user can delete the message » et « write all other message and specify the period after which the user can delete the message ».
Ces deux règles présentent la même interface. L’effacement se fait par bloc de 50.000 enregistrements et s’arrête dès qu’il reste moins de 50.000 enregistrements.
La purge n’est donc jamais complète (sauf si le nombre de messages est un multiple exact de 50.000, ce qui est plutôt rare).
Cette tâche correspond à la procédure dbo.sp_Delete AgedStatusMessages.

Logs

Smsdbmon.log Aucun


Delete inactive client discovery data

Cette tâche supprime les clients inactifs. Un client est une ressource dotée d’un agent. La tâche ne concerne donc que les équipements dotés d’un agent (ni les utilisateurs, ni les équipements non-Windows…).

Un client est marqué inactif :
– Quand il est remasterisé (il devient obsolète ET inactif)
– Quand « R2 Client Status reporting » est installé, configuré et
• Options/«Update Configuration Manager 2007 site database with inactive client information » est coché
• La limite indiquée a été dépassée

Il redevient actif dès qu’une pulsation d’inventaire (Heartbeat) est reçue le concernant. Cela n’est pas vrai pour les autres découvertes.
Quand cette tâche s’exécute, elle détruit les enregistrements « inactifs » plus âgées que le paramètre spécifié.
Pour cela, elle cherche une mise à jour « Heartbeat » plus récente que (date_du_jour – paramètre) et si elle n’en trouve pas la ressource est sélectionnée.
Si après cet effacement :
– une découverte l’identifie de nouveau,
– il est joignable et
– « Client Push » est activé,alors le Management Point procédera à une réinstallation du client qui enverra ensuite un premier inventaire (donc complet) qui remontera vers son éventuel site parent. Autant dire que l’impact sur le réseau peut être notable.

Donc avant d’activer cette tâche ou de modifier son paramètre sur un système où elle est activée, il est préférable vérifier quel résultat cela produira en lançant la procédure dbo.Sp_GetInactiveClients.

Logs

Smsdbmon.log 2417 — The Delete Inactive Client Discovery Data task has completed, %1 inactive clients have been removed from the database.%12


Delete obsolete client discovery data

Lorsqu’un enregistrement Hearbeat parvient au serveur, on l’a vu, il enregistre dans AgentDisc cette information. Auparavant il recherche l’enregistrement dans la table des ressources portant la même clef. Cette clef est la GUID, donc un « SMS Unique Identifier », générée par l’agent lors de l’installation.
– Quand le système est trouvé, il s’agit en fait d’une simple mise à jour.
– Quand un poste est remasterisé, son agent est réinstallé.

Donc son GUID change. Toutefois, d’autres propriétés permettent de détecter que ce poste a été déjà connu par Configuration Manager. Pour simplifier, disons qu’un identifiant de la machine existe (Hardware ID) et qu’il est invariant dans le temps, quel que soit le système installé6. Mais que se passe-t-il lorsque ce nouveau poste renvoie son « premier » heartbeat ? Cela dépend de la configuration du site, dans Site/Propriétés/Avancé. Si l’option automatique est sélectionnée, un Heartbeat portant un GUID inconnu mais un HardwareID connu rend obsolète l’enregistrement portant le même HardwareID. Les deux enregistrements apparaîtront dans la collection « All systems ».

Si c’est l’option manuelle qui est sélectionnée, lors de l’inspection des enregistrements en attente que l’on trouvera dans Computer Management / Conflicting Records, il sera possible de choisir entre :
– « nouvel enregistrement » qui fera exactement la même chose que l’option automatique.
– « bloquer » qui fera de même mais qui bloquera le nouvel enregistrement en attendant qu’il soit débloqué (donc ce client ne sera pas opérationnel)
– « fusionner » qui remplacera le GUID de l’enregistrement existant par celui du Heartbeat.

Un seul enregistrement apparaitra dans la collection « All Systems ». Voilà comment un client peut devenir obsolète. Et c’est maintenant que cette tâche prend son sens : elle détruira les enregistrements obsolètes plus âgés que le paramètre indiqué. Pour déterminer l’impact de l’activation de cette tâche, il est prudent de faire une requête avec un critère sur Obsolète= vrai, ou d’exécuter la procédure stockée Sp_GetObsolete Clients en indiquant en paramètre l’âge souhaité.

Logs

Smsdbmon.log 2418 — The Delete Obsolete Client Discovery Data task has completed, %1 obsolete clients have been removed from the database.%1

6 – http://blogs.msdn.com/steverac/archive/2008/05/12/discovery-internals-how-duplicates-are-created-handles-obsoletes.aspx

Téléchargez cette ressource

Préparer l’entreprise à l’IA et aux technologies interconnectées

Préparer l’entreprise à l’IA et aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Renaud ROSSET - Publié le 13 avril 2011