How to Enable and Use the Redfish API on Dell iDRAC 9 (with curl and PowerShell)

If you’re comfortable in the iDRAC web console and can drive RACADM without looking up flags, Redfish is the obvious next step. It swaps manual clicks and Dell-only commands for plain HTTPS calls that return JSON. Write a health-check script for a rack of PowerEdge servers today. Porting it to HPE or Lenovo hardware later just means changing endpoint paths, not starting over.

This guide covers enabling Redfish on iDRAC 9, getting authentication right (it trips up more people than it should), and running real health-check, power-control, and BIOS-configuration calls from curl and PowerShell.

What Is Redfish?

Redfish is a REST API standard maintained by the DMTF (Distributed Management Task Force) for managing servers out-of-band. It’s the same job iDRAC’s web UI and RACADM already handle, but over standard HTTPS instead of a proprietary protocol. Every request is a normal HTTP verb (GET, POST, PATCH, DELETE) against a URL. Every response comes back as JSON.

The practical win over RACADM is that Redfish isn’t locked to one vendor. RACADM only talks to iDRAC. Redfish’s resource model, Systems, Chassis, Managers, looks the same whether you’re hitting a Dell iDRAC 9, an HPE iLO 5, or a Lenovo XCC. Write a health-polling script once. Adapting it for a mixed-vendor fleet later just means tweaking paths, not rewriting logic.

Redfish support ships in every iDRAC 9 license tier: Basic, Express, Enterprise, Datacenter. No upsell required. The catch: it’s off by default on some firmware builds. Its authentication defaults have also shifted across firmware versions. That second part is where most people lose an afternoon. We’ll cover both.

Before You Begin

Make sure you have:

• A Dell PowerEdge server with iDRAC 9 (14th generation or later)
• iDRAC 9 firmware 7.00.30.00 or later (check via iDRAC Settings > Overview). Earlier firmware supports Redfish too, but the schema and default auth behavior differ
• An iDRAC account with at least Operator privileges (Admin recommended for BIOS/power actions)
• Network access to the iDRAC’s HTTPS management interface (port 443)
• Familiarity with the iDRAC web UI and basic RACADM usage (this guide assumes it)
• curl (bundled with Windows 10/11 and macOS) or PowerShell 7.x for scripting

Requirement	Details
Device	Dell PowerEdge server with iDRAC 9
iDRAC firmware	7.00.30.00+ (tested on 7.10.30.00)
Client OS	Windows 11 24H2 or macOS Sequoia 15
Tools	curl 8.x, PowerShell 7.4
Access level	iDRAC Operator or Admin account

Tested against a PowerEdge R750 running iDRAC 9 firmware 7.10.30.00, curl 8.7 on both Windows 11 and macOS Sequoia, and PowerShell 7.4.

Step-by-Step Guide

Step 1: Confirm Redfish Is Available on Your Firmware

Log into the iDRAC web console and check iDRAC Settings > Overview for the current firmware version. Redfish has been available since early iDRAC 9 firmware. But the schema version and default auth behavior shifted around the 6.xx-to-7.xx transition. If you’re chasing a “missing” field or endpoint later, check it against Dell’s Redfish API documentation first. It’s versioned per firmware family.

Step 2: Enable Redfish in the iDRAC Web Console

Redfish is on by default on most current iDRAC 9 firmware, but confirm it anyway. A disabled service returns a generic HTTP 404 on every request. Debugging that with no other clue is a miserable way to spend twenty minutes.

• Log into the iDRAC web console at https://YOUR-IDRAC-IP/.
• Navigate to iDRAC Settings > Services. On older-generation firmware this may be under Overview > iDRAC Settings > Network > Services.
• Scroll to the Redfish section.
• Confirm the Enabled checkbox is checked. If not, check it.
• Click Apply.

No web server restart is required. The change takes effect immediately.

Step 3: Verify Connectivity to the Service Root

The Redfish service root at /redfish/v1/ is readable without authentication on iDRAC 9. It just lists top-level resource collections, nothing sensitive. Open it directly in a browser to confirm the service is responding:

https://YOUR-IDRAC-IP/redfish/v1/

You should see raw JSON similar to this:

