Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.
I ran into an interesting issue when attempting to deploy the SCOM agent to a Solaris server. During the discovery, the server returned as being unable to be discovered with the following results:
I did some research on this particular error without much help. It’s typically related to an issue where sudo on the Unix machine has been moved to a different directory. By default, SCOM looks at /opt/sfw/bin/sudo for the directory. In that particular scenario, a symbolic link only needs to be created. However, that didn’t fix our problem.
For our next step, we turned on OpsModuleLogging. The logs showed successful deployment of getOSVersion.sh, but there were no entries after that. We did an SSH connection to the Solaris server and sure enough, it was there. when executing sudo getOSVersion.sh server manually, we got a ‘command not found’ error message.
Not knowing much about Linux/Unix, I enlisted the help of some folks internally. As it turns out, their login shell was set to a C-script shell (bin/csh) whereas SCOM only supports the default shell. Correcting that yields this result:
After that, deployment was successful.