Archive | February, 2016

[O so Cool] Connecting your Raspberry PI (RPi) to OMS.

8 Feb


At my home I have a Raspberry to do all my home automation. (Light, temperature, alarm, cams etc.) . Since the OMS Linux agent is available I was wondering if I could use this agent to monitor my raspberry pi without having a SCOM environment in place.

AND guess what? YES you can!!!

First before you are accusing me of plagiarism I have to say all the credits go to the guy of this blog ( ).

So I followed the steps and it worked. You can’t use the wget described on the oms Quick install Guide ( ) because this one will fail due to the pre check of AMD64.

Since the RPI platform isn’t AMD64 you will have to trick it a little.

So you will have to follow the steps below:


Install The OS on your RPI

We take the latest RASPBIAN WEEZY


Open a putty and log on as pi / raspberry



Now we install the Ruby , and fluent modules

sudo aptitude install ruby-dev git make

sudo gem install fluentd

sudo fluent-gem install fluent-plugin-td



Next we create a user that the OMS agent service is using for running. Remember the password you provide

sudo adduser omsagent



Now we are going to get the OMS source code for github

git clone


Next is to create the directory structure since we can’t use the OMS installer

sudo mkdir -p /etc/opt/microsoft/omsagent/certs

sudo mkdir -p /etc/opt/microsoft/omsagent/conf/omsagent.d

sudo mkdir -p /etc/opt/microsoft/omsagent/sysconf

sudo mkdir -p /etc/opt/microsoft/scx/conf

sudo mkdir -p /opt/microsoft/omsagent/bin

sudo mkdir -p /opt/microsoft/omsagent/plugins

sudo mkdir -p /var/opt/microsoft/omsagent/tmp

sudo mkdir -p /var/opt/microsoft/omsagent/run

sudo mkdir -p /var/opt/microsoft/omsagent/log

sudo mkdir -p /var/opt/microsoft/omsconfig/log

sudo mkdir -p /var/opt/microsoft/omsconfig/run

sudo chown omsagent:omsagent -R /var/opt/microsoft/omsconfig

sudo chown omsagent:omsagent -R /var/opt/microsoft/omsagent

sudo ln -s /usr /opt/microsoft/omsagent/ruby

sudo ln -s /usr/local/bin/fluentd /opt/microsoft/omsagent/bin/omsagent


We setup the correct config files for the OMS agent service

sudo cp OMS-Agent-for-Linux/installer/scripts/auth_key.rb /opt/microsoft/omsagent/bin/

sudo cp OMS-Agent-for-Linux/installer/scripts/ /opt/microsoft/omsagent/bin/

sudo chmod u+x /opt/microsoft/omsagent/bin/

sudo cp OMS-Agent-for-Linux/installer/scripts/service_control /opt/microsoft/omsagent/bin/

sudo cp OMS-Agent-for-Linux/installer/scripts/omsagent.ulinux /etc/init.d/omsagent

sudo chmod u+x /etc/init.d/omsagent

sudo cp -Rf OMS-Agent-for-Linux/source/code/plugins /opt/microsoft/omsagent/


We copy the default agent configuration files , we are going to change this later on to specify what we want to monitor

sudo cp OMS-Agent-for-Linux/installer/conf/omsagent.conf /etc/opt/microsoft/omsagent/conf/

sudo mv /etc/rsyslog.conf /etc/rsyslog.conf.default

sudo cp OMS-Agent-for-Linux/installer/conf/rsyslog.conf /etc/


And this is probably the trick for this all. We fake the OMS agent to believe it’s an AMD64 platform.

sudo echo “1.0.0-47 20151102 Developer_Build” > /tmp/installinfo.txt

sudo echo `date +%Y-%m-%dT%H:%M:%S` >> /tmp/installinfo.txt

sudo mv /tmp/installinfo.txt /etc/opt/icrosoft/omsagent/sysconf/

sudo echo “OSName=Ubuntu” > /tmp/scx-release

sudo echo “OSVersion=14.04” >> /tmp/scx-release

sudo echo “OSFullName=Ubuntu 14.04 (x86_64)” >> /tmp/scx-release

sudo echo “OSAlias=UniversalD” >> /tmp/scx-release

sudo echo “OSManufacturer=Canonical Group Limited” >> /tmp/scx-release

