This is a rare but interesting scenario… which can cause you to see and monitor duplicate objects (and get duplicate alerts) for specific types of discovered hosted objects that have a parent class which was upgraded from one version to another.
For instance – if you upgrade SQL 2005 > SQL 2008, or Windows 2000 > Windows 2003. Some of the child objects could potentially get “left behind” and I will explain how, using the SQL upgrade scenario.
When you upgrade a monitor SQL instance from 2005 > 2008, a few things must happen in the MP. We need to discover the SQL instance as SQL 2008, which while the same instance technically, is seen as a new object of a new class to OpsMgr. We also need to “undiscover” the SQL 2005 instance, and delete those previously discovered objects hosted by that class.
So… when you upgrade SQL from 2005 > 2008, IF (big IF) your SQL 2005 discovery runs FIRST, before we discover SQL 2008, then all will be well. We will undiscover the SQL 2005 DB engine instance, and mark all hosted objects (i.e. SQL Databases) as “deleted”, since they cannot exist without the parent SQL DB engine.
However – IF the SQL 2008 discovery runs FIRST… for a short time OpsMgr will have two discovered instances of SQL DB engine… until the SQL 2005 engine discovery runs and removes the SQL 2005 discovered DB engine from OpsMgr. In THIS scenario… what you will see… is that the SQL 2005 DB engine is indeed gone…. but the SQL 2005 databases which were hosted by the SQL 2005 DB engine remain. This is BAD.
The reason?
The issue here is how the MP was constructed… and this could affect any multiple-version OS or application that supports an upgrade scenario. Each version specific database engine uses “SQL.DBEngine” as its base class. Each version specific SQL DB uses SQL.Database as its base class.
The *relationship* of “SQL DBEngine hosts SQL Database” is placed on the base classes… not on each version specific class. The version specific classes inherit these relationships form the base class.
Therefore, what happens is, that when NO DBEngine exists – we MUST delete the SQL databases associated. But when we discover SQL 2005 and SQL 2008 at the same time, once SQL 2005 DB engine is deleted – we don’t delete the SQL 2005 databases, because technically a SQL DB engine exists.
Ok – that’s kind of confusing as to why this happens…. but just understand that this scenario is possible until the MP author figures out a way to better support the upgrade condition and writes that into the discovery model.
This doesn’t just affect SQL servers. This has also been seen when upgrading the OS from one version to another, and keeping old Logical Disks around which were associated with the previous OS version.
What can I do about this???
That said – we can develop some best practices to keep this from happening.
The best recommendation I can make is when you KNOW you are doing a major upgrade of an OS or core application like this…. uninstall the agent first, instead of using maintenance mode. When you reinstall the agent after the upgrade, only the NEW stuff will be discovered.
If you need to recover from this condition for an existing agent… simply delete the agent from agent managed. This will mark all hosted objects as deleted in the database. Then – approve it as a manually installed agent. This will only discover existing applications/objects. (alternatively, you could run an uninstall/reinstall of the agent *from the console*) The key step to to make sure that the agent is NOT present in agent managed at some point.