Tag Archives: MimboloveAutomating OpsMgr

Automating OpsMgr Part 20: Migrating Your OpsMgr Performance Collection Rules to OMS (Using OpsLogix VMware MP as an Example)

Written by Tao Yang

OpsMgrExntededIntroduction

This is the 20th installment of the Automating OpsMgr series. Previously on this series:

OK, it has been 6 months since my last post on this blog series. I simply didn’t have time to continue on, but I know this is far from over. I am spending A LOT of time on OMS these days, some of you guys may have heard (or have already read) our newly published book Inside Microsoft Operations Management Suite (TechNet, Amazon). I’m hoping you guys all have played with OMS and maybe even have started thinking what workloads can you move to OMS.

As we all know, we can pretty much categorise SCOM data into the following 4 categories:

  • Performance Data
  • Event Data
  • Alert Data
  • State Data

Unlike SCOM, since OMS does not use classes, there are no classes, relationships and state data in OMS, but for the other 3 types, we can easily get them over to OMS. With the SCOM alert data, you can simply enable the Alert solution after you have connected your SCOM management group to your OMS workspace. OMS also has its own alerting and remediation capability. For all existing performance collection and event collection rules, we can easily recreate them using a different Write Action module to store these data into OMS. In this post, I will show you how we can gather all performance collection rules from an existing OpsMgr management pack, and re-create these them for OMS (stored as PerfHourly data in OMS). But before we diving into it, let’s quickly go through the performance data in OMS.

OMS Performance Data

There are 2 types of performance data in OMS. The PerfHourly data was introduced with the Capacity Planning solution. As the name suggests, PerfHourly data is the hourly aggregated performance data. It does not store any raw perf data in OMS.

Another type of performance data is called Near-Real Time (NRT) performance data. NRT perf data can be access using queries such as Type=Perf. Unlike the PerfHourly data, NRT perf data can collect perf data as frequent as every 10 seconds, and the aggregation interval is every half hour. Both raw and aggregated NRT perf data are stored in OMS, where raw data is stored for 14 days and the OMS search queries only return aggregated data.

From the management pack point of view, it is a lot more complicated writing perf collection rules for NRT perf data. With the NRT perf data, we must always author 2 rules for every counter that we are going to collect, one for the raw data and one for the aggregated data. Secondly, for NRT perf data, when mapping performance data, the object name must always follow the format “\\<Computer FQDN>\<Object Name>”. Lastly, the collection rule that collects the aggregated data must use a Condition Detection module called “Microsoft.IntelligencePacks.Performance.PerformanceAggregator”.

Since an OpsMgr rule can only have up to one (1) condition detection member module, converting existing OpsMgr perf collection rules that already have an existing condition detection member module to OMS NRT perf rule may not be that straight forward. In this case, we may need to create some additional module types and things can get very complicated. It is certainly not something that we can use a generic script to achieve.

Therefore in order to make the script work with any existing OpsMgr performance collection rules, I have chosen to store the perf data in OMS as PerfHourly data because it has far less “red tapes”. Having said that, please keep in mind it is still possible to re-create OpMgr perf collection rules as OMS NRT perf collection rules, but it’s just not something we can develop as a generic automated solution.

If you want to learn more about performance data in OMS, or how to author OMS based collection rules in SCOM using VSAE, please refer to Chapter 5: Working with Performance Data and Chapter 11: Custom Management Pack Authoring of the Inside OMS book I mentioned in the beginning of this post.

PowerShell Script: Copy-PerfRulesToOMS.ps1

In the previous posts of this blog series, I have simply placed the scripts / runbooks within the post it self. I have decided to use Github from now on. So the script Copy-PerfRulesToOMS.ps1 can be found in one of my public Github repositories: https://github.com/tyconsulting/OpsMgr-SDK-Scripts/blob/master/OMS%20Related%20Scripts/Copy-PerfRulesToOMS.ps1

This script reads configurations of all performance collection rules in a particular OpsMgr management pack, and then recreate these rules with same configuration but stores the performance data as PerfHourly data in your OMS workspace. The OMS perf collection rules created by this script will be stored in a brand new unsealed MP with the name ‘<Original MP name>.OMS.Perf.Collection’ and display name ‘<Original MP display name> OMS PerfHourly Addon””’.

This script has the following pre-requisites:

  • OpsMgrExtended PS module loaded on the machine where you are executing the script.
  • An account with OpsMgr administrative rights
  • OpsMgr management group must be connected to OMS

The script takes the following input parameters:

  • ManagementServer – Specify the name of an OpsMgr management server that you wish to connect to. This is a mandatory parameter.
  • Credential – Specify an alternative credential that has admin rights to the OpsMgr management group. This is an optional parameter.
  • ManagementPackName – Specify the source MP where you want to copy to Perf collection rule to OMS. This is not the display name but the actual MP name. In the OpsMgr console, when you open the management pack property, it is the ‘ID’ field. i.e. since I’m going to use the OpsLogix VMware management pack as an example in this post, the name for this MP is “OpsLogix.IMP.VMWare.Monitoring”:

image

 

Executing the script:

I have added many verbose messages in the script, so you can use the optional –verbose switch when executing the script.

SNAGHTMLd5d2347

