OpsMgr and Cross Plat - Getting Started

Being my first post, it makes sense that I give a brief introduction.  My name is Michael Guthrie and I'm a recovering Spotlight user... actually user may be a bit of an undersell, I was the lead developer for Spotlight on Active Directory and Spotlight on Messaging - OCS Plug-in.  I left Quest to join a smaller company, Xandros who is working closely with Microsoft to bring a series of new products to market that leverage the new cross platform functionality available in Operations Manager R2.  Today I'm a Senior Program Manager with BridgeWays, a  division of Xandros, responsible for defining (and refining) the functionality that you can find in the management packs we write.

A common question I come across from OpsMgr administrators is "what do I need to know to start working with Unix/Linux machines?". For most, they've been working with Windows servers for years and know their way around OpsMgr but now that R2 is available they are being tasked with bringing the Unix/Linux servers into OpsMgr as well.  The purpose of this post is to pass on some tips that will help make that initial discovery of Unix/Linux systems go as smoothly as possible.

1. Resolving the Host name: You need to be able to resolve the hostname of the Unix/Linux server so that the certificate checks will pass.  There is a major gothcha when doing this, the names need to be exactly the same from your DNS (or Host file) lookup on the management server to the name reported when using the hostname command on the server to be monitored.  If they differ, for example you simply add a Linux server to your DNS server and the DNS entry is MyLinuxServer.corporate but the hostname command returns MyLinuxServer the certificate signing will fail because the common name will not match what the MS is looking for. To find the ipaddress for the Unix/Linux host use ifconfig -a
2. Update WinRM: Cross platform support requires that user accounts and passwords be passed from the MS to the monitored server.  In for this to work, you need to be able to use basic authentication with WinRM.  Have no fear, the data is transmitted securely, but the agents need to be able to access the username/password to create execution threads that will load the providers that collect the metrics.  To enable Basic Authentication you need to run the command winrm set winrm/config/client/auth @{Basic="true"} on the Management Server.
3. Super User password: To do the installation of the agent you can use a non-super user account, this is a common requirement because root is typically not given the rights to log in through SSH, but you will still have to provide a super user password.  During installation the scripts will execute an su - command for part of the install and they need an appropriate password.
4. Discover the server: You now have all the pieces you need to successfully discover a Unix/Linux server, so go ahead and do so.  You can use the IP address or the Host name to find the server, then install the agent and get the server into your Unix/Linux inventory.
5. Unix Action Account and Unix Privileged Account: Once discovery is done, you still have one more step to do.  It's not uncommon for people to discover a Unix/Linux server and patiently wait for the server to become "monitored" but it stays "unmonitored".  This is typically because they forgot to set up the Unix Action and/or Privileged Accounts.  To do this, you go to the authoring tab and double click the Unix Action Account, create a new RunAs account that will be used to gather the metrics, ensure it is created as a Basic Authentication account and then associate the account to the appropriate server.  Repeat this with a privileged account which is sometimes required by the MPs to access things like log files.

With that done, your Unix/Linux machine should now be monitored.

Comments

[Eric]

I was very excited to find this post. But I must be missing something. In step 5) during the creation of the Unix Action account you state "associate the account to the appropriate server"...
When I try to do this I cannot find my currently unmanaged unix box on the list of servers. It's not there to add.
What do you think I'm missing?
TIA!

[Eric]

I was able to get my Unix server managed and reporting as healthy but I had to use the 'less secure' option in Distribution tab of the 'run as' account.
I'm not sure what impact this will have and I'm very currious to find out why this worked and why I could not find my Unix server from the 'more secure' option.
So, I'm sort of working but I would love more details if anyone can help.

[Michael Guthrie]

Hi Eric, what is likely happening here is the way *nix agents are handled vs Windows Agents. For the *nix side of things you have to make sure the credentials are available to the Management Servers that are handling the *nix servers.

In the console, go to the Administration tab and the Unix/Linux Servers item. Check the Primary Management Server column to see which management server's need to be able to use the RunAs accounts.

Then goto the RunAs accounts that you need and add the approriate management servers to the distribution list.

I'm guessing you add the actual *nix servers as the distribution targets, this would be correct in the Windows world as each Agent is a real Health service but the *nix agents are only generic CIM servers so they can't work with the credentials directly.

Here's a link to another post I put together around the differences between the agents: http://blog.xplatxperts.com/xplat-xperts/2009/08/operations-manager-and-unixlinux-agents.html