Automating Dell PowerEdge R660 BIOS Validation and Remediation with PowerShell and Redfish API

A practical guide to validating 18 critical BIOS and iDRAC settings via the Redfish REST API — with interactive per-check remediation and zero automatic reboots.

Tags: PowerShell Dell PowerEdge Redfish API BIOS iDRAC 9 Automation Infrastructure VMware
⚠️

Use at your own risk. Test in a non-production environment first. The author is not responsible for any unintended outcomes.

Imagine commissioning twenty new Dell PowerEdge R660 servers for a compute cluster. They are racked, cabled, and handed to the OS team. Weeks later, workloads are live — and then someone notices a server is running with Node Interleaving enabled, another has SR-IOV turned on from a previous tenant's config, and three have IPv6 active on the iDRAC network interface. None of it was caught before go-live because BIOS validation was manual, checkbox-based, and entirely dependent on whoever was at the keyboard that day.

This is a pattern I have seen repeatedly across datacenter environments. BIOS misconfiguration is quiet — the server boots, the OS installs, everything appears fine. The performance impact or security exposure only surfaces under load or during a review. In this post, I will walk through the PowerShell script I built to solve exactly this: a Redfish-based BIOS validation and interactive remediation tool for the Dell PowerEdge R660 that checks 18 settings across seven sections, flags every failure, and offers to fix it immediately — with a clear Y/N prompt per check and zero automatic reboots.

Why Redfish API Instead of Manual Clicks or racadm

Dell gives you three ways to manage BIOS settings: the iDRAC web UI, the racadm command-line tool, and the Redfish REST API. For any repeatable, auditable process, Redfish is the right choice.

The iDRAC UI is fine for one-off changes but does not scale and leaves no traceable audit trail beyond what you document manually. racadm is scriptable but its attribute naming is inconsistent across server generations and requires either a local agent or SSH access. Redfish, on the other hand, is a DMTF open standard — fully RESTful, returns JSON, works over HTTPS from any machine that can reach the iDRAC management IP. No agents, no SSH tunnels, no additional tooling. Every modern Dell iDRAC 9 exposes it out of the box.

Redfish is not just an API — it is the foundation for serious fleet-level infrastructure automation. If you are still clicking through the iDRAC UI to configure servers one at a time, you are building operational debt.

The script authenticates with HTTP Basic Auth over TLS 1.2 and reads BIOS attributes from /redfish/v1/Systems/System.Embedded.1/Bios. iDRAC-level settings are read and written via /redfish/v1/Managers/iDRAC.Embedded.1/Attributes. In environments with self-signed iDRAC certificates — standard in most datacenter builds — a TrustAll certificate policy is applied at the session level.

The 18 Checks — Section by Section

Here is a full reference of every check, the BIOS attribute key, the required value, and how the fix is applied if the check fails.

Section Label Attribute Key Expected Value Fix Type
System ProfileSystem ProfileSysProfilePerfOptimizedStaged
System ProfileWorkload ProfileWorkloadProfileNotConfiguredStaged
MemoryNode InterleavingNodeInterleaveDisabledStaged
MemoryMemory Paging PolicyPagingPolicyPagingClosedStaged
ProcessorLogical Processor (HT)LogicalProcEnabledStaged
ProcessorCPU Interconnect SpeedCpuInterconnectBusSpeedMaxDataRateStaged
ProcessorVirtualization TechnologyProcVirtualizationEnabledStaged
ProcessorAdjacent Cache Line PrefetchProcAdjCacheLineEnabledStaged
ProcessorHardware PrefetcherProcHwPrefetcherEnabledStaged
ProcessorDCU Streamer PrefetcherDcuStreamerPrefetcherEnabledStaged
ProcessorDCU IP PrefetcherDcuIpPrefetcherEnabledStaged
ProcessorSST-Performance ProfileProcPwrPerfMaxPerfStaged
ProcessorCores Per ProcessorProcCoresAllStaged
BootBoot ModeBootModeUefiStaged
BootBoot OrderBootOptions collectionBOSS firstManual
PXE (×4)PXE Devices 1–4PxeDev1–4EnDisDisabledStaged
SR-IOVSR-IOV Global EnableSriovGlobalEnableDisabledStaged
iDRAC NetworkIPv4 EnabledIPv4.1.EnableEnabledImmediate
iDRAC NetworkIPv6 DisabledIPv6.1.EnableDisabledImmediate