sudo mv /tmp/scx-release /etc/opt/icrosoft/scx/conf/


Now we are going to onboard the OMS agent to your OMS workspace.

Get your (1) <workspace id> and (20 <key> from the OMS page -> Settings -> Connected Sources





And we fill it in the omsadmin script as parameters

sudo /opt/microsoft/omsagent/bin/ -w <workspace id> -s <key>


If everything is successful it will give you the onboard message. If not check the keys.


Next is to edit the OMS agent config to let it know what it should monitor.

Since the OMI agent isn’t installed on this platform we can only do the syslog stuff for now.

sudo vi /etc/opt/microsoft/omsagent/conf/omsagent.conf


The most important is to check if this elements exists in the file


type syslog

port 25224


tag oms.syslog



<filter oms.syslog.**>

type filter_syslog



Now we are going to let the OMS agent startup correctly as a service. We have to manipulate the init.d file a bit to have it run from of the source files we got from git hub.

sudo vi /etc/init.d/omsagent


Edit the file

Change this line:

START_QUALS=”-d $PIDFILE –no-supervisor -o $LOGFILE”


START_QUALS=”-d $PIDFILE –no-supervisor -o $LOGFILE -p /opt/microsoft/omsagent/plugins -c /etc/opt/microsoft/omsagent/conf/omsagent.conf


Next we setup the syslog log levels. Just get all 😉

sudo vi /etc/rsyslog.conf

add this row

*.* @


And we startup the OMS agent

sudo service omsagent start


And the syslog deamon

sudo service rsyslog restart


Now you logon to the portal

And you watch for the syslog event type messages. Could take some minutes.

Go to Search and type: “* Type=Syslog” (without the quotes)

Or you search by name if you know the PRI host name: “* HostName=raspberrypi” (without the quotes)


This could be the output. We see the startup syslog messages!!!


Cool isn’t it!!

Next step would be to get the OMI agent working so we can readout the performance data.


Happy OMS’ing

Michel Kamp

Touching SCOM



[FOR the MP Devs] Grooming your managed objects completely from scom

8 Feb


I some situations when you are developing a new MP you want to be sure that your discovery’s are working correctly.

The problem

Normally you would let the discovery run and watch if the managed object is created, but after the first time discovering and un-discovering the managed object it could trick you for the next discovery.

Basically we as MP devs know that we can simply manual delete a managed object from scom by using a SQL query and set the isDeleted to true. But this can be tricky. If the discovery workflow runs again and create a managed object (the same) it will just update the isDeleted to False. So basically you are getting ‘old’ discovery data. Knowing this in some cases the configuration is not updated and the workflows under this managed object just won’t get executed. So you will be stuck in having an uninitialized managed object(s). Especially when using Managed objects that are managed by a scom resource pool can be facing this issue.


Two solution could help you out. (ALL UNSUPPORTED BY MICRSOSOFT, but yhea … no guts no glory)

  1. Wait 2 days … then the normal purge will kick in
  2. Modify the purging threshold and manual run the purge

The SQL script below provides step 2. Connect to the operational DB as admin and follow the steps.

Before you run it you will have to change ‘‘ to the first parent name you want to delete. (By not including the right % in the like) In this case it’s the parent of all VMWARE monitoring managed objects.

— Delete a managed object completely from scom


— Michel Kamp


————- Find the object

from dbo.BaseManagedEntity where FullName like’

————- delete it (hmmm okay mark it as delete)

update dbo.BaseManagedEntity set IsDeleted=1 where FullName like’

— object is still in DB but now as isdeleted = true

— it will be deleted after 2 days. but we don’t want to wait.

— we force the delete by setting the purgedate delta to 0

————- Update the purge date time function

FUNCTION [dbo].[fn_DiscoveryDataPurgeThreshold]()



    –RETURN DATEADD(dd, -2, getutcdate())

DATEADD(dd, 0, getutcdate())


— now we call the purge stp to clean it all

————- do the real purge

exec p_DiscoveryDataPurging

— we do a check if it is gone.

————- Find the object

from dbo.BaseManagedEntity where FullName like’

— and there should not be any (0) result.

— End script

O don’t forget to change the DiscoveryDataPurgeThreshold back to its original when you are ready …


Michel Kamp