Embed a Powershell Script in a Management Pack

- Updated -

OpsMgr R2 allows you to embed powershell scripts in a MP - See this MP for an example - http://derekhar.blogspot.com/2009/11/new-agent-maintenance-mode.html

----------

If you want to run powershell, perl or any other scripts not run by cscript.exe from a management pack then you invariably had to create the script and distribute it across all the servers where it needed to run. This could easily become quite complex maintaining all these scripts in multiple different locations. If you are in a situation where you have multiple management groups and none of them are quite the same then you could have multiple different versions of the script and the rule that would call the script.

To avoid this problem it is now possible to embed other scripts in a management pack, not just vbscript and jscript.

To explain how this is done we need to break in to the XML. Open the image below to view the full command. This would be executed using on a recurring basis using a System.Scheduler datasource.


The Write Action aboves enables proxying for all management servers. This check is quite easy to do using the command shell alias.

<ApplicationName>%systemroot%\System32\windowspowershell\v1.0\powershell.exe</ApplicationName>

This line launches the Powershell exe. Remember that Powershell must be installed on any server you are targeting the rule at. The same goes for any other script language that you wish to use.


<WorkingDirectory>%MOMROOT%</WorkingDirectory>

The %MOMROOT% variable point to the Installation path of OpsMgr. This is useful when targeting Powershell scripts at the RMS or Management servers as it allows you to easily load the Command Shell Snap-in. This then gives access to all the Command Shell aliases.


<CommandLine>-Command "&amp; '$File/EnableProxy.ps1$'"</CommandLine>

The arguments being passed specifies to run the script $File/EnableProxy.ps1$. After this the file must be entered.


<Files>
<File>
<Name>EnableProxy.ps1</Name>
<Contents>

The name of the script must match the command line name. While I have not tested this there appears to be the ability to embed multiple files here.

Now we drop into the script itself. This rule is targeted to run only on the RMS so $rootMS is set as localhost. The next 3 lines load the Command Shell snapin, and opens the connection to the local management group.

$rootMS="localhost"
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";
set-location "OperationsManagerMonitoring::";
new-managementGroupConnection -ConnectionString:$rootMS;


Here is an example Management Pack

Data Warehouse Query

If you have multiple management groups rolling up to a single data warehouse here is a query that will allow you to return a computer name and its associated management group. Not great or anything but the first attempt at digging in to the db.

SELECT ManagedEntity.DisplayName, ManagementGroup.ManagementGroupDefaultName
from OperationsManagerDW.dbo.ManagedEntity
INNER JOIN OperationsManagerDW.dbo.ManagementGroup ON
ManagedEntity.ManagementGroupRowId
= ManagementGroup.ManagementGroupRowId
WHERE fullname like 'Microsoft.Windows.Computer:%'

XPath statements to display event data in monitors and rule-generated alerts.

http://goteamshake.com/?p=31

Here are the XPath statements to display event data in monitors and rule-generated alerts.

Monitors

$Data/Context/EventDescription$

Rule-Generated Alerts

$Data/EventDescription$

Active Directory Agent Assignment using a database

The post over on System Center forum about Using Property Bags with Custom Scripting in Operations Manager 2007 has helped me to solve a problem I was having with doing Active Directory based Agent Assignment using a database. This is for integration with a CMDB type database to control agent assignment.

This will take the form of a rule that runs a script to query a database and returns multiple property bags with each property bag containing the dnshostname and distinguished name of each computer that is to be assigned to a management server.

The output fo this script can then be passed to the AD writer action that writes the computer objects to the relevant security groups in the management group OU under the Operations Manger OU.

The rule that is generated by the GUI using the LDAP provider to perform the LDAP query and returns a result for each object found and passes each result seperatley to the Ad Writer rule. This is where the multiple property bags comes in as the of the AD Writer action expects multiple inputs that can only be provided, as far as I can determine, by using multiple property bags.

The rule will run on each management server and the script will simply query the database for the agents belonging to that management server. All the load balancing will be done by the database itself.

I will be have more on this rule in future posts.

More about Property bags and Varant types

When returning values in a property bag that are not string values you will have to break open the XML of the management pack to be able to compare the values correctly.

The XML generated by the Authoring console will look something like:

<ErrorExpression>
<SimpleExpression>
<ValueExpression>
<XPathQuery>Property[@Name='Status']</XPathQuery>
</ValueExpression>
<Operator>GreaterEqual</Operator>
<ValueExpression>
<Value Type="String">7</Value>
</ValueExpression>
</SimpleExpression>
</ErrorExpression>


If returning Integer values that you want to compare with integers you will have to change it to:

<ErrorExpression>
<SimpleExpression>
<ValueExpression>
<XPathQuery Type="Integer">Property[@Name='Status']</XPathQuery>
</ValueExpression>
<Operator>GreaterEqual</Operator>
<ValueExpression>
<Value Type="Integer">7</Value>
</ValueExpression>
</SimpleExpression>
</ErrorExpression>

Note that the Type declaration has to be on both sides of the expression. Also be aware that some version of the Authoring console may strip the Type="Integer" from the XPath query.


Thanks to Alexandre Coelho for this fix.

Passing an Event Description to an Alert description

Finding the correct Data Item Context Parameters to use in Operations manager can be a problem. Here is the one to pass an Event description to an Alert. Useful if you want the Alert description to contain the Event description.

$Data/Context/EventDescription$

Export a Sealed MP

Export a Sealed MP

A sealed MP can be exported to an XML file using Command Shell.
Find the correct name of the MP you want to export using:

get-managementpack | where {$_.Name -like "*Server.2003"}

Export using:

get-managementpack | where {$_.Name -eq "Microsoft.Windows.Server.2003"} | export-managementpack -path C:\MP