This script firstly connect to the management group, read the source MP, then retrieves all performance collection rules from this MP. If the source MP contains any perf collection rules, it will create a new unsealed MP and start creating a co-responding OMS PerfHourly collection rule for each original OpsMgr perf collection rule. the OMS PerfHourly collection rules will have the same properties, input parameters as well as the same data source and condition detection member modules as the original OpsMgr Perf Collection rules. But they will be configured to use another Write Action member module to send the perf data to OMS.

Note:

  • The script detects OpsMgr Perf collection rules from the source MP by examining the actual write action member modules. If any of the write action member modules are either ‘Microsoft.SystemCenter.CollectPerformanceData’ (used to write perf data to OpsMgr operational DB) or ‘Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData’ (used to write perf data to OpsMgr DW DB), then the script will consider the rule as a perf collection rule.
  • When the source MP is unsealed, the script will failed under the following circumstances:
    • a perf collection rule in the source MP is targeting a class defined in the source MP
    • a perf collection rule in the source MP uses any data source or condition detection module types that are defined in the source MP
  • The script does not disable any existing perf collection rules from the source MP
  • The script copies all attributes from the source perf collection rule to the new OMS PerfHourly rule, including the ‘Enabled’ property. So if the source perf collection rule is disabled by default, then the newly created OMS PerfHourly rule will also be disabled by default.
  • Depending on the number of OpsMgr Perf Collection rules to be processed, this script can take some time to finish because it is writing new OMS PerfHourly rules to the destination MP one at a time. I purposed coded the script this way (rather than writing everything at once), is because by doing so, if a particular rule has failed MP verification, it would not impact the creation of other rules.

When the execution is completed, you will see a new unsealed MP created in your management group:

image

and if I export it to XML and open it in MPViewer, I can see all the newly created OMS PerfHourly collection rules:

image

At this stage, I don’t need to do anything else and all the performance data collected by the source MP (OpsLogix VMware MP in this example) will be stored not only in OpsMgr, but also in OMS.

Because the original OpsMgr perf collection rules and the co-responding OMS PerfHourly rules are sharing the exact same data source modules with same configuration, this would not add additional overhead to the OpsMgr agents due to the OpsMgr Cook Down feature. However, please keep in mind that from now on, if you need to apply overrides to the either rule, it’s best to apply the same override to both rules (so you don’t break Cook Down).

Although the PerfHourly data will not appear in your OMS workspace straightaway (due to the aggregation process), you should be able to see them within few hours:

image

As you can see in the above screenshot, I now have all the VMware related counters defined in the OpsLogix VMware MP in my OMS workspace. the RootObjectName ‘VCENTER01’ is the vCenter server in my lab, and the ObjectDisplayName ‘exs01.corp.tyang.org’ is the VMware ESX host in my lab.

Summary

In this post, I have shared a script and demonstrated how to use this script to migrate your existing OpsMgr performance collection rules to OMS. We can easily write a very similar script for migrating existing event collection rules (maybe a blog topic for another day). I have demonstrated how to use this script to collect VMware related counters originally defined in the OpsLogix VMware MP.

In the next post of this series, I will demonstrate how to use OpsMgrExtended module, SharePointSDK module, Azure Automation, Hybrid Workers and SharePoint Online to build a portal for scheduling OpsMgr maintenance mode – this is based on one of the demos in my Azure Automation session with Pete Zeger from SCU 2016 APAC & Australia.

Until next time, happy automating!

Automating OpsMgr Part 19: Creating Any Types of Generic Rules

Written by Tao Yang

OpsMgrExntededIntroduction

This is the 19th instalment of the Automating OpsMgr series. Previously on this series:

Although I have written number of functions in the current version of the OpsMgrExtended module that allows you to  create some popular types of rules in OpsMgr (i.e. perf collection rules and event collection rules). Sometimes, you still need to create other types of rules, such as WMI event collection rules, or rules based on module types written by yourself. In this post, I will demonstrate how to create any types of rules using the New-OMRule function.

Additionally, since the OpsMgrExtended module can be used on both your on-prem SMA infrastructure as well as on your Azure Automation account (with the help of Hybrid Workers), and pretty much all the previous runbooks and posts are based on SMA, I will use Azure Automation in this post (and maybe in the future posts too). I will demonstrate 2 sample runbooks in this post. Since Azure Automation now supports PowerShell runbooks on both Azure runbook workers as well as on hybrid workers, with the 2 sample runbooks I’m going to demonstrate, one is based on PowerShell workflow and the other one is a PowerShell runbook.

What Components are OpsMgr Rules Made Up?

Before we diving into the sample runbooks, please let me explain how are the OpsMgr rules made up. In OpsMgr, a rule is essentially a workflow that contains the following components:

  1. One or more Data Source modules
  2. Zero or one Condition Detection Modules
  3. One or more Write Action modules

To explain in plain English, a rule can have multiple data source modules and write action modules, but condition detection module is optional, and you can only use up to 1 condition detection module in your rule. The order of execution is Data Source Modules –> Condition Detection Module –> Write Action Modules. Additionally, some modules requires mandatory and/or optional configuration parameters (i.e. System.SimpleScheduler), some modules do not require any configuration parameters (i.e. Microsoft.SystemCenter.CollectPerformanceData).

OM-Rule Design Consideration

When I was writing the New-OMRule function, I have realised in order to capture all required information for each member module, the following information is required:

  • Module Type Name (Mandatory)
  • Configuration (Optional)
  • Member Module Name (Mandatory)
  • RunAs Profile Name (Optional)

