Keep your management pack names SHORT in SP1!


I have seen this twice now… so I will blog about it.  It seems to be rare in the wild, but it will completely cripple a management group when this occurs.  So beware SP1 users!

 

This article does not apply to R2.  This is only an issue in OpsMgr 2007 SP1.

 

When you create your custom management packs – and especially your override management packs – keep the names as simple and short as possible.  There is an issue in OpsMgr SP1 – when an agent tries to download management packs – where it will fail if the MP ID (derived from the MP Name) is too long.  The worst part about this problem is there there WONT be an error logged.  What will happen – is that the agent will keep trying to re-download the MP in question, and it will block ALL other MP’s from being downloaded from that point forward.

There is no simple way to know this condition is impacting you.  What will happen – is that an agent will continue to work just fine… but will not get any NEW management packs.  So… you might think all is well, but not so.  The symptoms thatmight lead you to notice that something is wrong:

Performance data not collected for newer MP’s.

Objects not being discovered for newer MP’s

Alerts not generating as expected from newer MP’s.

 

The root problem is an age old Windows issue…. file paths over 255 characters not supported well.  This has been resolved in R2 in how the agent copies the files over.

In both cases I have seen – someone was creating an override MP for the “IBM Hardware Management Pack for IBM System x and BladeCenter x86 Blade Systems” management pack.  So – when they created their override MP – they named it something like:  “Overrides - IBM Hardware Management Pack for IBM System x and BladeCenter x86 Blade Systems”

This equated to a Management Pack ID of:  Override.IBM.Hardware.Management.Pack.for.IBM.System.x.and.BladeCenter.x.Blade.Systems

That MP ID is 86 characters!

 

What happens…. is when this management pack is created, and an override is placed in it…. (or custom rule)… the agents that require it will:

Get contacted by the RMS to update their config, and then issue a config change request (21024 in the event log)

Receive new config from the RMS (event 21025)

Process new config – and realize they need a new MP, and request that MP (event 1200)

 

Where this process breaks…. is the next step in the chain should be that the agent RECEIVES the MP (event 1201) and then issues a statement that the new config has become active (event 1210).  The never happen.

 

Behind the scenes…. from looking at a ETL tracelog, we can see this is failing, when we try to move the file from the “downloaded files” folder to the “management packs” folder:

Error CMPFileManager::MoveManagementPackFile(MPFileManager_cpp383)MoveFile from '\\?\C:\Program Files\System Center Operations Manager 2007\Health Service State\Downloaded Files\MGNAME\1\Override.IBM.Hardware.Management.Pack.for.IBM.System.x.and.BladeCenter.x.Blade.Systems.{26504FED-2FF4-4AC4-A63D-59BF8C09F51F}.{7136257C-1791-7BAB-7072-2FA24284C102}.xml' to 'C:\Program Files\System Center Operations Manager 2007\Health Service State\Management Packs\Override.IBM.Hardware.Management.Pack.for.IBM.System.x.and.BladeCenter.x.Blade.Systems.{26504FED-2FF4-4AC4-A63D-59BF8C09F51F}.{7136257C-1791-7BAB-7072-2FA24284C102}.xml' failed with code 3(ERROR_PATH_NOT_FOUND).

 

In the example above – the bad path is:

C:\Program Files\System Center Operations Manager 2007\Health Service State\Management Packs\Override.IBM.Hardware.Management.Pack.for.IBM.System.x.and.BladeCenter.x.Blade.Systems.{26504FED-2FF4-4AC4-A63D-59BF8C09F51F}.{7136257C-1791-7BAB-7072-2FA24284C102}.xml

Which is 261 characters.  The limit is 255. 

 

Therefore – I recommend you keep your Management Pack *ID* to less than 60 characters.   You can examine your long management packs by looking in the console – generally your longest display names will be the longest ID’s:

 

image

 

Even some Microsoft MP’s are dangerously close to the limit…. such as: Microsoft.SystemCenter.VirtualMachineManager.Pro.2008.VMWare.HostPerformance with 76 characters.  In most environments you can squeak by at 79 characters…. more or less depending on where you installed your agent path.

 

Here is a SQL query you can run against the OpsDB to also detect this condition…. and quick check all your potentially long MP’s:

 

select MPName from managementpack
WHERE len(MPName) > 60

Just change 60 to whatever character count you want. 

 

DONT freak out if you have some more than 60.  Just be aware.

 image 

DO freak out if you have some more than 80!

 

If someone had the time and was really handy – you could write a monitor – that runs against the RMS – that would in turn query the OpsDB, and run this query, and change the RMS to unhealthy when over a threshold.  THAT would be cool…. and alert you when some author makes a really long MP that has the potential to break all your agents.

 

Another idea I had… was to create a correlated missing event monitor…. and when you get a 1200, but do NOT get a 1201 within, say, 15 minutes….. that might be a problem.  Of course if you wrote this and were already impacted…. the bad agents would never get your new MP to tell you.  :-) 

Comments (0)

Skip to main content