Menu Close

New Administrative Console Views in SCOM 2019

In the SCOM Console you will see some new views in the Administration panel:


These actually aren’t new for SCOM 2019, they existed in 1801/1807 as well. 

These are driven by a Management Pack discovery, in the MP: Microsoft.SystemCenter.OperationsManager.Internal (Operations Manager Internal Library).  The new discovery is Microsoft.SystemCenter.OM.Products.Discovery (Discovery of Operations Manager deployment).

You will see things like Management Servers, Gateways, Consoles, etc.

One thing to note – this discovery only runs once per day, on ALL health service objects in the management group.  You might notice that your first Management Server that hosts the RMS Emulator (root health service) is not discovered, nor are the Databases.  The most common reason for this, is that we require an agent to be deployed to the SQL Servers that host the SCOM OpsDB and DW.  When the RMS discovery runs, it also discovers the instances for the SCOM databases, but discovers them for the Computer that hosts those DB’s.  If that Computer doesn’t exist in SCOM, this discovery will throw an error.  You might see this in the SCOM event logs on the missing Management Server:

Log Name:      Operations Manager
Source:        Health Service Modules
Event ID:      10801
Discovery data couldn’t be inserted to the database. This could have happened because  of one of the following reasons:

     – Discovery data is stale. The discovery data is generated by an MP recently deleted.
     – Database connectivity problems or database running out of space.
     – Discovery data received is not valid.

The following details should help to further diagnose:

DiscoveryId: 55f32a19-b0db-3a12-83d8-414183ff13b4
HealthServiceId: e1259bd6-c694-7eea-187c-809dd305f829
Microsoft.EnterpriseManagement.Common.DiscoveryDataInvalidRelationshipSourceException,The relationship source specified in the discovery data item is not valid.
Relationship source ID: 766eca98-7454-9141-0b3d-745545358e82
Rule ID: 55f32a19-b0db-3a12-83d8-414183ff13b4
<?xml version=”1.0″ encoding=”utf-16″?><RelationshipInstance TypeId=”{b22d9165-494b-5fa8-57af-f2c608e103bc}” SourceTypeId=”{ea99500d-8d52-fc52-b5a5-10dcd1e9d2bd}” TargetTypeId=”{3b6a3bec-2355-8c6a-4d8d-fc9ec20d4282}”><Settings /><SourceRole><Settings><Setting><Name>5c324096-d928-76db-e9e7-e629dcc261b1</Name><Value></Value></Setting></Settings></SourceRole><TargetRole><Settings><Setting><Name>5c324096-d928-76db-e9e7-e629dcc261b1</Name><Value></Value></Setting><Setting><Name>c631cdcb-89b0-7ac0-840c-8301b557249c</Name><Value></Value></Setting><Setting><Name>df750e2d-8323-25d2-0613-051bbc8bafaf</Name><Value>Operations Manager Database</Value></Setting></Settings></TargetRole></RelationshipInstance>.

Simply deploy an agent to the SQL Server(s) hosting the OperationsManager and OperationsManager databases.  Then wait 24 hours, or restart the Microsoft Monitoring Agent (HealthService) on the missing management server.






