Today I investigated a case where SCOM had an alert with the following name and contents:
Data Warehouse configuration synchronization process failed to write data
Data Warehouse configuration synchronization process failed to write data to the Data Warehouse database. Kan geen gegevens in de datawarehouse opslaan.
Uitzondering SqlException: Sql execution failed. Error 2627, Level 14, State 1, Procedure ManagementPackInstall, Line 2879, Message: Violation of UNIQUE KEY constraint ‘UN_ManagementGroupManagementPackVersion_ManagementGroupRowIdManagementPackVersionRowId’. Cannot insert duplicate key in object ‘dbo.ManagementGroupManagementPackVersion’. The duplicate key value is (1, 2020, Jun 18 2014 3:15PM).
There are event log entries in the Operations Manager event log with ID 31552 with the same kind of contents.
Now I want to give a big shout out to the guys in the SCOM Support team, who are writing Support Tip entries on their blog for common issues and solutions. I found their Support Tip quickly and the contents is very clear on how it probably happened and what not to do next time and how to solve the issue at hand.
Support Tip: Data Warehouse synchronization failures following restore of the OperationsManager DB
And yes in my case we did decide during some problems earlier not to restore the DW database because it was huge and so on :> And yes that probably was the cause. Was during an upgrade of SCOM and the upgrade wizard failed and killed the management server and touched the operational database so decideed to restore the OpsDb because well they wouldn’t have touched the datawarehouse db yet right? Wrong, they do 🙄 So lesson learned for sure, when restoring one database just restore the other one to the same point in time.
So ran the SQL script provided and pasted in the correct key value pair into the script and ran it. Sure enough it was the Notifications Internal Library. Exported the pack, increased the version number. Imported the pack. And few minutes later the 31554 event popped up in the event log.
Thanks again to the SCOM Engineering Blog and the escalation engineers behind it for publishing these kind of support tips.
Bob Cornelissen