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
Description:
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
Instance:
<?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>scsql1.opsmgr.net</Value></Setting></Settings></SourceRole><TargetRole><Settings><Setting><Name>5c324096-d928-76db-e9e7-e629dcc261b1</Name><Value>scsql1.opsmgr.net</Value></Setting><Setting><Name>c631cdcb-89b0-7ac0-840c-8301b557249c</Name><Value>scsql1.opsmgr.net</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.
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 ?
Thanks
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.
Kevin,
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
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?
It has the SQL Always on listener (not in FQDN) on where the omdb is hosted followed by the port.
I have the same issue as Kester and I also have the SQL Always on listener in the registry
Hi Guy’s any update on this failing discovery when using SQL Listener and port ??
We have raised a BUG for this which is yet to be fixed. I am not sure about the timeline.
Please keep us updated.
Hello do you have any update on this error. It driving me crazy. I find absolute no solution for this.
Thanks in advance
“suddenly” we have this problem on a SCOM 1807. Also pointing to the SQL Listener. any news?
Thanks!
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.
Such alert is because of the TLS1.2 Enforcement, and the respective MP does not support TLS1.2
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
W
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.
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…”
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.
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?
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.
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.
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.
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
Interesting!
We are going to do In-place upgrade from SCOM 2016 to 2019. any help will be appreciate.
I just published this: https://kevinholman.com/2021/01/13/upgrade-from-scom-2016-to-scom-2019-checklist/
Hello All,
Good day !!
All of sudden I have got the below error in SCOM 2019.
The partitioning and grooming processes for the operational database (OperationsManager) on the server scom_stage have either not been run recently or have been failing. At the time this alert was raised, the partitioning and grooming process had not completed for days.
I have restart MMA service in management server no luck.
I have the 10801 event id triggered and below is the same for your reference.
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: 711b2e47-8459-d6bb-5c83-034c96f12671
HealthServiceId: 5797e176-7ca0-772c-bf3d-2b81847e4878
Could some please help me ?
Thanks,
Adam
Hi,
I am facing issue in Gateway section. I have applied the UR2 on scom 2022 gateways but I am unable to see that in the “Update installed” section. Although i can see for few gateways but not all.
But When i am login to the gateways, there its showing that update installed
When you log in to a gateway – it is showing update installed? Where are you looking to ascertain this status?
Yes, when i logged in to gateway server, its showing that update installed.
I am looking the status in SCOM Console-> Administration->Operations manager products->Gateway Servers
I am asking – HOW are you validating it, when logging on to a Gateway server? WHERE is it “showing” that update installed?
I logged in to gateway servers and checked the below:-
1. I checked the event viewer , windows logs -> Application->event id 1022(Product: System Center Operations Manager Gateway – Update ‘System Center 2022 Operations Manager Update Rollup 2 Patch’ installed successfully)
2. Also i checked in , control panel -> program and feautures-> System center operations manager gateway version changes to 10.22.10118.0