Inventorying Servers via Redfish API: Serial Numbers and CMDB

What to collect and why a CMDB needs it

A CMDB is not just a pretty table. It answers practical questions: which servers do we have, what condition are they in, how do they differ, and what should be replaced first. To get accurate answers, collect not only names but verifiable facts: serial numbers, firmware versions, component lists, and statuses.

Details are often lost and later urgently searched for during an outage or procurement. The chassis serial is sometimes recorded, but serials for power supplies, drives, or network cards often remain only in management interfaces. The same goes for BIOS/UEFI versions, BMC, and drive or controller firmware. As long as everything works, no one notices; on incompatibility or vulnerability, it suddenly turns out that half the fleet runs different versions.

Manual collection via iDRAC/iLO and copying into Excel doesn't scale for three reasons. It's slow: tens of servers can take hours or days. Errors are inevitable: missed fields, swapped slots, incorrectly copied values. And data ages quickly: firmware updated, a drive replaced, a sensor drifting, but the file stays the same.

A CMDB almost always requires two things: a consistent data format and stable matching keys.

Consistent format means deciding in advance how values will look: dates, versions, units, manufacturer names. To a person "BIOS 2.3.1" and "2.3.1 (BIOS)" look the same, but for search and reporting they are different strings.

Stable matching keys are needed so the CMDB understands that this is the same server even if you renamed the host or moved it to another rack. Usually the base key is the chassis serial number, and for components a combination of "serial + type + slot/position." Then replacing a drive in bay 3 is a clear event, not a mysterious "a new unknown drive appeared."

Practical minimum to collect from Redfish for each server:

• Identifiers: chassis serial number, model, manufacturer, asset tag, UUID (if available).
• Firmware: BIOS/UEFI, BMC version, controller and drive firmware versions (if reported).
• Components: CPU, memory, drives, RAID/HBA, network adapters, power supplies, fans.
• Sensors and status: temperatures, power, fan status, overall health, active errors.

Measure inventory success not by "we collected something" but by four indicators:

• Completeness: share of servers and components with key fields filled.
• Repeatability: same queries yield the same data structure between runs.
• Matchability: CMDB updates existing records rather than creating duplicates.
• Clear errors: if a controller doesn't report firmware, it appears as an explicit field/status, not a silent omission.

Redfish in simple terms: what it gives for inventory

Redfish is a standard API that lets you read (and sometimes change) data directly from a server's BMC. Essentially you query the "management computer" inside the server and get facts about the hardware even if the main OS is off or not installed. That's why Redfish-based collection often becomes the basis for reliable CMDB records.

The main advantage is no OS agents are needed. You don't depend on which OS is installed, whether SSH/WinRM is available, or whether the system has booted. If the BMC has network access and credentials, you can gather a lot.

Typically available without agents are serial numbers and model, manufacturer, UUID, CPU and memory composition, network interfaces, drives and controllers, BIOS and some firmware versions, sensor readings (temperature, fans, power) and health status. In practice this helps quickly answer "what's installed," "which firmware version," and "where is overheating."

Structurally Redfish data is organized into sections. Commonly seen are:

• Systems: compute node logic (identifiers, CPU/RAM, boot info, sometimes storage and NICs).
• Chassis: the physical enclosure (sensors, power, fans, sometimes module inventory).
• Managers: the BMC itself (version, network, events, accounts).
• UpdateService: update-related info and sometimes a list of installed firmware.

Limitations must be considered too.

First, permissions. A read-only account is safer but might not return some fields. Admin rights provide more data but increase risk.

Second, vendors differ: the same section can be filled differently—one place stores the serial in one field, another vendor uses a different field or OEM blocks.

Third, support can be incomplete. For example, sensors may be present but component firmware reported only partially.

Practical example: a mixed fleet with data center and AI nodes. On some systems Redfish returns a full firmware list; on others only the BIOS version. That's normal. The important thing is not to fail on empty fields, to normalize data carefully, and to record in the CMDB what was readable and what was not.

Preparation: credentials, security and target list

Before starting, agree on basics: the source of the server list, which credentials you use for BMC access, and where you store results. This saves time when you discover half the BMCs are unreachable or the account has wrong privileges.

BMC access: least privilege and a single approach

Each server needs a BMC IP (iDRAC, iLO, XClarity, etc.) and an account that can read data. Usually a ReadOnly role is enough to get serials, firmware versions, component inventory and telemetry.

Prepare a short checklist:

