Subscriptions getting automatically disabled - Event ID 11452 logged

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:

Mass-Mailer PowerShell Script

Today a colleague asked me to write a script to send out a email to a large group of people but have the phrase “Dear <person’s name”>” in the beginning of email body.

I quickly wrote the script. Here are the steps you need to take before executing it:

Morning Check SCOM Alerts – Automated using PowerShell Script

One of my clients has a centralised SCOM management group for different segments of the business. The support team's hours are 6 am - 6 pm Monday - Friday. They are also required to perform a morning check Monday – Friday and manually log service desk calls based on the SCOM alerts generated after hours.

I wanted to automate the process (at least to generate a list of alerts that were raised since 6:00 pm previous night). We firstly had a look at the Alerts report from SCOM Generic Reports library but it did not meet our requirements as it does not include the alert resolution state in the report.

Using SCOM as a Basic Configuration Audit System – Part 6 Final

Eventually we get to the end of the story, now we miss the most important, but easiest of all components: the compliance checking monitor. As a design choice I targeted the unit monitor to the generic windows operating system class, I set it to disable and used a bunch of overrides to set the correct properties for the different baselines. This way I just have one single monitor that applies to all windows operating system and it is implemented via overrides for the supported baselines. If you need to add a baseline just add a new override for such an operating system (obviously as far as the generic checks we implemented are valid for that operating system, you should recall that we decided to use vbscript to remain as generic as possible).

The monitor itself is just an instantiation of our unit monitor type where we set the alerting part using our handy “Message” property . The script will set the message property to a list of missing fixes or operating system version mismatch or wsh version mismatch. I know this breaks localization in terms of alert description but as long as the alert parameters substitution is implemented the way it is, I can’t see a better way to do this.

Using SCOM as a Basic Configuration Audit System – Part 5

In my first post I defined the following baselines to be checked for compliance:

• Windows Server 2008
• Windows Server 2008 R2 RTM
• Windows Server 2008 R2 with Service Pack 1

While the first two are already discovered by standard management packs, the latter is missing, so we’re going to define a new class and discover it. There are plenty of choices here, but I chose to follow the pattern established by the Windows Server 2008 Management Pack in which the R2 operating system is derived from the Windows 2008 operating system.

This will be the new hierarchy:

Using SCOM as a Basic Configuration Audit System – Part 4

We are almost done with the types; we still need to define the HealthService to operating system relationship discovery data source and the monitor type for compliance checking.

The discovery data source is based on a handy condition detection module I found in the documentation: System.Discovery.RelationshipSnapshotDataMapper. In reality the documentation is not so clear since it misses an example that fits our situation, but with some management pack digging it’s not so difficult to end up with the correct usage. What we’re going to do is to combine a scheduler with the condition detection module to compose a data source we can use in discovery. The data source type just wraps the scheduler and the data mapper together and exposes the needed parameters, when we’ll define the discovery itself we’re just going to combine the key properties of both classes to obtain the relationship.

Using SCOM as a Basic Configuration Audit System – Part 3

Now that we have the core data provider in place we need to formalize the design defining the proper management pack constructs. In this post we will first define the loose relationship between the Operating System and the Health Service in such a way we can add a dependency monitor to the health service to project the compliance status, secondly we will define the data source embedding the script and the unit monitor type for compliance checking.

To define a loose relationship we’re going to define simple System.Reference relationship under the TypeDefinitions section. The source for the relationship is the HealthService and the target is the generic Microsoft.Windows.OperatingSystem class, I chose to define the relationship as “Internal” since I don’t think I will use it outside this Management Pack, but you define it as “Public” if you think this relationship is useful in general.

Using SCOM as a Basic Configuration Audit System – Part 2

The first step for our compliance management pack is to develop the core checking script. This is not to say that this must be the approach for every MP, probably a better start would be the health model, nevertheless I want to immediately check if there’s any show stopper in the core stuff so I will address the health model in the following post.

To build the script we need to keep in mind that:

• The output will be used to assess compliance on one side and to return data that can be used in reporting and in alerts to show what’s going on.
• The script must be generic enough to work across different OS versions, this is why we’re using vbscript

Using SCOM as a Basic Configuration Audit System – Part 1

I’m going to start a series of articles, I don’t know how many yet, on how to use your OpsMgr infrastructure to check for proper configuration of the managed systems. Then number of posts will be based on how much I can write in one hour. 

The basic need started with the growing number of patches needed to guarantee a complete and hassle free monitoring experience “Things to make and do for agent health”.