A failed module has been removed from a two-bay server, and purchasing has found a candidate 1200w server power supply with a similar faceplate and the same nominal wattage as the surviving unit. The server must return to redundant operation, but a visual resemblance and a “1200 W” label are not sufficient authorization to insert the replacement. The qualification task is narrower and more demanding: determine whether that exact candidate can operate safely, communicate correctly, and carry the required load in the known chassis.
The most reliable sequence begins with evidence from the installed platform, not with the candidate’s headline rating. Record the original module identity, chassis configuration, firmware context, input environment, and present load. Then work inward from mechanical fit to electrical behavior and finally to a controlled operating test. This order prevents an apparently successful power-on from concealing an unsupported or non-redundant installation.
Freeze the Known Chassis Configuration First
Before removing another module or changing any settings, capture the server’s current state. Photograph the labels on the original PSU, both power bays, the AC inlet arrangement, and any visible chassis power-distribution markings. Export hardware inventory and management-controller event logs where the platform permits it. Record the installed CPU, accelerator, memory, storage, and fan configuration because platform power limits may depend on those components.
The documentation set should include the chassis service manual, supported-parts list, power configuration guide, and any field replacement instructions available from the platform manufacturer. The original PSU datasheet can clarify its output rails and environmental limits, but the chassis documentation remains authoritative for platform approval. A module supplier’s general compatibility statement cannot override a server manufacturer’s restrictions on power-bay revisions, firmware combinations, or supported system configurations.
Capture at least the following identifiers without abbreviating them:
- Chassis product family, exact configuration identifier, and hardware revision where shown.
- Original PSU manufacturer part number and platform spare or option number.
- Candidate module part number, revision, and complete input/output label data.
- Power backplane or distribution-board revision if it is accessible without prohibited disassembly.
- Management-controller and system firmware versions.
- Number of occupied PSU bays and the platform’s configured redundancy mode.
- Measured or reported system power under idle and representative production load.
Matching an original manufacturer part number or an explicitly listed platform spare provides stronger evidence than matching an industry form-factor description. CRPS conventions can standardize important mechanical and electrical features, but a CRPS designation alone does not establish that every latch, key, output contact, management behavior, and power limit matches the chassis.
Separate the Module Rating from the Chassis Power Permission
The 1200 W value normally describes a maximum DC output capability under stated conditions. It does not say that the module always draws 1200 W from the AC source, nor does it guarantee that the chassis permits all 1200 W to reach installed components. AC input is the energy entering the PSU. DC output is the regulated power delivered from the module to the server’s power architecture, with conversion losses and auxiliary consumption between them.
The platform may impose a lower usable ceiling because of power-distribution limits, thermal policy, firmware settings, component combinations, or the selected redundancy mode. A server could therefore recognize a 1200 W module while allowing less than 1200 W for workload operation. Conversely, software may report a high platform demand that the replacement is not approved to support under the site’s actual input or temperature conditions.
Build a small evidence table for the specific server rather than treating label wattage as the acceptance criterion.
| Question | Required evidence | Reason for rejection or escalation |
|---|---|---|
| Is the module approved for this chassis? | Platform parts list, service document, or written manufacturer confirmation | Only physical resemblance or generic CRPS compatibility is available |
| What output is permitted? | Platform power guide and configuration rules | The system configuration exceeds an approved limit |
| Under which input conditions is full output available? | Candidate label and official module documentation | The site input falls outside the supported range or invokes an undocumented limit |
| Can one module carry the required state? | Platform telemetry, load test, and redundancy policy | Single-module operation causes throttling, shutdown, or an unacceptable alarm state |
Suppose, purely as an illustrative assumption, that a server reports 760 W during its heaviest repeatable application test and briefly reaches 840 W during fan acceleration. A candidate marked 1200 W appears to have ample arithmetic headroom. Qualification still fails if the chassis documentation permits that candidate only with a different input condition, if the power backplane limits the supported configuration, or if removal of one module causes a platform power cap below the application’s requirement. The observed watts are one piece of the case, not the approval itself.
Perform the Unpowered Mechanical Examination
A forced insertion can damage a power bay before any electrical test begins. With the server in the maintenance state required by its service procedure, compare the original and candidate side by side. Do not use the chassis connector to test whether a questionable module “almost fits.”
Latches, guides, and insertion depth
Inspect the handle travel, retention latch, guide features, housing profile, and insertion stops. The latch must engage the chassis feature at the intended depth without unusual force or handle preload. A module that sits slightly proud may leave DC contacts or management pins only partially engaged. One that travels too far can place stress on the backplane connector.
Check bay keys and any coding features intended to prevent an incompatible module from entering. Never file, bend, remove, or defeat them. Such features may separate modules that look interchangeable but use different contact arrangements or platform generations.
Airflow must match the server’s cooling path
Confirm intake and exhaust direction from official markings or documentation. A reversed fan path can recirculate hot air, oppose the chassis fans, or deprive the PSU of its specified inlet conditions. Also compare vent locations after insertion: a matching airflow arrow does not help if a chassis wall blocks a candidate’s intake area.
Cooling qualification includes the operating environment. The module’s output capability may be conditional on inlet temperature, altitude, airflow, or other published limits. Qualification should use the manufacturer’s allowed operating envelope rather than an assumed derating curve. If the candidate documentation does not define the relevant limits, the missing information is a reason to pause.
Inspect the blind-mate interface without inferring a pinout
Compare the DC mating interface, contact blade positions, insulating barriers, connector shell, and alignment features. The objective is to establish documented equivalence, not to reverse-engineer an unidentified pinout from appearance. Contacts with similar dimensions may serve different rails or control functions.
Look for discoloration, pitting, bent contacts, debris, damaged guide pins, or heat deformation in both the module and bay. Replacing a failed PSU into a damaged backplane can reproduce the fault. If the original failure left thermal or arc evidence, the chassis power interface requires examination under the organization’s repair procedure before another module is inserted.
Map the Power and Management Expectations
The main output voltage is only part of the interface. Server PSUs commonly participate in startup sequencing, standby operation, presence detection, status reporting, fan control, fault signaling, and management communication. The exact implementation must come from documentation for the candidate and platform.
Compare all documented electrical functions:
- Main DC output rail or rails, including nominal voltage and allowed regulation behavior.
- Standby output required while the main server power state is off.
- Power-enable, power-good, presence, inhibit, or fault signals where applicable.
- Current-sharing or load-sharing behavior expected by the redundant power architecture.
- Management bus protocol, addressing rules, telemetry fields, and identification data.
- Hot-plug contact sequencing and any pre-charge or inrush-control provisions.
- Protection behavior for overcurrent, overvoltage, overtemperature, and input loss as documented.
A candidate can energize the server and still be unacceptable. For example, the management controller may classify it as unknown, fail to read temperature or output current, report a mismatch with the companion module, or command a conservative power limit. These are not merely cosmetic alerts when the platform uses PSU identity and telemetry in its cooling, redundancy, or power-capping policy.
Do not assume two modules from different revisions will share load correctly because each works alone. Some platforms permit mixed capacities or revisions under defined rules; others require an identical pair or a validated combination. Follow the chassis matrix. If no supported mixing rule exists, test results from a temporary mixed pair do not create one.
Confirm the Actual Input Envelope
Read the candidate’s complete input label and official documentation. Compare supported voltage, frequency, connector arrangement, and any conditions attached to maximum output with the power delivered at the rack. The comparison must use measured or facility-confirmed input conditions, not the nominal name of the electrical service.
The distinction between AC and DC is important during test interpretation. A rack power monitor reports AC input to the server or PDU outlet. PSU telemetry may report DC output. Those numbers should not be expected to match because the PSU consumes some input energy internally and the readings may have different accuracy, update intervals, and measurement boundaries.
If full rated DC output is available only within part of the documented input range, use the applicable value for the site. Do not invent a linear derating estimate between label points. The acceptable operating region is the one published by the manufacturer and approved by the platform vendor, including any temperature conditions.
Define the One-Module Requirement Before Testing Redundancy
In a conventional 1+1 redundant arrangement, both installed PSUs may share the normal load, but the failure state must be supported by one remaining module. The pair does not provide 2400 W of failover capacity merely because each module is rated 1200 W. For continued operation after one module is lost, the surviving unit and the platform must support the required system load by themselves.
The required state should be written before the swap test. It might be “complete the representative workload without shutdown or power throttling after either AC feed is removed,” or it might allow a documented performance cap. The acceptance condition depends on the service objective, but it cannot be left ambiguous until after an alarm appears.
Use a repeatable workload that covers the server’s relevant power behavior. For an accelerator server, that may require simultaneous CPU, accelerator, memory, storage, and cooling demand rather than a processor-only utility. For storage equipment, drive spin-up or rebuild activity may matter. Workloads and monitoring methods should be approved for the platform and should not deliberately exceed its published operating limits.
Return to the illustrative assumed values of 760 W sustained and 840 W transient. If the platform confirms that one candidate module can provide the required output under the actual input and environmental conditions, there is apparent capacity for the test. If telemetry shows 1,050 W under a more complete workload, the earlier 760 W observation was not representative. If the chassis enters a lower power state when redundancy is lost, acceptance depends on whether that state satisfies the predefined service requirement—not on whether the server merely stays powered.
Run a Staged Swap Instead of a Single Power-On
Use the chassis manufacturer’s replacement procedure and the site’s electrical safety and change-control rules. Hot insertion should occur only when the platform, module, and procedure explicitly support it. Otherwise, conduct the installation in the prescribed powered-down state.
Begin with the candidate installed and both approved input feeds present. Observe physical seating, latch engagement, fan behavior, status LEDs as defined by the manual, management inventory, input status, output telemetry, and event logs. Allow enough time for delayed inventory or mismatch events to appear. Do not clear warnings simply to create a clean dashboard.
Next, run the representative workload with both modules available. Compare sharing behavior only against the platform’s documented expectations; perfectly equal current is not a universal requirement. Watch for oscillating load, repeated PSU resets, fan surges, voltage alarms, power caps, or intermittent disappearance from management inventory.
The failover test should remove one approved source or module by the method specified for the chassis, while maintaining the controlled workload. Confirm that the remaining PSU accepts the load, the server stays within its permitted operating state, and the management controller reports the loss accurately. Repeat for the opposite side if the procedure and maintenance window allow it. This catches bay-specific faults, feed problems, and asymmetric behavior that a one-sided test can miss.
After restoring the pair, check whether redundancy status returns without a reboot, whether event severity is appropriate, and whether the candidate remains consistently identified. Review logs by timestamp rather than relying only on current green indicators. A transient communication loss or protection event may have cleared before the operator looked at the front panel.
Interpret the Result as Evidence, Not as a Compatibility Discovery
A clean swap test supports acceptance only when the candidate was already documented as permissible and every relevant boundary was exercised. Successful booting establishes little by itself. Even a completed load test cannot prove long-term compatibility if the module is absent from the platform’s approved configuration or if the test never reached the required one-module state.
Classify unexpected results before making another attempt. A mechanical seating problem is not corrected with additional insertion force. An “unknown PSU” event points toward identity, firmware, management-bus, or approval issues. Shutdown during source removal may indicate excess load, unsupported input, failed sharing, a bay fault, or a platform policy response. Investigate from logs and documented limits rather than swapping variables at random.
Approve the replacement only if its identity is authorized for the known chassis, its mechanical and airflow interfaces match, its documented rails and controls satisfy the power backplane, the site input supports the required DC output, and either module can sustain the predefined failover workload without prohibited throttling or fault behavior. If the server operates normally with both modules but cannot meet that single-module condition, the candidate may power the chassis, yet it has not qualified for the required 1+1 service and should not be released as the redundant replacement.
