SCOM Powershell installation

The first step is to import the module.  If you’ve already got PowerShell 3.0 installed then you can skip this step, but let’s cover it for completeness
sake.  Open an instance of PowerShell, and run the following:

import-module operationsmanager

If you get no output and you just see the prompt on the next
line, then everything worked and now the module is loaded.  From there run the following command to see
the “about_” help topics that ship with the module:

get-help OpsMgr

For getting started, I’d recommend reviewing at least the

get-help about_OpsMgr_WhatsNew | more
get-help about_OpsMgr_Cmdlet_Names | more

Note:  As the What’s New topic points out, everything in this module will only work with OpsMgr 2012.  If you want to programmatically work with 2007 R2 then the What’s New topic walks you through how to do that and you’ll need to use your old scripts and one-liners to do it.  All the more reason to get to one version quickly :).

Next, get the full list of cmdlets that are included with the OperationsManager module by running the following:

get-command -module operationsmanager | more

If you find a cmdlet that is of interest to you and you want to learn more about what it does and how to use it, you can go any of the following

get-help <cmdletName> -detailed | more
This will provide the help content for the cmdlet, including the examples.

get-help <cmdletName> -full | more
This will provide the verbose details on the parameters that are available for the cmdlet.

<cmdletName> | Get-Member
This will show you the possible type(s) that a given cmdlet can return and what the methods and properties are on those types.  This is especially useful for figuring out what you can use in pipelining cmdlets together.

In the next post I’ll write about the new way in which the OpsMgr 2012 module handles connections.

To get familiar with how this works in the OpsMgr 2012 module, run the following command to see the four cmdlets that relate to management group connections.

get-command -module operationsmanager -noun SCOMManagementGroupConnection

Note: You may notice that the SCOMManagementGroupConnection noun (starting with SCOM) is actually an alias for cmdlets that use theSCManagementGroupConnection noun (starting with SC, for system center).  I use the SCOM specific aliases, but either nouns would work the same.

Likewise, there is an about topic that discusses how the connections work.

get-help about_OpsMgr_Connections | more

You could also review the help content provided on each cmdlet to get familiar with them.  With that said, the examples provided only go so deep.

The first step is to create a connection.  As the about topic mentions, there are a couple kinds of connection types to work with; persistent and temporary.  Connections that are created as persistent are held in the state of the PowerShell session, whereas temporary connections are tied to the execution of a specific cmdlet and live only as long as the resulting objects are in state.  The only distinction here is whether you use the New-SCOMManagementGroupConnection to create the connection (persistent) or if you use the -ComputerName (and optionally -Credentials) parameter to get connected (temporary).

We’ll start by walking through persistent connections and then I’ll cover the one use I’m aware of for temporary connections.

Setting up the connection

In order to create a persistent connection, run the New-SCOMManagementGroupConnection cmdlet.

New-SCOMManagementGroupConnection -ComputerName <OpsMgrServerName>

The value of <OpsMgrServerName> can be any OpsMgr 2012 server that is running the OpsMgr SDK service.  Since the SDK service is running on any management server in an OpsMgr 2012 management group, this gives us a lot more flexibility than in 2007 R2, where we could connect to the RMS only.

If the cmdlet produces no output, then you know you did it right.  If you want the cmdlet to return the connection object that it creates, you can include the –Passthru parameter when you run the cmdlet.

If you need to connect to multiple management groups, you keep running the NEW cmdlet for each management group or management server you want to connect to.  This is a big improvement over what you had to do in 2007 R2.

Once your connections are created, you can run the Get-SCOMManagementGroupConnection cmdlet to see the persistent connections that you’ve created.


The most important column in the output is the IsActive column.  This bit indicates which connection is the default connection.  The default connection is the connection that will be implicitly used by all cmdlets.  You can run cmdlets against non-active connections, but in those cases you’ll either have to switch which connection is active or pass in the connection details explicitly.  I’ll cover that scenario further down.

Using the connection

In most cases, creating one persistent connection is the first and last thing you’ll do with the connection directly.  I say that because once a persistent connection is established all cmdlets just work, and they run against the connection flagged as “TRUE” for IsActive.

The reason this works is that every cmdlet in the OpsMgr 2012 module includes a parameter named SCSession which takes in an array of type Connection.  If the cmdlet is not explicitly passed a connection object, then it will look in state for a connection with the IsActive bit set to TRUE and it will implicitly work with that.

If you needed to explicitly pass in a connection to a cmdlet you need to first get the connection and then pass it into the cmdlet(s).  For example, you would do the following to get the connection for a specific management group and then use it to get alerts from that management group.

$connection = Get-SCOMManagementGroupConnection –ManagementGroupName “MyGroup”

Get-SCOMAlert –SCSession $connection

An interesting (to me at least) side effect of the way connections work in relation to cmdlets in this module, is that every object that comes out of a cmdlet holds onto its own little connection back to the management group it was pulled from.  You can see this if you run Get-Member, in that there is a ManagementGroupproperty on almost every object type that can come out of a cmdlet in the OpsMgr module.  That property is of type Microsoft.EnterpriseManagement.ManagementGroup, which is the object type used in the OpsMgr SDK to hold a connection.  You can test this out yourself by doing the following:

## Create the connection
New-SCOMManagementGroupConnection –ComputerName “MyServer”

## Get alerts implicitly using the connection
$alerts = Get-SCOMAlert

