Before you start reading the blog below, I just wanted to let you know that I have limited knowledge on the Solaris side. To be honest when I hear Solaris, my memory takes me back 15 years….

Back in the day, (I’m sounding old now) I started working as a second line help-desk employee. I was sharing a desk, which was like 5-6 meters long, with a colleague of mine (it was just a really big room!).

One of the big benefits was that “old” abandoned machines could be bought for a couple of bucks. Most of the time these machines were defect or written off and this is where every IT guy or girl started their addiction of collecting tons of hardware for home usage.

Anyone working in the IT world for a number of years, had (or still has) a room filled with old abandoned hardware which no one wants any more. It is more or less like a computer sanctuary! To you, it’s a gold mine, but to a non IT person it looks like junk.

(To be honest if my wife never forced me to get rid of it all, I would probably still have my hardware sanctuary!)

When we first started working my colleague and I were pretty much on the same side, but soon he started looking at the other side. He started collecting Sun SPARCstations and looking at Solaris.

First with 1:

sparcstation sun pizzabox

but as his addiction grew the entire desk was filled with SPARCstations and most of the time looking like this:


He would endlessly “play” with the hardware, putting on jumpers and changing settings in the OS to try and get thing to work.

He never stopped talking about how much better all this was than my Microsoft crap…

And when he did finally get it to work, I couldn’t resist starting the following conversation:

“So, it is working now?”

“Yes, finally! I needed to mount this and start that and the jumpers were…”  he continued to speak like this for 5 minutes.

And I would always answer “Cool! So you’ve worked on it for a week now just to install the OS so it can recognize the cd player?” The look on his face was priceless.

So when I think of Solaris, I am back at this long desk with my colleague, covered in sun hardware, where we were always hoping we could score some more abandoned hardware! 

This introduction was just to give you an idea of my Solaris knowledge, and even with this knowledge I can write a Management Pack to monitor NFS mount points!

All I need is one shell command to query the file system and some spare time.

Before we start

If you have Oracle running on Solaris in your environment and you want to monitor these components using System Center Operations Manager 2012 R2, there are several steps that need to be taken.

  1. Import the required Management Packs (MP) to monitor Solaris –
  2. Install the open source SCOM agent on the Solaris server –
  3. Install the OpsLogix Oracle MP –

Once you have completed these steps you will be successfully monitoring Oracle running on Solaris.


Now you can see in the diagram above, that Oracle is fully covered by the OpsLogix MP.

But from the Operating Systems Perspective there is still a crucial part missing in the Microsoft Solaris MP: NFS mount points!

These are not discovered by the pack, nor monitored, so using NFS mount points leaves you blind when using the Solaris OS MP provided by Microsoft.

Here, you have a nice overview on logical disks but no mount points.


This can be a bad situation but remember, you are using SCOM and as I have been telling for years:

When you can communicate with the component, you can monitor it with SCOM. No exceptions!

The approach for Unix / Linux is no different:

  • Create a class
  • Create a discovery
  • Create a monitor to check health
  • Create a rule to collect performance
  • (optional) Create a nice view
  • (optional) Create a dashboard

We need to write a Management Pack which extends the default Microsoft Solaris Management Pack and contains these components.

Here, I will describe the entire process for creating the Management Pack.

You can re-use these procedures to monitor or discover any component running Linux / Unix or you can just grab this copy to include NFS mount points for your Solaris monitoring.

Prepare your environment

After installing Visual Studio and the Visual Studio Authoring Extensions, you will need to have references to the cross platform Management Packs.

You can find these Management Packs on the installation media of System Center Operations Manager 2012 (R2 ) in the folder “Management Packs”:


We will need to reference several of these packs in our custom Management Pack.

Create a new Management Pack project and add the required references.

While you could write a module yourself, I strongly recommend looking at the module Management Pack created by Kris Bash –

Download this library – and add it to your project.

How to use the library –

For additional information on monitors and rules –

Your project references should look similar to this:


Then we can create a new class and discovery.

Class and discovery

