New Home!

Dear followers, this blog moved to a new an revamped home. Please see me at http://fehse.ca

 

Thank you!

 

Jose

Fixing the SCOM Operating System Reports for good

Fixing the SCOM Operating System Reports for good

As stated by Marnix Wolf, here http://thoughtsonopsmgr.blogspot.ca/2012/11/base-os-mp-version-6069890-imported-and.html , after the 6.0.6989.0 OS Core MP update, these two reports became broken:

Marnix suggests creating a new rule, which probably works. My suggestion, after some research on SSRS and a lot of digging in the XML files, seems to fix the problem for good.

In the end, it is pretty simple. Here we go:

1.Download the Report file to a local folder:

1.1 Open the Reporting Services page and navigate to the folder:

1.2 Download the file to a local folder:

2.Edit the file in a good text Editor, namely, Notepad++:

1. Look for the word “Processor” inside the file. In some of them, you’ll need to replace “Processor” by “Processor Information”. Be careful, not all occurrences should be replaced, only the ones that refer the ObjectName itself.
2. Line 3:
3. Line 13:
4. Line 13, Col 13580:
5. Line 13, Col 20705:
6. Line 13, Col: 154693:
7. Line 13, Col 154920:Lines 15 and 21:
1. Save and upload the file back to SSRS:

Voi la!

 

This is all manageable from the Report Builder or SQL report designer, but there’s nothing like a good low level text file editing in a cold rainy day!

You can repeat the process for the other report. It is similar, but not exactly the same places. Look for the work Processor when it is used alone, not in variables, between dots,etc.

Have fun!

Issues after migrating SCOM 2012 Database

As this post is being written, the official MS procedure to migrate a SCOM 2012 operational Database is incomplete. See the official procedure here: http://technet.microsoft.com/en-us/library/hh278848.aspx
There are two extra steps that you have to do. One I’ve documented in a previous post:

You need to change the values in the key below. Otherwise, you’ll have issues and trying to apply SP1, for example. It tries to talk to you old server and can’t figure out the upgrade scenario.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup\DatabaseServerName
This used to be documented in the original 2007 database move guide. Don’t know why it was removed.

On step seven, Microsoft mentions one occurrence of the server name under the Cmdb tag:

Actually, the server name also appears in the ConfigStore tag and if you don’t change it, you’ll keep getting errors in the login with invalid login attempts against the old server.

Update: there is actually another step you should do avoid the funky (useless)SQL messages you see when something SQL related happens. Please see the article below from Marnix Wolf:

http://thoughtsonopsmgr.blogspot.ca/2012_10_01_archive.html

Hope this helps!

Can’t upgrade SCOM 2012 to SP1 after database has been migrated

Can’t upgrade SCOM 2012 to SP1 after database has been migrated

According to the official procedure documented here: http://technet.microsoft.com/en-us/library/hh278848.aspx , you have to change one registry key to point to the new database server:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\Database
However, if you try to run an Upgrade to SP1, you’ll get this message:
This happens because the keys below also need to be changed:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup\DatabaseServerName
This used to be documented in the original 2007 database move guide. Don’t know why it was removed:
http://technet.microsoft.com/en-us/library/cc540384.aspx
Hope it helps!

Creating rules to monitor Security Logs with SCOM 2012 (SP1)

The requirement

Monitor certain Security events, like account locked, account unlocked, etc in the security event log of the Domain controllers. Generate an Alert when any of the events happened and be able to generate a report on the occurrences.

The Challenges

• Event IDs – which ones are the ones we are looking for
• Rules – Create rules for all events and show appropriate information in the description
• Reports – Show Summarized views of the events

Challenges Accepted!

Event IDs

    Well, that part was not that hard. Having gurus like Kevin Holman really makes life easier. You can find a very good list of the events here:
http://blogs.technet.com/b/kevinholman/archive/2011/08/05/a-list-of-all-possible-security-events-in-the-windows-security-event-log.aspx
    I decided to start with:
Note that 2003, 2008 and 2008 R2 will have different IDs for the same event, so, double the work…
Now, with that, I think I can start creating the rules.

Rules
    To simplify things, I’m using the 2007 authoring console. I’ve created a new Empty Management pack and called it Security (ok, not very creative…but it is what it is!). No fancy targets here, since I want to target all domain controllers. Makes it easy to start. Let’s start with the Alert rule:




Repeat the process for the 4767 event: A User account was unlocked
Now, the rules above will generate alerts, but won’t store any data in the databases. For the Event collection rules, let’s proceed as follows:
Create a second Event-Collection rule for the Account unlocked event (4767).

You should have something similar in the end:
Import the rules in to the SCOM server. I kept this one unsealed for now, but sealing and versioning is the right way to go:
When you do it the first time, it should be green. It is showing the blue ! because I already have it there.

Now, let’s test the rules. In order to test it, I have used an existing user, called bubblehead. I tried logging in with the wrong password until the account got locked out. To be 100% sure it worked, I looked for the events on the security log of the DC:
Meanwhile, in the SCOM Console…
Ok, now, how do I know whether the events are being collected. Fear not, here it goes:
In the My Workspace area:




There they are!
The last step is reporting. Prepare to enter the magic land of report builder. It is going to be Legen…


Reporting on the Events

The basic Event Analysis template reports don’t seem to fit my summary needs. I have tried both and couldn’t get the results I wanted.
I wanted something like a simple table, with the Event ID, what kind of event that was and how many times it happened. Selecting the time range will be needed as well.
So, here we go.

You have the option to fire reporting services from the Reporting section in the SCOM Console:
However, this usually brings up an older version of Report Builder (it did for me, at least). So, if you want to go with the latest (and maybe greatest) version of SSRB, open the Reporting Services URL from any machine, as below, and click in Report Builder:
http://<SSRS_Server>/Reports
It will install the client locally and you’re ready to go…Not! First you need to make sure you have the Event.smdl model installed. Follow the instructions here:
http://technet.microsoft.com/en-us/library/ee292069.aspx
After that, we will need to create a dataset to work on the new report. You could start a new dataset from inside the report, but I like to see the dataset there and it could be shared with other reports. And it is my blog, so…:
If you don’t see the Event.SMDL there, use the Browse other data sources option:
Note: You can create new fields right in the dataset configuration, if you want them available for other reports. In this case, I will leave it and create one inside the report itself.

To create the report, save the dataset (as Events_Dataset) and follow the steps below:




If you run the report now, you will see all events in the database. We don’t want that. Let’s filter to what is important:

You can restrict as much as you want.
You should see something like this now when you run the report:

Let’s add a little bit more of information. Let’s create a calculated field, so we can find out what those events are. Back in the design view, add a calculated field:




Click the fx and add the formula:

=Switch(Fields!Event_Display_Number.Value="4767","A user account was unlocked.", "4740", "A user account was locked out.")
Yes, I know. Isn't it in the database somewhere. Very likely. It doesn't seem to be in the Event dataset that is provided, so, let's stick with it for now.

Now drag the new field to your table:


Note: Make sure you add it to the left, otherwise it will try to create a sum for it.

You should see something like that:

Now, the cherry on top. Let’s select the data range. First you need to add parameters to your report:


I have added a start date, with a default value of Yesterday (today-1 day):

Also added and End Date, with “Now()” as default value:

Now let’s add this to the criteria:



And Voila:
Now save your report in a folder in the Reporting Server:
If you look at your SCOM Console, in the folder you saved the report:



There you go!

…dary!!!!

So, if you came all this way, I hope you have enjoyed and that you can expand it, filter it, create new reports with it,etc.
Reporting with SCOM can be painful in the beginning, but with time, you may even start to like it.
True story.

Jose Fehse