We operate two HPE Primera C650 arrays that are still in production while migration to replacement systems is underway. Recently, every PCBM battery on both arrays simultaneously changed to Degraded / Expired.
The batteries still show roughly 97% charge and FullyCharged status. They have different serial numbers and reportedly came from different production runs, yet all display the same expiration date. Both arrays entered the degraded state at the same time, and we are seeing a performance impact.
This seems more like a software-enforced lifecycle limit than a conventional battery failure. We understand that redundancy protects against individual random failures, not necessarily against components reaching a shared age limit. However, the concern is that the PCBMs were not physically failing: the system appears to have marked them expired based on a vendor-defined date. Once both modules are expired, write-cache protection or cache use can be restricted, with real performance and resilience consequences.
The arrays were under active support for about five years and continuously sent telemetry. We were not aware that all the PCBMs were approaching the same expiration date, and HPE support has indicated that a paid engagement is required to explain the underlying mechanism.
Has anyone seen this behavior on Primera or older 3PAR systems? Is simultaneous expiration an expected lifecycle behavior, and are there reliable ways to receive advance warnings or avoid all redundant modules reaching that state together?
2 Answers
The likely distinction is between battery health and the product's service-life timer. A battery can report nearly full charge and still be considered expired because the controller is enforcing a predefined lifecycle date. Redundancy protects against one module failing unexpectedly; it does not automatically protect against every module sharing the same installation or lifecycle schedule.
That said, identical expiration dates across modules with different serial numbers and production histories are a legitimate concern. If the date is assigned or calculated by the storage software, then the event is a coordinated software state change rather than evidence that every battery physically failed at once. Because expired PCBMs can affect persistent write-cache protection and performance, this should be treated as an operational lifecycle issue, not merely a cosmetic alert. The key questions for HPE are how the date is calculated, when warnings are generated, and whether the modules can be deliberately staggered or replaced before the common deadline.
I saw advance warnings roughly a month before expiration. Replacing the batteries can take some planning because availability may be limited, and the platform may restrict how many can be replaced on an array within a 24- or 48-hour period. It is worth checking the array's health alerts, telemetry notifications, and support-case history rather than relying only on the current battery charge percentage.
Which array model was that, and where did the advance warnings appear? In our case, neither we nor our support partner noticed a useful warning before the simultaneous expiration.
That is the distinction we are trying to clarify. We agree that redundancy does not protect against a shared wear-out date, but the important issue is that healthy-looking modules from different production runs were all moved into an impactful expired state together. A five-year support and telemetry history should ideally have produced a clear, actionable warning well before that happened.