properties Archives - Kevin Justin's Blog

NOT monitored servers

Ever run into NOT monitored servers?

Unsure your experience, but recently, I’ve run across multiple occurrences where servers show up as ‘not monitored. As a result, I’ve found three distinct sets of issues that might cause ‘not monitored’ status –

1) Orphaned Agent blog

https://kevinjustin.com/blog/2020/07/02/identify-orphaned-agent-properties/

This scenario usually entails deleting server from Managed Agents view in Administration tab, where alerts or other details may still exist. The procedure leverages Holman’s orphaned agent blog (tried and true) post from years back to aid cleanup.

2) Do you have packs or connectors extending classes?

https://kevinjustin.com/blog/2021/12/14/caution-using-tags-notes-extending-classes/

3) Rebuilding a server with the same name is a common server occurrence

Related to 1, Holman’s orphaned agent blog to be used to cleanup.

First, let’s test in the Lab. Second, let’s talk about the express lane ‘easy button’. Begin by deleting the Windows Computer orphaned object GUID. Process the Windows Computer object (bottom), followed by the top two (2) are HealthService, and HealthServiceWatcher object properties (see three items highlighted).

Second piece, marking the Windows Computer GUID for deletion (IsDeleted=1) cleans up nearly ALL properties. See the progress below, how this slight change makes short order of orphaned properties for ‘server’.

Windows Computer object marks all but SCVMM for deletion

Third HealthService & SCVMM objects require manual deletion per GUID.

Note first screenshot shows health service properties marked ‘IsDeleted’ = 1 after manually processing each GUID.

Fourth, screenshot shows there the HealthServiceWatcher property is marked for deletion (IsDeleted=1)

HealthServiceWatcher marked for deletion

If you have SCVMM, you will need to repeat for each of the SCVMM properties to clear out the orphans in the DB.

Why – the issue:

Typically, when servers are reimaged, i.e. NOT deleted from SCOM, there are two+ healthservice, HealthServiceWatcher, Windows Computer properties created for each image of example server. Additional properties may show duplicated for any class discoveries that are common to the old and new image.

NOTE: Deleting the current agent may clean up objects for that instance of the discovered server, but NOT the old server image.

Detected malicious verification code error

Ever run into the ‘detected malicious verification code’ error while authoring? I ran into the malicious verification error authoring, and couldn’t find any content for this error while authoring a pack.

Watch your copy/paste’s with additional monitoring changes to prevent ‘detected malicious verification code’ errors

In my authoring example, I received the ‘detected malicious verification code error’ after adding Rules, Datasources, and WriteActions (including tasks). I was copying and pasting DataSources (DS) and WriteActions (WA), thought I had it all. Uploaded > got the error, and GRR! Hopefully this will help others authoring to know what to check to get the management pack uploaded.

Simply put – Watch out for typo’s to avoid ‘detected malicious verification code’ errors!

I stumbled across a few websites, but nothing really pointed out to what caused the ‘detected malicious verification code error’ when uploading a management pack. First, check monitor and rules to verify the DS/WA are called correctly (no errors in file names. Check the Tasks as well as DisplayStrings, to make sure everything matches.

Error Seen when uploading Management pack from SCOM Console GUI regarding ‘detected malicious verification code’ error

<ManagementPackNameHere> Reports could not be imported.

If any management packs in the Import list are dependent on this management

pack, the installation of the dependent management packs will fail.

Verification failed with 1 errors:

——————————————————-

Error 1:

Found error in

2|<ManagementPackNameHere>|1.0.0.6|<ManagementPackNameHere>|

| with message:

Detected malicious verification code when verifying element of type

Microsoft.EnterpriseManagement.Configuration.ManagementPackRule with inner

exception: System.Collections.Generic.KeyNotFoundException: The given key

was not present in the dictionary.

at System.ThrowHelper.ThrowKeyNotFoundException()

at System.Collections.Generic.Dictionary`2.get_Item(TKey key)

Microsoft.EnterpriseManagement.Configuration.ManagementPackRule.VerifyDataTy

pes(Dictionary`2 moduletypes)

