Tuesday, February 20, 2018

Document your SCOM Distributed Applications with Powershell and Excel


As a consultant I am typically required to provide some sort of documentation. That said I like to provide more documentation than required, which is why I give my SCOM clients a general How To document if they are new to SCOM. I also provide documentation on the SCOM Distributed Applications we have created in the environment. 

This script was born out for that reason, as well as for creating Visio based dashboards in SquaredUp. To create Visio dashboards you need the SCOM Object ID so that SquaredUp knows where to link the Visio Object to for Health status within SCOM. Getting the SCOM Objects of one or two items might not be a big deal, but when you have 30+ Distributed Applications each with multiple components and each component having more than one object, this adds up quickly.

The original version of this script just exported the information to separate CSV files and I took the time to "make it pretty" in excel to deliver it to the client.

Now, Powershell does it for me. 

First, what this script is: A script that attempts to grab all your Distributed Applications, their components and objects in the DA components.

What it is not: a full SCOM environment documentation script.
Also if you have a SCOM Group inside a SCOM Group inside a DA Component, the script will only go one level deep on the first SCOM Group.

The script accepts parameters -scom and -credential are required, obviously.
The script will also accept optional parameters -saveandclose (boolean) -path (string) -filename (string). If you use the SaveandClose parameter you need to fill out the path and filename or it will fail to save.

The script is designed to be run remotely on a machine that has Excel. Excel is obviously required. The account you specify needs to have remote Powershell access to the SCOM environment.

Here are some examples of running the script with parameters

If you don't specify credentials it will prompt for your credentials


Here is example output from my SCOM Lab. 
This is the main sheet where all Distributed Applications will be put with their Management Pack and SCOM Object ID.
 Example outputs of my two DA's.

GIF capture of it running.

The script has been tested in a production environment with approximately 88 distributed applications, in this instance the script took about 10 minutes to run.

Definitely test it in your lab first. Use at your own risk. The script does not modify any data in your environment, its only getting data. However it will put load on your SDK service for each call it makes.

Tested on SCOM 2016 and 1801 and Excel 2016. It should work in SCOM 2012 R2, if you try it and it does work please let me know.

Currently working on a github repository for it, for now you can download the script here

Friday, February 16, 2018

Windows Azure Pack & Service Management Automation IIS Error

So I had a problem in my lab, I had extended the storage pool disk I use for Hyper-V VMs but forgot to extend it in Windows. It filled up and bad things happened. I extended it in Windows and restarted my VMs, but the SQL Service on my Windows Azure Pack server did not restart upon reboot. So I was greeted with this when trying to access the WAP Portal.

Not a very good message, but at least IIS was up and working. Went in and found the SQL Service was not started. I started the SQL Service, waited a minute then went into IIS and restarted the IIS service

and we're back.

Also be aware that the Runbook Worker service on your SMA server will also be stopped if the SMA is connected to the same SQL Service that was down.

Wednesday, February 14, 2018

Upgrade SCOM 2016 to 1801

Updated Feb 15th for one of the but fixes mentioned below

Microsoft has released System Center 1801. Wait, that looks like a Configuration Manager build number. You are correct, MS has added System Center to the Semi-Annual Channel (SAC). What does that mean? It means to get new features in System Center, in particular SCOM, you have to install the SAC version of SCOM. If you remain on 2016 or 2012 R2 you get the normal support life and only bug fixes. No new features will come to the Long Term Servicing Channel (LTSC). You can read more about it here. https://azure.microsoft.com/en-us/blog/first-system-center-semi-annual-channel-release-now-available/

This post will discuss upgrading from SCOM 2016 to 1801, if you would like Marnix Wolf has a post on 2012 R2 to 1801. Though the process is mostly the same. http://thoughtsonopsmgr.blogspot.com/2018/02/my-scom-2012-r2-ur14-to-scom-1801.html

Upgrading SCOM 2016 to 1801 is supported on RTM, and any currently released update rollup.

Note: this is a true upgrade, you should follow your normal plan for upgrading, including research, change control any other requirements your organization has for upgrading production products. 

For my environment I have SCOM on one VM and the SQL Server that houses the OperationsManager and OperationsManagerDW Databases as well as the SSRS Instance for SCOM Reporting.

First we will upgrade the Management Server. The install will detect what is on the server you are upgrading.

Select your install folder

Since the environment is already on 2016 there are no upgrades needed for the Microsoft Report Viewer and the CLR types.

Enter your SCOM SDK Service account.

and we're ready to rock.

This will take a few minutes to run.

Setup is complete

One new things in 1801 is the ability to license your environment through the GUI, instead of using the powershell cmdlet to set the license.

Navigate to Help -> About

We now have the activate button on the about screen.

Enter your product key, which is always the same.

Lets look at one more new features in 1801. Under the Administration tab there is now a section for Operations Manager Products. Under each one of these sections SCOM will tell you what version that portion of the product is on.

For instance, I have the SCOM console installed on a couple of other servers for the powershell Modules. SCOM 2016 reports as version 7.2.11719.0 and 1801 reports as 7.3.13142.0. Pretty neat, especially if you have consoles in lots of servers or users machines. 

