Did you ever notice that GUIDs in error messages can seem consistent across management groups?

Did you ever wonder why you could count on your Managed Object IDs being the same across management groups?

Probably not, but it can actually be useful to know in advanced cases.  And since this took me hours to reverse engineer, I’m going to post it.  As I said in my profile, I post things I find interesting.  🙂

BaseManagedEntityId GUIDs are deterministic because they are hashes of known information.  OpsMgr does not use NewID() to generate random GUIDs on the fly.

If you want to know what your BaseManagedEntityId is going to be, you can use SQL Server functions to figure it out.  You just have to get the string exactly right.

The format of the string is:

TypeId={ManagedTypeId-GUID},{KeyProperty1Id-GUID}=some value,{KeyProperty2Id-GUID}=other value

ManagedTypeId GUID is available using Powershell

Get-MonitoringClass –Name “Microsoft.Windows.Computer” | fl Id

Or from the database

Select ManagedTypeId from BaseManagedType where FullName like ‘%Windows.Computer%’


PropertyId GUIDs are also available from Powershell

Get-MonitoringClass –Name “Microsoft.Windows.Computer” | Get-MonitoringObject | %{Get-MonitoringObjectProperty} | fl Name, Id

Or from the Database

Select * From ManagedTypeProperty where ManagedTypePropertyName = ‘PrincipalName’


Your string should look like this:


Now you get your hash by plugging this string into SQL Server’s Hashbytes function:

declare @hashstring nvarchar(max)
select @hashstring = ‘TypeId={EA99500D-8D52-FC52-B5A5-10DCD1E9D2BD},{5C324096-D928-76DB-E9E7-E629DCC261B1}=SERVER1.MYDOMAIN.LOCAL’
select convert(UniqueIdentifier, HASHBYTES(‘SHA1’,’@hashstring)

If you did everything right, your result will be the same ID as the one in the database for your SERVER1.MYDOMAIN.LOCAL object of type Microsoft.Windows.Computer.

Be careful:

  • GUIDs and Property Values (Server1.MyDomain.Local in the above example) need to be all-capitals.  Also, interestingly enough, you need to alphabetize your property GUIDs.  For example, if your class type has two key properties, you have to put them in alphabetical order in the string, even if the order isn’t meaningful.
  • Hosting objects’ key properties are key properties of the object you are looking for
  • You have to use the least-derived non-abstract managed entity that has a key property.  So if your class inherits from an abstract type that has a key property defined, and that abstract type is hosted by another object, you have to provide all those keys, but your ManagedType is the non-abstract one just below the abstract one.
  • The runtime code that does this in R2 has a bug.  If you start to mess with this stuff, be sure to get the rollup of fixes (due Nov 09).  Otherwise your hashes won’t match.

I haven’t figured out how these GUIDs are generated for Singleton types without key properties defined.  I also am not sure how other IDs (e.g. ManagedTypeId, ManagedTypePropertyId) are generated, but I believe they are also hashes, not random GUIDs.

This is certainly SCOM Esoterica, but is actually useful for some posts I hope to write shortly involving creating alerts and setting monitor states for objects other than the one targeted by the rule/monitor.  Cool stuff, actually.

Update (10/14/09)

The Id of a singleton object is the same as its class Id.

This entry was posted in Uncategorized. Bookmark the permalink.

3 Responses to BaseManagedEntityId

  1. Mike Sargent says:

    In the OperationsManager database, you will find stored procedures that calculate the ID’s of other objects. For example, [fn_MPObjectId] takes an MP name, key token, and the name of an object in the MP and will return the ID for it. We have checked and this definately works for Class ID’s. There is also [fn_MPSubObjectId] to get the ID of things like the Properties of a Class.

    If you look at the rest of the scalar valued functions, you will find a large number that return the pre-computed ID values for some of the common objects. The pre-computed values do match what is calculated above.


    • sentryboy says:

      Nice! Thanks for posting.
      I’m curious to know what you used this for that you did that level of database spelunking. I had a pretty obscure need for the IDs when I was working on this that got me to post the topic originally.

  2. Pingback: Service Manager 2012 SP1 secondary Management Server–Cannot set availability on a health service that doesn’t exist | Shaun Laughton

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s