Tag: custom authoring

Detected malicious verification code error

'detected malicious verification code' errors
Detected malicious verification code when verifying element – ever run into this scenario while authoring?

 

 

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)

at

Microsoft.EnterpriseManagement.Configuration.ManagementPackRule.VerifyDataTy

pes(Dictionary`2 moduletypes)

at

Microsoft.EnterpriseManagement.Configuration.ManagementPackRule.Verify(Verif

icationContext context)

at

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

Caution
Caution

 

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!

Identify orphaned agent properties

Detective investigating items under a magnifying glass

 

Back again, I’m going to ‘Identify orphaned agent properties’.  For instance, does an agent still show up under Windows Computer, or more classes, like Windows Operating System?  Typically we have handled this by using Holman’s purge blog.

 

 

 

Deleting and Purging data from the SCOM Database

 

 

First, my thanks to Kevin H, Mihai S from the SCOM PG, & Premier Support CSS, for their help.  Let’s begin the ‘Identify orphaned agent properties’ discussion with ‘how’.  First, how do you get an orphaned property?  Second, how to you resolve?

 

Some example scenarios

    1. Server rebuilt with same name.  New agent runs discovery, and creates new set of GUID’s in the database.
    2. The Monitoring Tab > Windows Computer view contains unhealthy <gray> server objects.  Upon further inspection, the server does NOT show up in the Administration > Agent Managed view.
    3. Custom management pack authoring extends the Windows Computer class, or others (via SDK or PowerShell)

 

‘Identify and resolve’ orphaned agent properties

 

    1. Check for COMMIT or Overrides in management packs

PG recommended looking at Windows Computer extended class properties, and Connector Framework discoveries.

Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Commit()

or

Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Override()

 

Search for the ConnectorFramework

Search management packs (MP) via SCOM OpsDB (OperationsManager Database)

    1. Login to your SCOM OpsDB > New Query

select MPName, convert(xml, MPXML)

from ManagementPack

where

   MPXML like ‘%Commit(%’ or

   MPXML like ‘%Override(%’

Export management pack output or snag it/snippet screenshot

Example Snapshot from SQL query

SQL Query output of Management Pack output with Commit or Override
SQL query of MP Commit or Override pack matches

FYI – mgmt packs above use %Commit(%, but not the connectorFramework

 

Correct discoveries that use ConnectorFramework

Replace Discoveries

Update discoveries that contain:

New-Object Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Commit()

New-Object Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Override()

Replace with:

New-Object -comObject MOM.ScriptAPI for discovery

 

Test discoveries that use Remove method

Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData.Remove()

 

 

 

Example management pack discovery script

Contains

$discovery = New-Object Microsoft.EnterpriseManagement.ConnectorFramework.IncrementalDiscoveryData

$discovery.RemoveInternal($Instance,$ClassInstance.GetClasses()[0])

$discovery.Commit($mg)  <– This is the offender that causes the orphans

}