Ah, it tells me my reporting server is still on 2016.

Running the install media on my SQL Server where SCOM Reporting is installed.

I fail the prereq check.  

Edit: per the release notes, which I somehow missed, figures, read Kevin Holmans blog and other release notes and missed these: https://docs.microsoft.com/en-us/system-center/scom/release-notes-1801?view=sc-om-1801

Workaround: Install the System Center 2016 - Operations Manager Operations console on the server hosting the Reporting server role and then retry upgrading the Reporting server role to version 1801. Once the upgrade is successfully completed, you can uninstall the upgraded Operations console from the Reporting server.  

Still not ideal, hopefully there is a hotfix release or it is fixed in the next release.

End Edit

Starting the SQL Server Agent Service is no big deal, its set to manually trigger. However, the bigger problem is that the setup fails to detect the latest version of 1801 on the Management Server. Several reboots later of both SQL and the SCOM Management server, I thought upgrading the SCOM agent on SQL would solve the problem.

Pushing the agent out reveals no OK button, enter works and will kick off the agent upgrade.

That also did not work. I tried installing the MSI directly from the install folder, that also did not work as the Reporting still shows as 2016 in SCOM Console.

Overall the upgrade is nice, minus the two issues I've found. I would wait for Microsoft to fix these issues before upgrading a production environment.

The new SCOM Section in Administration is nice and the new HTML 5 portal is great. Microosft put together a web series here on how to use it here: https://blogs.technet.microsoft.com/momteam/2018/02/12/new-scom-web-console-blog-series-post1/
I may put together a post on SquaredUp vs the new Web Console. SquaredUp is a very popular HTML5 add on portal for SCOM.

Monday, February 5, 2018

Working with the SCOM Powershell Module

Powershell Logo
Working with SCOM in the console and working with SCOM in Powershell are two vastly different things. Powershell is much quicker, especially for getting lots of data and related objects at once. However, if you haven't worked very much with the Operations Manager Powershell Module very much, these might be a few quirks or cool tips you should know. 

Lets start by getting management packs in SCOM. 

$mp = get-scommanagementpack -DisplayName "*windows*" | where {$_.sealed -eq $true}

As you can see get-scommanagment pack accepts wildcards, this should return back quite a few MPs if you are monitoring Windows. Also note when using pipe Where it wants an -eq to match true/false. More on why that is important in a minute. 
There are many properties available when you get SCOM objects, a few of the properties available for Management Packs are Name and DisplayName.

Management pack propertes Name and Displayname
Now, lets say we wanted to get all monitors that are enabled from these Management Packs. We'll use the Get-SCOMMonitor command.

 get-scommonitor -ManagementPack $mp | where{$_.Enabled -match $true}

from managementpacks where enabled matches true

So get-scommonitor accepts multiple management packs, however to get enabled monitors you need to use -match instead of -eq. If you use -eq you'll get nothing back. This can be slightly frustrating if you are expecting some consistency. 

Next lets get a SCOM Group by using Get-SCOMGroup command.

$grp = get-scomgroup -ComputerName $scom -Credential $cred -DisplayName "wa*"

 Notice here, I've used -computername This is getting the group to remotely to my SCOM management server. I've found more SCOM commands that accept the -computername parameter than don't.

Next if you do $grp.name it returns nothing. Unlike the Management Packs from above, that we got earlier, the full name of the object is not .name its .fullname. See below

And finally my favorite part of SCOM Powershell is .GetRelatedMonitoringObjects() This returns all the related monitoring objects of the item you performed it on. In this case it gets all the members of the group.

gets related monitoring objects of SCOM object

This works on many SCOM Classes, but not all. So try it out and see what you can do.

So, in conclusion we have:
- Many SCOM commands can take wild cards
- You can get multiple monitors from multiple management packs at the same time
- Some commands require -eq and some require -match 
- some SCOM Classes have a Name Property whereas others have FullName
- many SCOM Commands can be run remotely, provided you have the SCOM Module installed.
- use .GetRelatedMonitoringObjects() to find child objects of groups or other classes.

Tuesday, January 30, 2018

Automate SCOM Group Creation

Creating SCOM Groups can be tedious. Creating dozens of SCOM groups each with multiple members can be a long task indeed.

I searched and searched and thought surely someone somewhere has come up with some Powershell to do this task. I could not find anything. Enter Tao Yang and his OpsMgrSDK Powershell Module. If you are not familiar with this module you need to be. You can read about it and learn how to install it in your environment here https://blog.tyang.org/2015/06/24/automating-opsmgr-part-1-introducing-opsmgrextended-powershell-sma-module/

This is a small script using commands from the module. But I will be using this same method for larger scripts getting data from VMM and SCOM in later blog posts.

For this script to work you'll need a CSV file with three fields filled out for every SCOM Windows Computer Object you want to add to the group.  The computer field needs the FQDN of the server you wish to add to the group. The name field cannot have any spaces so either make it all one word or put periods between words.
Name: My.Awesome.Group
DisplayName: My Awesome Group
Computer: myserver.sandlot.dom

