http://blogs.technet.com/b/kevinholman/archive/2008/11/11/cleaning-up-the-default-mp.aspx

http://blogs.technet.com/b/kevinholman/archive/2011/02/15/renaming-your-default-management-pack.aspx

http://blogs.technet.com/b/jonathanalmquist/archive/2008/11/12/monitor-default-management-pack.aspx

Create a new Empty Management Pack (e.g. called XEventsInYMinutes)

Assign a Display Name of Alert on X Events In Y Minutes

Go to Type Library and create a new composite data source

Give the composite data source a unique identifier e.g. XEventsInYMinutes.ConsolidatedEvents

Enter a Display Name e.g X Events In Y Minutes Consolidated Events

Go to the Configuration Schema tab and under Simple Configuration Schema, click Add

Add IntervalInSeconds and EventCount (note – these are case sensitive in the authoring console!) and then make sure you change the type to Integer as follows

Go to the Overridable Parameters tab and add in the IntervalInSeconds and EventCount parameters and make sure you set each as Integer

On the Member modules tab, Add a Data Source of type Microsoft.Windows.EventProvider and give it a Module ID of Event

Click Configure

Choose windows event log e.g. Application

Choose Expression

You should then see the following

For Computer Name – note this from the help files:

The ComputerName parameter is most commonly passed to the module by using the $Target notation, although it can be specified as any string. This module attempts to connect either to the local computer’s event log or to a remove event log, depending on the configuration passed.

For a workflow that is targeted at Windows Computer, the ComputerName element is specified as shown in the following code:

$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$

If the target is a class hosted by computer hosting, references are added as required. For example:

$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$

The ComputerName parameter is optional, but as a best practice, it should be specified.

I am going to target the rule at Microsoft.Windows.Computer so best practice means I should enter the Computer Name as

$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$

Click OK to get back to

The Add a new Condition Detection module of type System.ConsolidatorCondition  with a Module ID of EventConsolidation

Then click Configure

And then click Configure again and change the Consolidation Settings. Each of these settings are discussed here

The click on the Edit button in the bottom right of the above screen shot to set the event properties that have to identical for events to be considered identical

Then click OK and OK again to get the following.

We want to expose the IntervalInSeconds and EventCount as overridable so change the fields to match the following

$Config/IntervalInSeconds$

$Config/EventCount$

Then click OK to get back to the following

Change the Next Module setting so that the Event module goes to the Event Consolidation Module and the Event Consolidation Module is set to module output as follows

Check data type

Then click OK and go to Health Model, Rules, New Custom Rule

Choose unique identifier e.g. XEventsInYMinutes.Event123

Set the Display Name and Target

On the modules tab, add the XEventsInYMinutes.ConsolidatedEvents module and assign a Module ID e.g. Event123XEventsInYMinutes

Configure the default settings for TimeIntervalInMinutes and EventCount

On the actions tab we need to generate an alert so add the module System.Health.GenerateAlert and provide a module ID e.g. Event123Alert

Then on the Action window, click Edit and then Configure to get the following

We can set an alert name, description, priority, severity, alert suppression, and any custom properties that we want to set.

http://support.microsoft.com/kb/2590414

I’ll continue to update this with SCOM 2007 specific information …

1) There is no support for windows 2000 agents.

2) Management Servers must be Windows 2008 R2 or later

3) SQL Server needs to be SQL 2008 SP1 or SQL 2008 R2

4) All SCOm 2007 R2 agents must have cumulative update 4 or later applied

The full list is here – http://technet.microsoft.com/en-us/library/hh205990.aspx

webconsole install error

The fix is to re-register IIS using:

- %Windir%\Microsoft.Net\Framework64\v4.0.30319\aspnet_regiis.exe -r

- additionally, you might find you need to go into the IIS Management Console and enable ISAPI and CGI restrictions of .Net4

- SQL needs Full Text Search Service … this is becoming a standard requirement in most System Center products to leverage advanced searching capabilities.

- Reporting is no longer a seperate install but is part of the initial installation routine. Therefore, to install SCOM, you MUST install Reporting at the same time.

- Operations Manager Administrators Group. You no longer get asked for the Operations Manager Administrators Group. Instead setup automatically assigns the Administrators group on the local computer to the Operations Manager Administrators role. You must be logged on with an account that has local Administrator rights to run Setup on the first management server that you install; this ensures that you can open the Operations console after Setup is completed. Best practice is to create a global OpsMgr Admins Security Group and a local OpsMgr Admins Security Group on each Management Server. Then add users who will have this role to the global group, and then add this global group to the local group. Then in the OpsMgr console, re-assign the OpsMgr Admins role to the local windows OpsMgr Admins security group.

Operations Manager Admin Role

- There isn’t a Root Management Server anymore. Well, that might not be 100% true depending on how pendantic you want to be but I’ll go into that in more detail in another article. In SCOM 2012, all Management Servers are created almost equal, similar to the move from NT4 domains to Windows 2000 Forests. But as with that move, we had a PDC emulator. In SCOM 2012 we have an RMS emulator that enables legacy management packs which rely on the RMS to continue to function in SCOM 2012. This role can be moved \ managed using PowerShell – there are new PowerShell cmdlets for this:
- set-scomrmsemulator
- get-scomrmsemulator

RMS Emulator Role

- Resource Pools. We can now create a resource pool for Network Devices and non-Windows Servers for failover.

Note that windows agents do not use resource pools for failover which continues to function exactly the same as in SCOM 2007.

Also that Resource Pools only apply to the “Health Service” functionality at present and not to SDK functionality. So you can’t use Resource Pools for OpsMgr connectors or for Reporting failover.

More also on Resource Pools in a later blog.