L’équipe OpsMgr a publié un article dans la base de connaissances sur un scénario qui peut être compliqué à détecter. Dans certains cas de figure, vous pouvez observer que la configuration ne s’applique pas aux agents ou que l’état n’est pas mis à jour :
-
Les agents fraichement installés sont affichés comme « Not Monitored » dans la console. Les agents déjà présents sont eux monitorés
-
Un ou plusieurs moniteurs sur un ou plusieurs agents ne changent pas d’état
-
Les agents sont affichés comme étant en mode maintenance dans la console, alors que le workflows n’a pas été chargé par le service System Center Management sur les ordinateurs concernés
-
Les changements de configuration, les nouvelles règles ou moniteurs ou overrides ne sont pas appliqués à plusieurs agents
-
Le journal d’événement d’un ou plusieurs agents affiche un évènement 21026 visant à indiquer que la configuration est valide, alors que la configuration de ces agents aurait dû être mise à jour
-
Le fichier « OpsMgrConnector.config.xml » dans le dossier du groupe d’administration de l’agent n’est pas mis à jour pendant une longue période comparé aux autres agents de ce même groupe d’administration
En outre, vous pouvez observer les erreurs suivantes :
Log Name: Operations Manager
Source: OpsMgr Config Service
Event ID: 29106
Level: Warning
Description:
The request to synchronize state for OpsMgr Health Service identified by "da4d36df-ce22-8930-e6d4-45b783e9fdb1" failed due to the following exception "System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
Log Name: Operations Manager
Source: OpsMgr Config Service
Event ID: 29106
Level: Warning
Description:
The request to synchronize state for OpsMgr Health Service identified by "fc1c815b-c0c4-242d-ae27-30db4ef99b54" failed due to the following exception "Microsoft.EnterpriseManagement.Common.DataItemDoesNotExistException: TypedManagedEntityId = 'ac8f3d08-ee2a-ae21-0e46-19c3da794183' is deleted.
Ce problème est dû à un problème entre les horloges système. En effet, le service System Center Management Configuration utilisé un timestamp pour déterminer quand de nouvelles données de configuration doivent être calculées. Si l’horloge système de l’agent est plus rapide que l’horloge système du RMS, les données de découverte de cet agent seront calquées sur un timestamp relatif à son horloge. Le service System Center Configuration Management retardera ainsi le calcul des mises à jour de configuration sur ces agents jusqu’à que l’horloge du RMS corresponde au timestamp de la donnée de découverte. Il est à noter que si l’horloge système est beaucoup plus rapide que celle du RMS, alors l’agent continue d’envoyer des données de découverte avec un timestamp dans le future, il est possible que le groupe d’administration expérimente les symptômes qu’on retrouve ci-dessus.
Pour cela, vous devez :
-
Résoudre les écarts d’horloge dans l’infrastructure
-
Les timestamps dans la future des données de découverte doivent être modifiés dans la base de données opérationnelle pour refléter l’instant
Attention ! sur les opérations qui touchent la base de données !!! -
Vous devez ensuite redémarré à la fois le service System Center Configuration Manager et System Center Management sur le RMS
En outre, la KB donne plusieurs requêtes SQL pour déterminer l’état.
Pour plus d’information, je vous invite à lire en intégralité la KB2635742 : Configuration may not update in System Center Operations Manager 2007
En outre, je conseille l'article de Daniele qui complète la KB avec le tracking des états post-datés : http://nocentdocent.wordpress.com/2012/03/09/post-dated-data-in-your-opsmgr-database/