The script will attempt to find the group first, if it cannot it will create it in the management pack you specific at the beginning of the script. There is a start-sleep after creation of the group, this is to give SCOM the necessary time to create the group before you start adding servers to it. Depending on how fast or slow your environment is, you may need to adjust the value, which is in seconds. In one environment I had to adjust it to over 500 seconds.

# Create SCOM Groups with members from CSV file
# Using Tao Yang's OpsMgr SDK powershell module found here https://blog.tyang.org/2015/06/24/automating-opsmgr-part-1-introducing-opsmgrextended-powershell-sma-module/
# Change $SCOM to your SCOM management server, run script on your Management Server where you have the OpsMgr SDK installed.

$groups = import-csv C:\newgroups.csv #create CSV file with fields called Name, DisplayName and Computer. Computername must be Fully Qualified Domain Name EG mycomputer.sandlot.dom
                                      #Script will create group if it does not exist
$mpname = "custom.groups" #management pack must exist
$scom = "om01.sandlot.dom" #change to your SCOM management server where OpsMgr module is installed

Import-Module OperationsManager

foreach($group in $groups)
    $groupname = $group.name
    $groupDisplay = $group.displayname
    $computer = $group.computer

    $verify = Get-scomgroup -DisplayName $groupDisplay

    if($verify -eq $null)
       $create = new-omcomputergroup -sdk $scom -MPname $mpname -computergroupname $groupname -computergroupdisplayname $groupDisplay
       start-sleep -Seconds 120 #you may have to adjust this depending on how fast or slow your SCOM environment is.
       $groupadd = New-OMComputerGroupExplicitMember -SDK $scom -GroupName "$mpname.$groupname" -ComputerPrincipalName $computer
    } Else {$groupadd = New-OMComputerGroupExplicitMember -SDK $scom -GroupName $verify.fullname -ComputerPrincipalName $computer}


I am so thankful for Tao Yang creating this module. It has saved me so much time. Once the groups are created you can this create aggregate Health roll-ups, I believe the module attempts to do this but my results have been mixed.

Lastly, the module and this script work in both SCOM 2012 R2 and SCOM 2016.

Thursday, June 16, 2016

Send OMS Search Results to Azure Automation: The Easy Way

A few weeks ago the Operations Management Suite (OMS) product team announced that you could include search results in webhook payloads. Article here. This is really useful if you are into automation and specifically Azure Automation. It is now much easier in my opinion to get pertinent data to Azure Automation from OMS when you include search results in the OMS Alert.

First let’s look at a simple query, we'll use the default query for finding when users were added to Domain Admins, which is already stored in OMS.

Type=SecurityEvent EventID=4728 OR EventID=4732 OR EventID=4756

As you can see there is a fair amount of information contained in this alert. Let’s add a Webhook that calls an Azure Automation runbook, to the Alert I already created in OMS so we can see what gets sent to Azure Automation.

Here is the PowerShell in my Azure Automation runbook.

In the first three lines we're passing the Parameter $WebhookData into the runbook. This variable is actually persistent in Azure Automation runbooks and it can be null or not even included if you just want to call the runbook without passing it any data. I have set the runbook to run on my Hybrid Worker and drop the variables into text files on the local hdd.

param (

if ($WebhookData -ne $null) {
    # Collect properties of WebhookData.
    $WebhookName    =   $WebhookData.WebhookName
    $WebhookHeaders =   $WebhookData.RequestHeader  
    $WebhookBody    =   $WebhookData.RequestBody
    $webhookname | out-file c:\temp\Webhookname.txt
    $webhookheaders | out-file c:\temp\webhookheaders.txt
    $WebhookBody | out-file c:\temp\webhookbody.txt 

This is what I get when I open the WebhookBody text file.

There is a lot of information in there, but when you try to parse it and add pertinent information to PowerShell variables, you get empty results. To format it and be able to assign data to variables we need to do two things. We need to modify the alert in OMS and add a couple lines of PowerShell in the runbook.

First changing the Alert. We'll add "IncludeSearchResults":true" after checking the "include custom JSON payload." 


Save the alert and then we add the PowerShell. 

Second we'll add the following to the runbook:

$SearchResults = (ConvertFrom-JSON $WebhookBody).SearchResults
$SearchResultsValue = $SearchResults.value

I added some more out-file commands so we can look at the data.

Now I'll generate the alert again and see what we get.

When I open SearchResultsValue.txt, this is what I get.

This is nicely formatted and easy to understand. More importantly I can now assign any one of the search result items on the left hand side to a PowerShell variable.

Let’s say in this example we want to get the MemberName and TargetAccount. These would be logical choices given the context of the alert. All we need to do now is add a ForEach loop and assign variables.

  Foreach ($item in $SearchResultsValue)


The complete runbook now looks like this: 

I'll trigger the alert again and we'll see the results.

From here it would be relatively easy to do some alert remediation in our on-prem Active Directory, now that we have the search result data available in PowerShell variables.