This problem appeared in SCOM 2012 RTM so I will talk about this version. The issue persists in all versions up to 2012 R2.
We need to understand how health rollup works to answer this question.
There is a workflow on SCOM Server which goes through the database and implements health roll up. It searches for the objects which need their health to be updated. It does not roll up health for all entities in one run. There are thousands of them and such implementation would cause huge performance impact on server.
After working with numerous environments we've figured out that Health Rollup Workflow skips entities which are being changed very often. A typical scenario to reproduce rollup problem is to reinstall the same Management Pack many times.
When you develop a pack usually you make some changes and install the new version in your dev SCOM just to verify the improvements work. However sometimes you make changes which break the compatibility with previous versions of MP and you have to remove it before deployment of new one.
The trick is that SCOM doesn't remove discovered entities from the database right away after MP uninstallation. It just marks them as deleted. So when you install MP again you rediscover the same object with the same GUID and there is a huge chance that Health Rollup MP will skip it and you'll see the sad picture:
If you hit this issue, you could try to restart System Center Management service (Monitoring Service in 2012 R2) but in most cases it doesn't help.
You'll ask me what to do if you develop and just need to reinstall and you need health to be rolled up?
There is a hope! I've invented one trick how to get instant rollup guarantee.
I'll post it in one of the next posts, dear diary. Follow up.
We need to understand how health rollup works to answer this question.
There is a workflow on SCOM Server which goes through the database and implements health roll up. It searches for the objects which need their health to be updated. It does not roll up health for all entities in one run. There are thousands of them and such implementation would cause huge performance impact on server.
After working with numerous environments we've figured out that Health Rollup Workflow skips entities which are being changed very often. A typical scenario to reproduce rollup problem is to reinstall the same Management Pack many times.
When you develop a pack usually you make some changes and install the new version in your dev SCOM just to verify the improvements work. However sometimes you make changes which break the compatibility with previous versions of MP and you have to remove it before deployment of new one.
The trick is that SCOM doesn't remove discovered entities from the database right away after MP uninstallation. It just marks them as deleted. So when you install MP again you rediscover the same object with the same GUID and there is a huge chance that Health Rollup MP will skip it and you'll see the sad picture:
If you hit this issue, you could try to restart System Center Management service (Monitoring Service in 2012 R2) but in most cases it doesn't help.
You'll ask me what to do if you develop and just need to reinstall and you need health to be rolled up?
There is a hope! I've invented one trick how to get instant rollup guarantee.
I'll post it in one of the next posts, dear diary. Follow up.
Dear can you post trick please
ReplyDeleteDear can you post trick please
ReplyDeleteHi, mate.
ReplyDeleteThe trick is to change the id of the entity. The issue with rollup is usually hit during development. When you need to deploy new versions very often. Just change the id of the entity and SCOM will create a new instance for it in the database.
If you don't develop but hit the issue with somebody's else MP I think the only option would be to wait. After some time SCOM will eventually roll it up.