Search This Blog

Thursday, November 21, 2013

Windows 2012 WMI Hotfix

Had a 2012 Server that was being monitoring by System Center lock up on us today. Suspect a WMI leak. Hotfix deployment, engage!

Friday, November 15, 2013

SCOM 2012 Powershell - Retrieving a List of Computers in a Group

Had to search for a batch file that is on one of the many SQL servers we have in the environment. First inclination was, let me pull the systems from SCOM since it has all our SQL servers.

Poked around the interwebs a while and noticed a lot of scripts had references to 2007 commands that hadn't been updated to 2012. Here's the basic steps taken to get my group of SQL servers. You could perform the same task on pretty much any group in the same manner.

  • Open the Operations Manager Shell powershell console

Image illustratin the correct System Center 2012 Operations Manager Shell to open for running the powershell commands
  • Type in : Get-SCOMGroup
Image shows the sample output of running the SCOM 2012 Get-SCOMGroup command in powershell
  • Search for the group you want to retrieve members from
  • Now type in: $Group = Get-SCOMGroup |  where {$_.DisplayName -eq "SQL Computers"} (or insert the group your looking for instead of SQL Computers")
Image illustrates running the Get-SCOMGroup command with a filter for a specific group and assigning to a variable

  • Next, type in: $Members = $Group.GetRelatedMonitoringObjects()
Illustrates the use of the command GetRelatedMonitoringObjects() for retriving a list of group members and assigning them to a variable

  • Now, you can simply type: $Members
Illustrates the output of members captured in the previous step using GetRelatedMonitoringObject(). Should show three headings and then the server members from the group

  • Or, pipe the command out to a file: $Members | Sort DisplayName | FT DisplayName | out-file C:\Scripts\Servers.txt
Illustrates running the following command in powershell to pipe a variable out to a file: $Members | Sort DisplayName | FT DisplayName | out-file C:\Scripts\Servers.txt

Thursday, October 31, 2013

Automated Discovery and Troubleshooting of Gray State Systems in System Center 2012 (Part-1)

Recently come across a rash of clients and internal systems at the office where monitored devices, for whatever reason, have gone into a gray state. I needed a way to quickly discover these systems, and ideally, run a script that would take some basic actions to remediate or troubleshoot these agents. In this first post, I'll give the full code necessary to get the gray agent discovery running. In the second post, I'll give a powershell script that detects the grayed out agents, shuts down the HealthService, clears the agent health directory, and then turns the HealthService back on automatically.

I came across three lines of code in the following blog, which got me pointed in the right direction. However, the code did not work correctly as provided.

$WCC = get-monitoringclass -name "Microsoft.SystemCenter.Agent"
$MO = Get-MonitoringObject -monitoringclass:$WCC | where {$_.IsAvailable -eq $false}
$MO | select DisplayName

With just that code, I would receive the following error screen:

Illustrates an error that is common when using powerhsell get-monitoringclass without specifiying the appropriate variables for the script to connect to the System Center 2012 Management Server

If you update the code to include the following path and connection to your system center server, the code will function properly. Running this should spit out a list of computers with a gray state in the agent status. This code should all be included in your powershell script:

$RMSFQDN = "<your SCOM managment server FQDN>"
$Name = "Microsoft.EnterpriseManagement.OperationsManager.Client"
$ModuleLoaded = Get-Pssnapin $Name -ErrorAction SilentlyContinue

If (-not $ModuleLoaded)
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";

New-ManagementGroupConnection -ConnectionString $RMSFQDN
Set-Location "OperationsManagerMonitoring::";

$AgentClass = get-monitoringclass -name:Microsoft.SystemCenter.Agent
$MO = Get-MonitoringObject -monitoringclass:$AgentClass | where {$_.IsAvailable -eq $false}

$MO | select DisplayName

Also, review this link for a comprehensive list of WMI hotfixes for various platforms:

Updated 11-15-2013: Review this link for agent based system hotfixes:

Friday, June 14, 2013

Scripting the Deployment of the Action Account to servers

If you have a large server list and you quickly want to add rights for your action account, check out this helpful method. Just go to active directory and create a query for your servers, then remove the columns (outside of the server names). I've enclosed the query definition. Drop this into an xml file and import into Active Directory, under "Saved Queries".

Here is the link to the site:

Thursday, May 2, 2013

Where Did My LINUX RPMs Go?! @##%&&%

Some time ago, I created a video and wrote a blog on a quick and painless way to install the LINUX agents for SCOM. Well, came time to do that again and I noticed, even after downloading the management packs from the catalog, I could not find the rpm files!

After some exasperating searching and much gnashing of the teeth, I finally found the download for the updated management packs. Installing the ones from this pack will give you the rpms. In the past, the rpms could be found on the CD/DVD.

System Center 2012 Monitoring Pack for UNIX and Linux Operating Systems :

Monday, March 11, 2013

Upcoming topics on SCOM

Haven't had a chance to post anything recently, but it's not for a lack of trying. I have 41 pages of screen shots and instructions that walk folks through the SNMP troubleshooting, from creating the LINUX test system through to getting the alerts in SCOM, trying to walk through where your SNMP setup could be failing. Also going to post pulling raw metrics for analysis in Excel. SQL Reporting is nice, but it can be overly complicated when sometimes, you just want some quick data and some graphs. Finally, will be posting another method for organizing data outside of the datawarehouse. This will provide a safer method of writing your own reports and views without disturbing the installation.

Friday, February 15, 2013

System Center Installer - OMServer.msi returned error 1603

Having problems installing your secondary management server, maybe even your primary? Great post about pre-requisites. Setting up our secondary server, the management server installer was failing. I had made sure to install the report viewer modules, .NET 4.0 but forgot .NET 3.51. The installer won't tell you directly that the prerequisite was missing and will simply fail, leaving you to pour through a large install log to find the problem.

If you're seeing this in your install log, it may be the same case:

Always: :LaunchMSI: Setting rollback to true
[16:58:55]: Error: :LaunchMSI: MSI C:\SCOMSP1\Setup\AMD64\Server\OMServer.msi returned error 1603

Check Christopher Keyaert's article for additional information and other troubleshooting steps.

Monday, February 11, 2013

Way to Mass Uninstall System Center Agents on Remote Computers

I needed to remove the agents on a number of computers and naturally, I wanted a quick way of doing so. I had a csv output from an active directory query but needed a way to use that to uninstall the agent. The following powershell script will allow you to do just so. It may or may not work on certain 2000 and 2003 installations. I am working on a script that works on all systems. In the mean time, here you go.

$Servers="computer1","computer2", "computer3"
FOREACH ($TargetServer in $servers){(Get-WmiObject -Class Win32_Product -Filter "Name='System Center Operations Manager 2012 Agent'" -ComputerName $TargetServer ).Uninstall()}

Errors with SCOM 2012 SP1 Upgrade or Installation

Upgraded to SCOM 2012 SP1 last week and exposed an few errors for those who may have gone a little to fast in the installation. Chances are, if you are seeing the following errors, you may have forgotten to change the "Data Access Service" option during the upgrade to a domain account. If you leave it a service account, you will get the following errors post upgrade. Now, the good thing is, if you've done this and can no longer log into the management console, go back to your server, hunt down the System Center Data Access Service and change the login from "Local Service" to your data access account that was created during the original installation of System Center.

Also, if you are starting from scratch with an SP1 installation, you will need to add trailing "\" back slashes on the SQL directories. If you do not, the Datawarehouse installation will likely fail and roll the entire installation back. So, when you perform the SQL server discovery during installation, the installer will find your data and log directories and populate them automatically as such:

"D:\SQL Data"
"L:\SQL Logs"

You need to change these to the following format (obviously your drives and directories may differ)

"D:\SQL Data\"
"L:\SQL Logs\"

And then your System Center Operations Manager 2012 SP1 installation should proceed.

Errors you may encounter if you do not have a domain login for the Data Access account:

Inner Exception.Type: Microsoft.EnterpriseManagement.Common.ServiceNotRunningException, Exception Error Code: 0x80131604, Exception.Message: The Data Access service is either not running or not yet initialized. Check the event log for more information.
Event 29120
OpsMgr Management Configuration Service failed to process configuration request (Xml configuration file or management pack request) due to the following exception
System.Runtime.Remoting.RemotingException: Unable to get ISdkService interface. Please make sure local Sdk Service is running.
   at Microsoft.EnterpriseManagement.ManagementConfiguration.Communication.CredentialDataProvider.CreateSdkConnector()

Event 29195
OpsMgr Management Configuration Service failed to communicate with System Center Data Access Service due to the following exception
System.Runtime.Remoting.RemotingException: Unable to get ISdkService interface. Please make sure local Sdk Service is running.

Event 26380
The System Center Data Access service failed due to an unhandled exception. 
The service will attempt to restart.
Microsoft.EnterpriseManagement.Common.SdkServiceNotInitializedException: The Data Access service has not yet initialized. Please try again.

Event 26340
System Center Data Access Service and/or System Center Management is unresponsive because Authorization Manager is unable to recover from database errors. Please restart services System Center Data Access Service and System Center Management.