The Federator FMS is gathering the data from multiple Children FMS. The likely cause is that this Host object has been discovered by more than one Child FMS which can inadvertently be adding the systemId to the monitored Host object and generate Host aliasing in the Federator FMS.
The systemId property, if set, can make unrelated Host objects to be merged as an alias in the Federator FMS even if there aren't any aliases in any of the Children FMS. This often occurs in Linux servers when they're cloned from a Virtual Machine template since they preserve the same System ID.
This may be caused by duplicate agents across different Children FMS as well.
To check if any Host aliasing is occurring in the Federator FMS, use the script in Step 1 of KB 205776. The output might be something like this for example:
Aliases for Host:examplehostname001
examplehostname005
examplehostname003
----
On the Federator FMS, search for this Host object in the Script Console and check the contents of the sourceIds property. See the following example for illustration purposes only:
In the example above the sourceIds are just these two:
0de14755-a4ec-4753-88e8-0d65b65b78bb:1c76a03d-06e7-4f8b-88ca-928b15fd2487:2
dc19e3f0-494a-4d61-a168-5d55befa8b03:49e0b9de-e02a-410c-a3a7-89e7036a6410:50
These strings represent a combination of the Object ID (uniqueId), an Id of the Child FMS and the object version number. When there's an issue with Host aliasing, this property will have 3 or more rows.
In order to fix the problem, follow steps 2 to 4 in KB 205776 for each of the objects in the list above to ensure the systemId is not being collected in any of the associated objects in the Children FMS.
The Federator FMS will recreate the Host object next time it resynchronizes with each Child FMS. This can take several hours to complete.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center