• BMC IP addresses and hostnames (if any)
• a dedicated service account for inventory (read-only)
• note which sites and network segments the collector can reach
• a naming convention to avoid confusion (e.g., SITE-RACK-U)

Source of truth for the server list

Don't rely on "about 200 servers mentioned in chat." Keep a single file or table where each record has at least: inventory number, site, room/zone, rack and unit, and owner/department. This helps link Redfish data to the CMDB object even if a serial can't be read temporarily.

Security: passwords, audit, and access boundaries

Don't store passwords in scripts or pass them on the command line. Use a secure secret store or at least environment variables on the collector host.

Create a separate service account with a clear name and audit logging: who, when and from where accessed the BMC. This makes incident investigation easier and confirms the collection was read-only.

Availability checks: network, HTTPS and certificates

Before a mass run, do a quick pass on a small sample. Check:

• routing and filters between the collector and BMC network
• port 443 and correct HTTPS responses
• TLS version requirements (older BMCs may fail new policies)
• certificate behavior: trusted, self-signed, expired

If certificates are self-signed, decide in advance: import trust into a store or allow exceptions for that segment. The approach must be stable, otherwise results will "jump" between runs.

Step-by-step: requests for serials, firmware and sensors

Start from the ServiceRoot: it shows which sections the BMC supports. The base path is almost always /redfish/v1. Then follow @odata.id links instead of guessing URLs—vendor structures vary.

# Example: basic check that Redfish responds
curl -k -u user:pass https://BMC_HOST/redfish/v1

1) Find Systems and Chassis and verify they exist

Collections are usually at /redfish/v1/Systems and /redfish/v1/Chassis. Open the collection and take elements from Members (there can be multiple).

Working traversal:

• GET /redfish/v1 and save links to Systems, Chassis, Managers, UpdateService (if present)
• GET each collection, then for each element follow Members[i][email protected]
• in each entity collect key fields and nested links to components (Storage, NetworkAdapters, Sensors, etc.)

2) Serial and model: compare System and Chassis

Often the serial and model are in the System object: SerialNumber, Model, Manufacturer, sometimes SKU and PartNumber. But sometimes chassis and system serials differ (e.g., a module in a chassis).

Practice: store both values and compare later.

• System: GET /redfish/v1/Systems/<id> -> SerialNumber, Model, UUID (if present)
• Chassis: GET /redfish/v1/Chassis/<id> -> SerialNumber, PartNumber, AssetTag

Different serials are not necessarily an error. The problem is silently overwriting a CMDB field with an unexpected source. Always record the source (which endpoint and field) when storing values.

3) Firmware: where to find BIOS, BMC and component versions

The most convenient case is when firmware inventory is supported: GET /redfish/v1/UpdateService/FirmwareInventory and follow Members. These records often include Version, SoftwareId or Id, and the component type.

If FirmwareInventory is absent, gather from multiple places:

• BIOS: /redfish/v1/Systems/<id>/Bios (or BIOS version in the System object)
• BMC: /redfish/v1/Managers/<id> (often a FirmwareVersion field)
• RAID and drives: /redfish/v1/Systems/<id>/Storage -> controllers -> Drives
• NIC: /redfish/v1/Systems/<id>/NetworkAdapters (if supported)

To distinguish "installed" vs "available," check that a field describes the installed version (for example Version in an inventory record). If you see two version fields, store both under different names and don't mix them.

4) Sensors: temperature, fans, power

Sensors are often under chassis: GET /redfish/v1/Chassis/<id>/Thermal and /redfish/v1/Chassis/<id>/Power. There are arrays like Temperatures, Fans, PowerSupplies.

Look at values and status: Status.State and Status.Health. Thresholds (min, max, critical) may be present and are useful to store so you know whether a "red" reading is truly critical for that model.

5) Collections, nested links and pagination

Redfish returns collections via Members. If there are many items (e.g., drives or events), pagination can appear. Check [email protected] and follow it until it disappears.

Data normalization: bringing everything to a single view

Normalization aims to ensure the same physical server looks like one object in the CMDB even when Redfish, the OS and other systems name it differently. Without that, inventory becomes a set of disconnected records.

One server — one "canonical" name

Choose an identification rule and apply it everywhere. A stable unique identifier plus a human-readable name usually works best.

Practical approach: keep separate fields for hostname (from the OS), AssetTag (inventory number) and the BMC name (as seen by the controller). Make the display name from a rule like <site>-<rack>-<unit> or use the AssetTag. Then a mismatch like System.Name=SRV-01 vs DNS srv01.prod.local won't break matching.