i.e. in the example below, I have high lighted the information required in a member module of a rule.

image

Other than the information listed above, if we are writing an alert-generating rule, we would also need the following information for the alert configuration:

  • String Resource
  • Language Pack ID
  • Alert Name
  • Alert Description

I needed to figure out a way to enforce users to supply all required information listed above. In order to do that, I think the best way is to define a class for member module configurations and another class for alert configurations. However, since class definition is a new concept only been introduced in PowerShell version 5 (which still in preview other than Windows 10 machines at the time of this writing), I could not do this natively in PowerShell. In order to work around this limitation, I have defined these two classes in OpsMgrExtended.Types.dll using C#. This DLL is shipped as part of the OpsMgrExtended module.

image

The OM-Rule is expecting instances of these classes defined in OpsMgrExtended.Types.dll as input parameters. You will see how I used these classes in the sample runbooks.

Sample PowerShell Runbook: New-WMIPerfCollectionRule

OK, let’s start with a “simpler” one first. The New-WMIPerfCollectionRule runbook is a PowerShell runbook that can be used to create perf collection rules based on WMI queries. I think it’s simpler than the other one because it’s a PowerShell runbook (as opposed to PowerShell workflow) and we don’t have to worry about configuring alerts for the rules created by this runbook. The source code for this runbook is listed below:

As you can see, this runbook requires the following input parameters:

  • RuleName – the internal name of the rule
  • RuleDisplayName – the display name of the rule. this is what people will see in OpsMgr console
  • ClassName – The internal name of the target class (i.e. “Microsoft.Windows.OperatingSystem”)
  • WMINameSpace – the WMI name space of where the WMI class you are going to query resides. This is optional. if not specified, the default value of “Root\CIMV2” will be used
  • WMIQuery – the WMI query to retrieve the performance counter value
  • IntervalSeconds – the rule execution interval in seconds. this is optional, if not specified, the default value of 900 (15 minutes) will be used.
  • ObjectName – The object name for the performance data (i.e. Process, or LogicalDisk)
  • CounterName – the counter name for the performance data (i.e. ProcessCount, or FreeSpaceMB)
  • InstanceNameWMIProperty – the property returned from the WMI query which represent the performance data instance value (i.e. if you are collecting logical disk counters, the result of WMI query may contain a property that represent the drive letter, which can be used to identify the instance in perf data). This is optional, if not specified, the perf data instance name would be “_Total”.
  • ValueWMIProperty – the property returned from the WMI query that represent the perf value.

The first step of this runbook is to retrieve a connection object named “OpsMgrSDK_Home” from my Azure Automation account (or SMA). This connection object is pre-configured, which contains the computer name of one of my OpsMgr management servers, and the credential of a service account which has OpsMgr admin privilege in my management group.

SNAGHTMLddea7c

The runbook also needs to explicitly import the OpsMgrExtended module. During the test, I found for this PowerShell runbook, I must manually import the module using Import-Module cmdlet in order to load the assemblies defined in the OpsMgrExtended.Types.dll. Since we are going to be using hybrid workers, you must manually deploy this module to your hybrid workers because at the time of this writing, Azure Automation is not able to automatically deploy required modules to hybrid workers.

Next, we must define the module configurations for each member module used by the WMI perf collection rules that this runbook creates. I have determined this type of rules should be configured using the following modules

  • One Data Source Module
    • Microsoft.Windows.WmiProvider
  • One Condition Detection Module
    • System.Performance.DataGenericMapper
  • Three Write Action Modules
    • Microsoft.SystemCenter.CollectPerformanceData
    • Microsoft.SystemCenter.DataWarehouse.PUblishPerformanceData
    • Microsoft.SystemCenter.CollectCloudPerformanceData

To explain in English, the rules created by this runbook would periodically execute a WMI query (Data source module), then map the result from WMI query to OpsMgr performance data (Condition detection module), finally store the performance data in OpsMgr operational DB, data warehouse DB and also OMS workspace (3 write action modules).

So we will need to use the New-OMModuleConfiguration function from the OpsMgrExtended PS module to create an instance of the “OpsMgrExtended.ModuleConfiguration” class. As explained earlier, the “OpsMgrExtended.ModuleConfiguration” class is defined in the OpsMgrExtended.Types.dll. Take the data source member module as an example:

I have placed the module type name, module configuration and the member module name into separate variables and passed them to the New-OMModuleConfiguration function and created a module configuration object for the data source module.

Note:

You can use Get-Help New-OMModuleConfiguration to access the help file for this function. If you need to use an alternative OpsMgr RunAs profile to for any member modules, you can also specify the name of the RunAs profile you are going to use with the –RunAsMPName and the –RunAsName parameter. The RunAsMPName parameter is used to specify the internal name of the management pack that defined the RunAs profile, and the RunAsName parameter is used to specify the internal name of the RunAs profile (i.e. if you are creating rules for SQL related classes, you might need to use the default SQL RunAs Profile, in this case, the –RunAsMPName would be “Microsoft.SQLServer.Library” and –RunAsName would be “Microsoft.SQLServer.SQLDefaultAccount”.)

Since a rule can have multiple data source modules and multiple write action modules, the New-OMRule function is expecting the array type of input for data source modules and write action modules. This is why even there is only going to be one data source member module or write action member module, we still need to place them into separate arrays before passing into the OM-Rule function:

