BWren's Management Space

Sample Application for SP1

Brian Wren — Fri, 05 Jun 2009 09:28:00 GMT

Attached to this post is a version of my sample application for Operations Manager SP1. This has the process monitor removed that relies on the modules in R2.

PowerShell Scripts in a Management Pack Part 2

Brian Wren — Fri, 05 Jun 2009 08:49:00 GMT

In a previous blog post, I explained how to run PowerShell scripts from a management pack. I honestly don’t remember why I titled that “Part 1” because I don’t remember what I figured that Part 2 was going to be. Turns out that using the native PowerShell modules in OpsMgr R2 is a perfect topic for Part 2 which I’ll present here (just pretend that I meant that all along).

Prior to R2 we could launch PowerShell scripts from a management pack, but we had to do it by building the command line and launching powershell.exe. This was more complicated, less efficient, and had the disadvantage that the agent didn’t actually know that it was running a script. If that script hit an error, we didn’t know about because the agent simply knew that it successfully launched the executable. Now that we have a native module, this is going to be much more efficient and reliable. I had some disclaimers in that post about overhead from PowerShell that don’t apply with the new modules. Keep in mind that PowerShell still has to be installed on the target agent.

There are some different details to know about using these modules though, and that’s exactly the point of this post. I updated my sample application with PowerShell equivalents of a discovery and a property bag script, so you might want to grab that to have as a reference as you read through the rest of this post.

Scripts

In the last post I mentioned that the scripts don’t really change from their VBScript counterparts. We still create discovery data and property bags using the MOM.ScriptAPI object – we’ll just need to use the New-Object cmdlet in PowerShell instead of the CreateObject method in VBScript. That’s really the only difference when we were calling PowerShell.exe with the Command, but there are some other changes we’re going to need when using the native R2 modules.

Parameters

The first change is how we are going to accept parameters into the script. Note that the term “parameter” is going to get a little tricky here. Modules have parameters, and we can pass parameters to a script. As you’ll see below, the PowerShell modules have a module parameter called Parameter to make things even more confusing. I’ll do my best to keep the wording clear though, and you shouldn’t have too tough of a time sorting all of this out.

I’ll show how to pass the values to the script parameters below, but for now let’s just worry about the script itself. Instead of accessing positional arguments with the $args variable (the equivalent of WScript.Arguments in VBScript) we’re going to use named parameters. We accept these into the script using the param() command at the start of the script specifying the variables that the script is accepting the parameters into.

For example, for the queue statistics script in my sample application, we need to pass in two parameters - $topFolder and $debug. We do that with the following line:

param($topFolder,$debug)

This would allow us to specify named parameters on the command line when executing the script. This would look something like below for the Queue Statistics script.

.\QueueStats.ps1 -topFolder 'C:\StoreQueues' –debug $false

We might type that command line when testing the script, but we won’t be putting it into the management pack – I’ll show how we do that below. Just want to give you a basic idea of how PowerShell works with named parameters if you aren’t already familiar with it.

Returning Data

In VBScript, we return data using the Return method on the MOM.ScriptAPI object if we are returning discovery data or a single property bag. If we are returning multiple property bags, we use ReturnItems(). Those aren’t going to work very well from the R2 PowerShell modules though. Instead, we can simply return the objects themselves from the script. In PowerShell, you do this by typing the name of the variable on a line all by itself.

This is best illustrated by the following examples which show the PowerShell equivalent to a VBScript snippet:

Discovery Data

VBScript PowerShell
Set oAPI = CreateObject("MOM.ScriptAPI") Set oDiscoveryData = oAPI.CreateDiscoveryData() … … oAPI.Return(oDiscoveryData)
$api = New-Object -comObject 'MOM.ScriptAPI' $discoveryData = $api.CreateDiscoveryData() … … $discoveryData
Single Property Bag

VBScript PowerShell
Set oAPI = CreateObject("MOM.ScriptAPI") Set oBag = oAPI.CreatePropertyBag() … … oAPI.Return(oBag)
$api = New-Object -comObject 'MOM.ScriptAPI' $bag = $api.CreatePropertyBag() … … $bag
Multiple Property Bags

VBScript PowerShell
Set oAPI = CreateObject("MOM.ScriptAPI") 
For Each object in collection 
    Set oBag = oAPI.CreatePropertyBag() 
    … 
    … 
Next 
oAPI.ReturnItems()
$api = New-Object -comObject 'MOM.ScriptAPI' 
foreach (object in collection) 
{ 
    $bag = $api.CreatePropertyBag() 
    … 
    … 
    $bag 
}

Note that in the multiple property bag example, we’re simply returning each bag as we create it. That’s not complicated but certainly a different approach than in VBScript where we stack up all of the objects before returning them at once with ReturnItems(). The condition detection or write action that is going to accept the output will work against each property bag returned from the script. The end result is identical to using ReturnItems() in VBScript – just looks a little different in the script.

Consoles

The PowerShell modules will not be accessible in the Operations Console in R2 (no word yet if they will be in future releases). You are still going to be limited to writing scripts with VBScript or JScript if you are living only in that console.

You will be able to use the new modules in the Authoring Console, although wizards aren’t going to be available for them. You aren’t going to be able to simply select New Rule and see something like Timed PowerShell Script. You’re going to have to create custom modules, monitor types, monitors, and rules if you want to use the PowerShell modules. For creating workflows based on scripts this is typically what you want to do anyway to be able to use your script in multiple workflows and to present a nice set of overrideable parameters to the operator. Really shouldn’t be much more complicated than other custom modules that you’ve built.

Modules

Discoveries

There is only a single data source module for executing PowerShell scripts - Microsoft.Windows.TimedPowerShell.DiscoveryProvider. This is the functional equivalent of the timed script discovery provider that you’ve probably used for creating a discovery with VBScript. I’m not going to list out all the parameters for the module since you’ll be familiar with most of them – IntervalSeconds, ScriptName, ScriptBody, etc. The new ones are going to be SnapIns and Parameters which I’ll get to below.

No real trick to using the module other than defining the new parameters. You’ll create a new discovery with that data source, plug in your script, and you’re on your way.

Property Bags

Scripts returning property bags are used for most monitors and rules using scripts. These are going to be trickier than the discovery scripts using R2 because we don’t have a data source module. We do have a probe action though called Microsoft.Windows.PowerShellPropertyBagProbe, so it’s a matter of creating a data source module using it and a System.Scheduler.

In the sample application, I have three data source modules for PowerShell property bag scripts as follows:

Demo.StoreApp.TimedPowerShell.PropertyBagProvider
Demo.StoreApp.TimedPowerShell.EventProvider
Demo.StoreApp.TimedPowerShell.PerformanceProvider

I’m not going to go into the details of each – you can have a look at the them yourself. They are the functional equivalents of the TimedScript modules in the Windows Library management pack. The first returns a property bag while the other two use the first one and then map the property bag output to either an event or perf data.

New Parameters

Parameters Parameter

Yes I know, a parameter called Parameters – sounds a little tricky. Actually pretty straightforward though. We have a module parameter that defines the script parameters that are going to be passed to our PowerShell script. This replaces the Arguments parameter on the VBScript modules and provides a more structured definition of the arguments being passed to the script.

The other thing that’s going to make this a bit tricky is that we’re going to have to directly edit the XML in order to provide the parameters. The structure is pretty simple, but you may not be familiar with launching an external editor from the Authoring Console. I’m not going to go into the details of that here, but I may do another blog post on it. It may seem a bit confusing how to do this and also why you have to.

The structure is pretty simple as you can see from the example below – just a matter of providing a name and value for each parameter. This is for the queue discovery in my sample application.

<Parameters> 
  <Parameter> 
    <Name>sourceID</Name> 
    <Value>$MPElement$</Value> 
  </Parameter> 
  <Parameter> 
    <Name>managedEntityID</Name> 
    <Value>$Target/Id$</Value> 
  </Parameter> 
  <Parameter> 
    <Name>topFolder</Name> 
    <Value>$Target/Property[Type="Demo.StoreApp.ComputerRole.CentralServer"]/QueuePath$</Value> 
  </Parameter> 
  <Parameter> 
    <Name>computerName</Name> 
    <Value>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value> 
  </Parameter> 
  <Parameter> 
    <Name>debug</Name> 
    <Value>$true</Value> 
  </Parameter> 
