Sample Script

SYNTAX: MptoXml.ps1

Example: .\MpToXml.ps1 C:\Software\MPs\sealed C:\Software\MPs\unsealed

param($mpFilePath,$outputDirectory)

$MPs = Get-ChildItem $mpFilePath -recurse -include *.mp

$assembly = [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.OperationsManager")| out-null

foreach ($mp in $MPs){

    $mgmtpack = new-object Microsoft.EnterpriseManagement.Configuration.ManagementPack($mp)

    $mpWriter = new-object Microsoft.EnterpriseManagement.Configuration.IO.ManagementPackXmlWriter($outputDirectory)

    $mpWriter.WriteManagementPack($mgmtpack)

}

More PowerShell Resources for System Center

We have a growing collection of PowerShell samples for System Center and general administration. You can find them in the Downloads section and many on this page - PowerShell Scripts for System Center (Master Collection)

Follow System Center Central (via Twitter and RSS)

In my case, I wanted to take a comma-separated file containing 3 values on each line (line 1 being the header). My intent in this case was to

1. Loop through each record in the csv file

2. Assign each value to the appropriate variable

3. Call two PowerShell functions, passing the output of the first function into the second function. (this step is not actually core to the task of csv input, but just part of my requirements in this case)

Sample comma-separated list (with header and three values)

Parent,Child,WQLQuery
Value1,value2,value3
Value1,value2,value3
Value1,value2,value3

PowerShell Syntax (Sample) to Read Values as Inputs

#Pass in comma-separated list 

$List = Import-Csv C:\scripts\list.txt 

ForEach ($entry in $list){ 

$Parent = $($entry.Parent)

$Child = $($entry.Child)

$WQL = $($entry.WQLQuery) 

#Echo values to verify result (test purposes only)

Write-host $Parent 

Write-host $Child

Write-host $WQL 

#Call functions and pass values

$Value1= Function1 $Parent Server 1 0

Function2 Server $Child $Value1 $WQL 

#------------

# Functions

#------------

Function1 {

<function logic>

}

Function2 {

<function logic>

}

More PowerShell Resources for System Center

We have a growing collection of PowerShell samples for System Center and general administration. You can find them in the Downloads section and many on this page - PowerShell Scripts for System Center (Master Collection)

Follow System Center Central (via Twitter and RSS)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

'Declare variables
Dim objMOMAPI, objBag, wshShell

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

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

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

If ReadRegValue = 2 Then

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

Else

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

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

And now, the ConfigMgr version

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

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

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

If ReadRegValue = 2 Then

    'Return COMPLIANT
    WScript.Echo "Compliant"

Else

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

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

 Conclusion

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

Next Up….DCM and Heisenberg Uncertainty Principle

Follow System Center Central via Twitter and RSS

As it turns out, Daniele Muscetta (a well-known Microsoft PFE) has already written a script that does most of the hard work to export the unsealed management pack and then retrieve the overrides in a readable format. The need came out in our forum discussion for a means to get the output into a single report file. All that was required were some simple changes to 1) add the name of the source management pack to a report column and 2) output the report to a single file instead of one for each management pack.

So I started with Daniele's script here -

Command Shell: Dumping all overrides in Operations Manager 2007 (Script)

Here are the changes I made:

• Added logic to store the output of all the packs in a single variable 
• Added the -notypeinfo flag to rid the output of the type info line on each pass, which is garbage for our purposes
• Added an extra column to include the name of the management pack the override is stored in
• Moved the override name to the far right column. The name string is so long and unruly it clutters the report

And here's the result. Many thanks to Daniele for this and the many other amazing contributions to the OpsMgr community over the past 3 years.

Sample Script

Here is a copy of the updated script. Make sure to replace the $exportpath variable with the name of an existing directory.

# ==============================================================================================

# 

# NAME: OpsMgr Overrides Report 

# 

# AUTHOR: Daniele Muscetta and Pete Zerger

# DATE  : 8/24/2010

# 

# COMMENT: This report will output the overrides in your OpsMgr environment including 

#          override settings, target, source rule/monitor and source management pack.

# ==============================================================================================

#---Save the following text as script "Export-Overrides.ps1"

#define the path you want to export the CSV files to

$exportpath = "c:\scripts\export\"

#gets all UNSEALED MAnagement PAcks

$mps = get-managementpack | where {$_.Sealed -eq $false}

#loops thru them

foreach ($mp in $mps)

