Get-SCOMGroup List of Computers

Sometimes you just want to get a list of computers that are members of a group, and just want their names. This is pretty easy using the cmdlet Get-SCOMGroup, just use the –DisplayName switch and add the name of the group and pipe it to the cmdlet Get-SCOMClassInstance.

To see what options are available at this point pipe it Get-Member and you will see a nice list of properties/methods available to the object in the pipe line.

An Important Note to make at this point, what is in the pipeline right now are objects, and can still be massaged with PowerShell very easily. So you could sort by DisplayName and then just dump it out to a table just showing display name.

Examples of what is described above:

# To load the opsmgr cmdlets, import the module first
Import-Module OperationsManager

# To find out what options are available to your output of the list of objects in the group use Get-Member cmdlet
Get-SCOMGroup -DisplayName "Your_Computer_Group_Name" | Get-SCOMClassInstance | Get-Member

# After looking at the Get-Member output we decide that DisplayName will work best
Get-SCOMGroup -DisplayName "Your_Computer_Group_Name" | Get-SCOMClassInstance | Sort DisplayName | Format-Table DisplayName

This is an easy way to get a list of computers that are members of a group. Something that I need to do quite frequently these days.

Hope that this post was helpful.

SCOM 2012 R2 now has support for SQL 2014

We are pleased to announce that System Center 2012 R2 Operations Manager (OpsMgr 2012 R2) now supports SQL Server 2014 Enterprise, Standard (64-bit) as its database. If you choose to use SQL 2014, below are a couple known issues and workarounds you’ll want to be aware of.

Issue: Installation to a SQL 2014 cluster using Cluster Shared Volumes (CSV) is blocked by SCOM 2012 setup.

Workaround: Deploy to a physical server and then use the documentation here to move the database to the CSV.

Issue: Upgrade of SQL SRS is blocked due to SCOM 2012 use of Custom Security Extensions.

Workaround: Uninstall SCOM Reporting and run ResetSRS.exe to clear the custom security extensions. Once that is complete, upgrade SQL and install SCOM 2012 reporting again. Can find similar steps in the documentation here.

Hope that this post was helpful.

Powershell Commands to Configure Gateway Server/Agent Failover

Why do we need to configure failover servers for Gateway Servers and Agents? 

When an Agent is installed and configured to report to a Management Server, it is automatically configured to fail over to ANY other Management Servers. So, if its assigned Management Server goes down, it will randomly pick any other Management Server in the Management Group to connect to (this could actually be a bad thing for large Management Groups, because some Agents will end up reporting to the RMS, which can cause performance problems.... but that’s for a separate blog post).

When an Agent is installed and configured to report to a Gateway Server, no failover servers are automatically configured. So, if the Gateway Server goes down, the Agents will not be able to send any data to the Management Group.

Also, when a Gateway Server is installed, it is configured to report to a specific Management Server and no failover is automatically configured. So, if the Gateway Server’s Management Server goes down, the Gateway Server cannot send any data to the Management Group.

To handle the above scenarios, we must configure the Gateway Server to be able to connect to additional Management Servers, and we must configure the Gateway Agents to be able to connect to additional Gateway Servers. This cannot be done in the OpsMgr Console, and must be done with PowerShell commands.

Notes: 

If a Gateway Server is in a Domain that is not trusted by the Domain where OpsMgr is installed, then you will be using Certificates for the Gateway to authenticate with it’s Management Server. If you configure the Gateway to be able to fail over to another Management Server, it (the failover Management Server) must also have an authentication Certificate installed and configured.

For the Gateway Agent Failover, if the Agents/Gateway are in a Domain that is not trusted by the Domain where OpsMgr is installed, then the Gateway Server that is used for Agent failover must be installed in this same domain (and must have an authentication Certificate installed and configured).

How to Get the Failover Management Servers for your SCOM Agents

Because of some issues arising on a large SCOM environment, I decided to work with PowerShell to create and run a script to see if the SCOM Agents has a Failover Management server.

Note: Use PowerShell to your advantage. It is a powerful tool to have in your arsenal.

Start off by getting the members of the "Get-SCOMAgent" PowerShell command

Get-SCOMAgent | Get-Member

You will likely see something like this…

As you see GetFailoverManagementServers is a collection, therefore this method could contain more than one entry. PrimaryManagementServerName is just a simple string property so we don’t have to do anything special.