Tag Archives: MimbolovePowershell

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!

Automating OpsMgr Part 10: Deleting Groups

Written by Tao Yang

OpsMgrExntededIntroduction

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

As I have previously demonstrated how to create and update OpsMgr groups using the OpsMgrExtended module, it’s now the time cover how to delete groups in OpsMgr.

Deleting groups that are defined in unsealed management packs can be easily accomplished using the Remove-OMGroup function from the OpsMgrExtended module. This function deletes the group class definition and discoveries from the unsealed MP. However, since it’s very common for OpsMgr administrators to also create dependency monitors for groups (for group members health rollup), you cannot simply use Remove-OMGroup function to delete groups when there are also monitors targeting this group. Therefore, I have written  a sample runbook to delete the group as well as monitors targeting the group (if there are any).

Runbook Delete-OpsMgrGroup

In order to use this runbook, you will need to update Line 9, with the name of your SMA connection object.

SNAGHTML1591389

This runbook takes 2 parameters:

image

GroupName: the name of the group you are deleting. Please note you can only delete groups defined in unsealed MPs.

IncreaseMPVersion: Boolean variable, specify if the unsealed MP version should be increased by 0.0.0.1

Runbook Result:

image

Verbose Messages (deleting dependency monitors):

SNAGHTML14fa1a1

 

Conclusion

This post is rather short comparing to some of the previous ones in this series. I have few ideas for the next post, but haven’t decided which one am I going to write first. Anyways, until next time, happy automating!

Automating OpsMgr Part 9: Updating Group Discoveries

Written by Tao Yang

OpsMgrExntededIntroduction

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

OK, now I’ve got all the darts lined up (as per part 7 and 8), I can talk about how to update group discovery configurations.

Often when you create groups, the groups are configured to have dynamic memberships. for example, as I previously blogged Creating OpsMgr Instance Groups for All Computers Running an Application and Their Health Service Watchers.

In this post, I will demonstrate once you’ve created an empty group (as shown in Part 4), how can you use OpsMgrExtended module to modify the group discovery data source, so the group will dynamically include all objects that meet the criteria (Membership rules).

Because this is not something you’d use as a standalone solution, I will not provide sample runbooks, but instead, just walk through the PowerShell code.

Example Walkthrough

In this demonstration, I have firstly created a blank management pack, and then use the runbook demonstrated in Part 4, and created an empty instance group. At this stage, the management pack looks like this:

SNAGHTML236ed3d

My goal is to update this group to include all objects of the Hyper-V host class that is defined in the VMM 2012 discovery MP (“Microsoft.SystemCenter.VirtualMachineManager.2012.Discovery”). The configuration for the group discovery data source module would need to be something like this:

image

As I explained in the previous post (Part 8), because the Hyper-V Host class is defined in the VMM MP, in order to build our discovery data source, the unsealed MP of which the group discovery is defined must reference the VMM discovery MP. As you can see from the management pack XML screenshot, the VMM discovery MP is not currently referenced there. As I’ve also shown in the new group discovery data source configuration that I’m about to put in, the VMM discovery MP need to be referenced as alias “MSV2D” (as highlighted). of course you can pick another alias name, but the group discovery data source config must align with whatever alias you’ve chosen.

So, in order to achieve my goal, I must firstly create a MP reference for the VMM discovery MP, then I will be able to update the group discovery data source.

Here’s the PowerShell script:

Please note, I’m specifying the management server name instead of the SMA connection object in this example, if you are using it in SMA or Azure Automation, you can also switch -SDK to -SDKConnection and pass a connection object to the functions.

