Lors de l’implémentation du Management Pack de supervision pour Microsoft Dynamics AX 2012 sur System Center Operations Manager, j’ai fait face à un problème de découverte des composants suivants :
- Environment Health
- Microsoft Dynamics AX 2012 Database
- Clusters
- Microsoft Dynamics AX 2012 Batch Framework
- Enterprise Portal Sites
- Reporting Services Instances
Le script de découverte en PowerShell semblait bien fonctionner dans le journal d’évènement Operations Manager des machines. Aucune erreur n’était rencontrée. Vous devez valider les éléments suivants :
- Avoir installé des agents SCOM sur l’ensemble des serveurs participants à l’infrastructure Dynamics AX 2012.
- Activer le mode proxy sur les agents participants à l’infrastructure Dynamics AX 2012.
- Configuré le Run As Account utilisé pour lire la base de données Dynamics AX et lui donner les droits SQL de connexion et de lecture.
Après investigation avec l’équipe du support de Microsoft, il s’avère que le script de découverte utilise des informations chargée au travers d’une librairie dédiée. Cette librairie charge des informations à partir de la base de données pour déterminer le premier serveur de l’instance AOS.
Cette information est récupérée dans la base de données à partir de la table SYSGLOBALCONFIGURATION et du champ SCOMPerformanceAOS. Celui-ci a une valeur sous la forme <Nombre d’instance>@<Premier Serveur de l’instance AOS>. L’arobase est utilisé pour séparer la chaine. Dans mon cas, la valeur pointait sur un serveur qui ne faisait pas partie de l’instance AOS. Ma déduction est qu’un serveur a été utilisé pour préinstaller et configurer l’instance AOS puis démantelé une fois que les autres serveurs étaient installés.
Vous devez donc modifier la valeur pour renseigner le bon nombre d’instances et le nom NETBIOS d’un serveur qui prend part à l’instance AOS. Une fois la modification faite et la découverte exécutée, les objets sont correctement instanciés.
