BWren's Management Space : Command Shell

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

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.

Command Shell Presentation at MMS 2008

Brian Wren — Mon, 25 Feb 2008 08:24:00 GMT

I will be doing a presentation at the upcoming MMS 2008 titled Administrative Scenarios using the Operations Manager 2007 Command Shell. This is a bit of a departure for me since I've presented several times at MMS but usually on management packs and custom monitoring scenarios. This will be a chance to present different solutions I've created with Command Shell working with various customers. Not management packs but still automation, so we're well within my comfort zone.

I'm working out the different scenarios I'm going to cover right now and already have a list longer than time is going to allow. That list currently includes the following:

Importing and exporting management packs from a command line
Analyzing management pack contents
Deploying agents from a command line
Modifying settings across multiple agents with a single command
Scheduling maintenance mode for single object and related objects
Resolving alerts matching specified criteria
Launching tasks from a command line
Extracting performance and alert data

Depending on the scenario, the solution may be a CmdLet or two or may require a full blown script. I personally hate trying to feverishly copy code and specific command lines while sitting in a presentation, so I'll include the code for each scenario here on the blog just prior to the presentation itself.

If you're going to be attending MMS this year and have any scenarios you'd like to see covered in my presentation, let me know. Obviously I can't guarantee anything, but I would like to see if there are any interesting scenarios I haven't thought of. I could also use a little feedback on the scenarios that are most interesting since a couple are probably going to have to fall off of that list due to time constraints.

Exporting Management Packs

Brian Wren — Wed, 22 Aug 2007 19:33:35 GMT

Obviously, /a great way to learn how to author a management pack is to look at existing ones. The problem is that most of the interesting ones are sealed so you can't read the file, and the Operations Console won't allow you to export a sealed management pack.

This is actually very easy using Command Shell. You can export a single management pack or export the entire set of installed management packs from a management group. This is my personal favorite as I like to have the entire set of management packs available for my reference.

Command Shell is an optional component of the Operations Manager User Interfaces, so it's probably something you already have installed.

Exporting a single management pack

To export a single management pack, use the following command:

get-managementPack -name <Name of MP> | export-managementPack -path <Directory to store exported file>

For example, to export the SQL Library MP to a directory called c:\mp:

get-managementPack -name Microsoft.SQLServer.Library | export-managementPack -path c:\mp

Exporting all management packs

It's actually easier to export all management packs since you don't have to specify the -name parameter on the get-managementPack CmdLet. Just use the following, and you will fill c:\mp with the entire set of management packs installed in your management group.

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

Update on 2/17/2008

I would be completely remiss if I didn't update this post to refer to Boris' PowerShell script that can convert an MP file to XML from a command line. Certainly easier if you need to convert a sealed management pack that you don't already have imported into a management group.

http://blogs.msdn.com/boris_yanushpolsky/archive/2007/08/16/unsealing-a-management-pack.aspx