Search This Blog

Friday 21 August 2015

UserVoice for SCOM - Let your voice be heard!


As of 01/05/2017, this blog will not be updated or maintained

The product group has opened a UserVoice for SCOM. You can submit your ideas or vote on the ones you’d like to see. All of the feedback you share in these forums will be monitored and reviewed by the Microsoft Engineering Teams responsible for building SCOM.

This is where we need to let Microsoft know what we as SCOM Engineers want in our product.

http://systemcenterom.uservoice.com/

Tuesday 18 August 2015

Available SCOM 2012, SCOM 2012 SP1 and SCOM 2012 R2 Update Rollup list


As of 01/05/2017, this blog will not be updated or maintained

Here is a list and links to the Update Rollup's (UR) that is available for SCOM 2012, SCOM 2012 SP1 and SCOM 2012 R2. The updates are listed according to build number. Update Rollup build numbers that have a larger numeric value include the fixes from all previously released update rollup packages. Any version of SCOM 2012 can be updated to a later-version update rollup. You cannot uninstall a later-version update rollup to downgrade to an earlier-version update rollup.

This post will not cover the Step-by-Step installation/implementation of the Update Rollup's. Where applicable, I will add a link to a article for the Step-by-Step.

Thursday 26 February 2015

Get-SCOMGroup List of Computers


As of 01/05/2017, this blog will not be updated or maintained

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.

Wednesday 25 February 2015

SCOM 2012 R2 now has support for SQL 2014


As of 01/05/2017, this blog will not be updated or maintained




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.

Friday 6 February 2015

Powershell Commands to Configure Gateway Server/Agent Failover


As of 01/05/2017, this blog will not be updated or maintained

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

Thursday 5 February 2015

How to Get the Failover Management Servers for your SCOM Agents


As of 01/05/2017, this blog will not be updated or maintained

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.