In the previous post, I introduced the OpsMgr 2012 PowerShell module and discussed a few of the ways that I used to get oriented to it. Now that we’re oriented, the first thing I want to explore is how connections work.
Both the previous and the current PowerShell implementations for OpsMgr support remotely connecting to one or more management groups. This is cool for a couple reasons. The first is I can open up PowerShell on my desktop and run cmdlets without having to TS onto a bunch of servers. The second is that I can connect to multiple management groups, which comes in use when I want to compare/align two or more environments together or I want to get data from all of my environments at once.
Note: The OpsMgr 2012 module does not support connecting to down-level versions of OpsMgr.
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 the SCManagementGroupConnection 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.
Get-SCOMManagementGroupConnection
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 ManagementGroup property 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.
Get-SCOMManagementGroupConnection
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
Id
--
e67d872b-815f-4d27-a812-a29a9a6fa438
a407c6d6-3feb-452a-aeb0-16d9f50ad44a
6d87b620-447d-40b1-ba68-1745c672676c
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.
Cheers until then,
Cory