SCOM 1807, Linux omiagent service stopped, 403 error in discovery and more

I hope this post saves you some time and pain – I lost 2 days to troubleshooting and opening cases. Here is the setup:

OpsMgr 1807
Latest Linux/Unix MP (updated in August, 2018)
OEL 7.x client
Followed the instructions here: SCOM 1801/1807 Install

The agent install went fine – install completed, cert created, conf file created and configured, cert signed by the OpsMgr server and replaced on the client, and the agent restarted. That’s when I checked ‘scxadmin -status’. Omiserver was running, but omiagent was stopped. Only one log was created – omiserver.log, and nothing for the agent. Trying to start or restart via scxadmin yielded nothing. No feedback, no updates to logs, nothing. Even doing the install with –debug or settings the logs to verbose did nothing. So what happened?

Turns out, the omiagent process won’t start until a successful discovery is ran in the console. Who knew? Turns out that I didn’t. Two days lost trying to troubleshoot. I knew that a discovery was needed, but I assumed that the agent processes would be running ahead of time. Turns out they don’t all run before the discovery.

So, run over to the console and try to do the discovery only to immediately get a 403 error. Specifically, “The WinRM client received an HTTP status code of 403 from the remote WS-Management service.” Turns out this one is an easy fix, at least in my instance. My environment, like most in the corporate world, uses proxy servers. On the MS, a quick “netsh winhttp set proxy proxy-server=”http=” bypass-list=”*.yourdomain.com”” was all it took to fix the issue.

Once the discovery ran fine, it took about 5 minutes before the omiagent on the Linux machine was up and running on it’s own.

I hope this saves someone a few minutes of troubleshooting – if it does, shoot me a tweet!

Leave a Reply