HP have relesed an update to the Proliant Server MPs.
Version Information:
HP ProLiant Server Management Packs for Operations Manager 2007 – Version 1.1.3
Hewlett-Packard Servers Core Library – Version 1.0.33.0
Hewlett-Packard ProLiant Servers Base – Version 1.0.33.0
Hewlett-Packard ProLiant Servers SNMP Management Pack – Version 1.1.0.0From the release notes:
Download HP ProLiant Server Management Packs Version 1.1 for Operations Manager 2007 here.
Go into the Operations Manager console. Under the Computer view, search for computer the computer object you want to pull data about
Right click on the object and select Open, Performance View,
In the upper right corner under actions select time range.
Go down to the bottom left corner of your screen and select the objects you want to graph.
Right Click on object, if you want to adjust Graph Scale.
Look at Graph!
null
Courtesy of Brian “The Brain” Wren:
Considering all my work with OpsMgr management packs and my infatuation with PowerShell, it’s surprising that I’ve never put the two together in a public forum. I keep meaning to, just don’t ever seem to get there. I finally committed myself to this blog post while sitting at my local It’s a Grind (that’s a coffee house to all you Seattle Starbucks fans. It’s a Grind was born in Long Beach, and I am fanatically loyal to my home town).
So here’s the basic question – can I use a PowerShell script in an OpsMgr management pack? In other words, can I execute a PowerShell script from a rule, monitor, diagnostic, recovery, or task? The answer is absolutely you can, but there are some considerations to keep in mind. First let’s cover those considerations, then we’ll get to concepts and code. If you just want the modules to copy and paste into your MP, go ahead and jump to the end.
The biggest issue is that most of the servers in your environment don’t have PowerShell installed. Rules and monitors sent to an agent are executed locally on the agent computer, and any executables must be installed prior to the agent attempting to use them. In the case of VBScript and JScript, we rely on cscript.exe being present, but that’s a safe bet since it is automatically installed on all Windows machines. Powershell is obviously not installed by default, and even in Windows Server 2008 it’s an optional feature. If you want to use a PowerShell script for a console task, then you’re going to need to make sure that it is installed on the client workstation the task is being executed from. This is less of a concern though since, while PowerShell and Command Shell are not required for the OpsMgr User Interfaces, they are pretty strongly suggested.
There can also be some significant overhead from launching PowerShell. Go ahead and launch a PowerShell window and then have a look at Task Manager. Powershell.exe will probably be consuming something like 30 MB of memory which is about 5x the typical cscript.exe instance in my personal testing. This is not surprising considering all the rich functionality that PowerShell provides. My only point is to try to stay away from scenarios where you need to launch a PowerShell script every couple of minutes. I’ve heard the OpsMgr product team is working on some strategies to reduce this overhead, but until then you want to use PowerShell scripts where they don’t have to be launched too frequently.
Concepts
The basic idea of running a PowerShell script is to use of the Command Executer modules to launch powershell.exe with your script. This is actually the method that quite a few of the scripts in existing management packs use – calling cscript.exe with these modules. The Command Executer modules will launch the executable of your choice, allow you to specify command line arguments, and allow you to specify the name and contents of one or more text files (which will obviously be your script). These text files are created on the agent prior to command execution, so you can be guaranteed they will be in place when your specified command is launched.
Have a look at Microsoft.Windows.ScriptProbeAction in Microsoft.Windows.Library for example. That module uses System.CommandExecuterProbe from System.Library. It specifies cscript.exe as the command to execute, provides the appropriate command line arguments such as /nologo and the name of the script, and then passes in the body of the script as a file. In order to execute Powershell, we really just need to figure out the command line required to launch PowerShell, execute a script, and then exit.
PowerShell Command Line
If you run powershell.exe /?, you get the command line arguments for PowerShell. To launch a command and exit, you use the -command argument, the invoke operator (&), and a command to execute. The example syntax given by that help is as follows:
powershell -command “& {get-eventlog -logname security}”
We’re going to need that basic syntax but put it in a format that the management pack can understand. It won’t handle that ampersand, and we’re go to have to have to specify a path for the script. PowerShell demands a complete path to a script even if it’s in the current directory. The Command Executer will drop the script to a temporary directory and then use that directory as its default when it executes the script, so we can assume the script will be located in the current directory. Assuming that we are going to use a parameter called ScriptName for the name of the script, then the command line in the management pack would look like the following:
-command “& {.\$Config/ScriptName$}”
If you’re completely baffled by that syntax, here’s a quick explanation. We replace & with & because OpsMgr interprets the & as a special character. We get away with that character in the script itself if we enclose the script in CDATA tags, but we can’t use CDATA tags on our command line. $Config/ScriptName$ is a context variable. OpsMgr will replace the variable inside the dollar signs with its actual value at run time. Config refers to the parameters of the module, and ScriptName is the name of the parameter. Finally, the .\ just refers to the current directory. So, if we used MyScript.ps1 for the script name, we would end up running the following command:
powershell -command “& {.\MyScript.ps1}”
Implementing the Modules
Rather than write a specific rule that uses the Command Executer modules and includes the specific PowerShell complexity, it is way more valuable to create a couple of base modules that can be leveraged by rules, monitors, and tasks. A Data Source module that runs a PowerShell script on a timed basis and returns a property bag could be used for a rule, monitor, or diagnostic. Another Data Source module returning discovery A Write Action module that just runs a PowerShell script on demand to perform some defined action would support a task or recovery.
I’ll provide the data source below. Given this it should be pretty straightforward to create a write action (hint – use System!System.CommandExecuter). You could also create a discovery module based on System!System.CommandExecuterDiscoveryDataSource.
<DataSourceModuleType ID=”PowerShell.Library.PSScriptPropertyBagSource” Accessibility=”Public”>
<Configuration>
<xsd:element xmlns:xsd=”http://www.w3.org/2001/XMLSchema” name=”IntervalSeconds” type=”xsd:integer”/>
<xsd:element xmlns:xsd=”http://www.w3.org/2001/XMLSchema” name=”TimeoutSeconds” type=”xsd:integer”/>
<xsd:element xmlns:xsd=”http://www.w3.org/2001/XMLSchema” name=”ScriptName” type=”xsd:string”/>
<xsd:element xmlns:xsd=”http://www.w3.org/2001/XMLSchema” name=”Arguments” type=”xsd:string”/>
<xsd:element xmlns:xsd=”http://www.w3.org/2001/XMLSchema” name=”ScriptBody” type=”xsd:string”/>
</Configuration>
<ModuleImplementation>
<Composite>
<MemberModules>
<DataSource ID=”DS” TypeID=”System!System.CommandExecuterPropertyBagSource”>
<IntervalSeconds>60</IntervalSeconds>
<ApplicationName>%windir%\system32\windowspowershell\v1.0\powershell.exe</ApplicationName>
<WorkingDirectory/>
<CommandLine>-Command “& ‘$Config/ScriptName$”</CommandLine>
<SecureInput/>
<TimeoutSeconds>30</TimeoutSeconds>
<RequireOutput>false</RequireOutput>
<Files>
<File>
<Name>$Config/ScriptName$</Name>
<Contents>$Config/ScriptBody$</Contents>
<Unicode>true</Unicode>
</File>
</Files>
</DataSource>
</MemberModules>
<Composition>
<Node ID=”DS”/>
</Composition>
</Composite>
</ModuleImplementation>
<OutputType>System!System.PropertyBagData</OutputType>
</DataSourceModuleType>
Writing the Script
For the write action, there’s really nothing special about the script. Any working PowerShell script will be fine. If you need to return a property bag or discovery data from a data source though, you’re going to need to use MOM.ScriptAPI just like in VBScript. PowerShell works fine with COM objects, so this is not a problem at all. The following line will create an object variable, and using it is pretty similar to how you did it in VBScript.
$api = new-object -comObject “MOM.ScriptAPI”
For example, below is a PowerShell script to output the name and size of a specified file as a property bag. This could be called from a rule or monitor that uses a condition detection to map the property bag information to performance data. While this is coded in PowerShell, the basic process is identical to a script
$file = Get-Item $args[0]
$api = New-Object -comObject “MOM.ScriptAPI”
$bag = $api.CreatePropertyBag()
$bag.AddValue($file.Name,$file.Length)
$api.Return($bag)
More Later
This should be enough information to get people off and running. I’d like to provide some more samples and thought of actually writing a library MP with a complete set of PowerShell modules. No hard commitment on that, but I’ll do my best in coming weeks.
System Center Operations Manager SP1 RTM Released to Web!!!
Feature Bullet Summary:
Improved Console Performance
Increased Scale Limits
Disaster Recovery solution for all OpsMgr roles
Supported in-place upgrade from RTM to Service Pack 1
Supporting Docs: http://technet.microsoft.com/en-us/opsmgr/cc280350.aspx
Dell silently released a updated MP back in October. It looks like a minor release but fixes some key problems.
Fixes and Enhancements
1) Added support for Microsoft System Center Operations Manager 2007 and System Center Essentials 2007.
2) Enhanced health drill down model in Diagram views from overall Dell Hardware health to individual hardware components.
3) Includes support for the latest versions of Dell OpenManage Server Administrator v5.2 (including the enhanced Storage Management Service 2.2).
4) Supports monitoring of Dell printers using SNMPv2
Version A02 changes:
– Release includes support for System Center Essentials 2007.
– Dell Management Pack code modified with fixes for removing debug events in the Operations Manager log. About time!! These were worthless
Version A01 changes:
– Documentation (Dell Management Pack functions with a reduced feature when the Management Server Action account has normal user privileges. This Account needs admin privileges only for DRAC discovery. When the account has normal privileges, Clear ESM Log task should be executed with a Power User or higher privileged account instead of the using the predefined Run As Account).
– No change in Dell Management Pack code.
I was always wondering why I never recieved any CPU alerts. This is why
Cause:
The CPU percentage Utilization monitors are targeted to the Windows server 2003 processor class. However, there is no available Windows server 2003 processor class instance by default, due to the corresponding discovery rule: Discover Windows CPUs is disabled by default.
Resolution:
1. In MOM operations Console, open Authoring -> Management Pack Objects -> Objects Discoveries.
2. Search for the discovery rule “Discover Windows CPUs”.
3. In the properties window of this rule, go to Overrides. Set overrides on all Windows server 2003 operations system role type objects. Check override on the Parameter named “Enable”.4. Save the override setting.5. When the “Windows server 2003 processor” is working, the CPU percentage Utilization monitors will also work.
I ran into this one myself with a new installation and ended up just re-installing the database clean. This would have helped!
Are you getting this error from your Data Warehouse?
I immediately started getting these alerts after I upgraded my Data Warehouse Library Management Pack to version 6.0.5000.26 from this knowledge base article http://www.microsoft.com/downloads/details.aspx?FamilyID=09f74984-7e9d-42ef-8b38-ad770b084363&DisplayLang=en. I believe the issues exists in SP1 RC1 as well.
The problem is caused by a few hardware MPs, primarily HP and Dell that populate the Data Warehouse with “last discovered on” date as a property, basically, making an object different every time they happen to run the discovery and not only when object really changed.
This has been fixed in SP1 (RTM not in RC0) with some scripts that I am posting. Theses scripts came from Microsoft and were installed by a number of other customers with no issues, however I cannot claim that they are fully tested. They will not prevent upgrade to SP1.
The scripts create indexes in the Data Warehouse. I verified them with one our DBA’s and he said they were safe to run. As soon as I ran the scripts the alerts stopped immediately
If you are getting this error. You can fix it by installing Operations Manager 2007 Data Warehouse Library Management Pack 6.0.5000.26
After installing that you might get this new error. Performance data collection process unable to store data in the Data Warehouse in a timely manner.
You can fix this error by referencing.
https://www.scom2k7.com/performance-data-collection-process-unable-to-store-data-in-the-data-warehouse-in-a-timely-manner/
I noticed a way to reduce our alert noise by up to about 80%. This may seem very obvious but it wasn’t to me till after I realized it.
In my environment we are using a ton of different applications by various software vendors. Some of these applications automatically restart their windows services during the day and night. Other times we will get a heartbeat notification in the middle of the night.
With the majority of these notifications we will get an open and then a closed alert almost immediately. In my environment SCOM is setup to send an SMS alert to the on-call admin. This meant that the on-call admin would often be getting woken up in the middle of the night for an issue that automatically resolved itself.
I wanted to reduce the number of alerts that the on-call person (which is sometimes me). I came up with the idea to set alert aging on initial alert by 5 minutes.
We were already using alert aging for escalation but by aging the initial alert drastically reduced the number of alerts that the on-call person gets. The majority of the Open and Closed alerts are no longer bothering the on-call person in middle of the night
Being that SCOM is state based anything that is really down or causing an issue will still page the on-call person.