image

image

On the other hand, since the condition detection member module is optional, and you can only have maximum one condition detection member module, you do not need to place the module configuration object for the condition detection module into an array.

Lastly, I have hardcoded the management pack name to be “Test.OpsMgrExtended” in this sample runbook. this MP must be created prior to running this runbook otherwise it would fail. However, if you have a look at the sample runbooks in previous posts, you can easily figure out a way to firstly detect the existence of this MP and use this runbook to create the MP if it does not exist in your management group.

Now, it’s time to take this runbook for a test run. I’m using the following parameters during the test run:

  • RuleName: “Test.WMIPerfCollection.Process.Count.WMI.Performance.Collection.Rule”
  • RuleDisplayName: “Windows Server Process Count Performance Collection Rule”
  • ClassName: “Microsoft.Windows.OperatingSystem”
  • WMIQuery: “select Processes from Win32_PerfRawData_PerfOS_Objects”
  • ObjectName: “Process”
  • CounterName: “ProcessCount”
  • ValueWMIProperty: “Processes” –verbose

And I have specified to run on a hybrid worker group:

SNAGHTMLd3df42

The hybrid worker will pick up this job very soon, and during this test run, the job was completed around 2 minutes. after the job finishes, I’m able to find this rule in OpsMgr console:

image

image

Sample PowerShell Workflow Runbook: New-WindowsEventAlertRule

Now, let’s take a look at the second sample runbook. This runbook is designed to create rules that detects certain event log entries and generates alerts upon detection. I think it’s more complicated than the first sample because this is a traditional PowerShell workflow runbook (which works on both SMA and Azure Automation), and we also need to configure alert settings for this rule. The source code for this runbook is listed below:

This runbook takes the following input parameters:

  • RuleName – the internal name of the rule that you are creating
  • RuleDisplayName – the display name of the rule
  • ClassName – The internal name of the target class (i.e. “Microsoft.Windows.OperatingSystem”)
  • EventLog – the name of the event log (i.e. “System”)
  • EventID – the ID of the event that you are detecting
  • EventSource – is what you see as “source” in Windows event log
  • EventLevel – can be one of the following value:
    • Success
    • Error
    • Warning
    • Information
    • Audit Failure
    • Audit Success
  • AlertName – the alert name / title
  • AlertSeverity – can be one of the following value:
    • Critical
    • Warning
    • Information
  • AlertProirity – can be one of the following value:
    • Low
    • Medium
    • High

As you can see, firstly, other than the standard process of retrieving the connection object for my OpsMgr management group, I have used several “Switch” statements with inline scripts to translate the event level, alert priority and alert severity from English words (string) to numbers (integer), because when configuring member modules for OpsMgr rules, we must use the number (instead of names). Note I’ve also used “ValidateSet” to validate the input of these parameters, so only valid inputs are allowed.

I am not going to explain the member module configurations again, because I’ve already covered it in the first sample. But please note because the rules created by this runbook will be generating alerts, we must configure alert settings. In OpsMgr, when a workflow is configured to generate alerts (either rules or monitors), other than the rule / monitor itself, we must also define a String Resource for the alert message ID, as well as defining the alert name and description in a preferred language pack (by default, ENU). Therefore, we are going to use another class defined in OpsMgrExtended.Types.dll for alert configuration. The class for alert configuration is called OpsMgrExtended.AlertConfiguration, and you can use New-OMAlertConfiguration function to create an instance of this class. Same as all other functions in the OpsMgrExtended PS module, you can use Get-Help cmdlet to access the help file for New-OMAlertConfiguration. You will need to specify the following input parameters for New-OMAlertConfiguration:

  • AlertName – the name / title of the alert
  • AlertDescription – the alert description / detail
  • LanguagePackID – the 3-letter language pack code for the language pack that you wish to create the alert message under. this is an optional parameter, if not specified, the default value of “ENU’’ will be used.
  • StringResource – the ID for the alert string resource

As you can see, since the write action member module for the rules created by this runbook would be “System.Health.GenerateAlert”, and we are defining <AlertMessageId> and <AlertParameters> in the write action member module configuration:

image

The String Resource must match the AlertMessageId:

image

And if you have previously authored OpsMgr management packs, you’d probably already know how to define the <AlertParameters> section for the alert description. Basically, any variables you are using in the alert description must be defined in the <AlertParameters> section, then in the alert description, you’d reference them using “{}” and a number inside. <AlertParameter1> becomes {0}, <AlertParameter2> becomes {1}, and so on. You can up to define 10 alert parameters:

image

Since you can define multiple alert messages (for multiple language packs), when you are creating alert generating rules, the New-OMRule function would expect you to pass in an array that contains OpsMgrExtended.AlertConfiguration objects. So, even if you are only defining the alert in one language pack, please still place it into an array before passing to the New-OMRule function:

image

OK, now, let’s give this runbook a test run with the following parameters:

  • RuleName: “Test.Disk.Controller.Event.Alert.Rule”
  • RuleDisplayName: “Disk Controller Error Event Alert Rule”
  • ClassName: “Microsoft.Windows.OperatingSystem”
  • EventLog: “System”
  • EventID: 11
  • EventSource: “Disk”
  • EventLevel: Error
  • AlertName: “Windows Disk Controller Error”
  • AlertSeverity: Critical
  • AlertPriority: High