{

    $mpname = $mp.name

    Write-Host "Exporting Overrides info for Managemetn Pack: $mpname"

    #array to hold all overrides for this MP

    $MPRows = @()

    #Gets the actual override objects

    $overrides = $mp | get-override

    #loops thru those overrides in order to extract information from them

    foreach ($override in $overrides)

    {

        #Prepares an object to hold the result

        $obj = new-object System.Management.Automation.PSObject

        #clear up variables from previous cycles.

        $overrideName = $null

        $overrideProperty = $null

        $overrideValue = $null

        $overrideContext = $null

        $overrideContextInstance = $null

        $overrideRuleMonitor = $null

        # give proper values to variables for this cycle. this is what we can then output.

        $name = $mp.name 

        $overrideName = $override.Name

        $overrideProperty = $override.Property

        $overrideValue = $override.Value

        trap { $overrideContext = ""; continue } $overrideContext = $override.Context.GetElement().DisplayName

        trap { $overrideContextInstance = ""; continue } $overrideContextInstance = (Get-MonitoringObject -Id $override.ContextInstance).DisplayName

        if ($override.Monitor -ne $null){

            $overrideRuleMonitor = $override.Monitor.GetElement().DisplayName

        } elseif ($override.Discovery -ne $null){

            $overrideRuleMonitor = $override.Discovery.GetElement().DisplayName

        } else {

            $overrideRuleMonitor = $override.Rule.GetElement().DisplayName

        }

        #fills the current object with those properties

        #$obj = $obj | add-member -membertype NoteProperty -name overrideName -value $overrideName -passthru

        $obj = $obj | add-member -membertype NoteProperty -name overrideProperty -value $overrideProperty -passthru

        $obj = $obj | add-member -membertype NoteProperty -name overrideValue -value $overrideValue -passthru

        $obj = $obj | add-member -membertype NoteProperty -name overrideContext -value $overrideContext -passthru

        $obj = $obj | add-member -membertype NoteProperty -name overrideContextInstance -value $overrideContextInstance -passthru

        $obj = $obj | add-member -membertype NoteProperty -name overrideRuleMonitor -value $overrideRuleMonitor -passthru

        $obj = $obj | add-member -membertype NoteProperty -name MPName -value $name -passthru

        $obj = $obj | add-member -membertype NoteProperty -name overrideName -value $overrideName -passthru

        #adds this current override to the array

        $MPRows = $MPRows + $obj

    }

  #Store up the overrides for all packs to a single variable

  $MPRpt = $MPRpt + $MPRows

}

    #exports cumulative list of overrides to a single CSV

    $filename = $exportpath + "overrides.csv"

    $MPRpt | Export-CSV -path $filename -notypeinfo

You can find all sorts of PowerShell scripts for System Center products at PowerShell Scripts for System Center (Master Collection) or in our Downloads section.

Follow System Center Central via Twitter and RSS

]]> Tue, 24 Aug 2010 09:54:56 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/78323/Default.aspx I've been doing some working with the OpsMgr Command Shell of late and wanted to share an old sample from my script archive (from three years ago!) that may be a useful snippet for enterprise customers especially. Whether you're working with AD Integrated or script-based agent assignment in OpsMgr, it's a good idea to check from time-to-time to verify the agent counts reporting to each of your management servers and gateways is properly spreading the load across your management servers.

Here's a quick snippet that will parse the PrimaryManagementServerName property of your agent computers and return the count for each management server. Run this script and check the output.

• Is your environment properly balancing the load across management servers?
• Do you have agents reporting to the root management server?

Run this short script and find out.

Sample Script

Instructions: Change the value of the $rootMS variable to the name of your root management server and run from a PowerShell prompt on any computer with the OpsMgr Command Shell installed.

$rootMS = "MyRMS"

#Initialize the OpsMgr Provider

add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";

set-location "OperationsManagerMonitoring::";

#set Management Group context to the provided RMS

new-managementGroupConnection -ConnectionString:$rootMS;

set-location $rootMS;

$agent = get-agent | sort Name

$agent | Group PrimaryManagementServerName -Noelement | sort Name

More PowerShell Samples on System Center Central

SCC has PowerShell samples for a variety of System Center products. Have a look in our Downloads section or at this member post by Tommy Gunn with links to a variety of PowerShell samples

PowerShell Scripts for System Center (Master Collection)

Follow System Center Central via Twitter and RSS

]]> Fri, 20 Aug 2010 13:17:07 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/77885/Default.aspx This question came up in the forums recently. You could update this field with a custom PowerShell script run on a schedule. Samples of how to update alert fields in PowerShell can be found in many places, including http://poshcode.org/582 and  http://www.maartendamen.com/?p=40. These examples both update the custom fields of the alert. The field that needed an update in this example is Owner field. To do this simply requires understanding which method to call.

