You have heard it all over the place, System Center Operations Manager 2007 R2 has reached the Release Candidate milestone and the RC bits have been made available on connect.microsoft.com.
As it is becoming a tradition for me with each new release, I want to take a look at the Unix Monitoring stuff like I did since beta1 of Xplat, passing thru beta2. I am an integration freak and I have always insisted that interoperability is key. I will leave the most obvious “release notes” kind of things out of here, such as saying that there are now agents for the x64 version of linux distro’s, and so on…. you can read this stuff in the release notes already and in a zillion of other places.
Let’s instead look at my first impression ( = I am amazed: this product is really getting awesome) and let’s do a bit of digging, mostly to note what changed since my previous posts on Xplat (which, by the way, is the MOST visited post on this blog I ever published) – of course there is A LOT more that has changed under the hood… but those are code changes, improvements, polishing of the product itself… while that would be interesting from a code perspective, here I am more interested in what the final user (the System Administrator) will ultimately interact with directly, and what he might need to troubleshoot and understand how the pieces fit together to realize Unix Monitoring in OpsMgr.
After having hacked the RedHat MP to work on my CentOS box (as usual), I started to take a look at what is installed on the Linux box. Here are the new services:
You will notice the daemons have changed names and get launched with new parameters.
Of course when you see who uses port 1270 everything becomes clearer:
Therefore I can place the two new names and understand that SCXCIMSERVER is the WSMAN implementation, while SCXCIMPROVAGT is the CIM/WBEM implementation.
There is one more difference at the “service” (or “daemon”) level: the fact that there is only ONE init script now: /etc/init.d/scx-cimd
So basically the SCX “Agent” will start and stop as a single thing, even if it is composed of multiple executables that will spawn various processes.
Another difference: if we look in “familiar” locations like /etc/opt/microsoft/scx/bin/tools/ we see that a number of configuration files is either empty (0 bytes) or missing (like the one described on Ander’s blog to enable verbose logging of WSMan requests), when compared to earlier versions:
But that is because I have been told we now have a nice new tool called scxadmin under /opt/microsoft/scx/bin/tools/ , which will let you configure those things:
Therefore you would enable VERBOSE logging for all components by issuing the command
./scxadmin -log-set all verbose
and you will bring it back to a less noisy setting of logging only errors with
./scxadmin -log-set all errors
the logs will be written under /var/opt/microsoft/scx/log just like they did before.
Other than this, a lot of the troubleshooting techniques I showed in one of my previous posts, like how to query CIM classes directly or thru WSMAN remotely by using winrm – they should really stay the same. I will mention them again here for reference.
SCXCIMCLI is a useful and simple tool used to query CIM directly. You can roughly compare it to wbemtest.exe in the WIndows world (other than not having a UI). This utility can also be found in /opt/microsoft/scx/bin/tools
A couple of examples of the most common/useful things you would do with scxcimcli:
1) Enumerate all Classes whose name contains “SCX_” in the root/scx namespace (the classes our Management packs use):
./scxcimcli nc -n root/scx -di |grep SCX_ | sort
2) Execute a Query
./scxcimcli xq “select * from SCX_OperatingSystem” -n root/scx
Also another thing that you might want to test when troubleshooting discoveries, is running the same queries through WS-Man (possibly from the same Management Server that will or should be managing that unix box). I already showed this in the past, it is the following command:
winrm enumerate http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem?__cimnamespace=root/scx -username:root -password:password -r:https://linuxbox.mydomain.com:1270/wsman -auth:basic –skipCACheck
but if you launch it that way it will now return an error like the following (or at least it did in my test lab):
Value = SOAP-ENV:Sender
Value = wsman:EncodingLimit
Text = UTF-16 is not supported; Please use UTF-8
FaultDetail = http://schemas.dmtf.org/wbem/wsman/1/wsman/faultDetail/CharacterSet
Error number: -2144108468 0x8033804C
the error message is pretty self explanatory: you need to specify the UTF-8 Character set. You can do it by adding the “-encoding” qualifier:
winrm enumerate http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem?__cimnamespace=root/scx -username:root -password:password -r:https://linuxbox.mydomain.com:1270/wsman -auth:basic –skipCACheck –encoding:UTF-8
Hope the above is useful to figure out the differences between the earlier beta releases of the System Center CrossPlatform extensions and the version built in OpsMgr 2007 R2 Release Candidate.
There are obviously a million of other things in R2 worth writing about (either related to the Unix monitoring or to everything else) and I am sure posts will start to appear on the many, more active, blogs out there (they have already started appearing, actually). I have not had time to dig further, but will likely do so AFTER Easter – as the next couple of weeks I will be travelling, working some of the time (but without my test environment and good connectivity) AND visiting relatives the rest of the time.
One last thing I noticed about the Unix/Cross Platform Management Packs in R2 Release Candidate… their current “release date” exposed by the MP Catalog Web Service is the 20th of March…
…which happens to be my Birthday – therefore they must be a present for me! 🙂
The information in this weblog is provided “AS IS” with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my own personal opinion. All code samples are provided “AS IS” without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.
THIS WORK IS NOT ENDORSED AND NOT EVEN CHECKED, AUTHORIZED, SCRUTINIZED NOR APPROVED BY MY EMPLOYER, AND IT ONLY REPRESENT SOMETHING WHICH I’VE DONE IN MY FREE TIME. NO GUARANTEE WHATSOEVER IS GIVEN ON THIS. THE AUTHOR SHALL NOT BE MADE RESPONSIBLE FOR ANY DAMAGE YOU MIGHT INCUR WHEN USING THIS INFORMATION. The solution presented here IS NOT SUPPORTED by Microsoft.
2 thoughts on “Cross Platform in OpsMgr 2007 R2 Release Candidate”
Hi thanks for posting this information as it has been quite helpful. I have installed the HP agents on a LINUX host that support WBEM.
The manual for it is http://h20000.www2.hp.com/bc/docs/support/SupportManual/c02471043/c02471043.pdf?jumpid=reg_R1002_USEN
Is located here.
I used your example above to attempt to pull data from the agents but I cant figure out the ResourceURI string.
name space I list root/hpq
How do I go about finding the resource URI for example the ones listed below.
I have no experience with it and I am not sure how the HP provides you are using would interact with our agent.
But before moving on to the windows side and trying thru WSMan from there, have you checked that the provider has indeed registered within our openpegasus installation? Have you tried from within “/opt/microsoft/scx/bin/tools/” to call something like “./scxcimcli nc -n root/hpq -di” ?
Comments are closed.