SNAGHTML1055790

After the hybrid worker in my lab executed the runbook, I am able to see the rule created in OpsMgr console:

image

image

and the raw XML (once I’ve exported the MP):

image

Hybrid Worker Configuration

Since the samples in this post are all based on Azure Automation and Hybrid worker, I just want to point out this article if you need help setting it up: https://azure.microsoft.com/en-us/documentation/articles/automation-hybrid-runbook-worker/

Also as I mentioned earlier, you will need to deploy OpsMgrExtended module manually on to the hybrid workers by yourself. When copying the OpsMgrExtended module to your hybrid workers, make sure you copy to a folder that’s listed in the PSModulePath environment variable. During my testing with a PowerShell runbook, I initially placed it under “C:\Program Files\WindowsPowerShell\Modules” folder, as it was listed in the PSModulePath environment variable when I checked in a PowerShell console on the hybrid worker. However, I got error messages telling me the runbook could not find commands defined in the OpsMgrExtended module. To troubleshoot, I wrote a simple PowerShell runbook:

image

and based on the output, the folder in “C:\Program Files” is not listed!

image

Therefore, I had to move the module to another location (C:\Windows\System32\WindowsPowerShell\v1.0\Modules). after the move, the runbook started working.

Summary

In this post, I have demonstrated how to use the New-OMRule function from OpsMgrExtended PS module to create any types of rules in OpsMgr. Although OpsMgrExtended module has already shipped two other functions to create event collection and performance collection rules, the New-OMRule fills the gap that allows users to specify each individual member module and its configurations. This is probably the most technically in-depth post in the Automating OpsMgr series. I have tried my best to explain and demonstrate how to use the New-OMRule function. But if you are still unclear, have questions or issues, please feel free to contact me.

I haven’t figured out what I will cover in the next post, but I still have a lot to cover in this series. Since I am attending few conferences in the coming weeks in November, I probably won’t have time to work on part 20 until end of November. Until next time, happy automating!

Automating OpsMgr Part 18: Second Update to the OpsMgrExtended Module (v1.2)

Written by Tao Yang

OpsMgrExntededIntroduction

This is the 18th instalment of the Automating OpsMgr series. Previously on this series:

Before I diving into the topic of creating generic rules using the New-OMRule function from the OpsMgrExtended module, I have updated this module again. It is now on version 1.2.

I was working on another project and I needed to use the New-OMRule function to create rules and I realised this function did not support specifying optional RunAs accounts for member modules. As I needed to create rules that use a RunAs account in the data source module, I had to update this function to accommodate it.

Additionally, as I mentioned in the previous post (Part 17), there is a bug in the New-WindowsServiceTemplateInstance function, where the description field is not populated. I have also fixed it in this release.

What’s New?

So, in summary, here’s what’s changed:

  • Updated OM-Rule function to allow specifying optional RunAs profile for each member module.
  • Fixed the issue in New-WindowsServiceTemplateInstance function where the description field is not populated.

Where to Download V1.2?

I have updated the original link, so you can download this updated version at TY Consulting’s web site: http://www.tyconsulting.com.au/portfolio/opsmgrextended-powershell-and-sma-module/

Conclusion

Now that I’ve updated and enhanced the New-OMRule function I will demonstrate how to create rules using this function as planned in the next module.

Automating OpsMgr Part 17: Creating Windows Service Management Pack Template Instance

Written by Tao Yang

OpsMgrExntededThis is the 17th instalment of the Automating OpsMgr series. Previously on this series:

Now that I have demonstrated how to create basic Windows service monitors using New-OMServiceMonitor, in this post, I’ll demonstrate how to use the OpsMgrExtended module to create an instance of the “Windows Service” management pack template:

image

The OpsMgrExtedned module comes with a function called New-OMWindowsServiceTemplateInstance. Same as all other functions in this module, it is fully documented, you can access the help document using Get-Help cmdlet:

Get-Help New-OMWindowsServiceTemplateInstance –Full

SNAGHTML2e5dc32

Sample Runbook New-WindowsServiceTemplateInstance

I have hardcoded the following parameters in the runbook:

  • SMA OpsMgr connection object name (which you will need to change to suit your environment)
  • (Unsealed) MP (where the rule  is going to be saved to) – “TYANG.Test.Windows.Monitoring”

Additionally, this runbook will firstly try to retrieve the management pack from the management group, if the MP deosn’t exist, it will create it first.

This runbook takes the following input parameters:

  • InstanceDisplayName– The Display name of the template instance.
  • InstanceDescription– This is an optional parameter. The description of the template instance.
  • TargetGroupName– The name of the target group
  • ServiceName–The name of the Windows service (i.e. w32time)
  • LocaleId– The 3-letter MP language pack locale ID. This is an optional parameter, if not specified, it will be set to “ENU”.
  • CheckStartupType– Set this Boolean parameter to True if you only want to monitor automatic service. More details about this parameter can be found from Kevin Holman’s blog post Monitoring Windows Services – Automatic, Manual, and Disabled, using CheckStartupType
  • CPUPercent– Specify the threshold for CPU Usage Percentage. This is an optional parameter, if not specifiied, the CPU Usage will not be monitored or collected.
  • MemoryUsageMB– Specify the threshold for Memory Usage (MB). This is an optional parameter, if not specifiied, the Memory Usage will not be monitored or collected.
  • ConsecutiveSampleCount– Specify the the number of (consecutive) samples for the CPU and Memory counters, This is an optional parameter. if not specified, the value is set to 2 (which is the default value when using the wizard in the OpsMgr console).
  • PollingIntervalInSeconds- Specify sample polling interval (in seconds). This is an optional parameter, if not specifiied, the value is set to 300 (which is the default value when using the wizard in the OpsMgr console).