Retrieving Alerts

The first step is to retrieve the alert (or alerts) you wish to update. For example, you retrieve the alert based on your criteria. In this example, I chose to retrieve a specific alert by ID in this sample:

$alert = get-alert -id 'b363356a-d824-4697-afdd-41fb052750b7'

You could retrieve alerts using  any number of different criteria, such as these shown below.

get-alert -criteria 'ResolutionState = ''0'' AND IsMonitorAlert = ''False'''

get-alert -criteria 'ResolutionState = ''0'' AND Severity = ''2'' AND IsMonitorAlert = ''False'''

Note: Be sure to use the –criteria option rather than WHERE clauses…more on this in a moment.

Setting the Owner Field

Then set the owner field to whatever you like using the Set_Owner method. Put the owners name between the quotes. You could even retrieve a value from an external source like a CMDB or Active Directory and insert it here.

$alert.set_owner("george")

If you wanted to set this to actual values out of AD, you'll simply need to make the call to AD to find the info you wish, assign that to variable (e.g. $NewOwner='Domain\User') and then you the Set_Owner method as shown above. If you use the free Quest ActiveRoles extension for PowerShell, you can look up user info in a single line of code!

Scalability

The main thing to be very wary of in using the Command Shell for something like this is scalability. If your environment has thousands or even tens of thousands of alerts, you can easily cause performance issues in a management group with inefficient queries. You need leverage the built in criteria of the Command Shell cmdlets rather than using WHERE clauses (e.g. – get-alert | where  {$_.Name –like ‘myalert*’}). For more on why this is and how to avoid scalability issues, see the articles below from Marco Shaw and Craig Pero.

OpsMgr: Command Shell tips and tricks when using a criteria with a monitoring class

Why YOU should care about using CRITERIA when using SCOM cmdLets

Other PowerShell Samples

You can also find many PowerShell script examples for System Center and Windows management at PowerShell Scripts for System Center (Master Collection)

Follow System Center Central via Twitter and RSS

]]> Mon, 16 Aug 2010 09:33:49 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/77309/Default.aspx This is a question that came up in our DPM support forum recently (see original thread). And generally speaking, the answer is “yes”. DPM 2010 builds on the DPM 2007, so most scripts should be compatible on the new platform. As always, you want to be sure to test your scripts in a non-production environment first. you can find quite a few DPM scripts on the PowerShell Scripts page, some of which I have also listed here.

DPM 2007 Scripts (many or all of which should be DPM 2010 compatible)

• SQL Recovery Point Restore Script for SCDPM
• CLI Script: Manual detailed inventory of unknown tapes
• CLI Script: Run consistency check on invalid datasources
• CLI Script: Force mark tape as free
• CLI Script: Recover to latest point in time for a SQL DB
• CLI Script: Copy latest point in time of SQL DB to a folder
• DPM CLI: Quick reference help
• DPM CLI Scripts
• CLI: Grow your replica and shadow copy volume sizes automatically!
• CLI Script: Job object fundamentals
• CLI: Create new Recovery points on tape for all datasources in a PG
• CLI script: Create protection groups for Disk based backups
• DPM CLI> Hello World
• DPM CLI Tips 'n Tricks: Powershell Basics
• DPM CLI Tips 'n Tricks: Powershell Basics - Part II
• DPM PowerShell Script -- invoking a Consistency Check
• DPM 2007 Share Restore Recovery Point Script
• DPM 2007 Individual File Share Recovery Point Script

DPM 2010

• SQL Self Service Recovery using DPM 2010

Follow System Center Central via Twitter and RSS

A question came up in the forum for which I thought I'd present a couple of easy options:

How can I retrieve a list of installed patches from a computer managed by Operations Manager 2007?