Why Each Check Matters

System Profile — Performance Mode

SysProfile = PerfOptimized tells the firmware to disable C-states, enable turbo, and maximise memory bandwidth. Servers shipped in PowerSaver or custom balanced profiles will throttle under sustained workloads without ever raising an alert. Combined with WorkloadProfile = NotConfigured, there are no conflicting profile-level overrides.

Memory — Node Interleaving and Paging Policy

Node Interleaving must be Disabled. When enabled, the firmware presents all NUMA nodes as a single flat memory pool. This destroys NUMA locality — applications that are NUMA-aware, and most high-performance workloads and hypervisors are, suffer significant latency increases when memory accesses cross node boundaries. VMware ESXi is particularly sensitive to this setting and will log NUMA warnings in the VMkernel.

Closed Paging (PagingClosed) keeps memory row buffers open until a different row is accessed, reducing row activation overhead for sequential workloads. This is the optimal default for general compute and virtualisation environments.

Processor — Nine Checks

The nine processor checks cover the settings most commonly left at suboptimal defaults:

  • Hyper-Threading — should always be enabled for mixed workloads. Only disable for specific security-driven requirements.
  • CPU Interconnect Bus Speed (MaxDataRate) — running UPI at below maximum on a dual-socket R660 directly caps cross-socket bandwidth, impacting any workload that crosses socket boundaries.
  • All four prefetchers (Hardware, Adjacent Cache Line, DCU Streamer, DCU IP) — disabling them only benefits very specific micro-benchmarking scenarios. In production, all four should be on.
  • SST-Performance Profile (MaxPerf) — Intel Speed Select Technology on Sapphire Rapids allows selecting operating points. MaxPerf runs all cores at maximum base frequency, which is critical for latency-sensitive workloads.
  • All Cores — partial core configurations exist for software licensing optimisation. Confirm this is intentional if you see anything other than All.

Boot — UEFI and BOSS First

UEFI boot mode is non-negotiable for any modern server OS deployment. The boot order check resolves human-readable device names from the Redfish BootOptions collection (using $expand) and validates that a BOSS card appears first. The expected order is BOSS → CD/DVD → Local Disk → NIC. A NIC in position one is one of the most common causes of servers hanging at POST waiting for a DHCP lease in environments without PXE infrastructure.

PXE — All Slots Disabled

All four PXE device slots must be Disabled. Leaving PXE enabled on production servers introduces a dependency on DHCP and TFTP at every startup, and creates a vector for accidental or deliberate network boot in environments where PXE infrastructure exists.

SR-IOV — Always Disabled

SR-IOV enables physical NIC functions to be passed directly into VMs, bypassing the hypervisor network stack. It is a legitimate feature when required, but should never be on by default. It is a very common leftover setting from previous tenants or pre-built reference images. The script treats this as a hard FAIL — not a warning — and prompts to correct it.

iDRAC Network — IPv4 On, IPv6 Off

IPv4 on the iDRAC management interface must be enabled — it is how the script itself connects. IPv6 should be disabled unless your management VLAN is IPv6-capable and you have a deliberate reason to use it. Leaving IPv6 active with no IPv6 management infrastructure is an unnecessary attack surface. This is the only check that applies and takes effect immediately, without touching the host server.

Interactive Y/N Remediation Design

When any check fails, the script prints the current and expected values, then pauses and asks the operator whether to apply the fix:

POWERSHELL OUTPUT
  [FAIL]    Hardware Prefetcher
            Current  : Disabled
            Expected : Enabled

            Apply fix? Set to 'Enabled' (staged — requires manual reboot) [Y/N]: Y

  [FIXED]   Hardware Prefetcher — change staged successfully

The reason for this design is deliberate. In a datacenter environment you may be validating a server that is partially in use, or where a setting was intentionally changed for a specific workload. Auto-applying every correction without confirmation would be dangerous. The operator needs to be in the loop for every single change.

⚠️
The script never automatically reboots the server. If at least one BIOS fix was staged during the session, a prominent warning is displayed at the end reminding the operator that a manual reboot is required before changes take effect.

Staged BIOS vs Immediate iDRAC Changes