For the NFS mount point, we need to define a new class. This so we can target specific rules and monitors against this class.

The class is named “Solaris.NFS.Mountpoint.Class” and its base class is Microsoft.Solaris.LogicalDisk which is located in the Microsoft.Solaris.Library pack.

Also, add an extra property called NFSFileSystem.

After creating the class, you need to create a discovery to locate instances of this class. Since I’m not a Solaris guy, I asked a friend of mine for a VM running Solaris, to find out which shell command to use in a SCOM environment.

The shell command is “df -k”. This will show you all NFS mount points (the –k switch shows you the Kbytes):


Now I can read the information from the solaris VM using putty!

The full command will be df -k | awk ‘{print $1 “,” $2 “,” $6}’

The awk command formats the results and ….. this is where the PowerShell came from.

You pipe the results to the formatting where we only want the first, second and sixth column and we are finished.

Next you can create a new discovery rule.

You can use the add new item and choose the discovery rule, which I find rather “annoying” as you have no idea what you are doing in the back, so I am going to add an empty Management Pack fragment and write the XML myself:

In the first part of the XML, we are targeting the discovery against Microsoft.Solaris.Computer so the discovery will run on all Solaris computers.


Next, add the class you want to discover:


Then, select the data source you are going to use and define the components used by the data source:


  • Interval will be the interval for running the discovery. (Don’t set it to low!)
  • Target system, the name of the Solaris computer.
  • Shellcommand, this is the shell command we want to run on the Solaris computer.
  • Timeout, is the timeout of the shell command.
  • Username, password will be the runasaccount used to run the rule. In this case default Unix action account.
  • PsScriptname, this is the PowerShell script we run for creating a property bag and more filtering.
  • PSScriptBody the actual PowerShell script we are going to use:


The script takes parameters from the datasource, which runs the shell script on the Solaris system and retrieves values:

  • Stdout = output from the Shell command.
  • StdErr = error messages, if there are any.
  • Returncode =  0 for success and the rest are considered failed.

After this it divides the output and creates a property bag for each line in the output.

Note: Since this is Unix, we run the workflow on the management server to query WSMan, therefore you can use PowerShell to output the results to the eventlog on the management server. This is helpful for troubleshooting! 

Next, the datasource will filter the results.


The last step is to create a new class instance based on the property bags created in the PowerShell script.


Now you have a class and discovery which will discover the NFS mount points.

Create a Monitor to monitor used space

For the monitor we are going to use the following Monitor Type: Unix.Authoring.ShellCommand.PropertyBag.GreaterThanThreshold.ThreeState.MonitorType

This will let you create the shell command df -k | awk ‘{print $6″:” $5}’

This will collect all NFS mount points and their usage in %:


After running the shell command we can use PowerShell to retrieve the proper values, put them in property bags and filter the correct instance.


When importing the Management Pack a new class will be discovered. It will be monitored for the used space and generate an alert if the used space is above 80 for warning or 90 for error! (this is the default)


Create a performance collection rule

Now you can create a performance collection rule for the used space. By doing this you can create performance views and reports on NFS mount point usage.

You can do this using the following module: “Unix.Authoring.TimedShellCommand.PropertyBag.DataSource”.

This module uses a shell command which passes this output to PowerShell where we can create multiple property bags. Multiple counters are then created in the Operational Database and Data Warehouse.

The shell command used:


You can select the name and the percentage used property.

In the PowerShell script I remove the percentage sign (%) and created a performance counter from the instance and value.


Then the performance data is created:



You can monitor NFS mount points easily with SCOM 2012. All you really need is the Management Pack with all the modules created by Kris Bash and one shell command.

Even with my Solaris Experience, I was able to do this with no trouble.

As long as you have some authoring experience, with the steps provided you should be able to extend this to other components running on Solaris or any Unix or Linux system supported by SCOM.

You can find the VS project in the technet gallery download (link) together with a full version of the Management Pack, including views and dashboards as shown below.

Cheers and happy authoring,

Oskar Landman