SCOM 2007: How to backup your environment
The funny thing is most of the admins think of backups just after they had a major crash and there were no backups available.
Most of the admin’s think backups are a hassle and they take some but loose interest in the long term. When disaster strikes they miss a vital piece to restore their environment, have an outdated backup or even worse… no backup at all.
In this series of blogs I’ll go over the different aspects of backing up your SCOM2007 environment to make sure that when Murphy is choosing you, you’re prepared…
One of my favorite cartoons to illustrate backups…
So let’s get started and get you prepared when disaster strikes.
Which components do you need for a successful restore of your environment:
This blog post is part of a series how to backup your SCOM environment.
- How to backup your SCOM environment
- How to backup your SCOM dbases
- How to backup your SCOM encryption key
- How to backup your SCOM IIS settings
- How to backup your unsealed management packs
- How to Document your SCOM installation
- How to Backup your Reporting
This series of blogs will be divided in the categories shown above and will be linked back to this post.
SCOM: Target a rule or monitor to a computer group
Today I had to explain to a customer how you need to target a rule or monitor to a specific computer group.
This is actually not a very intuitive process and if you are used to work with MOM2005 the process is different and can have big implications in the behavior of the rule / monitor you’ve created.
This is the only correct way if you want to target a rule or monitor to a select group of server.
Create your rule:
Open your console and go to the tab Authoring and navigate to the Rules. Right Click > Create a new rule…
In the “Create Rule Wizard” select the desired rule. In this example I’m going to create an Event Based rule in the NT Event Log (Alert).
CAUTION: make sure to change the destination management pack to a custom management pack and NOT the default management pack.
Give the rule name and click the “Select” button just behind Rule Target:
Here you need to target a class of which you are certain all the servers you want to target are part of. In this case I choose “Windows Server” but if you are for example convinced they are all SQL server you can target the “SQL server” class.
If you have selected the appropriate class hit ok but not next on the page.
Make sure the “Rule is enabled” tick box is off!
Now choose the event log where to target your rule. In our case it’s the Application log
The filter. In this example I’m searching for an Event ID 150 created by the source “Eventcreate”
Next thing is to specify the information that will be generated by the alert:
Now click create.
Create your Group
So far the rule has been created but is disabled. The next thing we need to do is create our group which contains the specific set of servers which need to be targeted. In the Authoring pane choose “Groups” > Right click > choose “Create a new Group…”
Choose a name for the group and again CHANGE the default management pack as a target.
NOTE: Choose the same management pack where you want to create your override in later on. It’s not possible to reference another unsealed group from a unsealed group so either use the same group for both your override and group or seal the management pack where your group is created in.
The next option is to specify the explicit group members.
There are actually 2 approaches to populating the group (which can be combined).
The first one is that you specify the explicit members of the group. They will be always in the group included no matter what criteria you specify later on. The disadvantage you have is if you install a new server which need to be targeted you have to manually include it here.
The second approach to populate your group is Dynamic Inclusion rules. These rules have a set of conditions to add servers. These can be for example all servers which are SQL servers based on the class or all servers which name starts with “SERVER0”.
You can also specify servers to be included in this group which reside in another group.
Specifically deny Objects from being included in the group:
When you are confident you have included all the servers in the groups click create.
Create your override for the rule
At this point go back to the Authoring pane > Rules > search for your new created rule.
In this example you can see our newly created rule in disabled state:
Right click the rule and choose Overrides > Override the Rule > For a Group…
Now choose the group we created earlier on:
In the override parameter locate the “Enabled” parameter and tick the box in the “Override” column. In the Override Value choose “True” , click Apply and OK.
At this point the rule we have created is targeted only to the servers you’ve added to the computer group and not enabled on all the other servers. This is in face a total different approach from the way of working in MOM2005.
This is because the computer groups (The class of objects that are computer groups) only exist on the RMS. If you target a rule directly to a computer group it will try to collect info from the RMS instead of the computers you have intended.
SCOM 2007: Scheduled reports failing
Recently I got a mail of a user stating he’s not receiving his reports anymore via mail. They were created way back and normally these reports are in my category “set it and forget it”…
When I checked the schedule reports pane instantly I noticed that all the reports are showing an error as shown below:
“The Subscription Contains parameter values that are not valid” error message is in the status field.
During my search on the web the most common solution was to recreate the report which I did for one but because these are like 20 reports it will be a lot of work to recreate them all and risk the fact that they break again without knowing when and why.
So the next step I tried in my troubleshooting is to see whether I could fill in the missing parameters in the report which resides in a custom management pack holding all these special reports.
When I tried to run the report I noticed the following: Data Aggregation and Histogram are greyed out and it’s impossible to change them
When I tried to run the report the following error message came up:
So there is an issue with the ‘Data Aggregation’ parameter. No possibility to troubleshoot any further in the SCOM environment so we’ll have to dig deeper and turn our attention to the underlying SQL Reporting Services (SRS) install.
Connect to the SRS server and open up the SQL management studio.
Note: If you’re not sure where your SRS install resides navigate to SCOM console > administration > Reporting. The Reporting Server URL is filled in there so you can retrieve the server name / alias here.
Make sure you select “Reporting Services” in the Server Type and select the server name you’ve retrieved from your console.
Navigate to Home > “Your management pack” > reports > Subscriptions.
In this example we’re troubleshooting the “PROD3_IOReport”.
Right click and choose view report.
The web browser opens and will generate the report. However in this case the following error shows up:
Didn’t we have an issue with the “DataAggregation”? The error above shows we have an issue with our “ManagementGroupId”.
Let’s take a look at the report properties to find out.
Right click the report and choose Properties.
The familiar SQL properties page pops up.
Behind the “ManagementGroupID” (in the above print screen the sixth item) it’s indicated that there are multiple… We only have one management group so why should there be multiple?
If you open the value you get a drop down box with the 2 id’s listed
So which one is the correct one…
I opened a newly created report in the same management pack (which I recreated to solve the issue with the first report) and there there’s only one ID listed:
This report is working with all the parameters so this ID is the correct ID for our management group.
Next step is deleting the ”wrong ID” in my report parameters and click ok:
Now we go back to our SCOM console and check the report once more.
Open the report and now it’s possible to check the Data Aggregation and Histogram again.
After clicking “run” the report is generated successfully.
So all we need to do is change the parameters in our scheduled report.
Navigate back to the scheduled reports list, right click the report and choose edit.
Check the parameters and fill in the correct Data Aggregation / Histogram settings (and check the other settings as well while you’re at it).
Click finish and check back at the scheduled report view.
The report has gone from error to “ready” and is able to process when the scheduled time is there…
In this particular case it apparently was an issue when there were agents temporarily multi homed to a test environment and this test environment was deleted afterwards.
Although this was a mistake on our side I posted this blog post to illustrate that the error message in SCOM was not the cause of the real problem which was hidden in the SRS installation. This threw me off when troubleshooting the issue because I was focusing on the wrong error and has cost me a lot of valuable troubleshooting time.
I’ve posted my experience to save you some time in troubleshooting the issue 
SCOM 2007: Renaming Default Management Pack display name
One of the most common frustration I face (and I’m sure I’m not alone) is the fact that from time to time there are things saved in the default management pack.
It’s so easy to forget to change the destination management pack while creating rules / monitors and just click next. We all know once you’ve created the rule it’s not possible to change the management pack anymore…
It’s best practice not to write anything to your default management pack but it’s always selected as default…
Yet you have 2 options:
- Delete the rule and start all over again
- live with the rule residing in your default management pack which is not a good idea in case you face issues with dependencies…
To avoid this common mistake / lack of attention I make a habit of renaming my default management pack display name to something eye catching so I see it before clicking next while creating a rule / monitor.
Open the SCOM console and navigate to Administration > Management packs and right click your Default Management Pack
Choose Properties in the menu:
Change the Name of your Default Management Pack. In my case I always put in capital “DO NOT WRITE TO” before the name.
And click apply.
This changes in fact the display name of your management pack but not the management pack ID. It’s not possible to change the ID (it’s greyed out) so your management pack will still hold all the dependencies…
At this point the default management pack is still the default when creating a rule but there’s a nice message in capital just above the next button.
This small modification saved me already a lot of (additional) headache to remind me to change to a different management pack when creating a rule / monitor…