To help you visualise what are these parameters mean, I’ve mapped them to the fields in the GUI wizard:

image

image

image

Runbook Execution Result:

image

A Known Issue

When I was writing the sample runbook, I found a small bug in the OpsMgrExtended module. You may noticed from the screenshots above, that the description field is not populated. I have found the cause of this issue and fixed it in my lab. This fix will be shipped with the next release. So please just be aware of this issue, I don’t think it’s too critical.

Conclusion

In this post, I have demonstrated how to create Windows Service MP template instances using the OpsMgrExtended module. This concludes the topics of monitoring Windows services. In the next module, I will demonstrate how to create any types of generic rules by specifying the configuration of each member module (Data Source, Condition Detection and Write Action) using the New-OMRule function. Until next time, happy automating!

Automating OpsMgr Part 16: Creating Windows Service Monitors

Written by Tao Yang

OpsMgrExntededIntroduction

This is the 16th instalment of the Automating OpsMgr series. Previously on this series:

I will dedicate this post and the next post to creating monitoring solutions for Windows services. In this post, I will demonstrate how to create a basic Windows service monitor using the New-OMServiceMonitor function from the OpsMgrExtended module.

You can access the help document for this function using the Get-Help cmdlet:

Get-Help New-OMServiceMonitor –Full

SNAGHTMLb42d9c

Sample Runbook: New-ServiceMonitor

I have hardcoded the following parameters in the runbook:

  • SMA OpsMgr connection object name (which you will need to change to suit your environment)
  • (Unsealed) MP (where the rule  is going to be saved to) – “TYANG.Test.Windows.Monitoring”

Additionally, this runbook will firstly try to retrieve the management pack from the management group, if the MP deosn’t exist, it will create it first.

This runbook takes the following input parameters:

  • ClassName – The name of the target monitoring class (i.e.Microsoft.Windows.Server.OperatingSystem)
  • UnhealthyState– The unhealthy state of the monitor (either warning or error).
  • ServiceName–The name of the Windows service (i.e. w32time)
  • IgnoreStartupType– Set this Boolean parameter to True if you want the monitor to become unhealthy and generate alerts even when the service startup type is not set to “Automatic”. More details about this parameter can be found from Kevin Holman’s blog post Monitoring Windows Services – Automatic, Manual, and Disabled, using CheckStartupType
  • UnhealthyWhenRunning – Set this Boolean parameter to True when you want the monitor to become unhealthy and generate alert when the service is running (instead of stopped)
  • MonitorDisabled– Boolean, whether the event monitor should be disabled by default
  • MonitorDisplayName– Display name of the unit monitor
  • MonitorName – The name of the unit monitor
  • ParentMonitor – The parent dependency monitor for the event unit monitor

Runbook Execution Result:

image

Monitor Properties from OpsMgr Console:

image

image

image

image

Conclusion

In this post, I have shown how to create a basic windows service monitor using a simple SMA / Azure Automation runbook with New-OMServiceMonitor function in the OpsMgrExtended module. In the next post, I will show you how to create an instance of the Windows Service management pack template using the OpsMgrExtended module.

Automating OpsMgr Part 15: Creating 2-State Event Monitors

Written by Tao Yang

OpsMgrExntededIntroduction

This is the 15th instalment of the Automating OpsMgr series. Previously on this series:

It’s been almost a month since the last post on this series, partially because I was working on the OpsMgr Self Maintenance MP v2.5. Previously on Part 14, I have demonstrated how to create an event collection rule using the OpsMgrExtended module. Today, I’ll show you how to create a 2-State event monitor using the New-OM2StateEventMonitor function from the OpsMgrExtended module.

Like all other functions in this module, it has been fully documented, with few examples, which can be accessed using Get-Help cmdlet:

Get-Help New-OM2StateEventMonitor –Full

SNAGHTMLb9099e1

Runbook: New-2StateEventMonitor

I have hardcoded the following parameters in the runbook:

  • SMA OpsMgr connection object name (which you will need to change to suit your environment)
  • (Unsealed) MP (where the rule  is going to be saved to) – “TYANG.Test.Windows.Monitoring”

Additionally, this runbook will firstly try to retrieve the management pack from the management group, if the MP deosn’t exist, it will create it first.

This runbook takes the following input parameters:

  • ClassName – The name of the target monitoring class (i.e.Microsoft.Windows.Server.OperatingSystem)
  • UnhealthyEventID – The Event ID for the unhealthy event.
  • HealthyEventID – The Event ID for the healthy event.
  • UnhealthyState– The unhealthy state of the monitor (either warning or error).
  • EventLog –The name of the event log (i.e. Application, System, etc)
  • Publisher– The event publisher
  • MonitorDisabled– Boolean, whether the event monitor should be disabled by default
  • MonitorDisplayName– Display name of the unit monitor
  • MonitorName – The name of the unit monitor
  • ParentMonitor – The parent dependency monitor for the event unit monitor