{
  "@odata.id": "/redfish/v1/",
  "@odata.type": "#ServiceRoot.v1_9_0.ServiceRoot",
  "Id": "RootService",
  "Name": "Root Service",
  "RedfishVersion": "1.14.1",
  "Systems": { "@odata.id": "/redfish/v1/Systems" },
  "Chassis": { "@odata.id": "/redfish/v1/Chassis" },
  "Managers": { "@odata.id": "/redfish/v1/Managers" },
  "SessionService": { "@odata.id": "/redfish/v1/SessionService" },
  "UpdateService": { "@odata.id": "/redfish/v1/UpdateService" }
}

Your browser will warn about the certificate. iDRAC ships with a self-signed cert by default. That’s expected. Ignore it for now. We’ll fix it properly in the Configuration section.

Three resource trees matter most for day-to-day work:

• Systems covers server-level data: power state, overall health, CPU/memory summary, BIOS settings
• Chassis covers physical hardware: thermal sensors, fans, power supplies
• Managers covers the iDRAC controller itself: firmware version, network config, session management

Step 4: Windows Setup with curl and PowerShell

Windows 10 and later ship with curl.exe built in, so there’s nothing to install for basic testing.

Open Windows Terminal or PowerShell and confirm curl is present:

curl --version

Expected output (version numbers will vary):

curl 8.7.1 (Windows) libcurl/8.7.1 Schannel
Release-Date: 2024-03-27

Now make a test call against the Systems endpoint. iDRAC uses a self-signed cert, so add -k to skip verification for lab and testing. See the Configuration section below for installing a trusted cert in production:

curl -k https://192.168.1.120/redfish/v1/Systems

You’ll get back a collection listing one member: System.Embedded.1. That’s the URI you’ll query for actual system data in later steps.

For anything beyond one-off calls, PowerShell’s Invoke-RestMethod is the better tool. It parses JSON automatically instead of leaving you to eyeball raw text. PowerShell 7.x also adds a native -SkipCertificateCheck switch. It avoids the older ServicePointManager workarounds Windows PowerShell 5.1 required.

$cred = Get-Credential -Message "Enter iDRAC credentials (e.g. root)"

