Search

And again I think I was sleeping. Long time ago when the Visio SCOM integration was released (4year ago) I always had the idea I was missing a key feature. The drill trough feature. So when I click on a shape it opens a next sheet with detailed shapes on it. Tried to established this but stopped looking due a unknown reason. I think it was RTM. (please don’t tell others). But the idea never left my mind. So @MMS2012 I spoke with the Operations manager team again and got my answer. O o oh what is the solution simple! Of course Microsoft I never dubbed you guys hadn’t thought about it!. Special thanks to Dale K. (MSFT)

Make the Visio document

Open Visio and create a new sheet. Lets say a overview of your DAD applications.

Now we link the correct SCOM targets to the Visio shapes. In our case we have a DAD application that we are linking to shape named Applications A. We do the same for the B and C application.

This is what we get.

So when the DAD linked to Application A is unhealthy it will change the shape named Application A red. So far it is almost basic stuff.

Drill trough

Now the value increment. We are going to link the application shapes to a other sheets containing detailed level of the selected application. So we create a new sheet. And Name it Application A.

And we add/link some SCOM targets related to application A to it.

Now we go back to the overview sheet (page-1) and select the Application A shape and right click –> Hyperlink.

Next we are going to create a new hyperlink.

Select the new hyperlink and press the sub-address browse.

Select the application A sheet. And the Zoom level.

And we are almost ready. This last step is important. Since clicking on a shape will only trigger the default hyperlink. We must select the just created hyperlink and set it as default. In this example we have no other hyperlinks but normally we have some default one’s.

The result

So still in Visio press F5. Now the Visio sheet will be shown full screen. Double click on shape Application A and you will we get the detailed sheet showing application A.

Cool isn’t it!!!

Tip: You can use the up/down button to switch the sheets. But better is to make a go to overview shape on every detail sheet. And hyperlink this to the overview sheet.

Will it work in SharePoint ??

YES it does!

Assuming you have configured the SCOM Visio add in for SharePoint. You just publish it to the document library and open it. You will see its working there also… Sooo cool.

Next idea is born

The only thing is that we still can’t get this into the native SCOM console. Okay we can make a web view showing the SharePoint Visio page but this has a lot off setup overhead. The good thing is that you can write your custom widgets in OM12. When I have time I will make a prototype showing this Visio sheet into the operations manager native console using a widget.

This weekly blog post will be about the idea and wish I have a long time now: I want to see what a SCOM operator is doing with SCOM. So an Audit trail of the SCOM SDK idea was born.

The Idea:

Its very simple , as a SCOM administrator you have the world for your self. You can create rules , modify overrides , import / delete Management Packs , add users as you wish. If something went wrong they can blame you for it. That’s no problem because you are the the only one that know how to fix this. But what when you are not the only one with administrator privileges. Who is blaming who ? And if blaming isn’t the issue how do I know What , Who and When something has changed (the 3 audit W’s) ?

Solution(s):

On the web there are plenty of solutions that try to solve this. Most of them are using SQL triggers to catch the functions the operator is doing and a separate DB to store the generated audit records. This solutions have a very big impact on the SQL engine and I think by applying the triggers to the tables you lose your Microsoft Support Warranty. And what will happen by applying a SCOM service pack …. So this is not the way to go.

I was thinking , since SCOM uses ADAM/AD LDS for user&operations authorization why not just go this way. Every call to the SCOM SDK (the native scom console, web console,power shell , connectors,ect…) will be checked for authorization . This is done by the Active Directory Lightweight Directory Service (AD LDS), formerly known as Active Directory Application Mode (ADAM). And the nice part of this is that there is a tool that lets you read and edit this authorization store. The tool is called “Authorization Manager”. You can find it as a MMC Snapin. I will show you this later on. For SCOM the authorization catalog can be located on disk as XML file or as a SQL tables. Not going into the details , SCOM 2007 SDK uses a file store and (yes) SCOM 2012 SDK uses a SQL table store. And now the reason we dig into this all: The Authorization layer has a AUDIT trail build in !!!. Simply enable it and setup the correct audit policy and we are getting audit records…