</Parameters>

The first line of the script this module would be calling is the following Param command which collects each of the named parameters.

param($sourceId,$managedEntityId,$topFolder,$computerName,$debug)

Snap Ins Parameter

The other parameter is to define snap ins that your script requires. Your script may not need any in which case you won’t use this parameter. I don’t have in my sample application since those scripts just use the file system. To show an example of the parameter though, consider a script that requires access to Operations Manager data – something you might run from a Management Server. That would require the client snap-in which is called Microsoft.EnterpriseManagement.OperationsManager.Client. To specify this snap-in for your script, you would use the following

<SnapIns>
  <SnapIn>Microsoft.EnterpriseManagement.OperationsManager.Client</SnapIn>
</SnapIns>

Samples

Rather than paste a bunch of XML in here, you can just grab the latest version of the sample application attached to the post. I have a discovery script and property bag script in there that have plenty of comments. I haven’t updated the document yet, but I’ll get to that. I didn’t want to hold off on the post.

Sample Application Dependencies

Brian Wren — Wed, 20 May 2009 08:25:00 GMT

I’ve had a couple of people tell me that the sample application I used for my MMS presentations won’t load in their environment. That’s because the management pack requires the OpsMgr R2 beta. It won’t load into an SP1 management group. I used a monitor in there from the new process monitoring MP in R2.

I’m about to update the MP with some PowerShell examples. When I do, I’ll strip out the process monitoring in the original version and have a second version that can load into SP1 for those people without access to an R2 environment. Should just be a couple of days before I get that done.

R2 Authoring Console

Brian Wren — Thu, 07 May 2009 19:16:29 GMT

I’ve been getting this question quite a bit, so I thought I’d give a quick answer to it. The question is whether we can use the R2 Authoring Console to create management packs for SP1. The answer is that you absolutely can – with a minor caveat. There is nothing different about the structure of a management pack for SP1 or R2, and the Authoring Console just creates management packs in XML. There are R2 specific modules, and using those will make your MP unusable in SP1, but you could use those with any version of the Authoring Console or even editing XML directly.

But what about that one caveat? When you create a new management pack in the Authoring Console, it will automatically add references to the library MPs – System.Library, System.Health.Library, Microsoft.Windows.Library, and Microsoft.SystemCenter.Library. The R2 Authoring Console will create those references to the latest versions of those MPs (6.1.7043.0 as of RC version of R2). You probably aren’t going to use any specific features of those new versions, but if you leave those references, your management pack won’t load in a management group with pre-R2 libraries.

To fix this, you should be able to just go to the References tab in Management Pack Properties and change the versions of those references. The Key Token won’t change since the same certificate was used for sealing the different MP versions. For reference, the SP1 libraries are version 6.0.6278.0, and the RTM libraries are version 6.0.5000.0.

Bottom line is definitely use the R2 Authoring Console regardless of which version of OpsMgr you’re working with. Several improvements over the SP1 version including the ability to create elements that we used to have to drop out to XML for.

MMS 2009

Brian Wren — Wed, 29 Apr 2009 03:44:43 GMT

A bit wiped out after delivering four consecutive sessions on management pack authoring. I'm impressed with people who made it through the entire five hours. That was definitely not light content. Seems like they were well received though.

The sample management pack that I showed along with a document describing the MP and the sample application that it's based on is on the OpsManJam site. I'm planning on continuously updating this MP as l create other example scenarios. I thought that would be more interesting than continuing to do random examples, and l can keep them all packaged up in one clean MP. I'm also getting tired of all the random little XML files l have cluttering up my MP library.

I'm getting mocked quite a bit at the conference about my lack of blog updates. Now that I've gotten through these presentations as well as some other training l was working on, l should be able to get to that.

SNMP Queries

Brian Wren — Wed, 21 Jan 2009 19:22:35 GMT

I recently help someone out getting a monitor working that uses the System.SnmpQueryProvider module in the System.Snmp.Library management pack to perform a query against an SNMP device. They were getting back an error message showing some cryptic characters in the community string. They were just providing simple text like "public" for the CommunityString parameter on the module, so this looked pretty strange.

After some research, it turns out that module wants the community string specified in Base64 format. Nothing special from the MP perspective – you just need to specify the Base64 equivalent of your community string in the CommunityString parameter rather than the simple text.

If you already have a means of converting a string to Base64, then you should be fine. If not, here’s bit of PowerShell that will do the conversion for you.

$communityString = 'public'
[System.Convert]::ToBase64String([System.Text.Encoding]::UNICODE.GetBytes($communityString))

If I run that code, I get the following value: cAB1AGIAbABpAGMA. Pasting that into the CommunityString parameter on the module should get you the results you want. Obviously, if you have a community name different than "public" you would paste that in and use the resulting converted value.

Programmatically Creating Groups

Brian Wren — Tue, 18 Nov 2008 11:04:27 GMT

Well, it looks from my last post that I took about a eight month hiatus from the blog. Fortunately, I've been doing a bunch of OpsMgr in that time, so I have a bunch of content to get out here. Just a matter of taking the time to write it up.

The one I'll go with first is programmatically creating groups. Now creating a single group is pretty easy in the Operations Console, so creating a single one from a command line isn't going to get anyone excited. What is exciting though is if you have a bunch of groups to create - especially if several of these are subgroups.

I'll leave you to figure out the complexity of providing a list of groups - maybe reading from a text file or something. That's just straight PowerShell work. What I will give you though is the code to create a new group. You should be able to use this base code to do whatever complex and repetitive group creation that you might need.

First of all, there is no cmdlet to create a group. You're going to have to manually create a Microsoft.EnterpriseManagement.Monitoring.CustomMonitoringObjectGroup object, set its properties, and then save it to the management group using the InsertCustomMonitoringObjectGroup method on the management group. That part's easy. It will be when I give you the code in a minute anyway. The tough part of the exercise is setting the membership formula, and we need to go through that before we get into the code.

Membership Formula

The membership formula is an XML expression defining the logic for what objects should be members of the group. The easiest way to figure out how to build this formula is to configure a group using the dialog box in the Operations Console and then copy out the resulting XML. There are a couple of things you need to know about this though, so let me provide a bit of explanation and a couple of examples.

When you export the management pack, you'll find the membership rule in the discovery for the group. It might take you a little bit of searching through the different discoveries if you aren't familiar with the XML schema of a management pack, but it shouldn't take too long. A typical discovery will look something like the XML below.