The patch list is actually the PatchesEx property of Windows Installer (http://msdn.microsoft.com/en-us/library/aa369432(VS.85).aspx). You can simply query the computer via WMI via PowerShell instead of agent or healthservice object. We can also use a custom OpsMgr report to retrieve installed patches for a chosen computer.

PowerShell

Retrieving install patches is very easy in PowerShell (and there are many VBScript examples floating around as well). In PowerShell, patch retrieval is a one-liner

Get-WmiObject -Query 'select * from Win32_QuickFixEngineering'

You can then use a WHERE clause to filter on Source, Description, InstalledBy and InstalledOn and HotfixID.

Example (single line)

Get-WmiObject -Query 'select * from Win32_QuickFixEngineering' | where {$_.HotFixID -eq 'KB999111'}

WIth PowerShell 2.0 remoting, it's also quite easy to make the same call to remote machines if you wish

OpsMgr Reports

We have such a report in our OpsMgr Health Check Reports mgmt pack if you like.

SCC Health Check Management Pack Version 2

There is also a State View with this information in the OpsMgr 2007 R2 Core Monitoring MP recently released.

Follow System Center Central via Twitter and RSS

]]> Tue, 10 Aug 2010 00:58:55 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/76714/Default.aspx Every now and again I get requests for OpsMgr Operations and Web Console tweaks to allow control of console refresh, amount of data presented. There are several resources on SCC and TechNet blogs with good information. There were a few tips available for both the full Operations console and the Web console. You do want to be careful for one very important reason. Changing the amount of data returned or frequency of these requests results in

more data retrieved = more load on your database server = potentially slower console performance

Many of the shortcuts are harmless enough, just use with caution and carefully think through scenarios before implementing.

Resources

Console Tuning Options in Operations Manager 2007 – Collection of registry settings used to control many of the limits within the OpsMgr Operations Console. 

Undocumented SCOM Web console parameters – Several new settings within the config files of the Web Console which change some behaviors that may be of use.

R2 Web Console Options – Some new settings in the R2 Web Console.

OpsMgr Tip: How to change the default Web Console start view – How to create links to open Web Console to the view of your choice.

Operations Console Command Line Shortcuts – Command  line examples of how launch one or multiple console instances to a views of your choice

Samples

Based on most common requests, here are a couple of samples taken from Console Tuning Options in Operations Manager 2007

Task execution against multiple targets
The first of these limitations is the 10 object selection limit for Tasks. What if I want to run a task against 20 objects….or 50 objects? Here’s how to change the maximum number of objects you can select simultaneously and for which you can then run a task.

This can be adjusted through the following registry key:

• Path: HKCU \Software\Microsoft\Microsoft Operations Manager\3.0\Console\
• Keyword: TaskSelectedObjectsLimit (DWORD)
• Values:
• -1 (xFFFFFF) : unlimited number of objects allowed to be selected
• 0 : tasks are not going to be populated for selected items in the view
• N > 0 : maximum number of simultaneously selected objects for which tasks are going to be generated.

Maintenance Mode execution against multiple targets
By default, Ops Mgr 2007 Console can only put to 50 objects into maintenance at any one time. If you have increased the previous tweak beyond 50, then this feature can be a potential bottleneck, so use with caution, increasing in small increments, gauging performance along the way. To adjust the amount of objects that can be selected in the UI and simultaneously put into maintenance, just modify the following key:

Path: HKCU\Software\Microsoft\Microsoft Operations Manager\3.0\Console\ConsoleUserSettings\

Keyword: MaxItemsForMaintenanceMode (DWORD)

Operations Console Refresh Rate
By default, the Operations Console refreshes its cache after 1 minute of inactivity. The refresh occurs only if there has been no user activity in the given console instance for the duration of the refresh period. Default value is one minute, with a maximum of 10. Raising this value on workstations running the console is another way to reduce calls to the operations database. This can be adjusted through the following registry key:

Path: HKCU\Software\Microsoft\Microsoft OperationsManager\3.0\Console\CacheParameters\

Keyword: PollingInterval (DWORD)

NOTE: The CacheParameters key did not exist by default in our environment. Both CacheParameters and PollingInterval had to be created from scratch, but we did see the value being read once present.

Have a console shortcut you couldn’t find in these resources? Have a question – ask the experts in the SCC Support Forums.

Follow System Center Central via Twitter and RSS

]]> Thu, 05 Aug 2010 09:37:52 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/76033/Default.aspx Here’s an error message I first encountered in beta 2 of the original RTM that you may encounter when running MOMCertImport.exe

Error:

The certificate is valid, but importing it to certificate store failed.
Error description: Catastrophic failure
Error code: 8000FFFF
ImportPFXCertificate failed

Cause:

MOMCertImport will throw this error if, when you exported the certificate, you chose "export all certificates in path" in the export wizard. If you are using a command line utility to export the certificate (like certutil.exe), you may find you are exporting the entire certificate chain and don’t even know it. This is definitely true on Win2003 (where the ‘nochain’ parameter does not exist) or on Windows 7 / 2008 when you run certimport –privatekey –exportpfx is run without the ‘nochain’ option.

