I recently ran across an issue where notification subscriptions were getting disabled every 30 minutes. The strange thing was that only about half of the subscriptions were being disabled and they were the same subscriptions every time. I tried re-enabling them with both Powershell as well as the GUI and had the same result, the subscriptions kept being disabled. After digging through event logs I found this warning:
Log Name: Operations Manager Source: Health Service Modules Event ID: 11452 Task Category: None Level: Warning
Validate alert subscription data source module encountered an alert subscription data source with configuration that has gone out of scope. Disabling the alert subscription data source module.
Alert subscription name: Subscriptionaca6a276_e5a9_446b_9751_0ea539168e41
One or more workflows were affected by this. Workflow name: Microsoft.SystemCenter.ValidateAlertSubscription
The problem turned out to be that I recently cleaned up the SCOM Admins user group and one of the users removed from the group had created half of the subscriptions. By putting the user back in the SCOM Admins group and re-enabling the subscriptions the problem was solved but we really didn’t want this user in the SCOM Admins group as he had moved on to a different role.
So why was this happening? When a subscription is created the user who created the subscriptions SID is associated with that subscription. There is a workflow that checks every half hour for SIDs no longer valid. They could be invalid because their accounts access that had been removed, or possibly because the account has been disabled or deleted.
To fix it long term I first exported the “Microsoft.SystemCenter.Notifications.Internal” management pack. This management pack is unsealed and contains all subscriptions.
Inside the management pack I searched for one of the subscriptions that were being disabled and one that was wasn’t. I then replaced the SID of the bad subscription with the SID of the good subscription.
After replacing the SIDs I re-imported the management pack and re-enabled all subscriptions and the problem was solved for good.
Here is an example of one of the SIDs I had to replace.
</Criteria> <ExpirationStartTime>10/11/2008 21:38:45</ExpirationStartTime> <PollingIntervalMinutes>1</PollingIntervalMinutes> <UserSid>S-1-5-21-3273141924-712819414-2074229892-500</UserSid> <LanguageCode>ENU</LanguageCode> <ExcludeNonNullConnectorIds>false</ExcludeNonNullConnectorIds> <RuleId>$MPElement$</RuleId>
Hope this helps,
Satish Phatge | System Center Support Engineer
Great Job Satish that really helped
Great article, helps out a lot... just curious if that was the intended design by MS, to have a UserSID tied to a notifcation subscription...seems to break some significant things if the user in question leaves the company and their account is deleted...almost like setting a service to run as a user account with an expiring password...
FYI, I had this happen when our scom admin left. We just logged into the server as the service account and recreated the subcriptions. Seemed easier to us.
This seems to be a pretty big miss for the SCOM dev team. Is there a fix on the way?
We had this same issue and were able to fix it by making a small change to the subscription (modified the name field) and saving it. Obviously this isn't a real fix since we just changed which SID is attached to the subscription and we'll have the same issue if that user leaves the company.