There are some questions on how the object GUIDs are calculated in Operations Manager and Service Manager when thinking about moving MPs to different Management Groups and/or side-by-side migration scenarios. Would the Groups created have the same GUIDs?
When I talk about the GUID of an object, I am talking about the BaseManagedEntityId value of the BaseManagedEntity table and the TypedManagedEntityId from the TypedManagedEntity table in the operational database.
The string which is hashed for Singleton Classes like Groups is the same as the class ManagedTypeId from the ManagedType table because for singleton classes we assume that the InstanceId is the same as the TypeId because we will always have *only* one object of that class.
- when I will talk about TypeId I will be referencing the ManagedTypeId from the ManagedType table
- while when talking about the InstanceId I will be referencing the BaseManagedEnittyId from the BaseManagedEntity table or the TypedManagedEntityId from the TypedManagedEntity table
When we want to get the InstanceId of a singleton class like a Group, we need to know how the TypeId was calculated – it is a hash (SHA1) of this string format:
- when I talk about the TypeId, this is directly the MPObjectId which is calculated based on the string ID of the element in the XML definition
- so this is exactly how definitions (classes, relationships, rules, monitors, etc.) get their GUID from the string ID from the XML definition
Here is an example for the All Windows Computers Group:
Now for any non-singleton class like the HealthService or WindowsComputer classes, this is the string used to calculate the InstanceId:
Here is an example on how the HealthService GUID is being calculated for an Agent based on its FQDN:
I hope this answers some questions about what happens in different scenarios like upgrading the OS on an Agent, migration, moving groups from a Management Group to another and so on 😀