Fix maintenance Schedule replication on HA SQL for SCOM
With SCOM Always On sql architecture. Whenever a maintenance schedule is created it is not replicated to secondary DB. This requires manual effort with DB permissions to replicate the SQL agent job. The schedule is not effective until its replicated which eliminates the self service feature for end users. Not every one has DB permissions.
This has been fixed with SCOM 2019.
I am getting below event when ever I try to view Maintenance Schedule Info List and I have try everything from SQL side with no use .abyfeedback
An exception was thrown while processing GetMaintenanceScheduleInfoList for session ID uuid:b3e5f264-db85-43c0-b81e-0601fc00b4ea;id=2.
Exception message: The creator of this fault did not specify a Reason.
Full Exception: System.ServiceModel.FaultException`1[Microsoft.EnterpriseManagement.Common.UnknownDatabaseException]: The creator of this fault did not specify a Reason. (Fault Detail is equal to The EXECUTE permission was denied on the object 'sp_help_jobactivity', database 'msdb', schema 'dbo'.
The data access service account might not have the required permissions).
Is this fixed in version 1807?
Rajeev Bansal commented
After UR6 update, when a new maintenance schedule is created below issues are observed:
1) The "create maintenance schedule" template freezes on clicking "Finish" in operation console
2) Duplicate entries of every new schedule with different schedule IDs are recurrently created in both database and Console.Ex: 3 new schedules were created and ~250 duplicate entries are continuously updated in DB,console and stopped only on system center services restart on management server
This appears to be a major defect with maintenance schedule feature after upgrade to UR6.
Requesting to verify this issue and share your comments.
Rajeev Bansal commented
This issue in fixed in SCOM 2016 UR6 as per https://support.microsoft.com/en-in/help/4459897/update-rollup-6-for-system-center-2016-operations-manager
Fixed: Scheduled Maintenance Mode doesn't work in an availability group that uses SQL Always-On configuration. In case of a failover to a secondary node, the Maintenance Mode Schedules that are created on the primary node don't run. This has now been fixed.
This issue is causing a lot of false alerts in our environment and needs someone with DBA privileges at all time to replicate the jobs on the backend. The issue is not only with new schedules but also with modification of existing schedules.