iDRAC-Redfish-Scripting: driving Dell PowerEdge servers over Redfish

Four surfaces: standalone scripts, a module, cmdlets, and a mockup

The repository is described as Python and PowerShell scripting for the Dell EMC PowerEdge iDRAC REST API with DMTF Redfish, and the sample scripts illustrate using the integrated Dell Remote Access Controller REST API with Redfish to manage Dell PowerEdge servers.

The top level of the tree shows how the four pieces are organised:

Redfish PowerShell/
Redfish Python/
iDRAC Python Redfish Module/
iDRAC Redfish Mockup Clients/

Two of those are the samples themselves, one set in each language. The third is the module. The fourth is the mockup, and it is the most useful thing in the repository for anyone learning the API.

The Python side offers two ways in. You can use either individual python scripts or install the iDRAC Python Redfish module, and the module is described as an interactive session with an iDRAC which allows you to perform multiple workflows like firmware updates or configuration changes to BIOS, NIC or Storage. You install it by running pip3 install IdracRedfishSupport, and there is a note that installing the module this way also installs all the standalone python scripts from the GitHub Python directory, so the two routes are not independent.

The PowerShell side mirrors it. Cmdlets can also be installed from the Powershell gallery using Install-Module, and the recommendation is to install the IdracRedfishSupport module which will import all iDRAC cmdlets.

So the same module name, IdracRedfishSupport, exists on both sides, which is a nice touch for a team that writes in both languages, and it means the examples and the packaged tooling are consistent with each other rather than drifting.

Redfish itself, and why it replaced the older management protocols

The README spends a long section on the standard itself, and the reasoning is the same reasoning that makes the samples worth reading.

There are various Out-of-Band management systems standards available in the industry today, but the argument runs that no single standard could easily be used within emerging programming standards, could be readily implemented within embedded systems, and could meet the demands of evolving IT solution models. New models placed new demands on systems management, including expanded scale, higher security and multi-vendor openness, while also aligning with modern DevOps tools and processes. Dell EMC and other leaders within the Distributed Management Task Force undertook the creation of a new management interface standard, and after a multi-year effort Redfish v1.0 was announced in July 2015.

The listed benefits are the ones that matter for automation. Increased simplicity and usability, encrypted connections and generally heightened security, a programmatic interface that can easily be controlled through scripts, and a basis in widely-used standards for web APIs and data formats.

The data model is the part that makes cross-vendor work possible. It defines the structure and format of data representing server status, inventory and available operational functions, and it is vendor-neutral, so administrators can create management automation scripts that manage any Redfish compliant server, which matters for the efficient operation of a heterogeneous server fleet.

On security, the README makes a specific claim. Unlike legacy management protocols, Redfish utilizes HTTPS encryption, and all Redfish network traffic, including event notifications, can be sent encrypted across the network. That matters for out-of-band management, because the channel is the one you use precisely when the server is broken.

The data shape is also worth knowing before you read a script. The tree-like structure makes information easier to locate, data returned from a Redfish query can be turned into a searchable dictionary of key-value pairs, and by looking at the values it is easy to locate settings and current status. Those settings can then be updated and actions issued to one or multiple systems.

What the iDRAC layer adds on top of the standard

The iDRAC with Lifecycle Controller section explains what the vendor layer contributes, and the distinction between the standard and the value-add is the point.

The Integrated Dell Remote Access Controller is designed to enhance the productivity of server administrators and improve the overall availability of PowerEdge servers. It alerts administrators to server problems, enabling remote server management and reducing the need for an administrator to physically visit the server. With Lifecycle Controller, administrators can deploy, update, monitor and manage Dell servers from any location without the use of agents in a one-to-one or one-to-many method.

That last phrase is the operational point. Agentless out-of-band management is what makes the controller worth having when the server is not booting, and it is why the API has value even for a fleet you already have a full management stack for.