Consistent formats: dates, versions, units

Redfish may return dates in one format while the CMDB expects another, and firmware strings can look like "1.2.3 (Build 456)". Define rules in advance:

• store dates in ISO 8601 (2026-01-19T10:15:00Z) and optionally a date-only field
• store firmware versions both as the raw string and as a normalized version for comparisons
• convert sensor readings to standard units (temperature - C, power - W) and keep the original unit if it varies

Matching components and fields

For components (CPU, DIMM, PSU, drives, NICs) it matters not only "what it is" but "how to relate it over time." Minimum per component: PartNumber, SerialNumber, FirmwareVersion and a link to the parent server.

Common problem: one vendor uses SerialNumber, another SN, a third hides it in Oem. Implement a mapping layer (a lookup table) and populate canonical fields from prioritized sources.

Empty fields and deduplication

Store empty values as null rather than empty strings or "N/A". It's easier to validate and find missing data that way. If a component has no serial, use a temporary key (e.g., Redfish Id plus component type) but mark data quality.

To avoid duplicate servers, define a deduplication key. Often it's:

• System.UUID (if stable) or SerialNumber + Manufacturer + Model
• fallback to AssetTag
• and only then the hostname

Before upload, check: if the key matches — update the record; if not — create a new one and record source, collection time and data schema version.

Typical CMDB fields for servers and components

To keep records useful, the CMDB must answer: what is this server and what is its current state. Identification keys are most important: otherwise reimaging or replacing a controller produces duplicates.

Identification and server card

Usually 2–3 stable identifiers plus one business identifier are enough. Store all of them but choose a primary key for matching.

• Chassis serial number as the main physical identifier
• System UUID as an additional key
• Asset Tag or inventory number for accounting and internal processes
• Manufacturer and model for reporting and support rules
• Location and responsibility: site, rack, unit, owner, criticality, role (e.g., virtualization or DB)

Also record operational context: environment (prod/test), domain or cluster, deployment date and last check date. This distinguishes real changes from stale collections.

Components: what to track and at what level

Store components so it's clear what was replaced: a memory stick, a drive or the whole server. A common model is separate CIs for major parts (CPU, RAM, drives, RAID, NIC, PSUs, fans) with part-of relationships to the server.

Practical minimum per component: model, serial (if available), specs, slot/port/position, presence status and health. For drives store size, type, and bay position plus RAID membership.

Firmware, drivers and change history

Don't mix firmware records: keep current values for quick compliance checks and history for incident analysis.

A useful model:

• Current: BIOS/BMC, RAID/HBA firmware, NIC firmware, backplane version (if available)
• History: date, old version, new version, change source (maintenance, incident)
• Compliance policy: target version for each server type/role

States, alerts and risks

Store Health (OK/Warning/Critical) at server and subsystem levels (power, cooling, storage). Keep the "last alert" text and timestamp so you know not only the problem but its recency.

If you track risks, add EOL/EOS dates and a "at risk" flag. Then the CMDB becomes a planning tool: generating lists for firmware updates, drive replacements and decommissioning is easier.

Example: in a government environment an integrator might use the chassis serial as the main key and the asset tag as a required field for reporting. Replacing a drive or PSU updates linked components rather than creating a new server CI.

Exporting to the CMDB: format, schedule and quality control

After collecting via Redfish, export data so the CMDB updates records over time. A common mistake is creating new records each time. Decide matching keys in advance: e.g., serial + manufacturer or stable system UUID.

Export format: what to choose

JSON is convenient for nested structures (server -> PSUs -> sensors) and preserves data types. CSV is useful for quick checks: you can open it and see missing fields.

In practice, use both: JSON for CMDB import and a CSV summary with key fields (identifiers, model, manufacturer, BIOS/BMC/RAID versions, basic sensor statuses, timestamps).

Ensure predictable field names, units and value types.

Incremental uploads and schedule

Incremental updates reduce load and risk. Compare new values with the previous snapshot and update only changed fields. Store:

• last_seen (last successful collection)
• a hash/etag of the field set (to detect changes fast)
• source (Redfish endpoint, account/role)
• update status (created, updated, skipped)
• skip reason (no access, timeout, field missing)

Nightly collections are common when fewer changes occur. Heavy inventories (detailed component lists) are best run in maintenance windows. Add retries for failures: short retries for transient errors and a separate run for hosts that didn't respond.

Logs and quality control

Log context: requested URL, response code, field count and mapping applied. This is crucial in a mixed fleet.