So in summary – if you have multiple management groups deployed, and want to use these views, you will have to ensure that the SQL servers hosting the SCOM DB’s have an agent that is connected to the SCOM Management group that it supports.


  1. Kester Stoner

    Hi Kevin,

    I have SCOM 1807 and both SQL servers have an agent installed, however both RMS and Database servers were never discovered in this view. Anything else to look into ?


    • Kevin Holman

      Restart the health service on the RMSe. Then, after 10 minutes or so, look for a 10801 event. This is a discovery rejection. See if that gives you any clues.

      • Kester Stoner


        The below alert was prompted, (I have pasted parts of it below)

        Discovery data couldn’t be inserted to the database.
        Microsoft.EnterpriseManagement.Common.DiscoveryDataInvalidRelationshipSourceException,The relationship source specified in the discovery data item is not valid.
        Rule name : Discovery of Operations Manager deployment

        • Kevin Holman

          on the management server, in the registry, at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup\DatabaseServerName string value – does what is in here match the FQDN of a Windows Computer object in your environment?

          • Kester Stoner

            It has the SQL Always on listener (not in FQDN) on where the omdb is hosted followed by the port.

  2. Simon

    Hello do you have any update on this error. It driving me crazy. I find absolute no solution for this.
    Thanks in advance

  3. Howard Brown

    We’re seeing a different issue here, in SCOM 2019. I figure I will post here first, to see if it’s a known thing.

    We have enabled TLS 1.2 Enforcement. We see a similar issue as that which is manifested above, but with a twist:

    Topology10.0Discovery.vbs : Unable to connect to the database with the specified configuration string. Please make sure that your connection string is valid and that your credentials are authorized to access the database. Cause: [DBNETLIB][ConnectionOpen (SECCreateCredentials()).]SSL Security error.

    [DBNETLIB][ConnectionOpen (SECCreateCredentials()).]SSL Security error seems to be the result of once TLS 1.2 is enabled, the connection string should be changed – but there doesn’t seem to be anywhere to do this in an override or anything.

  4. Howard Brown

    Need to add to this. It looks like my comment above is actually a problem with the AD CS MP, and not the initial discovery, but that’s for another post…

    This issue seems to be related to the following code in the discovery:

    $DBInfo = Get-ItemProperty “HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup\” | Select-Object DatabaseServerName, DataWarehouseDBServerName, DatabaseName, DataWarehouseDBName
    Write-Host $DBInfo
    $computerName = [System.Net.Dns]::GetHostEntry($DBInfo.DataWarehouseDBServerName.Split(‘\’)[0]).HostName
    Write-Host $computerName

    The money shot is here: $computerName = [System.Net.Dns]::GetHostEntry($DBInfo.DataWarehouseDBServerName.Split(‘\’)[0]).HostName

    It seems to expect an instance name. It tries to split on the ‘\’ but if there is no instance name, that is not present. I don’t see any compensating code for that. If you install to the default instance on a server, the registry keys are ,. If I modify the sample code above to split on the comma instead of the port, it works.

    Definitely a bug in this MP.

    • Howard Brown

      For some reason this didn’t accept it when I used carets to enclose a sample entry.

      It should read:

      “…default instance on a server, the registry keys are SERVERNAME.PORT…”

    • Howard Brown

      I just tested a workaround by modifying the registry keys to SERVERNAME\MSSQLSERVER,1433 and this fixes the issue immediately. I’m not sure if this could cause any other fallout elsewhere in the system, but it seems to work so far in our test environment.

      • Cesar

        Hi Howard
        I have been following up on the issue and I have a question; in all Management Servers you have to record in the registry
        HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup\
        the keys of DatabaseServerName, DataWarehouseDBServerName, DatabaseName, DataWarehouseDBName?

  5. Ed

    Hi, I’ve set SPN entries for the SQL cluster:

    setspn -s MSSQLSvc/SQL_AGListener Domain\SQLServiceAccount
    setspn -s MSSQLSvc/SQL_AGListener.domain Domain\SQLServiceAccount

    That solved this issue for me.

  6. Md Ali

    Hello kevin,

    I have configured the Ops DB in SQL AON, do i need to give any permission on secondary DB cos when i fail over to secondary DB, Additional MS instillation failed with permission issue. not sure what all permissions need to be given.
    When i failed back to primary the instillation went through.

    • Kevin Holman

      You will need to create the logins on the secondary if they are not created automatically…. I am not sure why they would not be.

  7. Gabriele

    Hello Kevin,
    we had a very similar issue on customer’s environmet, but in our case the DBs were already discovered.
    The root cause was an installer called “IBM Hardware Management Pack for Microsoft System Center Operations Manager” installed on the root management server.
    This caused the discovery Microsoft.SystemCenter.OM.Products.Discovery to throw an error with eventid 10801 on the Management server.
    In the error the cause was a duplicate key on property PatchInstalled.
    The reason behind I think it is that the discovery checks installed products with
    $products = Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName, DisplayVersion, InstallDate, PSChildName | Where-Object {$_.DisplayName -like ‘*Operations Manager*’ -or $_.DisplayName -eq ‘Microsoft Monitoring Agent’}
    the property PatchInstalled is based on
    if($patchListString -ne $null -and $patchListString -ne “”)
    $patchListString = $patchListString.Substring($patchListString.IndexOf(“Manager”) + 8)
    Hope this helps others with similar issues

Leave a Reply

Your email address will not be published.