This distinction is important to understand. Redfish exposes two separate writable endpoints with different commit behaviours:

  • /Systems/System.Embedded.1/Bios/Settings — BIOS pending settings. A PATCH here writes to the staging area. Changes are applied at the next POST. The server must be rebooted.
  • /Managers/iDRAC.Embedded.1/Attributes — iDRAC controller settings. A PATCH here is applied directly to the iDRAC firmware and takes effect within seconds — without touching the host OS or triggering a reboot.

The script handles both paths transparently. The prompt text explicitly tells the operator which type of fix they are confirming before they type Y.

How to Run the Script

The script runs from any Windows machine with HTTPS access to the iDRAC management IP. Three parameters: iDRAC IP (mandatory), username (defaults to rootadmin), and password (mandatory).

POWERSHELL
# Standard validation — prompts Y/N for each failed check
.\R660-BIOS-Validate.ps1 -iDRACIP 10.252.87.76 -iDRACPassword "YourPassword"

# Custom admin username
.\R660-BIOS-Validate.ps1 -iDRACIP 10.252.87.76 -iDRACUser "batman.admin" -iDRACPassword "YourPassword"

# Dump all iDRAC attribute keys and values (diagnostic mode, then exits)
.\R660-BIOS-Validate.ps1 -iDRACIP 10.252.87.76 -iDRACPassword "YourPassword" -DumpAttributes

The session summary at the end shows four counters:

EXAMPLE OUTPUT
=================================================
  TOTAL CHECKS : 18
  PASS         : 15
  FAIL         :  3
  FIXED        :  2
  SKIPPED      :  1
=================================================
  2 fix(es) applied successfully.
  1 item(s) skipped — no change made.

=================================================
   !! MANUAL REBOOT REQUIRED !!
   One or more BIOS settings have been staged.
   They will NOT take effect until the server
   is rebooted manually.
=================================================

The -DumpAttributes Diagnostic Switch

iDRAC attribute key names are not always obvious, and they can vary between firmware versions. The -DumpAttributes switch fetches every attribute from the Attributes endpoint, sorts them alphabetically, prints them all to the console, and exits without running any checks. Use it when:

  • A check returns a blank Current value (the attribute key name does not match)
  • A PATCH returns a 400 Bad Request (the key or value format is wrong)
  • You are adapting the script for a different firmware version or server generation
ℹ️
The iDRAC attribute keys confirmed on a live R660 running iDRAC 9 v7.30.10.50 are IPv4.1.Enable and IPv6.1.Enable — not iDRAC.IPv4.Enable as some older documentation suggests. The dump makes finding the correct name trivial.

Dell PowerEdge R650 Compatibility

The script was built and verified against the R660 (16th generation, Sapphire Rapids, BIOS 2.10.1, iDRAC 9 v7.30.10.50). It will work on the R650 (15th generation, Ice Lake) for the majority of checks, with one caveat: the ProcPwrPerf SST-Performance Profile options differ between generations — Ice Lake has fewer operating points than Sapphire Rapids. The iDRAC attribute keys (IPv4.1.Enable, IPv6.1.Enable) are identical since both run iDRAC 9.

Before running on an R650, use -DumpAttributes to confirm all iDRAC attribute keys are correct, and manually verify the BIOS attribute expected values match what your firmware version exposes.

Extending to Fleet-Wide Validation

The script currently targets one server per run — which is the right starting point while you are validating the checks. Once you trust the logic, wrapping it for fleet use is straightforward with a simple CSV loop:

POWERSHELL
# fleet-validate.ps1 — run validation against all servers in idrac-list.csv
# CSV columns: Hostname, iDRACIP, Password
Import-Csv .\idrac-list.csv | ForEach-Object {
    Write-Host "`nValidating $($_.Hostname) — $($_.iDRACIP)" -ForegroundColor Cyan
    .\R660-BIOS-Validate.ps1 -iDRACIP $_.iDRACIP -iDRACPassword $_.Password
}

The natural next step is a -AutoFix switch that stages all corrections silently, paired with a separate scheduled reboot window — turning this into a full server commissioning validation pipeline that runs automatically before a node is handed to any team. Getting BIOS right before the OS lands is always simpler than diagnosing performance anomalies six months into production.


The full script is available on GitHub — automatewithravi. If you are adapting this for the R650 or a different Dell generation and hit attribute name differences, drop a comment or reach out via LinkedIn.