Dell OpenManage Server Administrator (OMSA) is Dell’s on-host hardware management and monitoring framework for PowerEdge servers.
It runs inside the operating system and provides direct visibility into system hardware such as RAID controllers, physical and virtual disks, power supplies, fans, temperatures, memory, processors, and chassis health.
OMSA communicates with the server’s iDRAC and hardware controllers to retrieve real-time status and exposes this information through command-line tools like omreport, optional web interfaces, and SNMP for monitoring systems.
It is primarily used for hardware diagnostics, RAID and storage monitoring, fault detection, and health reporting, allowing administrators to verify system integrity and troubleshoot hardware issues without leaving the operating system.
So now that we have an idea of what it is, lets install it.
Note: Our system under test is a Dell R720. I probably should have lead with that.
Installation
First you will need to download the bootstrap script as shown below.
curl -O https://linux.dell.com/repo/hardware/dsu/bootstrap.cgi
Now we will make it executable.
chmod +x bootstrap.cgi
And then we run it.
sudo ./bootstrap.cgi
Now we have completed the following.
- Added Dell’s official repo
- Installed Dell signing keys
- Configured OMSA package sources
Now Install OpenManage (omreport)
sudo dnf install srvadmin*
This installs:
- omreport
- omconfig
- Storage monitoring
- RAID tools
- CIM providers
Starting and Enabling Services
Apparently, service names can vary from OS to OS, so run the command below to verify the correct service names
systemctl list-unit-files | grep -Ei 'dsm|omsa|srvadmin'dsm_om_connsvc.service enabled disableddsm_om_shrsvc.service disabled disableddsm_sa_datamgrd.service enabled disableddsm_sa_eventmgrd.service enabled disableddsm_sa_snmpd.service enabled disabled
Now that we have the names of the services we can start and enable them as shown below
# sudo systemctl enable --now dsm_om_connsvc dsm_sa_datamgrd dsm_sa_eventmgrd dsm_sa_snmpd dsm_om_shrsvc
| OpenManage Server Administrator (OMSA) Services | ||||
| Service Name | Full Name | Purpose | Required? | Notes |
| dsm_om_connsvc | OMSA Connection Service | Provides the web-based interface (HTTPS/1311) used to access OMSA remotely or locally | ✅ Yes (if using OMSA web UI) | This is what allows access via https://<host>:1311 |
| dsm_om_shrsvc | OMSA Shared Services | Provides shared libraries and backend support for other OMSA components | ⚠️ Usually | Required by other OMSA components; often left disabled unless needed |
| dsm_sa_datamgrd | Systems Management Data Manager | Collects and maintains hardware inventory and system data | ✅ Yes | Required for hardware monitoring (disks, temps, fans, etc.) |
| dsm_sa_eventmgrd | Systems Management Event Manager | Handles hardware events, alerts, and logs | ✅ Yes | Required for alerts and log reporting |
| dsm_sa_snmpd | OMSA SNMP Agent | Provides SNMP interface for monitoring tools (LibreNMS, Zabbix, etc.) | ⚠️ Optional | Needed only if using SNMP monitoring |
Service Review
Now let’s review each service in detail, and see how we can leverage each one.
dsm_om_connsvc
First we need to ensure our Firewall allows this traffic. So run the commands below (RHEL), ubuntu may use ufw.
# firewall-cmd --permanent --add-port=1311/tcp# firewall-cmd --reload
Now in your web browser, navigate to https://viper.lab:1311/ (Note https, and change host name accordingly).
Similar in appearance to the Idrac – you can find system information here, some of which does not appear in the Idrac itself. Everything is read-only.
dsm_om_shrsvc
(OMSA Shared Services) is a supporting service, not a management interface or monitoring agent.
It provides:
- Shared libraries
- Inter-process communication
- Authentication helpers
- Common backend utilities
These are required by other OMSA components to function correctly. So nothing really to see here.
dsm_sa_datamgrd.service
This is the service that collects all the data that is displayed in the WebUI (port 1311)
dsm_sa_eventmgrd.service
dsm_sa_snmpd.service is the OMSA component responsible for exposing Dell hardware monitoring data to external systems using the SNMP protocol.
This service does not collect or analyze hardware information itself; instead, it serves as the communication layer that allows remote systems to query or receive notifications about server health. When enabled, it allows OMSA to participate in centralized monitoring environments and enterprise alerting workflows, making it essential in environments where hardware status must be visible outside the server itself.
This service relies entirely on the existing system SNMP configuration, so no need to modify anything if you already have snmp configured and running with your specfic community string.
dsm_sa_snmpd.service
dsm_sa_snmpd.service is the OMSA component responsible for exposing Dell hardware monitoring data to external systems using the SNMP protocol.
It acts as the interface between the data collected internally by OMSA and third-party monitoring platforms such as LibreNMS, Zabbix, or Nagios.
This service does not collect or analyze hardware information itself; instead, it serves as the communication layer that allows remote systems to query or receive notifications about server health. When enabled, it allows OMSA to participate in centralized monitoring environments and enterprise alerting workflows, making it essential in environments where hardware status must be visible outside the server itself.
dsm_sa_snmpd.service acts as the Dell OMSA integration layer between the server’s hardware telemetry and the system’s SNMP stack, allowing Dell-specific health, storage, and sensor data to be exposed through standard SNMP queries.
It does not replace or conflict with existing monitoring agents such as Zabbix or LibreNMS (which I am using) Instead, it complements them by extending the SNMP data they can read
dsm_sa_snmpd provides access to Dell-specific MIBs that Zabbix Agent and LibreNMS Agent (or any other agent you may use) can query via the system’s SNMP daemon.
Basically, dsm_sa_snmpd is the bridge that exposes OMSA’s hardware awareness to your existing monitoring stack.
Note that if you are using Zabbix you will need to install additional templates. For example, this one, note that I have not tried it yet.
Ompreport
Omreport is the command-line interface (CLI) frontend for OMSA. It queries the OMSA backend services and formats the results for humans or scripts
Note we have to use the absolute path to run this as the working dir is not in our $PATH.
/opt/dell/srvadmin/sbin/omreport system summary
If you want to add to your $PATH, run the command below
echo 'export PATH=$PATH:/opt/dell/srvadmin/sbin' | sudo tee /etc/profile.d/dell-omsa.shsource /etc/profile
Example usage below.
omreport system summaryomreport chassis tempsomreport chassis fansomreport chassis power
Here is an example I found useful. For some reason my raid controller keeps throwing these errors which do not seem to go away despite the fact that both SAS cables are connected (tried switching them) and all disks are healthy.
# omreport system esmlogSeverity : CriticalDate and Time : Sat Jan 31 21:15:18 2026Description : The storage BP1 SAS B cable is not connected, or is improperly connected.Severity : OkDate and Time : Sat Jan 31 21:15:20 2026Description : The chassis is closed while the power is off.Severity : CriticalDate and Time : Sat Jan 31 21:15:21 2026Description : The storage BP1 SAS A cable is not connected, or is improperly connected.
Enter omconfig.
omconfig
omconfig is the configuration and control interface for Dell OpenManage Server Administrator (OMSA).
Unlike omreport, which is strictly read-only, omconfig is used to change system and OMSA behavior—including alerting, storage actions, and certain hardware-related settings exposed by OMSA.
Omconfig It operates by issuing commands to the OMSA backend services (primarily dsm_sa_datamgrd and dsm_sa_eventmgrd) and applying those changes at the software management layer, not directly to hardware firmware.
Common uses include enabling or disabling alert actions, configuring storage-related behavior, managing notification settings, and triggering maintenance operations such as consistency checks.
Because omconfig can modify system behavior and suppress alerts, it should be used carefully—especially on production systems—and is best suited for controlled configuration changes rather than routine monitoring.
Because omconfig can modify system behavior and suppress alerts, it should be used carefully—especially on production systems—and is best suited for controlled configuration changes rather than routine monitoring.
So back to my two SAS cable alerts. Lets leverage omreport and omconfig to diagnose and hopefully ether determine that there is an actual issue, or suppress the alerts.
OMCONFIG and OMREPORT – Real world Usage
First lets take a sneaky-peak at my raid controller.
omreport storage controller Controller PERC H730 Adapter(Slot 4)ControllerID : 0Status : OkName : PERC H730 AdapterSlot ID : PCIe Slot 4State : ReadyFirmware Version : 25.5.9.0001-----truncated---
According to chatgpt I am getting these errors because the system expects that I have an external enclosure connected. I do not think that is the case, as that seems dumb. More than likely this alert is due to the fact that I am using an H730 (a 13G controller) (and its cables) in an R720 (a 12G server) in Slot 4, which is a PCIe Adapter and not the integrated “mini” version.
So let’s look at the disks and make sure all is well
Here we can see that the PERC H730 adapter does not “See” the connector states as connected, rather just ready
omreport storage connector controller=0List of Connector(s) on Controller PERC H730 Adapter (Slot 4)ID : 0Status : OkName : Connector 0State : ReadyConnector Type : SAS Port RAID ModeTermination : Not ApplicableSCSI Rate : Not ApplicableID : 1Status : OkName : Connector 1State : ReadyConnector Type : SAS Port RAID ModeTermination : Not ApplicableSCSI Rate : Not Applicable
In order to use this 13th gen raid controller in a 12th gen Dell Server I could not use the original SAS cables. Rather I used SFF-8087 to SFF-8643 cables Which can cause the sideband signals (SGPIO / SES) which tell the iDRAC everything is okay which is why we are seeing the errors.
As stated above this is not actually a problem as I can see my disks. Lets do that below.
omreport storage pdisk controller=0 | awk '/^ID[[:space:]]*:/ {id=$3; state=""; status=""}/^State[[:space:]]*:/ {state=$3}/^Status[[:space:]]*:/ {status=$3}(state!="" && status!="" && id!="") {print id, state, status; id=""; state=""; status=""}'0:0 Online Non-Critical0:1 Online Non-Critical0:2 Online Non-Critical0:3 Online Non-Critical0:4 Online Non-Critical0:5 Online Non-Critical0:6 Online Non-Critical0:7 Online Non-Critical
Here we can see we have 8 disks, no critical errors
First lets clear the esmlog with omconfig – this will clear the error till we reboot
omconfig system esmlog action=clear
Sadly there is not a permanent fix. I would need to get a different raid controller that uses the original cables.
