Share via

OpsMgr 2012 PowerShell: Management and Gateway Servers

  • Article

Quick Reference

In the previous post I talked about how to get connected to management groups. In this post I’m going to talk about working with management servers and gateway servers. I will also introduce you to a script that I wrote, which gives a hierarchical view of state, much like the health explorer in the console.

Following are some useful ways that I’ve found to work with the management and gateway servers via PowerShell:

  • Check to see which servers are running which types of roles (e.g. the RMS emulator, the gateway server role, etc.)
  • Ensure the base configurations (i.e. action account, version, for your servers are correct
  • Check which agents are managed by the server and vice versa
  • Make sure all of your servers are healthy and figure what’s wrong with them if they are not

In order to see the cmdlets that you’ll work with in the OperationsManager PowerShell module, for management and gateway servers, run the following command:

get-command -module operationsmanager -Noun *ManagementServer

That will return four cmdlets. The first two cmdlets (Get-SCOMGatewayManagementServer and Get-SCOMManagementServer) are used to get list of gateway or management servers based. You can either get the list of all of them for a given MG by providing no parameters or you can use the -ComputerName or –Name parameters to look for servers that have particular names or substrings within their names, respectively.

The first thing to note is that gateway servers are really considered a type of management server in Operations Manager. As such, if you run the following cmdlet against a management group that has both gateway servers and management servers, you’ll get back a list that contains both types of servers:

Get-SCOMManagementServer

If you pipe the Get-SCOMManagementServer cmdlet into Get-Member you see that is returns objects of type Microsoft.EnterpriseManagement.Administration.ManagementServer.

Get-SCOMManagementServer | get-member

What’s more relevant though is if we look at the members of that class, which includes many properties and a few methods that are relevant to our common needs. For instance, since the default output of Get-SCOMManagementServer doesn’t distinguish between the two types of servers, we need to take matters into our own hands to figure that out:

Get-SCOMManagementServer | format-table HealthState, Name, Version, ActionAccountIdentity, IsGateway,IsRootManagementServer –AutoSize

And that how I address the first use mentioned above.

The second use is for ensuring the base configurations are set the way we want them to be. Base configurations, for me, include the following:

  • ActionAccountIdentity: If this changes you may not be able to complete agent maintenance in the way you expect.
  • AutoApproveManuallyInstallAgents/RejectManuallyInstalledAgents: I won’t weigh in on which setting is the best, but each team prefers one way or the other so it’s important to confirm it doesn’t change
  • MissingHeartbeatThreshold and HeartbeatInterval: The first is the number of heartbeats that can go missing before an agent will be flagged as missing heartbeats in the management group. The second is the amount of time (seconds) that is allowed between heartbeats. When a system doesn’t send in a heartbeat for HeartBeatInterval*MissingHeartBeatThreshold seconds the Heartbeat missing monitor gets flipped which can generate alerts. It also triggers the computer down monitoring. Set these values too low and you’ll be dealing with a bunch of false positive alerts. Turn these up too high and you might not know about servers that are offline, soon enough. Have them set differently on different servers and things can get really confusing.

So, for instance, to detect systems with a bad ActionAccountIdentity, you would do the following:

# Get the action account that should be used
$CorrectRunAs = Get-SCOMRunAsAccount -Name ‘YourAccountNameHere’ | where-object {$_.AccountType -eq 'SCOMActionAccountSecureData'}

# Get the management server(s) that are not using that account
Get-SCOMManagementServer | where-object{$_.ActionAccountIdentity -ne $CorrectRunAs.Name}

Side note: I tried to programmatically set the default action account (code that doesn’t work below), but apparently the SDK treats the default run as profile as a special case so we can’t do that any other way accept via the OpsMgr console. I’m sharing this non-working code though in hopes that someone will find it useful.

# This will fail because OpsMgr SDK blocks changes to the default profile
# Wouldn’t it be nice if it worked? Hopefully this is useful…
foreach ($IncorrectServer in $IncorrectServers) {Set-SCOMRunAsProfile -Instance $IncorrectServer.HostedHealthService -Account $RunAs -Profile $DefaultRunAsProfile}

This brings us to our third use, which is making the connection between agents their management and gateway servers and vice versa. Here are some commands that I find useful

# Show the list of management servers, their health state and how many agents they manage
get-scommanagementserver | ft -Property Name, HealthState, @{Name='Agent Count'; Expression={$_.GetAgentManagedComputers().Count}} –AutoSize

# Get the list of agents reporting to a server
$Agents = (get-SCOMManagementServer -Name ‘YourServerName’).GetAgentManagedComputers()

# Show just the agents from that server that are not healthy
# Note: Use the HostedHealthService property to look at the real agent state.
$Agents.HostedHealthService | where-object{$_.HealthState -ne 'Success'}

# Given an agent, find the parent management or gateway server(s)
Get-SCOMAgent –Name “YourAgentName” | Get-SCOMParentManagementServer

The last use is making sure all of our servers are healthy and figuring what’s wrong with them if they are not. The command for getting the unhealthy servers is easy enough:

$UnhealthyServers = get-SCOMManagementServer | where-object{$_.HealthState -ne 'Success'}

The part that’s tricky is getting an understanding of why each server is unhealthy. This is tricky (or non-obvious at least) for two reasons. The first is we have to get the hosted health service for each server, which is where the real state of the management server is held. Doing that is not hard, but it’s also not obvious. 

$UnhealthyServers | foreach-object{$_.HostedHealthService}

The second part is that we need something like the health explorer from the operations console in PowerShell, where we can pass in a health service and get back a hierarchical view of the state of that object. For that I had to create something. 

The attached PS1 file (Write-SCOMMonitoringStateHierarchy.ps1) contains two functions. The first function (Write-SCOMMonitoringStateHierarchy) takes in a hierarchy and then uses the second function (Write-SCOMMonitoringState) to write that hierarchy out to the screen. In order to make the view a bit more useful the functions will display warning and error states as yellow and red respectively. Also, they do not show monitors that are uninitialized (the empty green circle in the UI).

To use the functions download the PS1 file, save it to some location on your system (“FullPathToFile”) and then do the following:

# load the functions up into your session
. FullPathToFile\Write-SCOMMonitoringStateHierarchy.ps1

# Get the hosted health services, from those get the hierarchies
# and with those do the output to the screen
$UnhealthyServers | foreach-object{$_.HostedHealthService} | foreach-object{$_.GetMonitoringStateHierarchy()} | Write-SCOMMonitoringStateHierarchy

And that covers the topic of management and gateway servers. Next time I’ll start working with agents. The topic of getting agents installed and removed with PowerShell is pretty well covered in other places so we’ll probably breeze over that fast and get into topics around keeping them healthy and well configured.

Cheers until then,
Cory

Write-SCOMMonitoringStateHierarchy.ps1

Comments

  • Anonymous
    June 22, 2015
    Very useful. Thanks for sharing this.