Microsoft.EnterpriseManagement.Configuration.ManagementPackRule.Verify(Verif

icationContext context)

Microsoft.EnterpriseManagement.Configuration.Verification.VerificationEngine

.VerifyCollectionItems(Object context)

Additional links

Detected malicious verification code when verifying element

Forum https://social.technet.microsoft.com/Forums/en-US/ac50ae14-882a-4788-a8e4-6a975c498a29/detected-malicious-verification-code-when-verifying-element-of-type

Caution using Tags/Notes extending classes

Please take ‘caution using Tags/Notes extending classes’. Please read below if you use Tags/Notes on SCOM classes. Ran across examples where SCOM Class Properties were used for tags that used the .Notes field on various classes, causing orphaned properties, NOT removed from OperationsManager database.

Background

The Microsoft.Windows.Computer Class (insert class here) is updated using Tim McFadden’s blog. This can cause issues with orphaned classes in the database because it is not currently handled as part of the stored procedure (i.e. the Notes property classes do not get marked for deletion).

First, identify which classes have Notes property. Start from Management Server (MS) via PowerShell. See attached TXT for additional examples to check and add/remove Notes Property on additional windows classes.

Set Notes property for Windows Operating System server

Second, we need to see how to set and clear the value, in order to clean up the Operations Manager database, to remove the orphaned instances. The example below sets the value for one (1) server to ‘Production’.

$WOS = Get-SCOMClass -name Microsoft.Windows.OperatingSystem | get-SCOMClassInstance | where-object -property Path -eq “16db01.testlab.net”
$WOS.'[System.ConfigItem].Notes’

$WOS.'[System.ConfigItem].Notes’.Value = “Production”

$WOS.Overwrite()

$WOS = Get-SCOMClass -name Microsoft.Windows.OperatingSystem | get-SCOMClassInstance | where-object -property Path -eq “16db01.testlab.net”

$WOS.'[System.ConfigItem].Notes’

Example Output

PS C:\Users\scomadmin> $WOS.'[System.ConfigItem].Notes’.Value = “Production”
PS C:\Users\scomadmin> $WOS.Overwrite()
PS C:\Users\scomadmin> $WOS = Get-SCOMClass -name Microsoft.Windows.OperatingSystem | get-SCOMClassInstance | where-object -property Path -eq “16db01.testlab.net”
PS C:\Users\scomadmin> $WOS.'[System.ConfigItem].Notes’

PropertyAccessRights : Unknown
Parent : Microsoft Windows Server 2016 Standard
Type : Notes
Value : Production
Id : 00000000-0000-0000-0000-000000000000
ManagementGroup : SCOM2016
ManagementGroupId : e39f5f53-9fbb-9d7f-4bfe-5f0324630ae5

Set Notes property to NULL

$WOS.'[System.ConfigItem].Notes’.Value = $null
$WOS.Overwrite()

$WOS = Get-SCOMClass -name Microsoft.Windows.OperatingSystem | get-SCOMClassInstance | where-object -property Path -eq “16db01.testlab.net”

Verify Notes value

$WOS = Get-SCOMClass -name Microsoft.Windows.OperatingSystem | get-SCOMClassInstance | where-object -property Path -eq “16db01.testlab.net”
$WOS.'[System.ConfigItem].Notes’

Example Output
PS C:\Users\scomadmin> $WOS = Get-SCOMClass -name Microsoft.Windows.OperatingSystem | get-SCOMClassInstance | where-object -property Path -eq “16db01.testlab.net”
PS C:\Users\scomadmin> $WOS.'[System.ConfigItem].Notes’

PropertyAccessRights : Unknown
Parent : Microsoft Windows Server 2016 Standard
Type : Notes
Value : (null)
Id : 00000000-0000-0000-0000-000000000000
ManagementGroup : SCOM2016
ManagementGroupId : e39f5f53-9fbb-9d7f-4bfe-5f0324630ae5

Have a happy Holiday!

Good luck, hopefully this scenario isn’t something that impacted the monitoring environment!