The script is very self explanatory, with 2 catches:

  • the group discovery DS configuration is defined in a multi-line string variable, you MUST use single quotation marks (@ and @) for this variable, because the dollar sign ($) is a reserved character in PowerShell, if you use double quotes, you must also place an escape character (“`”) in front of every dollar sign, with can be very time consuming.
  • You must use the version 1.1 of the OpsMgrExtended module (published in part 7 earlier today). The Update-OMGroupDiscovery function is a new addition in version 1.1, and New-OMManagementPackReference had a small bug that was also fixed in version 1.1.

Since I’ve added -Verbose switch when calling both functions, I can also see some verbose output:

image

And now, if I check the group I’ve just updated, the MP reference is added:

image

and the original empty discovery rule was replaced with what I specified in the script:

image

Now when I check the group membership in the console, I can see all the Hyper-V hosts in my lab:

image

Conclusion

In this post, I have demonstrated how to use OpsMgrExnteded module to update a group discovery data source configuration. Although I’ve only provided 1 example, for an instance group, the process for updating computer groups are pretty much the same. In next post, I will demonstrate how to delete a group using the OpsMgrExtended module.

Automating OpsMgr Part 8: Adding Management Pack References

Written by Tao Yang

OpsMgrExntededIntroduction

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

In part 4-6, I have demonstrated how to create and add static members to both instance groups and computer groups. In Part 7, I have released the updated OpsMgrExtended module (version 1.1), and demonstrated simplified runbooks for adding static members to groups. In this post, I will demonstrate how to add a management pack reference to an unsealed MP. In the next module, I will demonstrate how to update a group discovery (how groups are populated). But in order for me to demonstrate how to update group discoveries, I will need to cover adding MP references first.

What is Management Pack Reference

Management packs often use elements defined in other management packs. i.e. a discovery MP would need to refer to the library MP of which the class being discovered is defined; a monitor refers to the monitor type defined in another MP; or an override you created in an unsealed MP need to refer to the MP of which the workflow that you are creating the override for is defined, etc.

Because OpsMgr needs to ensure the referencing management pack does not change in a way that may impact all other management packs that are referencing this pack, only sealed management packs (or Management Pack bundles in OpsMgr 2012) can be referenced in other management packs because sealed MPs must comply with a set of rules when being upgraded. Unsealed management packs can reference other sealed management packs, but they cannot be referenced in other MPs.

image

As shown above, in OpsMgr console, by opening the property page of a management pack, you can easily find out which management packs is this particular MP is referencing (the top section), and what other management packs are referencing this MP (the bottom section).

SNAGHTML11b42e4

When reading the management pack XML (as shown above), you’ll notice the references are defined in the beginning of the MP. When defining a MP reference, the following information must be supplied:

  • Alias – This alias must be unique within the MP itself, and it is used by other elements within this MP, followed by an exclamation mark(“!”)

SNAGHTML11f5dbc

  • ID – The internal name of the referencing MP
  • Version – The minimum required version of the referencing MP.
  • PublicKeyToken – the public key token of the key used to sealed this referencing MP.

Note: when you are writing management pack A and created a reference for management pack B with version 2.0.0.0, and the version of MP B loaded in your management group is version 2.0.0.1, then you will have no problem when loading A into your management group. However, if MP B in your management group is on version 1.0.0.0, you will not be able to load MP A without having to update B to at least 2.0.0.0 first before you are able to importing management pack A.

Creating Management Pack Reference Using OpsMgr SDK

When using OpsMgr SDK to create MP references, since you are creating the reference in an unsealed MP that is already loaded in your management group, the referencing management pack must also be present in the management group. And since the referencing MP should have already been loaded in the management group, the only 2 pieces of information you need to specify is the name of the MP, and the alias that you wish to use (but has to be unique, meaning not already been used). The SDK would lookup the version number and the public key token from the referencing MP, and use them when creating the reference.

The OpsMgrExtended module offers a function called New-OMManagementPackReference that can be used to easily create MP references in unsealed management packs. I have written a very simple runbook utilising this function.

Runbook: Add-MPReference

This runbook takes 3 input parameters:

  • ManagementPackName: the name of the unsealed MP where the reference is going to saved to
  • ReferenceMPAlias: The alias of the referencing MP
  • ReferenceMPName: The name of the referencing MP (must be a sealed MP).

image

image

After the execution, the reference is created in the unsealed MP:

image

Conclusion

In this post, I’ve demonstrated how to create a MP reference in an unsealed management pack. In the next post, I will demonstrate how to update a group discovery configuration (for dynamic group memberships).

Automating OpsMgr Part 7: Updated OpsMgrExtended Module

Written by Tao Yang

OpsMgrExntededIntroduction

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

I dedicated part 4-6 on creating and managing groups using the OpsMgrExtended module. I was going to continue on this topic and demonstrate how to update group discovery in part 7 (this post), but unfortunately there is a change of plan. While I was preparing for the group discovery update runbook, I noticed I had to firstly cover how to add reference MPs before I can talk about updating group discoveries. I then realised there was a small bug in the New-OMManagementPackReference. Therefore, I have decided to update the OpsMgrExtended module first, before continuing the topics of managing groups.

What’s New?

In this release (version 1.1), I have made the following updates:

  • Bug fix: New-OMTCPPortMonitoring fails when not using the the SMA connection object.
  • Bug fix: New-OMManagementPackReference returned incorrect result when the alias is already used
  • Additional Function / Activity: New-OMComputerGroupExplicitMember
  • Additional Function / Activity: New-OMInstanceGroupExplicitMember
  • Additional Function / Activity: Update-OMGroupDiscovery

In Part 5 and 6, I demonstrated 2 runbooks to add explicit members to computer groups and instance groups. As I mentioned in those posts, I would make those 2 runbooks as native functions within the module, hence the new functions New-OMComputerGroupExplicitMember and OMInstanceGroupExplicitMember. So instead of using the long and complicated runbooks from Part 5 and 6, with this updated version, you can now use very simple runbooks as shown below:

Runbook: Add-ComputerToComputerGroup

Runbook: Add-ObjectToInstanceGroup

How to Download Updated version?

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

With the updated module in place, I will continue my discussion on managing groups. In the next part of this series, I will demonstrate how to add a management pack reference to an unsealed management pack.

Automating OpsMgr Part 6: Adding Monitoring Objects to Instance Groups

Written by Tao Yang

OpsMgrExntededIntroduction

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

In part 4, I have demonstrated how to create empty instance groups and computer groups using the OpsMgrExtended module and in part 5, I’ve demonstrated how to add a Windows Computer object to a Computer Group as an explicit member. In this post, I will share a runbook that adds a monitoring object to an Instance Group. As I mentioned in Part 4, I will dedicated few posts on creating and managing OpsMgr groups, this post would be the 3rd post on this topic.

Runbook Add-ObjectToInstanceGroup

In order for you to use this runbook, you will need to modify line 9 with the name of the SMA connection you’ve created in your environment.

SNAGHTML325a4b96

This runbook requires 2 input parameters:

  • GroupName: The internal name of the group. I did not use the display name because it is not unique.
  • Monitoring Object ID: The ID of the monitoring object that you wish to add to the instance group.

image

Note:

Since the monitoring object ID is not visible in the Operations Console, I have previously posted an article and demonstrated several ways to find this Id for monitoring objects: Various Ways to Find the ID of a Monitoring Object in OpsMgr. If you are also using Squared Up dashboard, you can also use Squared Up to lookup and export the Monitoring Object ID as demonstrated in this YouTube video.

In the screenshot above, I’ve entered the Monitoring Object of a Hyper-V Host which is defined in the VMM 2012 management pack:

image

I have added a lot of comments and verbose messages in this runbook, therefore I don’t feel I need to explain how it works. If you’d like to know what it does step-by-step, please read the code.

After the runbook execution is completed, the monitoring object is added to the group:

image

SNAGHTML326cba18

Runbook Execution result:

image

Verbose messages:

image

Adding an Existing Member to the Group:

I have coded the runbook to also check if the monitoring object that you want to add is already a member of the group (by looking up related objects of the group instance). If it is the case, the runbook will write a warning message and exit without adding it.

i.e.

image

ce2dd108-0129-4fc0-842b-347311cb9107:[localhost]:The Monitoring Object ‘Microsoft.SystemCenter.VirtualMachineManager.201 2.HyperVHost:HYPERV03.corp.tyang.org;2541ebea-50ae-4d4b-8755-5b77a50cd32b’ (ID:’fabfe649-921c-cf17-d198-0fba29cee9ff’) is already a member of the instance group Group.Creation.Demo.Demo.Instance.Group. No need to add it again. Aborting.

Conclusion

This is a rather complicated runbook and most of the code runs within InlineScript. To make everyone’s life easier, I will add this as a function in the OpsMgrExtended module upon next release. In the next post, I will demonstrate how to update a group by updating the group discovery.