Today I had a kind of emergency operation to complete. The customer needed a pre-prod Solaris 10 environment monitored with SCOM 2007 R2. The purpose was to get an idea what he could do and to show other teams what it looks like. There was just one small hitch it had to be now (as always 
) and in an outdated pre-prod environment. So we didn’t have time to update to CU5 nor did I know in what condition the management servers were. To make thing’s even worse the network was separated in different networks separated by firewalls.
I just want to point out that the following steps were performed in a test environment – not in production!
So I started analyzing the environment. The management group contained 3 management servers in different networks. Luckily a management server (MS3) was in the same network segment where the Solaris box ran. So I could assume there is no firewall in between.
Next I found out that the management server MS3 has been updated to CU2. Current version of the cumulative update is CU5! You can figure it out by going to the directory \Program Files\System Center Operations Manager 2007\ using Windows explorer and display the file version. Notice here the *.*.****.15 at the end of each file it tells you that these binaries are version CU2.
I decided to try to import the necessary management packs for SCOM. The source I found here. Note here the KB reference CU3, anyway I wanted give it a shot.
After extracting the files I imported the following management packs.
Well, there was a error saying there is a dependency in the Microsoft.Unix.Library.mp to the WSManagement.Library.
I imported this WSManagement.Library.mp from another management group which was on CU5 qand imported it using the management pack wizard.
After that I could import all the necessary management packs above.
Now it was time to configure the RunAs profiles. I created two accounts in SCOM using “Basic Authentication” and with the option “More secure” targeting management server MS3. One account had user permission (low privilege) and the other had administrator permission (high privilege) on the Solaris system. Then I mapped these accounts to the corresponding profiles targeting all objects.
While I configured SCOM the Solaris administrator installed the scx-1.0.4-277.solaris.10.sparc.pkg agent manually on the system. Before we tried to manually install the scx-1.0.4-248.solaris.10.sparc.pkg but it didn’t work for Solaris 10 Zone.
Because I wanted to be sure not to run into a certificate problem I exported the /etc/opt/microsoft/scx/ssl/scx-host-.pem to my management server and run the command:
scxcertconfig -sign c:\temp\scx-host-.pem c:\temp\scx-host-_new.pem
Then I renamed the scx-host-<hostname>_new.pem to scx-host-.pem and copied into /etc/opt/microsoft/scx/ssl/ and restarted the agent by typing:
scxadmin –restart
Let’s run the Discovery Wizard…or…well…not. I tried few times to discover the Solaris system but finally I (almost) succeeded using these settings. Notice here I added the root password!
After running the wizard I received errors because SCOM wanted to install the agent version scx-1.0.4-248.solaris.10.sparc.pkg. Ok, I decided to uninstall the currently running agent on Solaris and to copy the latest agent available scx-1.0.4-277.solaris.10.sparc.pkg into the %programfiles%\System Center Operations Manager 2007\AgentManagement\UnixAgents directory.
To check which agent SCOM will deploy I enabled the EnableOpsmgrModuleLogging by executing this command on the management server. (More details here)
copy/Y NUL %windir%\temp\EnableOpsMgrModuleLogging
This generates several logs in %windir%\temp\
the one we are interested in is DeployFile.vbs.log. If you run the Discovery Wizard and open the log file you will immediately see which agent will be deployed. In my case it was the current scx-1.0.4-277.solaris.10.sparc.pkg.
The wizard almost finished but still failed with error “The WinRM client received an HTTP status code of 501 from the remote WS-Management service” . After some research I found this usefull post about KB2585542 http://operatingquadrant.com/2012/01/12/opsmgr-unixlinux-heartbeat-failures-after-applying-kb2585542/
I followed the steps described and managed to deploy successfully the SCOM Solaris 10 agent to the Sun Solaris 10 Zone System.
These are just some notes from the field. Don’t do it this way in production! Always update the entire management group with the latest CU and hotfixes.
