Monthly Archives: February 2016

The credentials supplied to the package were not recognized(0x8009030D)


 The error:

The certificate specified in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings cannot be used for authentication.  The error is The credentials supplied to the package were not recognized(0x8009030D).

The operating system that was experiencing the above error is Windows Server 2008 R2 SP1 (Version 6.1.7601).

Cause:

By directly installing the certificates, although no error is shown the process does not complete properly.

Resolution:

Import the certificate by opening the MMC snap-in for the Certificates management and open the Local Computer store. Right click the Personal container and import the certificate manually. After that run again the MomCertImport.exe tool with administrator priviledges.

 

Advertisements

Missing key in the discovery data item


The Error:

2016-02-15_4-53-46

The cause:
The cause for this error is that the Discovery data that is returned for the class instance needs to reference any primary key that is defined in the parent class.

Make sure the discovered class contains all the primary keys required.
Some things you need to check for:
• Make sure the PS script creates the correct number of instances, and they should be unique.
• Make sure that you are discovering key properties of hosting classes.

 
Details (example):
Consider that you have classes A, B and C. Class A is based on the Microsoft.Windows.ComputerRole and classes B and C are based on System.Entity. We have hosting relationships between the classes (A hosts B which hosts C) including the inherited relationship that Windows.Computer hosts Windows.ComputerRole which is the base class for Class A.
We use a Discovery script that discovers three different class instances:

2016-02-16_14-55-28

  1.  We create the ‘MOM.ScriptAPI’ object and create the Discovery bag to store the discovery data. We do a foreach loop on the items we need to check.
  2.  We create a new class instance of objects of type Class A and then we add the required properties. The first two properties we add are key properties from the classes that Class A is based on. As Windows Computer Role is based on Windows Computer class, the Windows Computer class has a Key Property that uniquely identifies the object. Also the System.Entity class is the root class which also has defined a key property called display name. All child instances inherit this property. The last line adds the instance data along with the properties to the Discovery bag data.
  3.  We create a new class instance of type Class B which inherits the key properties from System Entity and Windows Computer and also from Class A.
  4.  Again same thing new instance of class C with key properties from Class A, Class B and Windows Computer and System Entity.

Key properties are not always mandatory. If you create only one instance for a particular class you don’t need to specify one. Of course is you creating more than one then you need it in order to uniquely identify the instance and to which parent it belongs to. Here is a good example:
For the Windows operating system class you do not need a key property because you cannot have more than one operating system at a time (at a logical level). You might have more Logical Disks to that Operating System in which case you need a key to uniquely identify the disks.

2016-02-16_15-46-46

Windows Logical Disk is based in Windows Logical Device and inherits the key property from that class.

2016-02-16_15-50-10

Going back to the error, the conclusion is that if your discovery is missing a key property, like for example in step 4 you miss to specify the ClassA key property you will get this error.

The Health Service cannot verify the future validity of the RunAs account


The Health Service cannot verify the future validity of the RunAs account DOMAIN\account for management group MG due to an error retrieving information from Active Directory (for Domain Accounts) or the local security authority (for Local Accounts). The error is The network path was not found.(0x80070035).

How many times we’ve see this error?

2016-02-09_23-31-19

Sometimes with multiple domains you will see something like the RPC server is unavailable and you will probably try to find if there is any active directory communication issue.

Don’t waste your time. All you need to do is make sure that you have configured the correct DNS Suffixes on the virtual network card.

2016-02-10_1-13-33

Either one of the highlighted options work fine. Just have to make sure that you append the correct DNS suffix on that Health Service.

After doing the change, restart the Microsoft Monitoring Agent and check the Operations Manager log for the following event:

Capture

Putting SCOM instances in maintenance mode via PowerShell


Sometimes you don’t want to put the whole server object in maintenance mode and you just need the child component that you are working on.

There are a couple of ways to do this from the SCOM console.

You can open a view that is targeting that specific class, for example the SQL DB class, and simply right click and set the maintenance mode.

2016-02-09_23-22-03

After doing so, if you navigate back to the Database Engine view, you will see those components put into maintenance mode while the DB Engine itself is being monitored as usual.

2016-02-09_23-37-37

If you to put in maintenance mode a class that is not exposed through any built in views you can use the Discovery Inventory to search for objects of a specific class.

For demonstration purposes in the following screenshot we look for the SQL database class.

2016-02-09_20-39-30

There is also another way to configure maintenance mode via scripting. Here is how you can do this via PowerShell:

Import-Module OperationsManager

$SCOMCredentials = Get-Credential -Message  “Input your SCOM credentials”

New-SCOMManagementGroupConnection -ComputerName SCOM01.mariusene.com -Verbose

$DBclass = Get-SCOMClass | Out-GridView -PassThru -Title “Select the SCOM class”

$DBInstances = Get-SCOMClassInstance -Class $DBclass | Out-GridView -PassThru -Title “Select the instances to enable Maintenance Mode”

Start-SCOMMaintenanceMode -Instance $DBInstances -EndTime (Get-Date).AddDays(1) -Comment “Maintenance mode set by PowerShell script” -Reason PlannedOther -Verbose

 

In the above code, be sure to replace SCOM01.mariusene.com with your SCOM management server. After running the above code, you will be prompted for credentials. After that you will see a window that shows all classes.

Use the Filter to look for the correct class and click OK.

2016-02-09_23-44-46

Next, we select the instances by multi-select then clicking OK.

2016-02-09_23-46-59

After selecting OK, you will see that the Objects have been put in Maintenance Mode.

2016-02-09_23-48-27

2016-02-09_23-49-54

Now in order to remove from maintenance mode via PowerShell you can use something similar:

$MMInstances = Get-SCOMMaintenanceMode  | select * | Out-GridView -PassThru

$MMInstances | % { Get-SCOMMaintenanceMode | ? {$_.MonitoringObjectId -eq $_.MonitoringObjectId} | Set-SCOMMaintenanceMode -EndTime (Get-Date) -Verbose  }

After running the code, you will see a window with the instances that are in maintenance mode. Select the ones that you want to remove from maintenance mode.

2016-02-09_23-53-57

The output will be like this:

2016-02-09_23-57-38