To support Redfish, iDRAC with Lifecycle Controller includes support for the iDRAC REST API in addition to IPMI, SNMP and WS-Man. The REST API builds on Redfish to provide a Dell-specific interface for value-add operations. The listed areas are information on all out-of-band services, meaning the web server, SNMP, virtual media, SSH, Telnet, IPMI and KVM; expanded storage subsystem reporting covering controllers, enclosures and drives; for the PowerEdge FX2 modular server, detailed chassis information covering power supplies, temperatures and fans; and with the iDRAC Service Module installed under the server OS, detailed inventory and status reporting for host network interfaces including IP address, subnet mask and gateway for the host OS.

So a Redfish client sees a standard data model, and the Dell extension adds the operational detail that makes a PowerEdge fleet manageable. The samples in this repository are where you see which of those endpoints a real script actually calls.

The mockup server, and why it is the reason to look at this repository

The final section of the README is the one that makes the whole thing more than a set of examples.

A Redfish mockup server is an effective method to simulate a Redfish iDRAC environment without using a physical server or iDRAC, and the section lists the problems it solves, the first of which is simply not having access to the hardware.

That is the central practical problem with out-of-band scripting. A Redfish script that manages firmware, BIOS settings and storage is, by design, operating on a machine that is running the workloads you care about. You cannot develop one safely against production hardware, and a rack of PowerEdge servers is not a cheap place to experiment.

A mockup server changes the shape of the work. You write the script against a simulated Redfish interface, you can run it in CI, you can assert on the requests it makes, and you only point it at real hardware once it behaves. The repository ships the mockup clients alongside the scripts for that reason, and the directory name makes the intent clear.

The security advice in the README is worth repeating, because it is the kind of thing that fails at the worst moment. When executing any script or cmdlet, if your username or password has special characters, or if you are passing a domain name along with a username, make sure to surround the argument value with double quotes. The examples given are domain-qualified usernames in several forms:

"testdomain.i\aduser",
"testdomain.i/aduser",
"[email protected]"

An unquoted argument with a backslash or an at sign is a shell quoting problem that produces a confusing authentication error rather than a syntax error, and the three examples cover the shapes you will actually meet in a Windows domain environment.

Where to look next, and what to expect from a scripts repository

The README points at a substantial set of Dell documentation, and the list is worth reading as a map of what you can do once you have the basics working.

There is the iDRAC Server Configuration Profile Reference Guide, which is the document you want when you are changing settings rather than reading them, because a server configuration profile is the declarative way to apply a set of BIOS and firmware settings to a machine, and it is what makes a fleet reproducible. There are two mapping documents, one from RACADM to Redfish and one from the user interface to Redfish, which are for people migrating an existing script or a habit to the new API. There is the iDRAC Redfish FAQ, and the iDRAC Redfish API Guide. Then there are two task-specific guides, managing iDRAC virtual media using Redfish and remotely updating firmware on PowerEdge servers using Redfish APIs.

The last of those is the one that maps onto the module's description, since the module is described as letting you perform workflows like firmware updates, and the guide tells you what the underlying calls look like.

The full iDRAC manuals are at dell.com/idracmanuals, and the standard itself is documented at the DMTF site, which is where you go when a script needs an endpoint that the iDRAC extension does not mention.

The maintenance picture for this repository is modest. The last push was on 2026-09-16, the repository is not archived, there are no GitHub releases, and the licence is GPL-2.0.

What you are getting, then, is a set of working examples, two installable modules, and a simulator. For learning the API or for writing a one-off automation, that is a good deal. For a fleet management tool you intend to maintain, the missing piece is a supported library that handles session lifetimes, retries and Redfish version differences across firmware generations, and you will be writing that yourself.

Editorial conclusion

Adopt this repository if you are automating Dell PowerEdge hardware and want working examples of the iDRAC REST calls rather than a wrapper library, since the samples show the raw requests and the responses. Do not adopt it as a dependency, because it is a collection of scripts and a module rather than a supported package, and expect to write your own error handling. Before you start, install the IdracRedfishSupport module and read the mockup server section, because developing against the mockup rather than against a live iDRAC is the difference between a testable script and one you can only run in the rack.

Frequently asked questions

Official sources

1. dell/iDRAC-Redfish-Scripting on GitHub
2. Issues
3. License: GPL-2.0
4. README