This is a step-by-step article on installing the SCOM agent on a RHEL6 system, both from an SCOM and Linux administrator perspective. Everything in this demonstration assumes a new installation of RHEL6 with no additional configuration. It is also assumed there are no firewalls between the SCOM management servers and the RHEL system. Windows Firewall is not turned on, and the RHEL system is running with default IPTABLES configuration.

Disclaimer: I do not claim to be an experienced Linux admin. This is intended to familiarize SCOM administrators with the entire process. There may be better practices or methods for configuring Linux – comments are welcome.

If you do not have an SCOM environment or a RHEL system in your lab, you can download evaluation versions from the links below (these links may be outdated at the time you are reading this).

Configuring Linux

Before attempting to discover and install the SCOM agent, an account needs to be created on the Linux system and the sudoers file must be configured to allow the account to execute certain commands. Most out-of-box monitoring activities are performed using low privileges on the Linux system, but some activities do require elevation using sudo.

In this example, SCOM will leverage a single Linux account to perform all activities: opsmgrsvc.

Create the opsmgrsvc account

There are several free tools you can use to establish a SSH session to a Linux system. The most common is Putty, which can be downloaded at http://www.putty.org/.

Launch Putty and connect to the Linux host by entering the host name or IP address of the RHEL system and clicking Open.

Login with an account that has privileges to add user accounts and modify the sudoers file, or login with root. Create the opsmgrsvc account using the following command:

useradd opsmgrsvc

Next, set the password for the account using the following command:

passwd opsmgrsvc

You will be prompted to enter the password after issuing the command.

Configure sudoers file

Next you will configure the sudoers file, giving the opsmgrsvc account the ability to elevate and execute privileged commands without requiring a password (this is a SCOM requirement).

While still logged into the Linux SSH session as root, open the sudoers file editor by typing visudo and then:

1. Move down the file until you find the line Defaults requiretty, and enter Defaults:opsmgrsvc !requiretty just after it. This setting allows the service account to login without requiring a TTY session.

2. Move down the file until you find the line root ALL=(ALL) ALL, and enter opsmgrsvc ALL=(root) NOPASSWD: ALL just after it. This setting allows the service account to elevate without requiring a password.

3. Hit the ESC key to finish editing. To save and close the sudoers file, enter :wq. If you made a mistake in editing the file, you can close without saving your work by entering :q!.

NOTE!!! Your Linux administrator will likely want more granular control over which commands the SCOM service account can execute. Below are example sudoers file entries which would enable the opsmgrsvc account to only execute the command necessary for agent installation, maintenance tasks, and baseline monitoring.

The firewall is enabled in a default installation of RHEL6. It comes preconfigured to allow SSH connections, ICMP on local subnet, and very basic network service functionality (these protocol ports may need to be manually configured on other distributions). To see the firewall configuration, run the following command in your SSH session:

iptables --list

SCOM discovery and installation uses SSH to copy installation files to the target computer and execute shell scripts, such as GetOSVersion.sh, but before this can happen SCOM needs to connect to the SCX CIM provider on the remote host using WinRM. This occurs over port 1270, which is not open in the default iptables file.

To allow WinRM to do it’s job, add the iptables rule with the following command (this is one line):

Important: You will need to save your iptables configuration and configure the network interface to restore iptables rules at startup. Otherwise, those rules will disappear the next time the computer restarts. Check your distribution for saving/restoring iptables.

iptables command explained

-I INPUT 1 : insert new rule at the beginning of the ruleset.

-p tcp : protocol to match.

-s 192.168.2.0/24 : accept requests from specified host (or hosts). Note: this must be changed for your environment or can be removed from the command to accept from anywhere.

--dport : destination port to match on the host.

-m : match specific connection states.

--state NEW, ESTABLISHED : connection states to match.

-j ACCEPT : accept connection and stop processing the ruleset.

DNS Configuration

If you host is not resolvable in DNS – forward and reverse – then read this section. Otherwise, you may skip to the next section about creating a resource pool.

Forward lookup zones are required for SCOM in general, and reverse DNS lookup zones are minimally required for a management server to establish communication with UNIX/Linux agents. connections with the management group. Some DNS systems do not automatically create DNS records, so in this example we will walk thru creating these records and zones in Windows DNS Manager.

Create forward lookup record

To register the Linux host in DNS, open DNS Manager and create a new A record in the forward lookup zone of your domain. If you have a reverse DNS lookup zone configured in your domain, select Create associated point (PTR) record. This should automatically create the reverse DNS record, but you may want to verify this on your first attempt.

Verify your configuration with nslookup.

In this example, forward lookup is working with nslookup rhel6-01, but reverse lookup isn’t working with nslookup 192.168.2.70. This is because either there was no reverse lookup zone configured in the domain, or the Create associated pointer (PTR) record option was not selected. In this case, a reverse DNS lookup zone did not exist.

Create reverse lookup record

If you don’t have a reverse lookup zone in your DNS, you’ll need to create one in DNS Manager. Select the defaults in the wizard, entering your network Id – in this case, 192.168.2.x.

Now a PTR record can be created for the Linux host. One way to do this is to open the A record created in the previous step (in the forward lookup zone) and select Update associated pointer (PTR) record.

Testing reverse DNS lookup now returns the Linux host name, and now you’re ready to move onto the next step.

Create a Resource Pool

In a typical production environment, there will be a resource pool dedicated to monitoring cross-platform systems. This resource pool should contain at least two management servers for high-availability. This example adds management servers OM12-MS02 and OM12-MS03 to the new Cross-Platform Monitoring Resource Pool.

Navigate to Administration > Resource Pools in the Operations console to create a new resource pool.

Add the management servers.

Install Certificates on Resource Pool Members

Each management server in the cross-platform monitoring resource pool needs to have it’s certificate installed on each other management server. This is task is performed by running the scxcertconfig tool on each management server; first exporting the certificate from each management server, then importing each other management server’s certificate.

Login to each management server in your cross-platform resource pool, open a command prompt as administrator, navigate to %Program Files%\System Center\Operations Manager 2012\Server folder, and execute the following command:

scxcertconfig.exe -export <hostname.cert>

In this example, <hostname.cert>is replaced with OM12-MS02 on the first management server.

After exporting the certificate on each management server, import the certificate(s) from each other management server in the same manner. in this example, if I’m logged into OM12-MS02, I would execute the following command:

By default, there are several Unix/Linux management packs installed in SCOM.

However, this is not enough to perform agent installation using the Discovery Wizard. You will need to import the version specific management packs before even attempting to install a cross-platform agent, because they contain definitions specifically designed to detect which version of the the installation package to install on the target host.

In this example, we minimally need to install the Linux and Red Hat Libraries, and the RHEL6 bundle. These management packs can be found on your installation media, in the Management Packs folder. You can also download most recent versions from the online management pack catalog.

Navigate to Administration > Management Packs in the Operations console to install the required management packs: Microsoft.Linux.RHEL.6.mpb, Microsoft.Linux.Library.mp, and Microsoft.Linux.RedHat.Library.mp.

At this point, all the prerequisites are satisfied for installing the agent on a Red Hat Enterprise Linux 6 operating system by using the Discovery Wizard. Unless you don’t want to actually monitor the Linux system, you can skip to the Discovery Wizard section.

Configuring Runas Accounts and Profiles

One last thing we need to do in order for object discovery and monitoring workflows can run on our Linux system. This isn’t necessarily required to install cross-platform agents, but obviously there wouldn’t be much value in it if this task isn’t completed.

Navigate to Administration > Run As Configuration > UNIX/Linux Accounts in the Operations console and create a new account.

Create monitoring account

1. On the Account Type screen, select Monitoring account.

2. On the General Properties screen, enter a display name.

3. Enter your Linux monitoring account credentials on the Account Credentials screen – do not use elevation with this account. If you use elevation with this account, monitoring workflows implementing Linux commands that do not support sudo elevation will fail.

4. Select More secure on the Distribution Security screen. Then click Create and Close.

Create elevated monitoring account

Create another account that will be used for elevated monitoring tasks that require sudo.

Perform the same steps for the UNIX/Linux Privileged Account profile, using the privileged account you setup earlier.

Discovery Wizard

Navigate to Administration > Device Management in the Operations console to start the discovery wizard, and UNIX/Linux computers.

On the Discovery Criteria screen, Add the Linux host information and click Set credentials. Keep Discovery type set to All computers.

On the Credentials Settings screen, select User name and password and enter the account information that was created previously. Select This account does not have privileged access on the drop down list. Then click Ok.

The Credentials section on the Discovery Criteria screen should look like this.

The host should be discovered and you can continue by ticking the checkbox and clicking Manage. If you scroll to the right in this window, you can also see that operating system, version, and architecture information was discovered.

After clicking manage, the wizard goes through an installation, validation, and certificate signing process. Given that all goes well, a typical installation should take 30-60 seconds for a single host. Within minutes you should see the new Linux agent appear in the monitor space, with objects being discovered and monitored.

Hi. Really nice post! It’s exactly what I was looking for.
Additionally I’d like to ask you regarding the manual install. Where can I obtain the rpm file?
Browsing scom agent folder I just found a shell script.

I’ve followed the steps mentioned and created the (Server Name.cert) certificate kept it in D:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server path, Linux machine is discovered, once I click on Manage ending with error message” Task invocation failed with error code -2130771918. Error message was: Certificate signing module called with an empty certificate. Check that the certificate on the remote host is valid, and that the remote host can be accessed over SSH”.