While working for a client, the seemingly simple task of installing the SCOM Linux agent on a Red Hat 7 server, suddenly became a bit less easy. After successfully attempting to discover a server and try to manage it as well, the following error previously unknown to me was presented:
Failed to install kit. Exit code: 1
Standard Output: Sudo path: /usr/bin/
Extracting…
Installing cross-platform agent …
—– Installing package: omi (omi-1.6.8-0.ulinux.x64) —–
(Reading database … 0 files and directories currently installed.)
Preparing to unpack 100/omi-1.6.8-0.ulinux.x64.deb …
—– Installing package: scx (scx-1.6.8-0.universal.x64) —–
Selecting previously unselected package scx.
(Reading database … 0 files and directories currently installed.)
Preparing to unpack …/scx-1.6.8-0.universal.x64.deb …
—– Removing package: scx —–
(Reading database … 0 files and directories currently installed.)
Removing scx (1.6.8.0) …
—– Removing package: omi —–
(Reading database … 0 files and directories currently installed.)
Removing omi (1.6.8.0) …
—– Installing package: omi (omi-1.6.8-0.ulinux.x64) —–
Selecting previously unselected package omi.
(Reading database … 0 files and directories currently installed.)
Preparing to unpack 100/omi-1.6.8-0.ulinux.x64.deb …
Install failed
Wait.. What? .deb? Surely SCOM can’t decide to install an agent suitable for Debian systems on a Red Hat server, right?
Workaround solution
Our Linux lady quickly noticed SCOM selected the wrong package. Indeed, the installation of an RPM package would be more likely on a Red Hat server. However, for reasons still unknown to me, Debian’s package manager DPKG was also present on that same server. In the SCX agent’s installation script, SCOM determines which version to install based on the package manager present on that system, and DPKG is checked for first.
Time to open the script and see if we can trick SCOM into installing the RPM package anyway! That should save us for now (*1)
- Connect to a SCOM management server that is part of a/the Linux servers resource pool
- Browse to [your SCOM installation folder]\Server\AgentManagement\UnixAgents\DownloadedKits.
(e.g. C:\Program Files\Microsoft System Center\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits)
In the below example, we will open scx-1.6.8-0.rhel.7.x64.sh as we are attempting to start monitoring a Red Hat 7 system. However, chances are this might work for several other distros/versions as well.
- Make a backup of the .SH file that matches your Linux version!
- Edit the file, preferably with Notepad++ (*2).
- In that file you will find a function named ulinux_detect_installer(). In this specific version it is defined at line 225:
- Simply comment out anything in that function except for the INSTALLER=RPM part. By doing so, the function can only deliver one result; take the RPM package instead of the DPKG one!
The result should look like this;
- Save the changes you have made to apply it for this resource pool member.
- If you have other management servers that are part of a Linux monitoring resource pool, make sure to distribute the file to those servers as well. Otherwise you will often run into errors during the installation of a Linux agent, when the .sh file is taken from another resource pool member.
Alright! Let’s try again!
Success!
In short, sometimes you might run into Linux systems that come with multiple package installers present. Unfortunately, those are used by SCOM to define the type of agent that should be installed. Unfortunately sometimes the wrong choice is made because of it.
Notes
*1 – This is only a temporary workaround. The moment Microsoft releases a new SCX agent, the .SH file is replaced by a newer version and your modification is made undone. The preferred method is making sure you only have the package manager installed that comes with your Linux distro, but I have been told there are certain scenarios where more package managers equals more fun.
*2 – I have recommended Notepad++ as an editor as this worked without issues. Earlier we attempted to modify the file using VS Code. For certain reasons the file size increased from 19MB to a whopping 34MB after commenting out certain lines. There probably is a perfectly reasonable explanation and an even more reasonable resolution. Let me know if you have it!
Enjoy!
– Martijn