That’s however in theory ….

The real world

Of course I have tried it out before I wrote this post. And yes we are getting audit events and yes it are events for every SDK operation and NO they do not contain parameter information. (95%not) So we can see what operation is executed but can’t see the parameters supplied with the call. For example add user X to role Y. We see the add user role operation but don’t see X and Y in the audit event. Does this make my ideas useless ? I think not. I found out that there are still some events useable. And hopefully I can get the SCOM product team so far implementing the missing parameter logging.

Some LAB testing

I will now show you how to get the audit events.

Login to the OM2012 MNG server. Open the MMC console. And add the “Authorization Manager” snapin.

The first time you will see this below:

Now we are going to make the connection to the OM SDK Authorization Store. Remember for OM2012 this in SQL. Right click and choose “Open Authorization Store..”

Now choose Microsoft SQL. And type in the Store name. I say it very easy but believe me this one cost me hours to find out (maybe because my IQ ;–) ). There is almost no documentation on Authorization manager and SQL connection. And for sure no information where the SCOM store is located. But never mind that’s your luck , because I share it with you guys.

Replace SCOMSQLSERVER\INSTANCE to the SQL server and Instance where your SCOM database is on.

Replace OperationsManager with the database name you have used for the operations manager database name while installing SCOM 2012.

For my LAB it will be :

Press OK and you are ready.

You will see the store and all it groups. Browse to AzmanStore\Microsoft System Center\Role Definitions and you will see the screen shot below. And I am sure you know it from the operations manager console!

Now press right button and select properties –> Definition. And you will see all the SDK operations (tasks) a SCOM administrator role can do. So every time the SDK receives a operations from for example the native console it will first check if this operation may be executed by this user. You can even add or change some operations. So you can add for example Rule__Get to a normal operator so the operator can now see the rule properties. REMEMBER IF YOU DO YOU MAY LOOSE YOUR MICROSOFT SUPPORT.

If you are curios what all the operations availably in SCOM are, Go to the Add… and press Operations. Now you will see the complete list of operations. And this one is huge..

So explained all of this you may forget it quickly now. They only thing we have to do is set the auditing flag on the store. Right click on the azmanstore and choose properties.

Now go to Auditing and enable the 2 auditing boxes.

I just wanted to show you all of this because it is fun core level stuff. But as it seems this 2 boxes are enabled by default. So the next time you can skip this part too. Sorry if I wasted your time

The only real step we have to do is enabling the security auditing policy. So lets do that. First this. The audit records are written to the server eventlog where the SQL server instance is installed. So if you have a 2 box scom installation , one OM , one SQL. You must login to the SQL server to proceed. If you have a 1box scom installation you login to the OM server.

Open the Local Security Policy editor. And enable “Audit object access” for Success and Failure. Press OK and the events will flow in.

REMEMBER HOWEVER THIS IS TOTALLY SUPPORTED BY MICROSOFT IT WILL GENERATE A HUGE NUMBER OF EVENTS AND MAY HIT THE PERFORMANCE OF YOUR SERVER.

So lets look at the events. Open the windows event viewer and go to the security logs. This will show a huge number of events. Better is to create a custom view by only selecting events with Source MOMSDK Service Security or Task Category (3).

Now if you look at a event you will notice that it has some basic information about the operation and the user plus session it belongs too. The part that is missing for a lot of operations are the parameters belonging to the operation (Data access method) if this was supplied we where done. However I found some operations that give the missing parameter information. For example when you create a new MP you will see this event. Look at the extra info given.

Same for the MP delete

I haven’t looked at all the operations but as far I can see now there are not a lot of operations with extended information. Again I hope it will be added soon with a service pack release.

Conclusion:

With the solution described we can see What is done and Who has done it and When its done. The only part missing is some extra information on the What part. So we can really see what this operator is trying to do. But better than having nothing it’s a good start.

To be continued:

I am trying to convince the OM product team to look at this. Meanwhile I have a other idea I will try to work out to solve this. I will try to post it soon.