## Check out the ManagementGroup property on an alert
$alerts[0] | select-object -Property ManagementGroup | get-member

What this means to you, is that even if the connection that was used in the cmdlet to get the objects gets blown away, the object itself will still be able to interact with the management group, through this mini-connection is carries around.

Working with multiple connections

But what if you have more than one management group you want to work with?  Maybe you’ve got a pre-prod environment that you want to copy settings or management packs from.  Maybe you’ve got scale or security requirements so you needed to deploy more than one MG in order to scale, but you want to see the data from all of those environments in one place.

As I mentioned previously, you create multiple connections by running the New-SCOMManagementGroupConnection cmdlet.  Once you’ve created all of the connections you need you can use the Get-SCOMManagementGroupConnection cmdlet to see them all.


The GET cmdlet also has a few parameters for filtering the connections that are returned.

Id:  This is a GUID that uniquely identifies the connection.  The ID column is not shown in the default output so you’ll need to get at it if you need it.  The easiest way to do that is by piping the GET cmdlet to “Select-Object –Property ID”, but any standard PoSH approach will work.  This will come in use when we want to set a different connection as active.

Get-SCOMManagementGroupConnection | select-object -Property ID



ManagementGroupName: Get all connections that exist with the given management group.  This is just a string and it does support typical wildcards.  This comes in use if you have to connect to multiple management groups and you have a predictable MG naming scheme.

Get-SCOMManagementGroupConnection -ManagementGroup “OMCOR2″ | format-table ManagementServerName, IsActive –Auto

ManagementServerName IsActive
——————– ——–
OMServer1            True
OMServer2            False

ComputerName:  Get all connections that exist with the given ComputerName, which would be the name of a management server.

Get-SCOMManagementGroupConnection -ComputerName OMServer1 | format-table ManagementServerName, IsActive –Auto

ManagementServerName IsActive
——————– ——–
OMServer1            True

If you need to change which connection is active you can get the connection you want and then use the Set-SCOMManagementGroupConnection cmdlet to set it to active.

Get-SCOMManagementGroupConnection –Id e67d872b-815f-4d27-a812-a29a9a6fa438 | Set-SCOMManagementGroupConnection

Note: You can use any parameter you want to on the GET cmdlet, to get a connection, but the ID parameter is the only one that is guaranteed to return one and only one object.

Now that the connections are created you can use them in a couple of ways.

The first way you can use them is to get details from one source management group and then apply those settings to other management groups.

# Get the source connection
$Source = Get-SCOMManagementGroupConnection -ComputerName “OMServer1”

# Get all other connections
$Target = Get-SCOMManagementGroupConnection | Where-Object{$_.ManagementServerName -ne “OMServer1″}

Now you can do things like the following:

# Sync the Database grooming settings
Get-SCOMDatabaseGroomingSetting -SCSession $Source | Set-SCOMDatabaseGroomingSetting -SCSession $Target

# See which management packs are not the same between MGs
Compare-Object -ReferenceObject (Get-SCOMManagementPack -SCSession $Source) -DifferenceObject (Get-SCOMManagementPack -SCSession $Target)

The second way you can use multiple connections is to get the same set of details from all connections at the same time.

# Get all connections into an object
$Connections = Get-SCOMManagementGroupConnection

# Get alerts from all connections
Get-SCOMAlert -SCSession ($Connections)

# Get all pending management actions and clear them out (Deny)
Get-SCOMPendingManagement -SCSession ($Connections) | Deny-SCOMPendingManagement

Closing connections

If you need to remove a connection you again use the GET cmdlet to get the connection and then you pipe that into the Remove-SCOMManagementGroupConnection cmdlet.

Get-SCOMManagementGroupConnection –Id e67d872b-815f-4d27-a812-a29a9a6fa438 | Remove-SCOMManagementGroupConnection

Note: You can use any parameter you want to on the GET cmdlet, to get a connection, but the ID parameter is the only one that is guaranteed to return one and only one object.  This is especially important in this case since the REMOVE cmdlet will dutifully remove all connections that get passed into it.  You’ve been warned.

Working with temporary connections

Earlier I mentioned there are two types of connections.  The entire post thus far has discussed persistent connections.  The other type of connection is a temporary connection.  Instead of using the NEW cmdlet to create a connection and then implicitly or explicitly using those connections, temporary connections are created when a cmdlet is run with the –ComputerName and –Credential parameters.

I don’t use these at all myself (so I can’t speak from personal experience), but from what I’ve gathered these parameters come in use when you are running a one-liner via a direct call to PowerShell.exe

PowerShell.exe -Command “& {import-module operationsmanager; Get-SCOMAlert -ComputerName OMServer1}"

So that’s what I know about connections.  Next time I get a chance to kick out a blog post I’ll talk about working with management and gateway servers via PowerShell.  I’ll try to dabble into agent topics there too, but I suspect that will merit an entirely separate post.


SCOM Powershell

SCOM 2012 – Install SCOM PowerShell Modules Without SCOM Console Installation


Install SCOM 2016 PowerShell Modules without SCOM Console




Passive Income Links

30 Passive Income Ideas You Can Use to Build Real Wealth

Passive Income Ideas You Can Start Today

45+ Proven Wealth-Building Passive Income Ideas (2019)

43 Best Passive Income Streams & Opportunities

Passive Income Ideas

31 Best Passive Income Ideas for 2019