Invoke-RestMethod -Uri "https://192.168.1.120/redfish/v1/Systems/System.Embedded.1" `
    -Credential $cred `
    -Authentication Basic `
    -SkipCertificateCheck

Get-Credential pops a secure prompt instead of putting a password on the command line or in shell history. Worth doing even for a quick test.

Step 5: macOS Setup with curl and Optional PowerShell

macOS ships with curl preinstalled, so the same commands from Step 4 work unchanged in Terminal:

curl --version

Expected output:

curl 8.7.1 (x86_64-apple-darwin23.0) libcurl/8.7.1 (SecureTransport)
Release-Date: 2024-03-27

Test connectivity the same way:

curl -k https://192.168.1.120/redfish/v1/Systems

If you want to reuse PowerShell scripts across Windows and macOS clients, that’s handy on a mixed team. Install PowerShell 7 via Homebrew:

brew install --cask powershell

Launch it with pwsh and every Invoke-RestMethod example works identically.

Step 6: Choose Basic Auth vs Session Auth

Redfish on iDRAC 9 supports two authentication modes. Picking the right one matters more than it sounds like it should.

Basic authentication sends credentials with every request. It’s fast for a one-off test call, but inefficient for scripts making dozens of calls. More importantly: recent iDRAC 9 firmware in the 7.xx family changed the default for advertising HTTP Basic Auth from Enabled to Unadvertised. If your existing scripts suddenly started throwing 401 Unauthorized after a firmware update, this is almost certainly why.

Session authentication is the right approach for anything beyond a quick test. Authenticate once, and iDRAC hands back a session token in the X-Auth-Token response header. Reuse that token for every following call. It’s also what Dell’s own Redfish scripting examples on GitHub use throughout.

To open a session, POST your credentials as a JSON body to SessionService/Sessions:

curl -k -i -X POST https://192.168.1.120/redfish/v1/SessionService/Sessions \
  -H "Content-Type: application/json" \
  -d '{"UserName": "root", "Password": "YOUR_PASSWORD"}'

-i includes response headers in the output, which is what you need. The token comes back as a header, not in the JSON body:

HTTP/1.1 201 Created
X-Auth-Token: a1b2c3d4e5f60718293a4b5c6d7e8f90
Location: /redfish/v1/SessionService/Sessions/22
Content-Type: application/json

Use that token on every following request instead of a username and password:

curl -k https://192.168.1.120/redfish/v1/Systems/System.Embedded.1 \
  -H "X-Auth-Token: a1b2c3d4e5f60718293a4b5c6d7e8f90"

When your script is done, delete the session so you don’t leak session slots (iDRAC 9 has a limit, typically 6 concurrent sessions):

curl -k -X DELETE https://192.168.1.120/redfish/v1/SessionService/Sessions/22 \
  -H "X-Auth-Token: a1b2c3d4e5f60718293a4b5c6d7e8f90"

Step 7: Get System Health and Power State

This is the call that replaces “log into the web UI and stare at the dashboard.” Query the Systems resource for the embedded system:

curl -k https://192.168.1.120/redfish/v1/Systems/System.Embedded.1 \
  -H "X-Auth-Token: a1b2c3d4e5f60718293a4b5c6d7e8f90"

Relevant fields in the response:

{
  "PowerState": "On",
  "Status": {
    "Health": "OK",
    "State": "Enabled"
  },
  "Model": "PowerEdge R750",
  "BiosVersion": "2.19.1",
  "MemorySummary": {
    "TotalSystemMemoryGiB": 256,
    "Status": { "Health": "OK" }
  },
  "ProcessorSummary": {
    "Count": 2,
    "Status": { "Health": "OK" }
  }
}

Status.Health is the one field worth alerting on in monitoring scripts. Anything other than OK (Warning or Critical) means something needs attention.

Step 8: Pull Sensor and Thermal Data

For fan speeds, inlet/exhaust temperatures, and power supply status, query the Chassis resource instead of Systems:

curl -k https://192.168.1.120/redfish/v1/Chassis/System.Embedded.1/Thermal \
  -H "X-Auth-Token: a1b2c3d4e5f60718293a4b5c6d7e8f90"

The response includes arrays for Temperatures and Fans:

{
  "Temperatures": [
    { "Name": "Inlet Temp", "ReadingCelsius": 21, "Status": { "Health": "OK" } }
  ],
  "Fans": [
    { "Name": "Fan1", "Reading": 6720, "ReadingUnits": "RPM", "Status": { "Health": "OK" } }
  ]
}

This is the same data the iDRAC web UI’s System > Thermal page shows. The difference is you can now script it across every server in a rack in one pass, instead of clicking through pages one at a time.

Step 9: Trigger a Power Action

Power actions live under Actions on the Systems resource. To gracefully restart a server:

curl -k -X POST https://192.168.1.120/redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset \
  -H "X-Auth-Token: a1b2c3d4e5f60718293a4b5c6d7e8f90" \
  -H "Content-Type: application/json" \
  -d '{"ResetType": "GracefulRestart"}'

Common ResetType values:

ResetType	Effect
On	Powers the server on
GracefulShutdown	OS-initiated shutdown, then power off
ForceOff	Immediate hard power off; no OS shutdown
GracefulRestart	OS-initiated shutdown, then power on
ForceRestart	Immediate reset, no OS involvement
PowerCycle	Full power off, then on, which resets hardware state

Warning: ForceOff and ForceRestart do not wait for a clean OS shutdown. Use GracefulShutdown or GracefulRestart for production systems unless the OS is already unresponsive.

A successful call returns HTTP/1.1 204 No Content. No response body, just the status code confirming the action was accepted.

Step 10: Read and Set BIOS Attributes

BIOS settings live under Systems/System.Embedded.1/Bios. To read current values:

curl -k https://192.168.1.120/redfish/v1/Systems/System.Embedded.1/Bios \
  -H "X-Auth-Token: a1b2c3d4e5f60718293a4b5c6d7e8f90"

To change a setting, PATCH the Bios/Settings resource, not Bios directly. For example, here’s how to disable processor virtualization:

curl -k -X PATCH https://192.168.1.120/redfish/v1/Systems/System.Embedded.1/Bios/Settings \
  -H "X-Auth-Token: a1b2c3d4e5f60718293a4b5c6d7e8f90" \
  -H "Content-Type: application/json" \
  -d '{"Attributes": {"ProcVirtualization": "Disabled"}}'

BIOS changes on iDRAC don’t apply instantly. They’re staged as a pending job and need a reboot to take effect. That’s exactly like changing BIOS settings through the web UI or racadm set followed by racadm jobqueue create. After the PATCH, check /redfish/v1/JobService/Jobs for the pending configuration job. Then trigger a GracefulRestart to apply it. For bulk BIOS deployment across many servers, Dell’s idrac-redfish-scripting repo has a full Python example (SetBiosAttributesREDFISH.py) that handles job polling for you. Worth borrowing instead of reinventing.

Step 11: Automate Health Polling With PowerShell

This is where Redfish earns its keep. You can check health and power state across an entire rack without opening the web UI once. The script below opens a session per server, pulls health and power state, then cleans up the session when done.

# health-check.ps1
# Requires PowerShell 7.x for -SkipCertificateCheck

$iDRACs = @(
    "192.168.1.120",
    "192.168.1.121",
    "192.168.1.122"
)

$cred = Get-Credential -Message "Enter iDRAC credentials"
$results = @()

foreach ($idrac in $iDRACs) {
    $baseUri = "https://$idrac/redfish/v1"

    try {
        # Open a session and capture the auth token from response headers
        $sessionBody = @{
            UserName = $cred.UserName
            Password = $cred.GetNetworkCredential().Password
        } | ConvertTo-Json

        $sessionResponse = Invoke-WebRequest -Uri "$baseUri/SessionService/Sessions" `
            -Method Post -Body $sessionBody -ContentType "application/json" `
            -SkipCertificateCheck

        $token = $sessionResponse.Headers["X-Auth-Token"]
        $sessionLocation = $sessionResponse.Headers["Location"]
        $headers = @{ "X-Auth-Token" = $token }

        # Query system health and power state
        $system = Invoke-RestMethod -Uri "$baseUri/Systems/System.Embedded.1" `
            -Headers $headers -SkipCertificateCheck

        $results += [PSCustomObject]@{
            iDRAC      = $idrac
            Model      = $system.Model
            PowerState = $system.PowerState
            Health     = $system.Status.Health
        }

        # Close the session so we don't hit the concurrent session limit
        Invoke-WebRequest -Uri $sessionLocation -Method Delete `
            -Headers $headers -SkipCertificateCheck | Out-Null
    }
    catch {
        Write-Warning "Failed to poll ${idrac}: $_"
    }
}

$results | Format-Table -AutoSize

Run it:

./health-check.ps1

Expected output:

iDRAC Model PowerState Health
—– —– ———- ——
192.168.1.120 PowerEdge R750 On OK
192.168.1.121 PowerEdge R650 On OK
192.168.1.122 PowerEdge R740 Off OK

Drop this into Task Scheduler or a cron-equivalent. Pipe $results to an alerting webhook if Health -ne "OK". You’ve got a lightweight fleet monitor without installing anything beyond PowerShell itself.

Configuration

Setting	What It Does	Default
iDRAC.Redfish.Enable	Turns the Redfish service on/off; also settable via racadm set iDRAC.Redfish.Enable 1	Enabled on most current firmware
HTTP Basic Auth advertisement	Whether Basic Auth credentials are accepted on requests without a session token	Changed to Unadvertised on recent 7.xx firmware
Session auth (X-Auth-Token)	Token-based auth for scripts making repeated calls	Created per-session, not persistent
TLS/SSL certificate	Certificate presented on HTTPS connections	Self-signed by default

Go to iDRAC Settings > Network > SSL Certificate in the web console to install a trusted certificate. That way, production scripts don’t need to rely on -k / -SkipCertificateCheck. Either generate a certificate signing request for your internal CA, or upload an existing cert/key pair.

Tips and Troubleshooting

401 Unauthorized on calls that used to work

Cause: Recent iDRAC 9 7.xx firmware changed the default for advertising HTTP Basic Auth from Enabled to Unadvertised. Scripts that sent a username and password on every call started failing after a firmware update, even though nothing in the script changed.

Fix: Switch to session authentication. Open a session, capture the X-Auth-Token, and use it for subsequent calls (Step 6). It’s also more efficient for scripts making many requests, so it’s worth adopting even if Basic Auth still works on your firmware.

Certificate errors (“SSL certificate problem” / “unable to verify”)

Cause: iDRAC ships with a self-signed TLS certificate. Most HTTP clients, including curl, PowerShell, and browsers, reject self-signed certs by default.

Fix: For lab/testing, use curl -k or PowerShell’s -SkipCertificateCheck. For production automation, install a trusted certificate signed by your internal CA under iDRAC Settings > Network > SSL Certificate. Then drop the skip-verification flags entirely. You want cert validation working in scripts that touch production hardware.

Redfish requests return HTTP 404 on every endpoint

Cause: The Redfish service itself is disabled at the iDRAC level.

Fix: Log into the web console, go to iDRAC Settings > Services, and check Enabled under the Redfish section. Click Apply (Step 2). No restart needed. Retry the request immediately after.

Fields or endpoints from Dell’s docs don’t match your actual responses

Cause: Dell’s Redfish schema is versioned per firmware family. The 7.xx API guide describes 15th/16th-gen PowerEdge behavior on firmware 7.00.30.00 and later. Older iDRAC 9 firmware on 14th-gen hardware exposes a different, usually smaller, set of endpoints and attributes.

Fix: Check your exact firmware version under iDRAC Settings > Overview. Match it to the corresponding version at developer.dell.com/apis/2978 before assuming a field is “missing.” It may just be gated behind a newer firmware release.

Scripts that worked fine before a firmware update suddenly break

Cause: Firmware updates can change default behavior (the Basic Auth change above is the most common example) or add/deprecate schema fields between versions.

Fix: Before re-running automation after any iDRAC firmware update, check the release notes for that version. Re-test authentication logic first. It’s the most common breaking change, followed by renamed or relocated attributes.

Where Redfish Fits Alongside RACADM

Redfish doesn’t replace RACADM. The two overlap, but they fit different habits.

Task	Better Tool	Why
Quick one-off command on a server you’re SSH’d into	RACADM	Faster to type, no JSON parsing needed
Multi-vendor or cross-platform automation	Redfish	Same resource model works across Dell, HPE, Lenovo
Health polling across a rack	Redfish	Structured JSON is easy to parse and alert on programmatically
CI/CD pipeline integration (firmware update gating, pre-flight checks)	Redfish	REST/JSON integrates cleanly with existing pipeline tooling
Local scripted deployment via racadm config files	RACADM	Still the simpler option for pure Dell shops doing bulk racadm set
Enabling Redfish itself, from a script	RACADM	racadm set iDRAC.Redfish.Enable 1 is the bootstrap step before Redfish is even reachable

In practice, most shops use both. RACADM handles local, Dell-only, one-off admin tasks. Redfish handles anything that needs to scale across servers or eventually span vendors.

Wrapping Up

At this point, Redfish is enabled, authenticated, and handing back real health, power, and sensor data from your iDRAC 9. You’ve also got a working PowerShell script that polls an entire rack in seconds instead of clicking through the web UI server by server.

The payoff compounds once you’re managing more than a handful of hosts. The JSON structure and session-token pattern here carry over almost unchanged if your infrastructure ever grows past Dell.

Step	Action	Applies To
1–2	Verify firmware, enable Redfish in web console	All platforms
3	Confirm service root responds at /redfish/v1/	All platforms
4–5	Set up curl/PowerShell client tooling	Windows, macOS
6	Authenticate via session token (X-Auth-Token)	All platforms
7–10	Query health, sensors, power actions, BIOS settings	All platforms
11	Automate polling with PowerShell	Windows, macOS (via pwsh)

Resources

• Dell Redfish API Documentation Portal
• Dell iDRAC9 7.xx Redfish API Guide
• Redfish API with Dell Integrated Remote Access Controller (KB article)
• Dell iDRAC9 Redfish Scripting Examples (GitHub)
• iDRAC9 v3.4 Series User’s Guide