Fix:

Re-export the cert to pfx format, but do not check this box. then MOMCertImport will process the cert successfully. If you’re doing the export with a command line utility, switch over to VBScript (CAPICOM samples on the net) or PowerShell.

Follow System Center Central via Twitter and RSS

]]> Wed, 04 Aug 2010 02:30:46 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/75871/Default.aspx The latest update for OpsMgr connectors is now available…

System Center Operations Manager 2007 R2 Connectors Cumulative Update 2 (KB2274165)

Download details: System Center Operations Manager 2007 R2 Connectors Cumulative Update 2 (KB2274165)

Can I include the overrideable parameters in the alert description for my custom rule or monitor?

The answer to this is generally “no”. However, as with many situations in OpsMgr, there are always exceptions. This was pointed out by OpsMgr MP authoring guru Stefan Koell (code4ward.net) in a forum thread (HERE). Let’s take a look at an example of his suggested solution to this problem.  I was recently developing a custom script-based file size monitor in which I need to solve this problem.

My workflow looked like this:

The Challenge

In this case, the workflow I created accepted two inputs from the user as overrideable parameters:

1) The name of the file to check

2) the maximum size

To make the alert description as useful as possible to the operators, I wanted to include the following text:

“The current file size for is is larger than the user-defined threshold of .”

The problem is that there is no XPath replacement variable is available to include the used-provided values of the overrideable parameters in the alert description. Since the only value in the data source module output of the data source module passed to the next module in the workflow is the ActualFileSize, it is not a surprise really.

The Solution

The key point to finding a solution is contained in a portion of that last statement. If you want to include the values of FileName and FileSizeTheshold overrideable parameters, you need to find a way to pass those values in the data source module output. The solution is simple really. The PropertyBag (shown in the figure above) is a set of one or more name/value pairs passed to the data source output to next module in the workflow. Since in this example I was only interested in comparing the ActualFileSize to the user-defined FileSizeThreshold, ActualFileSize was all I put into the PropertyBag initially. However, the PropertyBag in this case has a secondary purpose that you can advantage of; as the vehicle to pass any value of interest to the next module in the workflow.

Think of the PropertyBag as a virtual container that will carry multiple name/value pairs that we can use in any way the product allows.  In this example, since the parameters are values assigned to variables in a VBScript anyway, it’s only two lines of code to add FileName and FileSizeTheshold to the PropertyBag resulting in a big payoff. We can now add the values of these parameters supplied by the user into the alert description (as shown in the figure below)

XPath Syntax

To can add any value in the PropertyBag to the alert description using the following the XPath syntax.

$Data/Context/Property[@Name='YourPropertyName']$

In this example, the value in alert description would look like this in the monitor definition.

“The current file size for $Data/Context/Property[@Name='FileName']$ is $Data/Context/Property[@Name='ActualFileSize']$ is larger than the user-defined threshold of $Data/Context/Property[@Name='FileSizeThreshold']$.”

When an alert is raised, we’ll now see the parameter values supplied by the user through overrides in the alert generated by the monitor inserted as part of the XPath variable replacement that occurs

Conclusion

Hopefully you found this tip useful. Since I was shooting for a quick example, I’ve not attached a management pack to this post. If you’d like to see the XML to demonstrate the concept, leave a comment on this post.

You can do this quite easily, although this may not be the most reliable way. Here’s a snippet to pull back a list of Health Service related alerts from an OpsMgr Command Shell prompt