Runbook Execution Result:

image

Monitor Properties from the OpsMgr operations console:

General:

image

Unhealthy Event:

image

image

Healthy Event:

image

image

Alert Setting:

image

Conclusion

In this post, I’ve demonstrated how to create a 2-state event monitor using the OpsMgrExtended module. now that I have covered both even collection rules and even monitors, I will dedicate the next 2 posts on monitoring Windows services.

Automating OpsMgr Part 14: Creating Event Collection Rules

Written by Tao Yang

OpsMgrExntededIntroduction

This is the 14th installment of the Automating OpsMgr series. Previously on this series:

Previously in part 12 and 13, I have demonstrated how to create performance related workflows using the OpsMgrExtended module. Today, I will start discussing event data, in this post, I will demonstrate how to create an event collection rule.

In the OpsMgrExtended module, there is a function called New-OMEventCollectionRule, which can be used to create event collection rules. It has been fully documented, you can access the documentation by using the Get-Help cmdlet:

Get-Help New-OMEventCollectionRule

SNAGHTML8b917c0

A side note here, Last week, I received an email asked me if the OpsMgrExtended module can be used outside of SMA and Azure Automation. The answer is yes, it can be used as a normal PowerShell module. for all the functions included in the module, you can access the examples by using the Get-Help cmdlet with –Full or –Example switch:

image

Runbook: New-EventCollectionRule

I have hardcoded the following parameters in the runbook:

  • SMA OpsMgr connection object name (which you will need to change to suit your environment)
  • Frequency – 900 seconds
  • (Unsealed) MP (where the rule  is going to be saved to) – “TYANG.Test.Windows.Monitoring”

Additionally, this runbook will firstly try to retrieve the management pack from the management group, if the MP deosn’t exist, it will create it first.

This runbook takes the following input parameters:

  • ClassName – The name of the target monitoring class (i.e.Microsoft.Windows.Server.OperatingSystem)
  • EventID – Optional. the Event ID to be collected by the rule.
  • EventLog –The name of the event log to be collected by the rule
  • Publisher– The event publisher
  • RuleDisabled– Boolean, whether the event collection rule should be disabled by default
  • RuleDisplayName– Display name of the rule
  • RuleName – The name of the rule

Runbook Execution Result:

image

Viewing the rule properties in OpsMgr operations console:

image

image

image

image

What if I don’t want to use SMA or Azure Automation?

Like I mentioned before, you don’t have to if you don’t want to. You can simply modify the runbook demonstrated above to run in a standalone PowerShell console by changing the PowerShell workflow to pass the OpsMgr management server name to the OpsMgrExtended functions (instead of SMA connection objects):

image

After updated the script (which contains the PS Workflow), firstly run the workflow in PowerShell, then call / execute the workflow:

Load the workflow:

SNAGHTML93cdde2

Execute the workflow:

image

Conclusion

In this post, I have demonstrated how to create an event collection rule using OpsMgrExtended module, with and without automation engines such as SMA and Azure Automation. I will demonstrate how to create a 2-state event monitor in the next post of the Automating OpsMgr series. Until next time, happy automating!

Automating OpsMgr Part 13: Creating 2-State Performance Monitors

Written by Tao Yang

OpsMgrExntededIntroduction

This is the 13th instalment of the Automating OpsMgr series. Previously on this series:

In the previous post (Part 12), I have demonstrated how to create performance collection rules using the OpsMgrExtended module. In this post, I will demonstrate how to create a 2-State performance monitor.

OpsMgrExtended module provides a function called New-OM2StatePerformanceMonitor. It has been documented in the embedded help within the module. you can access it via the Get-Help cmdlet:

image

Same as the previous posts, I’m going to show a sample runbook which utilise this function.

Runbook New-2StatePerformanceMonitor

As you can see, I have hardcoded the following parameters in the runbook:

  • Frequency – 900 seconds
  • (Unsealed) MP (where the monitor is going to be saved to) – “TYANG.SMA.Automation.Perf.Monitor.Demo”
  • Increase MP Version – true

So, before I can kick off this runbook, I need to firstly create the MP. This can be easily done using a one-liner on a machine where OpsMgrExtended is loaded:

image

After the test MP is created, I can then execute the runbook. This runbook takes the following input parameters:

  • ClassName – The name of the target monitoring class (i.e.Microsoft.Windows.Server.OperatingSystem)
  • CounterName – Name of the perf counter
  • InstanceName (Optional) –The Name of the instance of the counter. if not specified, the monitor will use All Instances.
  • MonitorDisplayName – The Display Name of the monitor.
  • MonitorName – The name of the monitor
  • ObjectName – Name of the object where the counter belongs to (i.e. memory, logical disk, etc.)
  • Threshold – The numeric threshold used by the monitor
  • UnhealthState – The unhealthy state of the monitor (Error or Warning)
  • UnhealthyWhenUnder (Boolean) – Specify if the monitor is unhealthy when the perf counter is under the threshold (or over the threshold).

Runbook Execution Result:

image

Monitor created by the runbook:

image

image

image

image

image

Conclusion

In this post, I have demonstrated a SMA / Azure Automation runbook to create 2-state performance monitors in OpsMgr. Now that I have covered both aspect of the performance  data (perf collection rule and monitor), I will move on to the event data in the next post.

