The Advanced Settings Utility, or ASU, is a command-line tool from IBM and Lenovo. It’s used to modify firmware settings on System x servers and BladeCenter hardware. It works across multiple operating systems, including RHEL, SUSE, ESX/ESXi, and Windows. The key advantage: it changes BIOS and firmware settings without a reboot into the F1 setup screen.

If you manage more than a handful of servers, that distinction matters. Walking up to each machine and pressing F1 during boot doesn’t scale. ASU does.

What ASU Actually Does

ASU gives administrators command-line access to firmware settings. These are normally buried in BIOS, UEFI, or management controller menus. Specifically, it can:

• Modify BIOS CMOS settings without restarting the system to access F1 setup
• Configure Baseboard Management Controller (BMC) settings
• Configure Remote Supervisor Adapter (RSA) and RSA II settings
• Modify Integrated Management Module (IMM) firmware settings and IBM System x server firmware, which runs on UEFI
• Set up iSCSI boot configuration
• Manage Feature on Demand activation keys
• Configure secure boot
• Handle limited VPD (vital product data) settings on IMM-based servers and Chassis Management Modules (CMM)

It also supports remote connectivity, so IMM-based servers can be reconfigured over the network without a technician physically present. Since ASU 3.60, it bundles RDCLI, a utility for mounting an ISO or CD/DVD image to a remote IMM system.

Why It Exists

Standard BIOS or UEFI setup menus require physical or console access at boot time. That’s one server at a time. It works fine for a single machine. It breaks down in a data center running dozens or hundreds of servers.

ASU solves this by exposing firmware settings as command-line parameters. The same setting can be scripted, applied in batch, and repeated identically across a whole fleet. For teams managing server firmware as part of a standardized build process, that’s a real shift. It moves them from manual, error-prone configuration toward something closer to infrastructure automation.

Supported Platforms

ASU is built for specific IBM System x and Lenovo x86 server hardware. Support is version-dependent. The most recent version, 9.64, supports systems that don’t require an externally applied BIOS patch. That’s a broad range of BladeCenter, Flex System, System x3000-series, and iDataPlex hardware. Older hardware is a different story. Earlier xSeries and BladeCenter models are supported by the older 3.63 release, and some of that hardware needs an external BIOS patch before ASU will work with it at all.

This version-to-hardware mapping matters. Running the wrong ASU version against unsupported hardware won’t necessarily fail cleanly. Checking your exact server model against the supported systems list before deploying at scale is worth the extra few minutes.

Command Reference: The Commands You’ll Actually Use

ASU’s syntax follows a consistent pattern: asu [options] command [command-options]. A handful of commands cover most day-to-day work, based on IBM and Lenovo’s official documentation:

• asu show all — lists every setting and its current assigned value. This is usually the first command run on a new system to see what’s actually configurable.
• asu show <setting> — displays the current value of one specific setting.
• asu showvalues <setting> — shows the possible values a setting can be changed to, along with its default. For a numeric setting, this includes the minimum, maximum, and step values — useful before setting something you’re not already familiar with.
• asu set <setting> <value> — changes a setting to a new value. This is the core command for actually modifying firmware configuration.
• asu show -l -b all — displays all settings in long batch format, the format ASU expects when building a batch file to apply settings across multiple machines.
• asu --help and asu -v --help — display general and verbose help. Running asu -v <command> --help shows verbose help for one specific command.

For applying multiple settings at once, ASU supports transaction-based batch mode: the tropen command opens a transaction, and trset adds settings to it before executing the full set together. This is what makes scripted, fleet-wide configuration practical, instead of running individual asu set commands one at a time.

Requirements and Limitations Worth Knowing

A few practical details matter once you’re actually running ASU, not just reading about it:

• UEFI settings need a reboot to take effect. Changing a setting with asu set doesn’t apply it live. The host system has to restart before the new value is active.
• Windows requires administrator privileges. ASU won’t run correctly under a standard user account on Windows.
• IMM-based servers sometimes need a reset after changes. For some settings on IMM-based servers, you need to run asu rebootimm after making changes. Skip it, and the settings you configured might not take effect or display correctly. If you’re about to flash new firmware after changing settings, resetting the IMM first matters — skipping it can cause your changes to be lost.
• Certificate management has a firmware floor. Managing certificates on IMM-based servers through ASU requires a minimum IMM firmware level. Older firmware won’t support it.
• Security patching matters on older versions. IBM’s release notes show ASU has shipped fixes for real vulnerabilities over the years. Version 9.64 disabled outdated protocols (SSLv2, 3DES, RC4, Blowfish) and patched a specific CVE. Version 3.63 fixed a temporary-file security issue. If you’re running an ASU build from several versions back, check whether a newer release addresses a known vulnerability before deploying it broadly.

Where to Download It

ASU is distributed through IBM’s Fix Central and Lenovo’s ToolsCenter. There are separate builds for Windows (32-bit and 64-bit) and Linux (32-bit, 64-bit, and RPM packages). If you’re working with newer Lenovo-branded hardware rather than legacy IBM System x equipment, note that Lenovo maintains its own current ASU distribution, separate from the IBM legacy downloads. Confirm which vendor’s build matches your hardware generation before downloading.

Common Use Cases

• Standardizing firmware across a server fleet — applying identical BIOS and BMC settings to every new server in a batch during provisioning
• Remote configuration — changing IMM or RSA settings on servers in a remote data center without dispatching a technician
• Scripted deployment — integrating firmware configuration into an automated server build pipeline
• Secure boot and Feature on Demand management — enabling security settings or activating licensed features without manual BIOS navigation

FAQs

Is ASU free to use?

Yes. It’s distributed as a support tool through IBM and Lenovo’s official download channels at no additional cost.

Does ASU replace the BIOS/UEFI setup screen entirely?

No. It extends what’s configurable beyond the standard F1/F2/Delete setup menu. You make those changes from the command line instead, but the setup screen itself is still there.

Which servers does ASU support?

Support depends on the ASU version. The current release (9.64) covers a wide range of newer System x, BladeCenter, Flex System, and iDataPlex hardware that doesn’t require an external BIOS patch. Older hardware is covered by the legacy 3.63 release. Some older models need a BIOS patch applied first. Check the supported systems list for your exact model before deploying.

Is ASU a GUI tool?

No. It’s a command-line utility, built specifically for scripting and batch operations rather than interactive point-and-click configuration.

Do ASU changes apply immediately?

No. For UEFI settings, changes take effect after the host system reboots. For some IMM-based server settings, you also need to run asu rebootimm to reset the management module, or the change may not fully register.

Key Takeaways

The Advanced Settings Utility is IBM and Lenovo’s command-line tool for configuring BIOS, BMC, RSA, and IMM firmware settings. It works on System x and BladeCenter servers, without a manual reboot into setup. Its real value is scale: scripting identical firmware configuration across many servers, rather than touching each one by hand. Support is tied to specific hardware and ASU versions. Confirming your server model against the current supported systems list before rolling out changes is the one step worth not skipping.