Keep simple quality metrics: percent of key fields filled, list of exceptions (hosts not updated), and comparison with the previous export. If a server had firmware and 12 sensors yesterday and now shows 0, mark the record suspicious and don't overwrite old values without verification.

Example scenario: inventorying a small fleet

Twenty servers on two sites: 12 in the main DC and 8 in a secondary site. Vendors vary; BMC behavior differs: some return nearly everything, some name fields differently, and a couple have old BMC firmware.

Start with a "target map" — a simple table: node name, BMC IP/DNS, site, rack, unit and owner. Then poll Redfish and decide on the primary identifier. It's useful to store both SerialNumber (from hardware) and AssetTag (organization inventory). Many organizations use AssetTag as the main CMDB key because it can survive a system board replacement. If AssetTag is empty, temporarily use BMC IP + SerialNumber.

After normalization the record looks like a single object with tidy attributes: model, manufacturer, serial, UUID, list of NICs and MACs, CPU and RAM composition, drives, BIOS version, BMC version and basic sensors (temps, fans, power) with units.

Common findings: 1–2 servers where the Redfish serial doesn't match the sticker (often after board replacement), 3–5 machines with outdated BMC versions, and a "hot spot" in one rack (higher inlet temperature during peak hours).

Deliver two artifacts to stakeholders: CMDB export and a short data quality report. The report should list missing fields, identifier conflicts, firmware updates needed and racks to check for cooling.

Typical mistakes when collecting via Redfish and how to avoid them

Even if a script queries and receives responses, the CMDB often ends up "dirty." Below are common mistakes and remedies.

• Mixing up System and Chassis and getting different serials. Many servers have different system and chassis serials and both can be correct. Agree in advance which serial is the CI key and store the other as a separate field. Always record the source endpoint and field to explain discrepancies.

• Collecting sensors without units and later being unable to compare across models. Temperatures may come as plain numbers or values with units, sometimes with varying precision. Store both raw and normalized values. Normalize to one system (C, W, RPM) and store the unit separately.

• Ignoring permissions and getting "200 OK" without necessary fields. Some Redfish implementations respond successfully but hide details when permissions are insufficient. Check not only the status code but presence of critical fields. Maintain a small control set (SerialNumber, UUID, at least BIOS/BMC) and mark targets with missing values as "partial collection" and record the reason.

• Storing firmware versions as free text and losing comparability. Strings like "2.10", "2.9", "2.10a" sort poorly as text. Separate DisplayVersion (vendor text) and ComparableVersion (your normalized format). If semantic versioning is unclear, at least store an array of numeric parts plus suffix and don't overwrite the original string.

• Creating new records instead of updating due to wrong matching key. Duplicates often result from using IP or hostname, which can change. Use a stable identifier: UUID, system serial, or a combination (manufacturer + model + serial). In a heterogeneous fleet use a key hierarchy: UUID first, if absent — serial, if absent — AssetTag.

Practical test before full rollout: pick 2–3 different models, collect twice a day apart, and ensure the CMDB updates the same CI rather than creating new ones.

Quick checklist and next steps

Validate quality on a sample before uploading. This usually prevents polluting the CMDB and creating duplicates.

Quick pre-upload checks

• BMC reachable over HTTPS, credentials work, and hostname (if DNS used) resolves consistently.
• Serial, model, UUID and asset tag are filled and logically consistent (e.g., no identical UUIDs across different hosts).
• At minimum BIOS and BMC firmware collected and versions normalized.
• Sensors (temperature, power, fans) include units and statuses mapped to OK/Warning/Critical.
• Export contains one stable matching key for the CMDB (usually UUID or serial + manufacturer) independent of the host name.

If you find inconsistencies, record not just "what is wrong" but "how you fixed it." Example: a serial was missing due to old BMC firmware; after updating the field appeared and the CMDB entry was annotated with the fix date.

Next steps

Iterate in small steps rather than collecting the entire fleet at once.

• Run a pilot on 5 diverse servers to test field coverage.
• Approve the minimal required set for the CMDB (identifiers, basic firmware, sensor health) and update rules.
• Set a schedule: critical fields (sensor status) more frequently, firmware and inventory less often.
• Add quality controls: fill rate, duplicate detection, alerts on sudden UUID/serial changes.
• Document responsibilities: who manages BMC access, who resolves discrepancies, and how quickly CMDB updates after changes.

If you are planning server upgrades or accounting process changes, GSE.kz (gse.kz) as a system integrator can assist with server selection and CMDB integration, including support and maintenance setup.