Monitor Dell iDRAC with VCF Operations and Redfish
Built and tested around iDRAC9 firmware 7.20.30.00 on a PowerEdge R650, using Redfish directly without OpenManage Enterprise.
65 objects · 125 metrics · Runtime validated
Before importing the Dell design
- Use the documented design with built-in Management Pack Builder and compare your iDRAC resource paths with the tested R650/iDRAC9 firmware.
- Prepare collector-to-iDRAC HTTPS access, working collector DNS and a trusted certificate whose SAN matches the configured name. Keep certificate verification enabled.
- Use dedicated credentials with access to the required Redfish GET requests. The minimum iDRAC role was not independently established.
- Configure Builder test credentials and the installed integration account separately. The installed account is collecting on schedule; validate at least two current cycles in your own environment.
PowerEdge hardware visibility in VCF Operations
This custom Dell iDRAC management pack design connects VCF Operations directly to the Redfish API over HTTPS, without OpenManage Enterprise. I cover the expanded hardware data, TLS troubleshooting, powered-off null behavior, powered-on sensor validation, and deployed operational content.
The current design covers server health and inventory, power, supplies, temperatures, 16 fans, processors, populated memory modules, storage resources, and firmware inventory. Builder verification, installation, upgrade, and scheduled runtime collection succeeded.
The environment
I tested a PowerEdge R650 with iDRAC9 Datacenter, firmware 7.20.30.00, and VCF Operations 9.1.0.0400.25541561. The design was created with the built-in Management Pack Builder. The initial powered-off test validated missing-sensor semantics. Later powered-on validation supplied live fan, processor, memory, storage, firmware, power, and temperature data.
This is a custom community preview. These results are not a compatibility matrix or a claim of Dell or Broadcom certification.
How the management pack connects
VCF Operations collector → HTTPS → iDRAC Redfish API
There is no OpenManage Enterprise, OMEVV, exporter, or bridge in this design. The source uses Basic authentication with the iDRAC username and password. Unlike the QNAP pack, it does not require a manually Base64-encoded and URL-encoded password. Enter the ordinary password into the protected credential field and let the client construct the header.
All configured requests are GET requests. The pack does not invoke server power actions, change configuration, or update firmware. That describes the pack’s behavior, not the privileges of the account used to connect. Use a dedicated account with the minimum access needed for these reads; I have not separately established the minimum iDRAC role.
The Redfish requests
| Purpose | Method and path |
|---|---|
| Test the source | GET /redfish/v1/ |
| Server inventory and health | GET /redfish/v1/Systems/System.Embedded.1 |
| System power and power supplies | GET /redfish/v1/Chassis/System.Embedded.1/Power |
| Temperature sensors | GET /redfish/v1/Chassis/System.Embedded.1/Thermal |
The base path is redfish/v1; Builder supplies the slash between the host and path. The resource paths use the tested System.Embedded.1 layout. Check them against your own iDRAC before assuming they apply unchanged.
Dell’s responses mark Power and Thermal as deprecated in favor of newer subsystem resources. These endpoints worked on the tested firmware, but a future version should validate those newer resources rather than assuming the old ones will always remain available.
The TLS issue that caught me out
The first connection reached iDRAC, but its self-signed certificate needed to be trusted. Accepting it was only the first step: the certificate named the iDRAC hostname, while the source was configured with an IP address.
Trusting a certificate does not make a hostname mismatch disappear. I tried the hostname in the certificate next. It resolved from the workstation, but the Operations collector could not resolve it.
That distinction is easy to miss when the browser already opens the iDRAC dashboard. The collector performs the API requests, so its DNS and network access are what matter.
For this lab test, I explicitly allowed No Verify for the source. HTTPS remained enabled, but certificate identity verification was disabled. For a deployment you intend to rely on, fix DNS and use a trusted certificate with a matching SAN. The exported design defaults to Verify and leaves the hostname blank.
What the preview collects
The design started with four core object types and now also includes Dell Fan, Dell Processor, Dell Memory Module, Dell Storage Resource, and Dell Firmware Component objects:
- Dell PowerEdge Server: hostname, model, service tag, UUID, BIOS, processor and memory inventory, power state, and health rollups.
- Dell System Power: consumed, allocated, and capacity watts, plus average, minimum, and maximum consumption.
- Dell Power Supply: identity, serial number, model, firmware, state, redundancy status, efficiency, and input/output power.
- Dell Temperature Sensor: identity, context, Celsius readings, health/state, and available warning and critical thresholds.
The full Builder test returned:
| Result | Count |
|---|---|
| Objects | 65 |
| Metrics | 125 |
| Properties | 463 |
| Relationships | 64 |
| Events | 0 |
The latest firmware-expanded preview completed with 65 objects, 125 metrics, 463 properties, and 64 relationships. The Dell-scoped dashboard displayed 66 adapter objects including the adapter instance.
Builder adds an adapter instance identifier to object identities, so the same sensor number on different configured iDRACs remains distinct. Server identity uses UUID; power supplies also use member ID and serial number.
A powered-off server still tells a useful story
The reference system reported 26 W of standby power and an inlet temperature of 20 C. It returned four temperature sensor objects, but CPU and exhaust temperature readings were null.
The numeric mappings correctly omitted unavailable readings rather than converting them to zero. A missing reading and a real zero mean different things. Health values remain string properties; Unknown or null is not treated as healthy.
The powered-on validation discovered 16 fans and collected RPM, health, location, and unit values while preserving the earlier powered-off null behavior.
Builder credentials and runtime credentials are separate
The same setup lesson from the QNAP project applies here: the credentials used to test a source in Builder are separate from the credentials on the installed integration account.
The installed Dell iDRAC Redfish account was validated and populated VCF Operations through scheduled collection. Other environments should still validate the account and confirm at least two current collection cycles.
I verified Builder collection, installation, upgrade, scheduled runtime collection, a Dell-scoped dashboard, and the healthy-state behavior of a two-cycle server-health alert.
What is not included yet
- Individual drives, virtual disks, controller cache/battery health, and hardware event ingestion are not included.
- Health rollups provide summaries, not detailed component diagnostics.
- A Dell-scoped dashboard and two-cycle server-health alert are deployed in the tested VCF Operations instance. They are documented in the repository but are not embedded in the Builder JSON export.
- Power and temperature units are stated in metric labels; the available Builder unit list did not include watts or Celsius. Efficiency uses percent and installed memory uses GiBy.
- Other PowerEdge models, iDRAC generations, and firmware releases need their own validation.
- No standalone
.pakis supplied. The reusable artifact is an importable Builder design JSON.
Deployment at a glance
- Download the Dell design JSON from the repository. Extract it first if using the design ZIP.
- Prepare a dedicated iDRAC account and verify collector-to-iDRAC HTTPS access, DNS, and certificate naming.
- Import the JSON under Build > Developer Center > Management Pack Builder. Preserve any existing design.
- Configure the test source with your iDRAC hostname, HTTPS port, collector, username, and ordinary password.
- Test the source and collection requests, then run a full collection and compare values against iDRAC.
- Install the validated management pack through Builder.
- Add a separate integration account and validate its credentials and connection.
- Confirm at least two scheduled collection cycles and fresh timestamps before relying on the data.
The ZIP is a distribution archive, not an installable management-pack package. Do not rename it to .pak or upload it to a conventional .pak installer.
Final thoughts
This version brings expanded PowerEdge hardware data into VCF Operations without another management appliance. It was built around a PowerEdge R650 with iDRAC9 7.20.30.00. Other generations are best-effort targets; the repository iDRAC10 framework is synthetic and untested on physical iDRAC10 hardware.
The troubleshooting lesson was straightforward: browser access does not prove collector access, trusting a certificate does not fix its name, and unavailable sensor data should stay unavailable.
Explore the project
Get the design and deployment guide from the Dell project on GitHub. Read the limitations and security guidance before deploying. The QNAP walkthrough covers the storage integration that preceded this work.
Untested iDRAC10 framework: the GitHub repository also contains an experimental framework for building an iDRAC10 management pack. It is based on modern Redfish schemas and synthetic test data, but has not been tested against an actual iDRAC10. It is separate from the iDRAC9 firmware 7.20.30.00 pack described in this post and should not be treated as verified iDRAC10 support.
Try the Dell iDRAC Redfish design
Review the deployment guide, validation scope, and security guidance before importing.