Category Archives: SMA

Automating OpsMgr Part 10: Deleting Groups

Written by Tao Yang


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.


This runbook takes 2 parameters:


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

Runbook Result:


Verbose Messages (deleting dependency monitors):




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


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:


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:


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:


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


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


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



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


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.


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).


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(“!”)


  • 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, and the version of MP B loaded in your management group is version, then you will have no problem when loading A into your management group. However, if MP B in your management group is on version, you will not be able to load MP A without having to update B to at least 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).



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



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


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:


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.

Updating Connection Fields in SMA and Azure Automation Modules

Written by Tao Yang

Recently when I was working with Stanislav Zhelyazkov on the OMSSearch module, Stan discovered an issue where the module connection type does not get updated when you import an updated version of the module in Azure Automation if the fields have been modified in the module. I have also seen this issue with SMA, so it is not only specific to Azure Automation.

Stan has also raised this issue in the User Voice:

As you can see from the feedback from Joe Levy and Beth Cooper, it is a known issue with SMA and Azure Automation. Joe has also provided a workaround for Azure Automation (deleting the connection type using REST API).

I have seen this issue many times in the past with SMA, and when I started writing this post, I realised I actually blogged about this issue almost a year ago. – I didn’t remember blogging it at all, maybe it a sign that I’m getting old Smile.

Anyways, I’ve updated the SQL script from my previous post, wrapped the deletion commands in a transaction as per Beth’s advice:

As I explained in the previous post, you will need to update the @ModuleName and @ConnectionName variables accordingly.

Lastly, I’d like to state that it is very common to update the connection type JSON file during your module development phase. During this phase, you would probably use this script a lot on your development environment. But please do not try and use this in production environment. It is developed by myself with no involvement from Microsoft, and Microsoft would never support directly editing the database.


If you are having this issue with On-Prem SMA, in your non-prod environment, you can try to use this SQL script to remove the connection type AFTER the old module has been deleted.

If you are having this issue in Azure Automation, please use the REST API as Joe mentioned in the User Voice:

Automating OpsMgr Part 6: Adding Monitoring Objects to Instance Groups

Written by Tao Yang


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.


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.



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:


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:



Runbook Execution result:


Verbose messages:


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.



ce2dd108-0129-4fc0-842b-347311cb9107:[localhost]:The Monitoring Object ‘Microsoft.SystemCenter.VirtualMachineManager.201;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.


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.

OMSSearch Module Sample Runbook: Invoke-OMSSavedSearch

Written by Tao Yang

Over the last few days, I’ve been playing with the OMSSearch PowerShell / SMA / Azure Automation Module my friend and fellow SCCDM MVP Stanislav Zhelyazkov has created.

I am now part of this project on Github and have become the 3rd contributor (after Stan and Stefan Stranger). The module was updated yesterday (version 5.1.1) with some of my updates.

Today, I have written a sample runbook: Invoke-OMSSavedSearch. As the name suggests, it performs a user defined saved search.

Note: due to the limitation of the OMS Search API, we can only retrieve the user defined saved searches. Therefore you cannot use this runbook for any built-in saved searches in OMS.


This runbook expects 3 input parameters:


  • OMSConnectionName: the name of the OMS Connection object defined in SMA or Azure Automation
  • SavedSearchCategory: the saved search category you specified when you saved the search query
  • SavedSearchName: the display name of the saved search you specified when you saved the search query


Runbook Result in SMA:


Same event in OMS:



This runbook is written based on version 5.1.1 of the OMSSearch Module. It will not work with the previous versions because I have added few additional paramters in the OMSConnection object which are used by this runbook.

Automating OpsMgr Part 5: Adding Computers to Computer Groups

Written by Tao Yang


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

In the previous post (part 4), I have demonstrated a runbook creating new empty instance groups and computer groups using the OpsMgrExtended module. As I also mentioned in Part 4, I will dedicate few posts on creating and managing OpsMgr groups. So, this post is the 2nd one on this topic.

In OpsMgr, groups can be populated via Explicit memberships (static) or Dynamic Memberships (query based), or combination of both:


In this post, I will demonstrate how to use a runbook to add a Windows computer object to a computer group via Explicit membership.

Runbook Add-ComputerToComputerGroup

When using this runbook, you will need to update line 9 of the runbook, and replace the SMA connection name with the one you’ve used in your SMA environment:


This runbook requires 2 mandatory parameters:

  • Windows computer principal name (FQDN) – which is the key property of the Windows Computer object


  • The group name – it’s the internal name, not the display name. I did not use the display name because it is not unique. i.e.



If the group was created using the New-OMComputerGroup and New-OMInstanceGroup functions from the OpsMgrExtended module, these 2 functions would automatically prepend the management pack name in front of the group name specified by the user (if the management pack name is not already the prefix of the specified names). I forgot to mention this behaviour in my previous post (Part 4).

Since the OpsMgrExtended module does not (yet) have a function to add a computer to a computer group, I wrote this runbook to perform this task directly via OpsMgr SDK (therefore all within the inlinescript). The high level steps for this runbook is listed below:

  1. Establish OpsMgr management group connection (and the SDK assemblies will be loaded automatically).
  2. Get the Windows computer monitoring object
  3. Get the computer group monitoring class (singleton class)
  4. Check if the group object specified is indeed a computer group
  5. Get the computer group instance
  6. Get the computer group discovery
  7. Make sure the discovery is defined in an unsealed management pack
  8. Detect if any “MembershipRule” segments in discovery data source module contains existing static members
  9. If there are existing static members in one of the membership rule, add the Windows computer as a static member in the membership rule.
  10.   If none of the membership rules contain static members, define a static member section (“<IncludeList>”) in the first Membership Rule.
  11. Update the unsealed management pack where the discovery is defined.


Executing Runbook

Group membership before execution:


Executing runbook:



Group membership after execution:



In this post, I have demonstrated how to use a runbook and OpsMgrExtended module to add a Windows computer object as a static member of a computer group.

I’ve also demonstrated even when an activity is not pre-defined in the OpsMgrExnteded module, we can still leverage OpsMgrExnteded module to perform the task because we can directly interact with OpsMgr management groups and SDKs via this module – by using the Connect-OMManagementGroup function, the SDK will be loaded automatically.

When I was writing this runbook few days ago, I have realised this is something I should have included in the OpsMgrExtended module because it could be very common and useful. Although I’ve published this as a rather complex runbook at this stage, I will probably included this as an additional function in the future release of OpsMgrExtended module.

I will demonstrate how to add a explicit member to an instance group in the Part 6 of this series.

Automating OpsMgr Part 4: Create New Empty Groups

Written by Tao Yang


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

When developing management packs, it is very common to define various groups that contain objects discovered by the management pack. The groups can be used for overrides, maintenance modes, reports, scoping user access, etc.

Generally speaking, there are 2 types of groups in OpsMgr: instance groups and computer groups. As the names suggested, instance groups can contain any types of instances in OpsMgr, and computer groups can only contain computer objects.

In the OpsMgr console, the easiest way to identify the group type is by the icon. i.e.


As you can see, the computer group has an additional computer in the icon.

There are 2 steps when creating a group:

1. Class definition – A singleton, unhosted group class representing the group itself. i.e.


2. A discovery workflow which uses A Data Source module type called “Microsoft.SystemCenter.GroupPopulator” to populate the group membership. i.e.


The class definition and the discovery can be defined in the same management pack, or different packs (i.e. Class definition in a sealed MP, and discovery MP can reference the sealed class definition MP). As you can see, the class definition for groups are really simple, but the discovery can sometimes get very complicated – all depending on your requirements.

When I was developing the OpsMgrExtended module, I have created 2 functions for group creations:

  • New-OMInstanceGroup
  • New-OMComputerGroup

As the names suggest, these 2 functions create new instance groups and computer groups respectively. But because the group populations can sometimes be tricky and complicated, after careful consideration, I have decided to code these 2 functions to only create empty groups and users will have to either manually populate the groups via the operations console, or developing their own runbooks to update the group discovery workflow.

So what does an empty group mean?

I simply coded the group populator data source to always return nothing by using a simple expression where True equals False (which would never happen):


Since populating groups can get complicated, and I think it will be very useful for people to use the OpsMgrExtended module to create and manage groups, I will dedicate this post and the next few posts in this blog series on creating and managing groups. So, please consider this as the first episode of the “sub series”. In this post, I will demonstrate a simple runbook that you can use to create instance groups and computer groups.

Runbook: New-Group

Executing Runbook

Creating Instance Group:


Creating Computer Group:



In Operations Console:


Management Pack – Class Definition:


Management Pack – Instance Group Discovery:


Management Pack – Computer Group Discovery:


Management Pack – Language Pack:


Additional Readings

Over the years I’ve been working with OpsMgr, I’ve booked mark the following great blog articles on creating groups in OpsMgr. You might find some of them useful:

Also, few previous posts from this blog:


In this post, I have demonstrated how to create computer groups and instance groups without any members. In the next post, I will demonstrate a runbook to add an explicit member to a computer group.

Automating OpsMgr Part 3: New Management Pack Runbook via SMA and Azure Automation

Written by Tao Yang


This is the 3rd instalment of the Automating OpsMgr series. Previously on this series:

Today, I will demonstrate a rather simple runbook to create a blank management pack in the OpsMgr management group. Additional, I will also demonstrate executing this runbook not only on your On-Premise Service Management Automation (SMA) infrastructure, but also from an Azure Automation account via Hybrid Workers.

Since the Hybrid Worker is a very new component in Azure Automation, I will firstly give a brief introduction before diving into the runbook.

Azure Automation Hybrid Worker

Ever since Azure Automation was introduced, it was great solution for automating around your assets and fabric on Azure, but there was lack of capabilities of reaching out to your on-prem data centres. Last month during Microsoft Ignite in Chicago, Microsoft has announced an additional component: Hybrid Workers, which is a Azure Automation runbook worker that you can setup on a on-prem server computer. To find out more, you can watch this Ignite session recording: Automating Operational and management Tasks Using Azure Automation. and my buddy and fellow SCCDM MVP Stanislav Zhelyazkov has also written a good post on this topic:

I am not going to go through the steps of setting up hybrid workers as Stan has already covered in his post. As Stan pointed out in his post, currently, any Integration Modules that you imported into your Azure Automation account does not get pushed out Hybrid Workers. Therefore in order to execute the New-OpsMgrMP runbook on your hybrid workers, after you’ve imported the OpsMgrExtended module in your Azure Automation account,  you must also need to manually copy the module to all your hybrid worker servers. To do so:

1. log on to the hybrid worker, and look up the PSModulePath environment variable. You can do so in PowerShell using $env:PSModulePath


2. Copy the OpsMgrExtended module to a folder that is on the PSModulePath list. Please do not copy it to any folders that are part of your user profile. I have copied it to “C:\Program Files\WindowsPowerShell\Modules” folder.

Operations Manager SDK Connection

The “Operations Manager SDK” connection must be created in the Azure Automation account, the same way as your On-Prem SMA environment:


The server  name I used is the FQDN of one of my OpsMgr management server. The user name is a service account I created in my on-prem Active Directory (I believe it’s called Legacy AD or LAD now Smile). i.e. Domain\ServicecAccount.  This is connection is created exactly the same as the one I created in my On-Prem SMA environment.

New-OpsMgrMP Runbook

The runbook in Azure Automation and SMA is exactly identical. Please note I have configured the Operations Manager SDK connection name to be identical on Azure Automation and SMA. you will need to update Line 11 of this runbook to the name of the connection you’ve created:


Executing the runbook on SMA:

Fill out the required parameters. the parameter “Version” is configured as optional in the runbook (with default value of “”), so I did not enter a version number in that field:




And you can then see the management pack in OpsMgr operational console:


Executing Runbook on Azure Automation via Hybrid Worker:

Fill out the input parameters and select “Hybrid Worker”. As you can see, the default value for “Version” parameter has already been prepopulated in the Azure portal:




And then the management pack appeared in OpsMgr operational console:



This is a rather simple runbook sample, the key to this runbook is the “New-OMManagementPack” activity from the OpsMgrExtended module.

For those who do not have SMA in their environment, I have just demonstrated how to leverage Azure Automation and Hybrid Workers to perform the same activities. As shown in Stan’s blog post, it’s rather easy to setup a Hybrid Worker in your environment, all you need is a Windows server with Internet connection. Unlike SMA, you do not need any database servers for Hybrid Workers.

I’d also like to point out, even if you have not opened an Azure Automation account yet, I strongly recommend you to do so and give it a try. You can go on a free tier, which gives you 500 job minutes a month. For testing and up skilling purposes, this is more than enough!

Lastly, if you would also like to see the ability to automatically push out custom modules to Hybrid workers in the future, Please help me and vote this idea in Azure  user voice: