Blog
By Pete Zerger on 8/25/2010 10:51:28 PM • Rank (1483) • Views 1678
1

1

emo suicide

I’ve always said “girls make the smartest IT people”….and so it goes again in today’s post. I was talking to my friend Lizzie the other day about an OpsMgr script I wrote, and she got a bit off topic…and had a great idea! With all the talk of green IT, let’s talk about saving some green by reusing work we’ve already done. I’ll replay a bit of our conversation for you here simply because Lizzie tends to speak her mind and is usually hilarious in the process.

Lizzie: “You know, these two-state monitor scripts would be perfect for ConfigMgr”

Pete: “Girl, what’re you talkin’ about?”

Lizzie: “You know…for DCM???”

Pete: “You mean to check CIs [configuration items] in a baseline?”

Lizzie: “Yeah, you could recycle these for ConfigMgr...You do recycle don’t you? That’s hot.” (she frequently quotes Paris Hilton [or other ridiculous celebrities] for a laugh or for effect)

Pete: “That’s a good idea. Gee, you’re pretty smart.”

Lizzie: “Duh! No $%*#$ I’m smart!”

States of Being: OpsMgr Two-States versus ConfigMgr Two-State

Let’s look at Lizzie’s point a little more closely.

  • In OpsMgr, a two-state monitor script looks for two conditions….healthy or not healthy
  • In ConfigMgr, a script-based CI in a DCM baseline is generally looking for two states, compliant or not compliant.

There are some differences, but nothing we can’t handle in a few minutes time.

Converting Scripts to “The Other Side” – A Simple Example

So really, the transition is moderately to very easy depending on the script. It mostly depends on how much of the OpsMgr scripting API you have mingled in your OpsMgr script. Let’s do a quick conversion of one of our most simple samples here on SCC… This is an OpsMgr script designed to check the startup configuration of a Windows service (to make sure its set to start automatically). Notice the purpose of the script is configuration monitoring….appropriate for this example and DCM in general

Note: In truth, we could do this particular check as a registry-based CI, but sometimes we use scripts anyway for flexibility when we want to check multiple registry values as part of a single CI or we really need to log an event, etc. Good enough for purposes of demonstration here…I’m sure you get the point.

Here’s the OpsMgr Version of the Script. I’ve highlighted in red the bits we’ll need to lose in the transition. In the end, the script will actually become even more simple

‘----------Start of OpsMgr Two-State Monitor Script------------------

'Declare variables
Dim objMOMAPI, objBag, wshShell image

'Instantiate (create an instance) of MOMScriptAPI
Set objMOMAPI = CreateObject("MOM.ScriptAPI")

'Instantiate MOMScriptAPI and Create PropertyBag
Set objAPI = CreateObject("MOM.ScriptAPI")
Set objBag = objMOMAPI.CreateTypedPropertyBag(StateDataType)

'Read Registry Value
Set WshShell = WScript.CreateObject("WScript.Shell")
ReadRegValue = WshShell.RegRead("HKLM\SYSTEM\CurrentControlSet\Services\Spooler\Start")

If ReadRegValue = 2 Then

    'Set state to GOOD
    Call objBag.AddValue("State","GOOD")
    Call objMOMAPI.Return(objBag)

Else

    'Set state to BAD
    Call objBag.AddValue("State","BAD")
    Call objMOMAPI.Return(objBag)

    Wscript.Quit()
End If

‘---------End of Script-------------

 

And now, the ConfigMgr version

You can see here, this resulting DCM script is dead simple and took about 60 seconds to convert. It checks the same value representing the service startup type and returns compliant or not compliant, 0 or a 1, true or false.

‘----------Start of ConfigMgr DCM Script------------------
'Declare variables
Dim wshShell

'Read Registry Value
Set WshShell = WScript.CreateObject("WScript.Shell")
ReadRegValue = WshShell.RegRead("HKLM\SYSTEM\CurrentControlSet\Services\Spooler\Start")

If ReadRegValue = 2 Then

    'Return COMPLIANT
    WScript.Echo "Compliant"

Else

    'Return Not Compliant
    WScript.Echo "NotCompliant"
End If

‘---------End of Script-------------

 Conclusion

There’s all kinds of green IT. In this case we’re just recycling and saving some $green. After all, time is money.

Next Up….DCM and Heisenberg Uncertainty Principle

 

Follow System Center Central via Twitter and RSS

Twitter_icon rss_big_default_300x300

Comments (4) - Comment RSS
Andreas Zuckerhut wrote: on Aug 25, 2010 07:10 PM
Is it just me, or did you actually just tell us to copy and paste (recycle) code parts from one script to another?



Hm... I hope she was at least hot ;)
Pete Zerger wrote: on Aug 26, 2010 01:02 AM
Repurposing scripts across products in this case is exactly what I am suggesting. Two-state montiors and DCM scripts are simular in form and function as you can see, and with SCCM, we can create dynamic collections of non-compliant systems to allow automatiion of corrective action. As OpsMgr admins, I think we tend to do things in OpsMgr that would be better handled from ConfigMgr just because we are more comfortable in one product versus another.

I'll talk more about WHEN we should do this in coming days.
Marco Shaw wrote: on Aug 27, 2010 09:12 AM
In your first script, you should likely place Wscript.Quit() at the end of your script, and it isn't in the DCM version at all. I think it is a common misconception though that you actually need to add such clean up routines in a script unless... You are re-using the same Wscript process continuously or you specifically need to prematurely (not a "hot" term) exit a routine/logic.
Pete Zerger wrote: on Nov 04, 2010 08:40 PM
Marco, I would suggest that cleaning up never hurts (and may help), but in this case we're looking at a check that would run once every few hours to few days...so you have a point. In the end, I am trying to provide an basic example of effective reuse of code across System Center products.


Who Viewed
Who Reviewed
Categories
Related Pages
Shortened URL
http://tinyurl.com/2fyztfm

Top Contributors
Featured Members
Pete Zerger
Points: 72533
Level: System Center Expert
Tommy Gunn
Points: 47345
Level: System Center Expert
Simon Skinner
Points: 40804
Level: System Center Expert
Andreas Zuckerhut
Points: 30700
Level: System Center Expert
Stefan Koell
Points: 30179
Level: System Center Expert