Automating OpsMgr Part 12: Creating Performance Collection Rules

Written by Tao Yang

OpsMgrExntededIntroduction

This is the 12th instalment of the Automating OpsMgr series. Previously on this series:

From now on, I will start concentrating on creating various monitoring workflows (rules, monitors, template instances, etc) using the OpsMgrExtended module. I will dedicate at least 6-7 posts on this topic. Since OpsMgr is a monitoring solution, I am now getting to the core offering of this module – providing ways for OpsMgr professionals to automate the creation of their monitoring requirements. In this post, I will demonstrate a runbook utilising New-OMPerformanceCollectionRule activity from the OpsMgrExtended module, to create performance collection rules in OpsMgr.

Runbook New-PerfCollectionRule

In order to use this runbook, you firstly need to modify line 14 with the name of the SMA connection to your OpsMgr management group:

image

I have also hardcoded few other parameters in the runbook:

image

$MPName is the name of the unsealed MP where the rule is going to be saved to, and $Frequency is the interval in seconds on how often does this perf collection rule need to run. You also need to modify these 2 variables, especially the $MPName – the unsealed MP must exist in your management group already.

This runbook requires the following input parameters:

$RuleName – name of the perf collection rule

$RuleDisplayName – The display name of the perf collection rule

$CounterName – name of the perf counter you need to collect

$ObjectName – name of the object where the counter belongs to (i.e. memory, logical disk, etc.)

$InstanceName (optional) – name of the instance of the counter. if not specified, the rule will collect All Instances.

$ClassName – name of the OpsMgr monitoring class of which the perf collection rule is targeting

$RuleDisabled – Boolean variable (true or false). specify if the rule should be left disabled by default

Runbook execution result:

image

Rule configuration (from the console):

image

image

Accessing Perf data collected by this rule in a Perf view:

SNAGHTMLb5a869e

Conclusion

In this post, I have demonstrated how to use a runbook to create a performance collection rule in OpsMgr. In the next post, I will demonstrate how to create a 2-state performance monitor.

Automating OpsMgr Part 11: Configuring Group Health Rollup

Written by Tao Yang

OpsMgrExntededIntroduction

This is the 11th instalment of the Automating OpsMgr series. Previously on this series:

Since I have already covered how to create, update and delete OpsMgr groups using the OpsMgrExtended module, the last thing I want to cover on this topic is how to configure health rollup for the groups.

The runbook I’m demonstrating today was based on the PowerShell script in the OpsMgr Group Health Rollup Configuration Task MP which I published yesterday. As I explained in the previous post, because instance groups do not inherit any dependency monitors for their base class, when OpsMgr admins creating groups in the console (which can only be instance groups), they are shown as “Not monitored”:

SNAGHTMLaf5f001

By creating an agent task to create health rollup dependency monitors (in the OpsMgr Group Health Rollup Configuration Task MP), I have provided a more user friendly way for OpsMgr users to configure health rollup for groups, but this task won’t help us when we are designing an automation solution. Therefore, I have written a SMA runbook based on the script I developed for the MP.

Runbook: Configure-GroupHealthRollup

This runbook requires the following input parameters:

  • GroupName: Required parameter. Name of the group (note, this is not the display name you see in the OpsMgr console)
  • Algorithm: Required parameter. The algorithm to use for determining health state. Possible values: ‘BestOf’,’WorstOf’,’Percentage’.
  • Percentage: The worst state of the specified percentage of members in good health state. This parameter is only required when the specified algorithm is ‘Percentage’. Optional parameter, default value is 60 if not specified.
  • MemberUnavailable: The health state when the member is unavailable. Possible Values: ‘Uninitialized’, ‘Success ‘,’Warning’, ‘Error’. Optional parameter. If not specified, the default value is “Error”.
  • MemberInMaintenance: The health state when the member is in maintenance mode. Possible Values: ‘Uninitialized’, ‘Success ‘, ‘Warning’, ‘Error’. Optional Parameter. If not specified, members in maintenance mode will be ignored.
  • ManagementPackName: The Management Pack name of which the monitors going to be saved. This is only going to be used when the group is defined in a sealed MP.’
  • IncreaseMPVersion: Boolean optional parameter. Specify if the management pack version should be increased by 0.0.0.1.

Before executing the runbook:

image

Executing the runbook:

image

After runbook execution:

image

Dependency monitor health rollup policy:

image

Conclusion

In this post, I have demonstrated how to configure OpsMgr group health rollup by creating dependency monitors using a SMA runbook. As I mentioned in part 4, I was going to dedicate few post for a creating and managing groups mini series. This post would be the last post for this managing groups mini series. To summarise, on managing groups, I have covered the following aspects:

  • Creating new empty groups (Part 4)
  • Adding Computers to computer groups (Part 5)
  • Adding monitoring objects to instance groups (Part 6)
  • Incorporated the runbooks from part 5 and 6 into the new version of the OpsMgrExtended module (part 7)
  • Updating group discoveries (Part 9)
  • Deleting Groups (Part 10)
  • Configure Group Health Rollup (Part 11, this post)

Starting from next post, I will start talking about how to create monitors, rules, etc. So it should only get more interesting from now on.

This is all I’m going to share for today. Until next post, happy automating OpsMgr!