$filename = "c:\temp\output\computer_list.txt"
$computer_list = get-alert | where {$_.MonitoringRuleId -eq "b59f78ce-c42a-8995-f099-e705dbb34fd4" -and `
                 $_.ResolutionState –eq 0} | Select-Object MonitoringObjectDisplayName;
$computer_list | out-file $filename;

Better is simply pulling back a list of unhealthy agents I think. We can all thank Andreas “Tenchuu Zuckerhut for this script, who’s a great PowerShell scripter (and almost old enough to enter a pub now I think).

$WCC = get-monitoringclass -name "Microsoft.SystemCenter.Agent"

$MO = Get-MonitoringObject -monitoringclass:$WCC | where {$_.IsAvailable -eq $false} 

$MO | select DisplayName

See http://www.systemcentercentral.com/BlogDetails/tabid/143/indexid/49552/Default.aspx  for a bit more background.

If you want to retrieve grey agents in SQL, there is a SQL query in that article, but I don’t recommend direct SQL queries if you can avoid it. If you want to pull any health-related info directly from SQL, I recommend using the report in the OpsMgr Health Check Management Pack. You can download that pack from the Community Management Pack Catalog at http://www.systemcentercentral.com/tabid/145/indexId/69990/Default.aspx

Follow System Center Central via Twitter and RSS

We are excited to announce that two important new server management capabilities will be available through purchasing Server Management Suite Enterprise (SMSE) and Server Management Suite Datacenter (SMSD) licenses.

Server Management Suites: New Capabilities and Price Change - Nexus SC: The System Center Team Blog - Site Home - TechNet Blogs

How to monitor a process on a multi-CPU agent using ScaleBy - Kevin Holman's OpsMgr Blog - Site Home - TechNet Blogs

• Brand the OpsMgr 2007 Web Console
• Securely publish to the Internet.
• Make sure the console is available both internally and externally from the URL shortcut in the alert description.

Everything you need to know to make this happen is contained within this four part series.

• Part 1 - Secure Publishing of the OpsMgr 2007 Web Console to the Internet
  
• Part 2 - Branding the Web Console in Operations Manager 2007 
• Part 3 - Publishing the Web Console through ISA 2004
• Part 4 - Customizing the Web Console URL in alert notifications

Follow System Center Central via Twitter and RSS

Q: What is the best practice for choosing a name for the management packs used to store my overrides in OpsMgr 2007 (or SC Essentials 2010)?

A: While there is an official Microsoft best practice for when and why to create an override pack in the first place, there is no official best practice for what to name your override packs. The right answer requires a bit of thought to your particular situation.

In the most simple scenario, I like to name my overrides packs with a 'Overrides – ' or 'OR – ' as the first element of the management pack name, as this causes the overrides packs to appear in a contiguous area of the drop down when we are creating overrides and need to select an overrides pack to store our changes. This basically makes the correct overrides pack easy to find. Since best practice is to create an (unsealed) overrides pack for each version of each sealed MP (that contains discovery or monitoring), override packs named in the format 'Overrides - ' name would be appropriate. For example, the management pack used to store overrides for Windows 2008 might be named 'Overrides – Windows 2008 OS'. Some examples are shown in the screenshot in the figure below.

MP Naming Considerations in Multi-tenant OpsMgr Deployments

The situation is somewhat different for situations where OpsMgr has been implemented as part of a multi-tenant monitoring and management solution. The challenge here stems from the pack that every agent generally receives a copy of every management pack (OpsMgr was not designed for multi-tenancy). While the location where the management packs are stored is not well known to novice users (such as customers in the multi-tenant scenario), the packs can be found. They are located in the '\\Health Service State\Management Packs\' directory on each agent managed computer – the default is \%ProgramFiles%\System Center Operations Manager 2007\Health Service State\Management Packs\'.

The problem for service providers stems from the fact that management packs are often created for individual customers to monitor specific aspects of a customers environment or to group servers for scoping purposes, such as for use in user roles, overrides and reporting. If management packs include the customer name, such as 'Web Monitoring - Customer A', it is possible that other customers being monitored (e.g. Customer B or Customer C) may notice a pack with 'Customer A' in the pack name and may demand an explanation. I've been involved in situations where I have been asked how to deal with this situation after a customer of the service provider has already made this discovery and raised this concern, which often necessitates an uncomfortable discussion.

Workaround

To avoid this situation, service providers may consider adopting a unique  'customer code' of some sort for each customer that makes the custom management packs purpose and target customer well-known to the service provider, but obfuscates the purpose from a customer perspective.  For example, Customer A could be 'C01', Customer B 'C02', etc. Such a naming convention would allow easy identification to the service provider and eliminate any concerns being raised by IT staff at monitored customer environments.

How have you tackled MP naming conventions in your OpsMgr environment? Leave your thoughts as comments on this post.

Follow System Center Central

RSS | TWITTER

• Trouble related to the WSUS code-signing certificates is a common occurrence many IT pros cannot resolve
• SCE has no Command Shell, so scheduled maintenance mode is very difficult for IT pros
• Reading SCE setup logs to identify the problem can even be challenging for some IT consultants 

The System Center Essentials 2010 Resource Kit addresses these issues and more with a set of tools meant to augment Essentials 2010 off the shelf functionality 

The System Center Essentials Resource Kit includes:

• Essentials Server Migration Advisor
• Published Software Certificate Update Tool
• Setup Log Parser
• Maintenance Mode Management Pack
• Computer Group Repair Tool
• Essentials Server Cleanup Tool

Essentials Server Migration Advisor
You can use this tool to move an Essentials 2010 management server installation to a different server. The tool backs up the installation on the source server and restores it on the target server.
Published Software Certificate Update Tool
The published software certificate update tool removes the existing software publishing certificate from the Essentials 2010 or Essentials 2007 management server and all managed computers, generates a new certificate, deploys the certificate to managed computers, and signs all locally published content with the new certificate.
Setup Log Parser
When you install System Center Essentials 2010, Setup creates SCESetupWizard.log and a set of related log files, depending on the features you chose to install, such as SQL Server, Reporting, and Virtualization Management. If installation fails, you can use this tool to get an easy-to-read-report that contains enough information to determine if the installation was successful and to highlight any issues.
Maintenance Mode Management Pack
System Center Essentials 2010 maintenance mode does not provide a way to schedule the maintenance mode start time to begin at a future time. Use this tool if you want to schedule a group of computers to enter maintenance mode at a fixed time in the future. For example, you may want to schedule a group of computers to be in maintenance mode every Friday and Saturday night at 11:00PM for a duration of three hours.
Computer Group Repair Tool
The computer group repair tool identifies and repairs broken relationships between System Center Operations Manager computer groups and their corresponding Windows Server Update Service (WSUS) computer groups.
Essentials Server Cleanup Tool
After an installation failure, you can run the Essentials Server Cleanup Tool to clean out files left over from the failed installation and restore the computer to a clear, preinstallation state so that you can start the installation over again. Note that the tool removes existing Windows Server Update Services (WSUS) certificates from the computer.

Download

You can download the Essentials 2010 Resource Kit at http://www.microsoft.com/downloads/details.aspx?FamilyID=32b2872a-a31d-4db1-abe8-018d91bf3942&displaylang=en. 

 Problem

When a report is run directly from SCOM 2007 R2, the report contains the expected graph and text data line (maximum value XXX, minimum value XXX, average value XXX). However, when the report is scheduled and sent by email only the text line is sent. Instead of the graph there is a empty space in the message.

Resolution

1. Add the following entries to the ReportingServicesService.exe.config file in the \ReportServer\bin folder on your Reporting Server.

2. After doing this, restart the SQL Reporting service

Background

When you build a .NET Framework application against a strong-named assembly, the application uses that version of the assembly at run time by default, even if a new version is available. However, you can configure the application to run against a newer version of the assembly. For details on how the runtime uses these files to determine which assembly version to use, see How the Runtime Locates Assemblies on this page in MSDN. In this case, the redirect is from a SQL 2005 version to SQL 2008 version (in fact, OpsMgr 2007 did not always support SQL 2008).

Issue and Resolution Reported By: Andreas "Tenchuu" Zuckerhut]]> Sat, 17 Jul 2010 01:50:07 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/73516/Default.aspx Since Quest announced they would provide Quest Management Extensions (QMX) for VMware monitoring for FREE (my very  favorite price!) for Operations Manager 2007, I've been implementing the solution for a couple of our customers in recent days. Since any third party solution for OpsMgr 2007 is a learning experience your first time out, I wanted to share some of what I've learned. In this post, I'll talk about some of the areas where I had the most questions initially and in future posts we'll review the solution architecture in greater depth.

• Data Sources
• Licensing
• Setup Instructions
• Minimizing Alert Noise
• How to Get Support
• Scaling Out (for enterprise)
• Service and Health Model (Classes, Relationships and Health Rollup)
• Under the Hood (how Quest works beneath the surface
• Hardware Monitoring for VMware

NOTE:

• Look for the Our Experience: labels throughout this article where I briefly mention our experience in each area of the installation and configuration process.
• In the coming days, I'll also create a proper article for our "ByExample" series, but wanted to get this information to you more quickly.

How QMX for VMware collects data

This QMX extension monitors VMWare Virtual Center servers using 3 different methods. You can mix and match these methods based on your VMWare architecture and to suit your monitoring needs. The 3 collection methods are:

• VMWare Infrastructure SDK (VI API) for Host and Guests ( see tab Perf_VISDKAPI and job Perf_VISDKAPI in tab __VirtualAgentJobs in QMX console)
• SNMP (traps) - (see job SNMPTRAP in tab __VirtualAgentJobs in QMX console)
• SNMP (get to check for availability) (see job SNMPWATCHDOG in tab __VirtualAgentsJobsin QMX console)

NOTE: You disable a method by removing the "Run" checkbox column for the job in tab __VirtualAgentJobs, click the Save button and stop/restart the Virtual Agent.

figure 1 – QMX for VMware solution architecture

Licensing

Since this Quest offering is now free, one of my first questions was "how do I get the free license for my customer?". This basically requires a simple e-mail request. This information is available on the Quest management-extensions.org website at http://management-extensions.org/entry.jspa?externalID=3794&categoryID=385. Note that only VMware monitoring via vCenter is free. Quest has an offering that probes the hosts directly, which has a cost. However, if you have vCenter, there is little reason to go the direct option.

Our Experience: We sent our first request on a Sunday and had the license Monday morning.

Setup Instructions

Most of the basic setup instructions are actually contained within the QMX Admin Console. Just highlight the VMware node in the QMX Console to see the Table of Contents

figure 2 – Instructions TOC within the QMX Console

Our Experience: We missed this the first time out and incorrectly setup some of the direct monitoring. RTFM (Read the Friendly Manual) is always important....so RTFM!

Minimizing Alert Noise (Tuning)

VMware ESX / vSphere and vCenter are enterprise technologies, so tuning is a big part of the implementation process no matter which solution you with. Here are some important tips for minimizing non-actionable alerts from QMX for VMware. In the QMX Console, you will find three tabs that contain settings key to adjusting QMX monitoring to your specifications (shown below).

_Performance_Rollups(VISDK) - This tab includes settings for performance rollups for enterprise components, including vCenter, DataCenter, Cluster and Resource Pool

_Performance_ESXServer(VISDK) – This tab includes settings for host performance metrics including ESX/vSphere Host CPU, Memory, Disk and Network, Host Resource Group CPU, Host Management Agent Memory

_Performance_VM(VISDK) - This tab includes settings guest performance metrics including Guest CPU, Guest Memory, Guest Disk, Guest Network, Guest Resource Group CPU and Uptime, Guest Management Agent Memory. In plain English, this data describes guest performance from a host perspective.

IMPORTANT (pay special attention here)

There are some adjustments that most administrators in mid-size business and small enterprise may want to change to minimize alert noise, including

What you will notice about the settings on each of these tabs is that

• "Auto Resolve Alert" is NOT SELECTED by default – This means you will have to close the alerts yourself unless you select this checkbox.
• Aggregate is set to 1 by default – This means alerts will be raised after a single sample breaches the threshold. A number greater than one means that number of consecutive threshold breaches are required to raise the alert, effectively resulting a recurring threshold monitor.
• Graph is selected by default – This means performance data will be collected and sent to the OperationsManager and Data Warehouse databases

In fact, before changing these defaults we asked support if there was any harm that could come from adjusting these defaults and the answer was "no". When we asked why the defaults are set as shown above, the answer was this:

auto-resolve is set to false by default because many NOCs have internal processes that require/mandate human intervention on ALL alerts and do not allow auto resolve.

Fair enough. So, as with every management pack, at the very least watch the alerts and do some tuning to eliminate noise alerts.

Our Experience: If you are not a NOC that mandates human intervention, you will definitely need to do some tuning. We chose to enable "Auto  Resolve Alert"  in most areas. We also bumped the Aggregate setting to two or three on most monitors to reduce alerts for transient (brief) spikes in performance. For our customer that doesn't use reporting or performance graphs a great deal, we also disabled a lot of the performance collection (performance is almost always your biggest contributor to database growth/bloat, so disable what you won't use. Since it's all in these three tabs, it was actually much faster than if we had been required to go set a bunch of overrides.

figure 3 – Configuration tabs within the QMX Console

 How to Get Support

You can register for free on the Quest Management Extensions website (http://management-extensions.org/forum.jspa?forumID=723&start=0) and ask questions in the support forums.

Our Experience: We posted questions and received answers the same day. Just look for questions from pzerger in the support forums at http://management-extensions.org/forum.jspa?forumID=723&start=0. I notice that the guys doing most of the answering are solution architects Gary Broadwater and Tony LaMark.

Conclusion and Up Next

I hope you find a few nuggets here that make your experience a good one. In the next post (or posts) we'll talk about

• Scaling Out (for enterprise)
• Service and Health Model (Classes, Relationships and Health Rollup)
• Under the Hood (how Quest works beneath the surface

  I'd be interested to hear your experiences with QMX for VMware if you have actually implemented. Please share your experiences in comments on this post. I'll try to supplement this info with more tuning experience as time passes in the article I'm working on for the "ByExample" series.

  You can read about all the available options for VMware monitoring with Operations Manager 2007 in my previous blog post VMware VI3 Monitoring Options for Operations Manager 2007.