One common issue I see regularly, is when customers upgrade their OS in place on Agent monitored systems, or replace and older OS with a new VM and a new OS, but keep the same server name.
This practice causes issues for SCOM. You might see duplicate discovered instances across OS versions when you do this. The “proper” way to manage this, is to delete the machine from SCOM, when performing these OS version upgrades or replacements. However, most of the time, the monitoring team is not even made aware that this activity is happening, and they are left with this issue.
It isn’t terribly harmful, the primary side effect is duplicate alerts when a disk fills up, performance counters collected in duplicate, and increased instance space consumed on the Agent and in SCOM as a whole.
You can detect if you are affected by running this SQL query against your Operations Database:
--BEGIN QUERY SELECT bme.Path, bme.DisplayName, Count(*) AS 'Count' FROM BaseManagedEntity bme WHERE bme.FullName LIKE 'Microsoft.Windows.Server.%.LogicalDisk:%' AND bme.DisplayName = 'C:' GROUP BY bme.Path, bme.DisplayName HAVING Count(*) > 1 --END QUERY
You might have duplication of other OS based versioned objects, but this one will output the names of Computers that have more than one “C:” drive discovered… which usually means it is affected.
You can simply delete these agents from SCOM, then let them come back into the management group as a new agent. Caution however, sometimes when you delete an agent in SCOM and it immediately comes back, it will sit in an “unmonitored” state and require the local Healthservice on the agent get restarted, so plan accordingly.
This will improve over time, as we move more toward “Version Agnostic” management packs, that aren’t so version specific, such as the Windows Server 2016 and Later OS MP, or the SQL 2012+ version agnostic MP.