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 Profile | System Profile | SysProfile | PerfOptimized | Staged |
| System Profile | Workload Profile | WorkloadProfile | NotConfigured | Staged |
| Memory | Node Interleaving | NodeInterleave | Disabled | Staged |
| Memory | Memory Paging Policy | PagingPolicy | PagingClosed | Staged |
| Processor | Logical Processor (HT) | LogicalProc | Enabled | Staged |
| Processor | CPU Interconnect Speed | CpuInterconnectBusSpeed | MaxDataRate | Staged |
| Processor | Virtualization Technology | ProcVirtualization | Enabled | Staged |
| Processor | Adjacent Cache Line Prefetch | ProcAdjCacheLine | Enabled | Staged |
| Processor | Hardware Prefetcher | ProcHwPrefetcher | Enabled | Staged |
| Processor | DCU Streamer Prefetcher | DcuStreamerPrefetcher | Enabled | Staged |
| Processor | DCU IP Prefetcher | DcuIpPrefetcher | Enabled | Staged |
| Processor | SST-Performance Profile | ProcPwrPerf | MaxPerf | Staged |
| Processor | Cores Per Processor | ProcCores | All | Staged |
| Boot | Boot Mode | BootMode | Uefi | Staged |
| Boot | Boot Order | BootOptions collection | BOSS first | Manual |
| PXE (×4) | PXE Devices 1–4 | PxeDev1–4EnDis | Disabled | Staged |
| SR-IOV | SR-IOV Global Enable | SriovGlobalEnable | Disabled | Staged |
| iDRAC Network | IPv4 Enabled | IPv4.1.Enable | Enabled | Immediate |
| iDRAC Network | IPv6 Disabled | IPv6.1.Enable | Disabled | Immediate |
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:
[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.
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).
# 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:
=================================================
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
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.
-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:
# 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.