<Discovery ID="UINameSpace9e378de9416945c4820c4cacfd0475fa.Group.DiscoveryRule" Enabled="true" Target="UINameSpace9e378de9416945c4820c4cacfd0475fa.Group" ConfirmDelivery="false" Remotable="true" Priority="Normal"> 
  <Category>Discovery</Category> 
  <DiscoveryTypes> 
    <DiscoveryRelationship TypeID="SCIG!Microsoft.SystemCenter.InstanceGroupContainsEntities" /> 
  </DiscoveryTypes> 
  <DataSource ID="GroupPopulationDataSource" TypeID="SystemCenter!Microsoft.SystemCenter.GroupPopulator"> 
    <RuleId>$MPElement$</RuleId> 
    <GroupInstanceId>$MPElement[Name="UINameSpace9e378de9416945c4820c4cacfd0475fa.Group"]$</GroupInstanceId> 
    <MembershipRules> 
      <MembershipRule> 
        <MonitoringClass>$MPElement[Name="SCIG!Microsoft.SystemCenter.InstanceGroup"]$</MonitoringClass> 
        <RelationshipClass>$MPElement[Name="SCIG!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass> 
        <IncludeList> 
          <MonitoringObjectId>d47ea9a0-a039-d399-bec3-4b305269b57e</MonitoringObjectId> 
        </IncludeList> 
      </MembershipRule> 
    </MembershipRules> 
  </DataSource> 
</Discovery>

The only part you want is the MembershipRules section, and that’s what I’ll describe below.

Membership Formula Examples

First, let's look at a typical dynamic membership. The following dialog box shows a criteria that you might create.

That logic would translate to the following membership rule which could be used as is. There are no GUIDs here to worry about.

<MembershipRule> 
  <MonitoringClass>$MPElement[Name="Windows!Microsoft.Windows.Computer"]$</MonitoringClass> 
  <RelationshipClass>$MPElement[Name="SCIG!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass> 
  <Expression> 
    <And> 
      <Expression> 
        <RegExExpression> 
          <ValueExpression> 
            <Property>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Property> 
          </ValueExpression> 
          <Operator>MatchesWildcard</Operator> 
          <Pattern>lgb*</Pattern> 
        </RegExExpression> 
      </Expression> 
      <Expression> 
        <RegExExpression> 
          <ValueExpression> 
            <Property>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/IPAddress$</Property> 
          </ValueExpression> 
          <Operator>MatchesWildcard</Operator> 
          <Pattern>10.1.*</Pattern> 
        </RegExExpression> 
      </Expression> 
    </And> 
  </Expression> 
</MembershipRule>

How about a group with explicit members? Now this is probably a bad example, because you probably won't pragmatically be creating groups with explicit members, but it is possible.

This generates the following membership rule which includes GUIDs. These GUIDs really can't be swapped out though since they refer to specific objects. If you were to programmatically create something like this, you would presumably use Get-MonitoringObject in Command Shell to get the GUID of the object you're interested in and then add it to the XML.

<MembershipRule> 
  <MonitoringClass>$MPElement[Name="SystemCenter!Microsoft.SystemCenter.ManagedComputer"]$</MonitoringClass> 
  <RelationshipClass>$MPElement[Name="SCIG!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass> 
  <IncludeList> 
    <MonitoringObjectId>b3e9befe-173b-78a2-3e41-e19ecb58d9d5</MonitoringObjectId> 
    <MonitoringObjectId>0852e1eb-f854-eb88-2f7d-a1bb0794d18f</MonitoringObjectId> 
    <MonitoringObjectId>6e813ffe-2267-a191-ccbb-566d4ddf95bc</MonitoringObjectId> 
    <MonitoringObjectId>98e3ee12-54c0-f14c-506c-4113bb8f1dcb</MonitoringObjectId> 
  </IncludeList> 
</MembershipRule>

Subgroups are something you very well might want to use. One use of programmatically creating groups is to create a complex group structure which may contain several levels of different groups.

This would generate the following XML, and in this case we would want to swap out that GUID which refers to the subgroup (Sample Group - Level 2 in the example).

<MembershipRule> 
  <MonitoringClass>$MPElement[Name="SCIG!Microsoft.SystemCenter.InstanceGroup"]$</MonitoringClass> 
  <RelationshipClass>$MPElement[Name="SCIG!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass> 
  <IncludeList> 
    <MonitoringObjectId>e499513e-4e67-142e-f1f6-53b24b5195bb</MonitoringObjectId> 
  </IncludeList> 
</MembershipRule>

This would work better with the following. The end result is the same since we'll still end up with the GUID of the subgroup. but this example could be installed in other management groups and would make a lot more sense when working with code.

<MembershipRule> 
  <MonitoringClass>$MPElement[Name="SCIG!Microsoft.SystemCenter.InstanceGroup"]$</MonitoringClass> 
  <RelationshipClass>$MPElement[Name="SCIG!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass> 
  <IncludeList> 
    <MonitoringObjectId>$MPElement[Name='bwren.GroupDemo.SampleGroupLevel2']$</MonitoringObjectId> 
  </IncludeList> 
</MembershipRule>

Finally, we need to talk about empty groups since this is very common situation when programmatically creating groups. You may automate the creation of a large group structure relying on users to add objects to these groups through the Operations Console once the management pack is loaded. Empty groups have a very specific structure which is below.

    <MembershipRule Comment="EMPTY_RULE_8eadaced-59c8-4ebc-a4e4-b8428a374442"> 
      <MonitoringClass>$MPElement[Name="SC!Microsoft.SystemCenter.AllComputersGroup"]$</MonitoringClass> 
      <RelationshipClass>$MPElement[Name="SCIG!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass> 
      <Expression> 
        <SimpleExpression> 
          <ValueExpression> 
            <Value>True</Value> 
          </ValueExpression> 
          <Operator>Equal</Operator> 
          <ValueExpression> 
            <Value>False</Value> 
          </ValueExpression> 
        </SimpleExpression> 
      </Expression> 
    </MembershipRule>

As you can see, the basic logic is to check if True equals False. Since this will obviously never be a true statement, we have no objects that match the criteria. The other thing you need though is the comment with that specific string on the MembershipRule tab. There’s no real value in going into the background on that. Just know that you need it. If you don’t include it, the group will get created, but you’ll get a pretty ugly error when you try to modify the membership of that group from the Operations Console.

Management Pack Aliases

If you aren’t familiar with management pack aliases, they are separated from management object names with a ! in all the examples above. An alias is required if you are referring to an object in another management pack. The alias to that management pack must be in the References section of the management pack containing your group. In the examples above, you can see the alias SCIG which refers to the System Center Instances Group management pack. As such, the Reference section would need to contain the following entry.

<Reference Alias="SCIG"> 
  <ID>Microsoft.SystemCenter.InstanceGroup.Library</ID> 
  <Version>6.0.6278.0</Version> 
  <PublicKeyToken>31bf3856ad364e35</PublicKeyToken> 
</Reference>

Your management pack might use a different alias for Microsoft.SystemCenter.InstanceGroup.Library. I just created a new management pack with the Operations Console, and it used MicrosoftSystemCenterInstanceGroupLibrary6164070. Obviously, you will need to use whatever alias your management pack is using. I have some code that will figure out what alias is being used for a particular management pack, but that will have to wait for a later post.

Creating the Group

Now that you know how to create the formula, you need the code to create the group. We’re using the InsertCustomMonitoringObjectGroup method of the ManagementPack class. We need to pass that a CustomMonitoringObjectGroup which is created with a group name, a group display name, and a formula. The group name is created from a combination of a namespace and a name. The namespace acts as the standard prefix for all objects in the management pack. It will append that the the group name that we specify to build a complete name. In the example below, I’m using a namespace of bwren.Groups and a group name of Gargantua. The full name of the resulting group will be bwren.Groups.Gargantua.

With all that explanation, I’ll let the following code speak for itself. This example creates an empty group, but all you would need to do to create a different membership rule is to replace the $formula variable with one of the examples above.

$mpName = 'bwren.Groups' 
$namespace = 'bwren.groups' 
$groupName = 'gargantua' 
$groupDisplayName = 'Gargantua'


$formula =  '<MembershipRule Comment="EMPTY_RULE_8eadaced-59c8-4ebc-a4e4-b8428a374442">' + ` 
            '<MonitoringClass>$MPElement[Name="SCIG!Microsoft.SystemCenter.InstanceGroup"]$</MonitoringClass>' + ` 
            '<RelationshipClass>$MPElement[Name="SCIG!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass>' + ` 
            '<Expression>' + ` 
            '<SimpleExpression>' + ` 
            '<ValueExpression>' + ` 
            '<Value>True</Value>' + ` 
            '</ValueExpression>' + ` 
            '<Operator>Equal</Operator>' + ` 
            '<ValueExpression>' + ` 
            '<Value>False</Value>' + ` 
            '</ValueExpression>' + ` 
            '</SimpleExpression>' + ` 
            '</Expression>' + ` 
            '</MembershipRule>' 

$group = New-Object Microsoft.EnterpriseManagement.Monitoring.CustomMonitoringObjectGroup($namespace,$groupName,$groupDisplayName,$formula) 
$mp = Get-ManagementPack -name $mpName 
$mp.InsertCustomMonitoringObjectGroup($group)

One more MMS Follow Up

Brian Wren — Wed, 07 May 2008 19:26:00 GMT

As I ran out of time in the MMS session, I quickly showed a script that listed all performance monitors and their thresholds. This came from the SharePoint Portal Server Management Pack Guide. The only change I made was to comment out the command to export the results to a csv so the information would come scrolling across the screen. I attached the script with that small change to this post.

Monitoring Object Properties

Brian Wren — Sun, 04 May 2008 00:10:00 GMT

There has been some question about how to get properties for monitoring objects with Command Shell. I wanted to go into this in my MMS session last week, but I already ran out of time just trying to cram in all the topics I did cover. Shouldn't be too tough to explain it here though.

If you use Get-MonitoringObject, you get a common set of properties for all objects. Kind of like the following:

PS Monitoring:\OpsMgr01
>$mc = get-monitoringClass -name Microsoft.Windows.Computer
>$mc | get-monitoringObject | where {$_.name -match 'web01'} 

Id               : 0844f543-762c-5800-794c-a72a1823ea96
PathName         : web01.greengargantua.com
DisplayName      : web01.greengargantua.com
ManagementMode   :
ManagementGroup  : gaira
HealthState      : Success
OperationalState : 

PS Monitoring:\OpsMgr01
>$mc = get-monitoringClass -name Microsoft.SQLServer.2005.Database 
>$mc | get-monitoringObject | where {$_.name -match 'blob'} 
 

Id               : dfd4fd2b-6c7f-6c9c-a1cd-4d074613e3fd
PathName         : opsmgr01.greengargantua.com%003bMSSQLSERVER%003ablob
DisplayName      : blob
ManagementMode   :
ManagementGroup  : gaira
HealthState      : Success
OperationalState :

That example shows two objects that are completely different - a database and a computer - but we show an identical set of properties. We know that there a bunch of properties unique to each of those classes, but where are they?

In order to display all properties for the object, you can use one of the Format CmdLets with * indicating you want all properties. That results in the following:

PS Monitoring:\OpsMgr01
>$mc = get-monitoringClass -name Microsoft.SQLServer.2005.Database
>$mc | get-monitoringObject | where {$_.name -match 'blob'} | fl * 

PathName                                        : opsmgr01.bwren.com%003bMSSQLSERVER%003ablob
UniquePathName                                  : Microsoft.SQLServer.Database%003aopsmgr01.bwren.com%003bMSSQLSERVER%003bblob
[Microsoft.SQLServer.Database].DatabaseName     : blob
[Microsoft.SQLServer.Database].RecoveryModel    : FULL
[Microsoft.SQLServer.Database].DatabaseAutogrow : True
[Microsoft.SQLServer.Database].DatabaseSize     : 2
[Microsoft.SQLServer.Database].LogAutogrow      : True
[Microsoft.SQLServer.Database].Updateability    : READ_WRITE
[Microsoft.SQLServer.Database].UserAccess       : MULTI_USER
[Microsoft.SQLServer.Database].Collation        : SQL_Latin1_General_CP1_CI_AS
[Microsoft.SQLServer.Database].LogSize          : 1
[Microsoft.SQLServer.Database].Owner            : BWREN\Administrator
[System.Entity].DisplayName                     : blob
Name                                            : blob
Path                                            : opsmgr01.bwren.com;MSSQLSERVER
DisplayName                                     : blob
FullName                                        : Microsoft.SQLServer.Database:opsmgr01.bwren.com;MSSQLSERVER;blob
IsManaged                                       : True
LastModified                                    : 11/26/2007 7:07:20 AM
HealthState                                     : Success
StateLastModified                               : 5/1/2008 8:39:45 PM
IsAvailable                                     : True
AvailabilityLastModified                        : 5/3/2008 5:20:29 PM
InMaintenanceMode                               : False
MaintenanceModeLastModified                     : 5/1/2008 8:39:06 PM
MonitoringClassIds                              : {10c1c7f7-ba0f-5f9b-c74a-79a891170934, cae6be07-6483-361b-710f-c7612e29fa7b}
LeastDerivedNonAbstractMonitoringClassId        : 10c1c7f7-ba0f-5f9b-c74a-79a891170934
Id                                              : dfd4fd2b-6c7f-6c9c-a1cd-4d074613e3fd
ManagementGroup                                 : bwren
ManagementGroupId                               : 80342cfb-a3e1-aa59-7eac-cb5b5f167c38

The properties specific to the individual class are preceded with the name of the class they came from surrounded by brackets. I'll explain the details of that later. For now, just know that you have to specify the entire thing to retrieve the property value. Since PowerShell sees those brackets as special characters, you need to surround the entire property name with quotes.

>$mc = get-monitoringClass -name Microsoft.SQLServer.2005.Database
>$mo = $mc | get-monitoringObject | where {$_.name -match 'blob'}
>$mo."[Microsoft.SQLServer.Database].LogAutogrow"

That syntax can actually get tricky, and I'll be honest that I haven't figured out how to get it working in all cases. The other approach you can use is the Get-MonitoringObjectProperty CmdLet. The name property from that CmdLet will be the simple name of the property.

>$mc = get-monitoringClass -name Microsoft.SQLServer.2005.Database 
>$mo = $mc | get-monitoringObject | where {$_.name -match 'blob'} 
>$mo | get-monitoringObjectProperty | sort parentElement,name | ft parentElement,name,value 

ParentElement                         Name                      Value
-------------                         ----                      -----
Microsoft.SQLServer.Database          Collation                 SQL_Latin1_General_CP1_CI_AS
Microsoft.SQLServer.Database          DatabaseAutogrow          True
Microsoft.SQLServer.Database          DatabaseName              blob
Microsoft.SQLServer.Database          DatabaseSize              2
Microsoft.SQLServer.Database          LogAutogrow               True
Microsoft.SQLServer.Database          LogSize                   1
Microsoft.SQLServer.Database          Owner                     BWREN\Administrator
Microsoft.SQLServer.Database          RecoveryModel             FULL
Microsoft.SQLServer.Database          Updateability             READ_WRITE
Microsoft.SQLServer.Database          UserAccess                MULTI_USER
System.Entity                         DisplayName               blob

If you already know about the concept of base classes in OpsMgr, then you already know what that that ParentElement class is. If not, let me provide a very brief description just so you at least have a little background information.If you want more details on this whole concept of class structures in OpsMgr, the Authoring Guide has complete documentation.

All classes in OpsMgr have a base class. That base class may have a base class, and its base class may have a base class, etc. All classes will eventually find their way up to System.Entity which is the only class with no base. The object tree for the SQL 2005 Database class is shown below.

If a class has properties associated with it, then any classes that inherit from it (ie. they use that class as their base class) inherit its properties and any properties along the class tree. There are no properties explicitly assigned to SQL 2005 Database. Instead, those properties you see (Collation, DatabaseAutogroup, etc) are defined on the SQL Database class. As you might imagine, SQL 2000 Database inherits from that same class so it inherits the same properties as SQL Database.

Setting Maintenance Mode from an Agent

Brian Wren — Fri, 02 May 2008 03:19:00 GMT

My apologies that I forgot to talk about this in my MMS session earlier today. I did mention it to a couple of people after the session. Derek Harkin came up with an interesting method for initiating maintenance mode from an agent. No OpsMgr client of any kind required - just a simple script for the user to execute. No need to reiterate the details here, have a look at Derek's blog entry.

MMS Command Shell Presentation

Brian Wren — Tue, 11 Mar 2008 17:28:00 GMT

As promised, here are all the samples that I am showing in my MMS session on Command Shell. There are also a several samples I'm planning on mentioning but won't have time to show. Hope it's helpful.

Given the length of the this, chances are pretty good that I have an error somewhere. Please let me know if there's anything that doesn't work, if there's anything you think I forgot, or if you have any improvements to any of these scenarios.

Management Groups

Add a management group connection:

> new-managementGroupConnection OpsMgr02

Change your default management group connection:

> new-defaultManagementGroupConnection OpsMgr02 $true

View all current management group connections:

> get-ManagementGroupConnection

or

> cd \
> dir

Management Packs

Export a specific management pack (sealed or unsealed):

> get-managementPack -name Microsoft.SQLServer.2005.Monitoring | export-managementPack -path c:\mp

Export all management packs in a management group:

> get-managementPack | export-managementPack -path c:\mp

Install a management pack to multiple management groups:

> new-managementGroupConnection OpsMgr02
> cd \
> install-managementPack c:\mp\Contoso.MyManagementPack.mp

Export management pack from test environment, seal it, and import to two production management groups:

> get-managementPack -name bwren.MMS | export-managementPack -path c:\mp
> MPSeal.exe Contoso.MyManagementPack.xml /I c:\mp /Keyfile c:\keys\contosoKeyPair.snk /Company "Contoso"
> new-managementGroupConnection ggOpsMgr01.greenGargantua.com
> cd \ggOpsMgr01.greenGargantua.com
> install-managementPack c:\mp\bwren.mms.xml
> cd \OpsMgr01.bwren.com
> get-managementGroupConnection | where {$_.managementServerName -eq 'ggOpsMgr01.greenGargantua.com'} | remove-managementGroupConnection

Agents

Install an agent on a single computer:

> $ms = get-managementServer | where {$_.name -eq 'OpsMgr02.GreenGargantua.com'}
> install-agentByName -name 'srv01' -managementServer $ms

Install agents to a list of computers from a text file:

> $ms = get-managementServer | where {$_.name -eq 'OpsMgr02.GreenGargantua.com'}
> gc c:\scripts\agents.txt | foreach {install-agentByName -name $_ -managementServer $ms}

Schedule install of agents to a list of computers from a text file.

Script: InstallAgents.ps1

param($file,$managementServer,$rmsServerName)
Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";
Set-Location "OperationsManagerMonitoring::";
$mgConn = New-ManagementGroupConnection -connectionString:$rmsServerName
Set-Location $rmsServerName
$ms = get-managementServer | where {$_.name -eq $managementServer}
gc $file | foreach {install-agentByName -managementServer $ms -name $_}

Run from Task Scheduler:

C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe "c:\scripts\InstallAgents.ps1" -file:'c:\scripts\computers.txt' -managementServer:OpsMgr02 -rmsServerName:'OpsMgr01'

Discover all domain controllers and install an agent on each:

> $ms = get-managementServer | where {$_.name -eq 'OpsMgr02.GreenGargantua.com'}
> $discoveryConfig = new-ldapQueryDiscoveryCriteria -domain contoso.com -ldapQuery "(primaryGroupID=516)"
> $discoveryResult = start-discovery -managementServer $ms -windowsDiscoveryConfiguration $discoveryConfig
> $installResult = install-agent -managementServer $ms -agentManagedComputer $discoveryResult.CustomMonitoringObjects
> $installResult.MonitoringTaskResults

Display the proxy setting for all agents with a particular string in the computer name:

> get-agent | where {$_.computerName -match 'dc'} | ft name,proxyingEnabled

Enable the proxy setting for all agents with a particular string in the computer name:

> $agents = get-agent | where {$_.computerName -match 'dc'}
> $agents | foreach {$_.ProxyingEnabled = $true}
> $agents | foreach {$_.ApplyChanges()}

Move all agents on a subnet to a different management server:

> $ms = get-managementServer | where {$_.name -eq 'OpsMgr02.greenGargantua.com'}
> $agents = get-agent | where {$_.IPAddress -match '10.2.*.*'}
> $agents | set-managementServer -primaryManagementServer $ms

Security

Get list of roles a user belongs to:

> get-userRole | where {$_.users -match 'iggy'} | ft name

Add list of users from a text file to a user role:

Script: AddUsersFromFile.ps1

param($file)

$entries = import-csv -path $file
foreach ($entry in $entries) {
$role = get-userRole | where {$_.name -eq $entry.role}
add-userToUserRole -userRole $role -user $entry.user
}
Sample Text File: users.txt

role,user
Marketing,contoso\iggy
Marketing,contoso\johnny
Finance,contoso\sid
IT,contoso\trent

Running Script:
> c:\scripts\AddUsersFromFile -file c:\scripts\users.txt

Monitoring Classes and Objects

List all monitoring classes:

> get-monitoringClass | ft name

List all SQL 2005 databases:

> (get-monitoringClass -name Microsoft.SQLServer.2005.Database) | get-monitoringObject | ft name

OR

> (get-monitoringClass | where {$_.displayName -eq 'SQL 2005 DB'} | get-monitoringObject | ft name

List all Windows computers and their IP addresses:

> get-monitoringClass -name Microsoft.Windows.Computer | get-monitoringObject | foreach {$_."[Microsoft.Windows.Computer].IPAddress"}

List all monitoring classes in the SQL Server 2005 Discovery management pack

> $mp = get-managementPack -name Microsoft.SQLServer.2005.Discovery
> $mp | get-monitoringClass | ft name

Display the proxy settings for all agents holding a particular class:

> $mc = get-monitoringClass -name 'Microsoft.Windows.Server.AD.DomainControllerRole'
> $mos = $mc | get-monitoringObject
> $mo | foreach {get-agent | where {$_.computerName -eq $mo.name}} | ft name,proxyingEnabled

Enable the proxy settings for all agents holding a particular class:

> $mc = get-monitoringClass -name 'Microsoft.Windows.Server.AD.DomainControllerRole'
> $mos = $mc | get-monitoringObject
> foreach ($mo in $mos) {
   $agent = get-agent | where {$_.computerName -eq $mo.displayName}
   $agent.proxyingEnabled = $true
   $agent.applyChanges()
}

Maintenance Mode

Set maintenance mode for a single object:

> $StartTime = (get-Date '4/1/2008 22:00').ToUniversalTime()
> $EndTime = (get-Date '4/2/2008 2:00').ToUniversalTime()
> $mc = get-monitoringClass -name Microsoft.SQLServer.2005.Database
> $mo = get-monitoringObject -monitoringClass $mc | where {$_.name -eq 'MyDatabase'}
> new-maintenanceWindow -monitoringObject $mo -startTime $StartTime -endTime $EndTime -reason PlannedOther -comment "Scheduled maintenance."

Set maintenance mode for an object and all of its contained objects:

> $StartTime = (get-Date '4/1/2008 22:00').ToUniversalTime()
> $EndTime = (get-Date '4/2/2008 2:00').ToUniversalTime()
> $mc = get-monitoringClass -name Microsoft.Windows.Computer
> $mo = get-monitoringObject -monitoringClass $mc | where {$_.name -eq 'srv01'}
> $mo.ScheduleMaintenanceMode($StartTime,$EndTime,PlannedOther,"Nightly reboot.","Recursive")

Schedule maintenance mode for all computers in a group (uses GroupMM.ps1):

> C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe "c:\scripts\GroupMM.ps1" -groupName:'Nightly Reboots' -hours:2 -rmsServerName:'OpsMgr01' -startMM:$true

View maintenance mode history for an object:

> $mc = get-monitoringClass -name Microsoft.Windows.Computer
> $mo = get-monitoringObject -monitoringClass $mc | where {$_.name -eq 'srv01'}
> $mo | get-maintenanceWindow -history

Tasks

Run task to enable audit collection on all agents:

> $task = get-task | where {$_.name -eq 'Microsoft.SystemCenter.EnableAuditCollectionService'}
> $mc = get-monitoringClass | where {$_.name -eq 'Microsoft.SystemCenter.HealthService'}
> $mc | get-monitoringObject | foreach {start-task -task $task -targetMonitoringObject $_}

Data

View all unresolved alerts:

> get-alert -criteria "ResolutionState <> 255"

View all alerts grouped by severity and name

> get-alert -criteria "ResolutionState <> 255" | sort severity,name | group severity,name

View alerts from a particular rule group by managed object:

> get-alert -criteria "ResolutionState <> 255" | where {$_.name -match 'Script or Executable Failed to run'} | group monitoringObjectDisplayName

Change resolution state of alerts from a particular rule group by managed object:

> get-alert -criteria "ResolutionState <> 255" | where {$_.name -match 'Script or Executable Failed to run'} | group monitoringObjectDisplayName | foreach {
>> $_.ResolutionState = 50
>> $_.update("Comment")
>>}
>>

Resolve all alerts generated by rules as opposed to monitors:

> get-alert -criteria "ResolutionState <> 255 and IsMonitorAlert = 'False'" | resolve-Alert

Reset health for a monitor called "Manual monitor" on all objects of the class "Contoso.MyCustomClass" currently in an Error state.

> $mon = get-monitor | where {$_.displayName -eq 'Manual monitor'}
> $mc = get-monitoringClass -name Contoso.MyCustomClass
> $mc | get-monitoringObject | where {$_.HealthState -eq 'Error'} | foreach {$_.ResetMonitoringState($mon)}

Performance Data

Extract processor utilization data for all computers for the month of March 2008 to a comma delimited file.

> $startTime = get-date '3/1/2008'
> $endTime = get-date '3/31/2008'
> $pc = get-performanceCounter -criteria: "ObjectName='Processor' and CounterName='% Processor Time' and MonitoringObjectPath='web02.bwren.com'"
> get-performanceCounterValue -startTime $startTime -endTime $endTime -performanceCounter $pc | export-csv c:\scripts\mom\perf.csv

Management Pack Elements

List all rules by management pack:

> get-rule | select @{name="MP";expression={foreach-Object {$_.GetManagementPack().DisplayName}}},DisplayName | sort mp,displayName

List all monitors in a specific management pack:

> (get-managementPack -name Microsoft.SQLServer.2005.Monitoring) | get-monitor | sort displayName | ft displayName

List all disabled discoveries:

> get-discovery | where {$_.enabled -eq 'false'} | ft displayName

View the display name, category, and enabled status of all performance collection rules in the SQL Server 2005 Monitoring management pack:

> get-rule -managementPack $mp | where {$_.category -eq 'PerformanceCollection'} | ft displayName,category,enabled

Update to the Maintenance Mode Sample MP

Brian Wren — Mon, 10 Mar 2008 17:59:32 GMT

Andrzej Lipka, a fellow consultant in Poland, took my maintenance mode sample MP and added some interesting features. Have a look at the specific post here. I also added a link to Andrzej's blog to my general list since he has some great posts on OpsMgr and SCCM.

Using Wildcards with the Windows Service Template

Brian Wren — Sat, 08 Mar 2008 10:25:20 GMT

The Windows Service template in the Operations Console lets you discover and monitor a Windows service by doing little more than typing in the service name. I was just talking with someone who had a situation where the name of the service includes the local computer name meaning that it's different on every computer. It's the same service and should be monitored as such - just a slightly different name on each agent. Unfortunately, the template won't allow us to provide a wildcard in the service name.

For those who are skilled with management pack authoring, you're probably not relying on the template anyway, and this wouldn't be too difficult of a task. As such, I'm going to write this post from the point of view of someone who primarily lives within the Operations Console. We do have to get exposed to a bit of XML in order to pull this off, but it really should be minimal.

First, let's understand what the Windows Service template does. It performs two functions: 1) creates a new class (aka target) for your service and 2) creates a discovery to find instances of that new class. The new class that the template created should be fine as is. We can provide the template with any name we want, and it doesn't have to have anything to do with the name of the service itself. The discovery is what we need to think about.

The discovery that the template uses is a special one specifically designed for finding a service, and it doesn't allow wildcards. We can replace that discovery with a WMI discovery module since we can pretty easily write a WMI query to find all services that match a certain criteria, and that criteria can include a wildcard. There is a module called WmiProviderWithClassSnapshotDataMapper in the Windows Library management pack that will work perfectly.

Let's go through this step by step. I have a virtual machine running under the beta of Hyper-V in Windows Server 2008. That includes a few services that start with the three letters "vmi". I know this is a bit of a difference scenario than I described above, but it will still illustrate the point of discovering services using a wildcard.

1. Walk through the Windows Template wizard as normal providing your wildcard string. Note that we are going to pass this off to WMI which uses % as a wildcard character, not *.

2. Export the management pack you just used for the template.

3. Open the XML file you just exported. Use an XML editor if you have one. Otherwise, you could use Notepad.

4. You have to locate the discovery you just created which can be a little tricky since the names generated by the Operations Console are pretty long and ugly. Probably the easiest method would be to search on the wildcard string you typed in.

5. The Discovery will look something like mine which I pasted below. The long ID strings will be different in yours, but the rest should be pretty similar. There's a lot going on here, but we're not going to have to worry about most of it. I highlighted in blue the parts that we're going to need to change, and that shouldn't be too intimidating.

<Discovery ID="ServiceStateProbePage_eaa08473602945a592b2a117b62c634f.DiscoveryRule" Enabled="true" Target="Windows!Microsoft.Windows.Computer" ConfirmDelivery="false" Remotable="true" Priority="Normal">
<Category>Discovery</Category>
<DiscoveryTypes>
    <DiscoveryClass TypeID="ServiceStateProbePage_eaa08473602945a592b2a117b62c634f" />
</DiscoveryTypes>
<DataSource ID="DS" TypeID="Windows!Microsoft.Windows.Win32ServiceInformationProviderWithClassSnapshotDataMapper">
    <ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
    <ServiceName>vmi%</ServiceName>
    <Frequency>60</Frequency>
    <ClassId>$MPElement[Name="ServiceStateProbePage_eaa08473602945a592b2a117b62c634f"]$</ClassId>
    <InstanceSettings>
      <Settings>
        <Setting>
          <Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Name>
          <Value>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>
        </Setting>
        <Setting>
          <Name>$MPElement[Name="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/ServiceName$</Name>
          <Value>$Data/Property[@Name='Name']$</Value>
        </Setting>
        <Setting>
          <Name>$MPElement[Name="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/ServiceProcessName$</Name>
          <Value>$Data/Property[@Name='BinaryPathName']$</Value>
        </Setting>
        <Setting>
          <Name>$MPElement[Name="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/DisplayName$</Name>
          <Value>$Data/Property[@Name='DisplayName']$</Value>
        </Setting>
        <Setting>
          <Name>$MPElement[Name="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/Description$</Name>
          <Value>$Data/Property[@Name='Description']$</Value>
        </Setting>
        <Setting>
          <Name>$MPElement[Name="System!System.Entity"]/DisplayName$</Name>
          <Value>Hyper-V Services</Value>
        </Setting>
      </Settings>
    </InstanceSettings>
</DataSource>
</Discovery>

6. Modify the discovery to use the WMI discovery module. I highlighted in red the modifications you want to make. You could just copy and paste right from this pots into your management pack. Obviously, in that query, you're going to use your wildcard string as opposed to the vmi% that I used. All we're doing is changing out the module we're using as the data source for the discovery. Then we're replacing the parameters that we were passing to the old module to the parameters expected by the new one.

<Discovery ID="ServiceStateProbePage_eaa08473602945a592b2a117b62c634f.DiscoveryRule" Enabled="true" Target="Windows!Microsoft.Windows.Computer" ConfirmDelivery="false" Remotable="true" Priority="Normal">
<Category>Discovery</Category>
<DiscoveryTypes>
    <DiscoveryClass TypeID="ServiceStateProbePage_eaa08473602945a592b2a117b62c634f" />
</DiscoveryTypes>
<DataSource ID="DS" TypeID="Windows!Microsoft.Windows.WmiProviderWithClassSnapshotDataMapper">
    <NameSpace>root\cimv2</NameSpace>
    <Query>select * from win32_service where name like 'vmi%'</Query>
    <Frequency>60</Frequency>
    <ClassId>$MPElement[Name="ServiceStateProbePage_eaa08473602945a592b2a117b62c634f"]$</ClassId>
    <InstanceSettings>
      <Settings>
        <Setting>
          <Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Name>
          <Value>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>
        </Setting>
        <Setting>
          <Name>$MPElement[Name="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/ServiceName$</Name>
          <Value>$Data/Property[@Name='Name']$</Value>
        </Setting>
        <Setting>
          <Name>$MPElement[Name="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/ServiceProcessName$</Name>
          <Value>$Data/Property[@Name='PathName']$</Value>
        </Setting>
        <Setting>
          <Name>$MPElement[Name="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/DisplayName$</Name>
          <Value>$Data/Property[@Name='DisplayName']$</Value>
        </Setting>
        <Setting>
          <Name>$MPElement[Name="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/Description$</Name>
          <Value>$Data/Property[@Name='Description']$</Value>
        </Setting>
        <Setting>
          <Name>$MPElement[Name="System!System.Entity"]/DisplayName$</Name>
          <Value>Hyper-V Services</Value>
        </Setting>
      </Settings>
    </InstanceSettings>
</DataSource>
</Discovery>

7. Import the modified management pack. If you get an error on import, then you made a mistake in the modification. Go back and export the management pack and try again.

8. Go to Discovered Inventory and change the target type to your class. Within a minute or two, you should start to see instances showing up.

Great Minds Think Alike

Brian Wren — Wed, 05 Mar 2008 07:46:00 GMT

I just got done with my previous post on setting maintenance mode for a group of objects, and I happened to check Boris Yanushpolsky's blog. Bori's blog is an outstanding reference for various Command Shell scripts, and I have to give him credit for helping me come up to speed on several concepts. Turns out just tonight put up a script for....yep, you guessed it....setting maintenance mode on a group of objects.

As it turns out, I spent more time getting the script to run in a management pack, using overrides, etc. The script that Boris did is more complex than the one I did by putting computers into maintenance mode along with their health service. If that one fits your requirements better, than it should take all that much effort to move it into my sample management pack. Just a matter of pasting the script code into my write action and swapping around some script arguments.

Scheduling Groups of Objects for Maintenance Mode

Brian Wren — Thu, 28 Feb 2008 18:08:00 GMT

I was given a challenge recently to come up with a solution for an organization that wanted to suppress any alerts for certain computers and services during a particular time window every night. The particular set of objects and the times in question had to be manageable by the administrators - preferably from the Operations Console.

This is a great example for a few concepts, so this will be a pretty long post where I'll describe each step along the way. If you just want the answer, scroll to the link at the end for the sample MP. Otherwise, you should find some good information on the following concepts:

Launching a PowerShell script from a rule
Composing a rule made up of a data source and write action
Replacing explicit values in a rule with overrides
Creating a simple custom class

First of all, the obvious answer to suppressing alerts is to get those objects into maintenance mode. That way we not only aren't bothered by the alerts, but we can also remove this time window from any availability reporting. The questions that we're faced with though are:

How can we schedule maintenance mode on a regular basis?
How can we set maintenance mode for a set of objects?
How can we give control to the administrators through the Operations Console?

One answer for our challenge might be to write a Command Shell script to put an object in maintenance mode and then launch it from the Windows Scheduler. That would handle question 1, but it would leave us hanging on questions 2 and 3.

A very straightforward solution would be to create a group in OpsMgr. Instead of setting maintenance mode for a single object, the script could put each member of the group in maintenance mode. Administrators could easily populate the group with any objects that should be included in the maintenance window. Assuming we had a script that could do that group enumeration, question 2 is covered. In order to really address question 3, we would need to launch the script from an OpsMgr management pack instead of the Windows Scheduler and have the ability to overwrite critical parameters.

So that leaves us with two challenges - setting maintenance mode for a group of objects and creating a rule to launch the script from a management pack. Let's take them one at a time. First the script.....

Setting Maintenance Mode on a Group of Objects

We're going to need Command Shell in order to enumerate the group and set maintenance mode. I'm assuming that we're going to end up creating a rule calling powershell.exe as described in my previous blog post, so we're going to need to need the script to include the code to load the Command Shell snap-in and setup the connection to the management server. When we launch Command Shell from the menu, this is done automatically done for us.

The script should accept the group name as an argument and then enumerate all members of that group. In specific OpsMgr terms, that means that we need to enumerate the objects that are target of a Containment relationship with the group's class.

If we use the New-MaintenanceWindow CmdLet, then we would need to write a function to recurs through the group members and follow each group members down through its set of hosted and contained objects. Rather than use that CmdLet, I'm going to use the ScheduleMaintenanceMode method on the monitoring object class. That method includes an argument called TraversalDepth. A value of "OneLevel" means that only the object itself will be put into maintenance while a value of "Recursive" means that we will follow hosting and containment relationships all the way down the object tree setting maintenance mode on each object along the way. A middle ground would be nice where we could just address the second level of objects, which in our case would be the specific group members and not their contained objects, but that's a scenario we're going to have to address on our own.

I thus have two scenarios I want the script to support - setting maintenance mode for just the objects contained in the group and setting maintenance mode for those objects in addition to all of their contained objects. The second scenario is actually easier since we just execute ScheduleMaintenanceMode against the group with TraversalDepth set the "Recursive". For the first method, we're going to have the enumerate the group contents ourselves and then set maintenance mode for each one.

With all of that said, my script is below. Notice that I'm accepting as arguments the name of the group (not to be confused with the Display Name), the number of hours for maintenance, whether to include hosted objects, and the description. We'll make most of these overrideable on the rule so the administrator has control over them.

$groupName = $args[0]
$HoursInMaintenance = $args[1]
$IncludeHostedObjects = $args[2]
$Description = $args[3]
$CommandShellPath = $args[4]

Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";
cd "$CommandShellPath"
.\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Startup.ps1

$api = new-object -comObject "MOM.ScriptAPI"
$api.LogScriptEvent("SetMaintenanceMode",100,4,"Maintenance mode set for all members of group: $groupName")

$startTime = (Get-Date).ToUniversalTime()
$endTime = $startTime.AddHours($HoursInMaintenance)

$group = get-monitoringClass -name $groupName | get-monitoringObject

if ($IncludeHostedObjects -eq $true) 
{
    $group.ScheduleMaintenanceMode($startTime,$endTime,"PlannedOther",$Description,"Recursive")
}
else
{
    $classContain = get-relationshipClass -name 'System.Containment'
    $relations = $group | get-relationshipObject | where {$_.SourceMonitoringObject -eq $group} 
    $groupMembers = $relations | foreach {$_.TargetMonitoringObject}

    foreach ($object in $groupMembers)
    {
        $object.ScheduleMaintenanceMode($startTime,$endTime,"PlannedOther",$Description,"OneLevel")
    }
}

Creating the Rule

The next question is how we're going to launch that script and give administrators control over the schedule. We could do that from the Windows Scheduler, but it would be more straightforward for the administrator if we put it into an OpsMgr rule. If we configure it correctly, we can allow our administrators to use overrides to control the schedule, length of maintenance mode, and whether to include contained objects.

Data Source

The rule will need a data source and a write action. Since we want to execute the script on a nightly schedule, System.Scheduler will be a perfect data source. There is one little trick with that data source though. It allows you to define multiple schedules that have a start and a stop time. In the context we are going to use it though, the stop time is ignored. It will have to be larger than the start time to prevent errors, but other than that it won't be used.

You could just use System.Scheduler unchanged in which case you'll get the benefit of the dialog box for setting multiple schedules. In that case, you would need to modify the rule itself to change the schedule though. Since I want to control it through overrides I'm going to limit us to a single schedule, and I'm going to have to set the parameters myself. The Start and End times are pretty obvious. The DaysOfWeekMask is a little confusing. This is the integer value of a bit mask with each day representing a single bit. If you're familiar with bit masks you won't have a problem. If not, just determine the appropriate value by using the following values for each day of the week: Su-1, M-2, T-4, W-8, Th-16, F-32, Sa-64. Just add up the values for the days you want the script to run. If you want all days of the week, they'll add up to 127. If you just want Sunday, the value is 1. Just Tuesday and Thursday would be 20.

With all of that said, here's a valid data source for running the script every day of the week at 10:00 pm.

To define overrides though, we have to create a new module type. Rather than using this data source directly in the rule, I'll create a data source allowing the StartTime and DaysOfWeekMask to be overriden. The rule will then use the new data source module. Notice in the data source below that I've changed the changed the values for <Start> and <DaysOfTheWeeMask> to overrideable values that will be provided by the rule itself.

<DataSourceModuleType ID="bwren.Maintenance.DataSource.Scheduler" Accessibility="Public">
    <Configuration>
        <xsd:element name="StartTime" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema"/>
        <xsd:element name="DaysOfWeekMask" type="xsd:integer" xmlns:xsd="http://www.w3.org/2001/XMLSchema"/>
    </Configuration>
    <OverrideableParameters>
        <OverrideableParameter ID="StartTime" ParameterType="string" Selector="$Config/StartTime$"/>
        <OverrideableParameter ID="DaysOfWeekMask" ParameterType="int" Selector="$Config/DaysOfWeekMask$"/>
    </OverrideableParameters>
    <ModuleImplementation>
        <Composite>
            <MemberModules>
                <DataSource ID="DS" TypeID="System!System.Scheduler">
                    <Scheduler>
                        <WeeklySchedule>
                            <Windows>
                                <Daily>
                                    <Start>$Config/StartTime$</Start>
                                    <End>23:59</End>
                                    <DaysOfWeekMask>$Config/DaysOfWeekMask$</DaysOfWeekMask>
                                </Daily>
                            </Windows>
                        </WeeklySchedule>
                        <ExcludeDates/>
                    </Scheduler>
                </DataSource>
            </MemberModules>
            <Composition>
                <Node ID="DS"/>
            </Composition>
        </Composite>
    </ModuleImplementation>
    <OutputType>System!System.TriggerData</OutputType>
</DataSourceModuleType>

Write Action

The write action is just a matter of launching our PowerShell script. We'll again need a new module type to handle overrides. That strategy has other benefits anyway, since we can put the complexity in the module type and keep the rule simple. That will make it easy to create other rules for other groups.

The module type using our script is shown below. I won't bother explaining all the details since you can get that from the PowerShell post. The formatting gets pretty screwed up here, so you might just want to have a look at it in the sample MP.

            <WriteActionModuleType ID="bwren.Maintenance.WriteAction.SetMaintenance" Accessibility="Public">
                <Configuration>
                    <xsd:element name="GroupName" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema"/>
                    <xsd:element name="HoursInMaintenance" type="xsd:integer" xmlns:xsd="http://www.w3.org/2001/XMLSchema"/>
                    <xsd:element name="IncludeHostedObjects" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema"/>
                    <xsd:element name="Description" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema"/>
                </Configuration>
                <OverrideableParameters>
                    <OverrideableParameter ID="HoursInMaintenance" Selector="$Config/HoursInMaintenance$" ParameterType="int"/>
                    <OverrideableParameter ID="IncludeHostedObjects" Selector="$Config/IncludeHostedObjects$" ParameterType="string"/>
                </OverrideableParameters>
                <ModuleImplementation Isolation="Any">
                    <Composite>
                        <MemberModules>
                            <WriteAction ID="WA1" TypeID="System!System.CommandExecuter">
                                <ApplicationName>%windir%\system32\windowspowershell\v1.0\powershell.exe</ApplicationName>
                                <WorkingDirectory/>
                                <CommandLine>-Command "& {.\SetMaintenance.ps1 $Config/GroupName$ $Config/HoursInMaintenance$ $Config/IncludeHostedObjects$ '$Config/Description$'}"</CommandLine>
                                <SecureInput/>
                                <TimeoutSeconds>30</TimeoutSeconds>
                                <RequireOutput>true</RequireOutput>
                                <Files>
                                    <File>
                                        <Name>SetMaintenance.ps1</Name>
                                        <Contents><![CDATA[
$groupName = $args[0]
$HoursInMaintenance = $args[1]
$IncludeHostedObjects = $args[2]
$Description = $args[3]

Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";
cd C:\"Program Files"\"System Center Operations Manager 2007"
.\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Startup.ps1

$startTime = (Get-Date).ToUniversalTime()
$endTime = $startTime.AddHours($HoursInMaintenance)

$group = get-monitoringClass -name $groupName | get-monitoringObject

if ($IncludeHostedObjects -eq $true)
{
    $group.ScheduleMaintenanceMode($startTime,$endTime,"PlannedOther",$Description,"Recursive")
}
else
{
    $classContain = get-relationshipClass -name 'System.Containment'
    $relations = $group | get-relationshipObject | where {$_.SourceMonitoringObject -eq $group}
    $groupMembers = $relations | foreach {$_.TargetMonitoringObject}

    foreach ($object in $groupMembers)
    {
        $object.ScheduleMaintenanceMode($startTime,$endTime,"PlannedOther",$Description,"OneLevel")
    }
}
                                        ]]></Contents>
                                        <Unicode>true</Unicode>
                                    </File>
                                </Files>
                            </WriteAction>
                        </MemberModules>
                        <Composition>
                            <Node ID="WA1"/>
                        </Composition>
                    </Composite>
                </ModuleImplementation>
                <OutputType>System!System.CommandOutput</OutputType>
                <InputType>System!System.BaseData</InputType>
            </WriteActionModuleType>

Setting the Rule Target

With those modules created, we need a rule that includes each data source and specifies the required arguments. The biggest question is what to use as its target. Technically, we can target anything that will end up deploying to an agent with PowerShell and Command Shell installed. We only want a single agent to get it though. We also want to make sure that our target is going to be accessible to the server admins. The root management server typically has Command Shell installed, and this is a perfect candidate for this task. Chances are pretty good though that we don't want to give permission to our administrators to author rules against our RMS.

I had thought of targeting the group itself since, as described in another previous post the root management server "hosts" groups, so that's where the rule would get deployed. I had some issues with this working reliably though, and I also thought it might get a bit confusing.

The solution I went with was to create a new class based on ComputerRole called CommandShellProxy. This can serve as the target for any rules I want to create that launch a Command Shell script. I can give permission to different people to override rules targeted at it without giving them access to the rules and monitors directly targeting the RMS. As an added benefit, I stored the path to the PowerShell executable and the Command Shell snap-in so I don't have to hardcode those into the rule.

I did a simple registry discovery for my new class and targeted it at the Root Management Server class. The only criteria I'm using is determining whether Command Shell is installed. If you want to use something other than the RMS as your Command Shell proxy, all you would have to do is change that discovery.

I didn't bother pasting in the discovery XML since I've already cluttered up this post with enough code. You can have a look at it in the sample MP though.

End Result

Go to the bottom of this post for a link to the sample MP. You can go through the following steps to get it up and running:

1. Load the management pack

2. Add an object or two to the group Maintenance Mode Group 1.

3. Make sure that you are discovering the Command Shell Proxy by selecting Discovered Inventory. Then click on Change Target and select Command Shell Proxy from the list.

4. Go to the Authoring tab and look at rules for the target Command Shell Proxy.

4. Create an override on the rule Set maintenance mode - group 1, and set appropriate values for StartTime, HoursInMaintenance, IncludeHostedObjects, and Description. The allowable values for IncludeHostedObjects are $true and $false (those are the PowerShell variables for True and False. You could do a little script work to allow a boolean in the override and then convert appropriately if you really want).

I know this is a long and detailed post, but it seemed like a good opportunity to illustrate a few points. Hope it's helpful.

Discovery Data
VBScript	PowerShell
Set oAPI = CreateObject("MOM.ScriptAPI") Set oDiscoveryData = oAPI.CreateDiscoveryData() … … oAPI.Return(oDiscoveryData)	$api = New-Object -comObject 'MOM.ScriptAPI' $discoveryData = $api.CreateDiscoveryData() … … $discoveryData

Single Property Bag
VBScript	PowerShell
Set oAPI = CreateObject("MOM.ScriptAPI") Set oBag = oAPI.CreatePropertyBag() … … oAPI.Return(oBag)	$api = New-Object -comObject 'MOM.ScriptAPI' $bag = $api.CreatePropertyBag() … … $bag

Multiple Property Bags
VBScript	PowerShell
Set oAPI = CreateObject("MOM.ScriptAPI") For Each object in collection Set oBag = oAPI.CreatePropertyBag() … … Next oAPI.ReturnItems()	$api = New-Object -comObject 'MOM.ScriptAPI' foreach (object in collection) { $bag = $api.CreatePropertyBag() … … $bag }