resolving SES enclosure mapping failure on SAS JBOD in S2D via PowerShell

Question

resolving SES enclosure mapping failure on SAS JBOD in S2D via PowerShell

Liam Wilson 20

Hello,

I have a question about fixing storage enclosure awareness mapping after upgrading firmware for our company. So we're using external SAS JBOD enclosures that comes with our clustered nodes, which is deployed in a Storage Spaces Direct (S2D) environment. I want to update and maintain the expander firmware so that we can use enclosure-level fault tolerance and accurate disk location tracking across the cluster. However, after applying the firmware update, all physical disks report their enclosure status as unknown, and when I researched and surveyed solutions from hardware vendor forums, I saw that they all quoted using the complete storage pool recreation method or the full cluster restart or physical shelf power-cycling options.

I've seen some posts about refreshing enclosure awareness through the PowerShell SCSI Enclosure Services (SES) re-binding process, but I don't quite understand it. The requirements seem pretty simple, for example, having the storage subsystem re-scanned and disk mapping updated. I'm not sure if there's any difference in re-querying the SES topology from Update-StorageProviderCache versus triggering specific WMI/CIM methods on the storage management provider.

We are using Windows Server 2022 Datacenter running Storage Spaces Direct (S2D) connected to redundant SAS JBOD storage enclosures.

0 comments

1 answer

Your answer

Answer 1

Hello @Liam Wilson

There’s an important issue with this configuration before trying to force an SES rebind with PowerShell.

For Windows Server 2022 Storage Spaces Direct, Microsoft supports external SAS JBOD only when the enclosure is directly attached to one server. Microsoft explicitly states that shared SAS enclosures connected to multiple servers, or configurations where drives are accessible through multiple paths/MPIO, aren't supported for S2D.

SES is required for supported external JBOD configurations because Windows uses it for enclosure identification and physical slot mapping, and each enclosure must expose a unique identifier.

If your JBODs meet that supported topology and the problem is only stale discovery information after the firmware update, you can safely start with a storage-provider rediscovery:

Update-StorageProviderCache -DiscoveryLevel Full
Get-StorageEnclosure
Get-PhysicalDisk |
    Format-Table FriendlyName,SerialNumber,HealthStatus,
                 OperationalStatus,EnclosureNumber,SlotNumber

Update-StorageProviderCache -DiscoveryLevel Full instructs the storage provider to rescan associated physical disks and refresh reported state. Microsoft also warns that a full discovery can take considerable time in larger environments.

I wouldn't use undocumented WMI/CIM calls to manually rewrite enclosure associations. The enclosure/slot information ultimately comes from the HBA, enclosure SES implementation, firmware and Windows storage provider; PowerShell isn't intended to manufacture that topology when SES discovery itself is failing.

Since this began immediately after an expander firmware update, I would also verify that:

Get-StorageEnclosure still returns each enclosure with a unique identity.
EnclosureNumber and SlotNumber are populated for the SAS disks.
The HBA is operating in simple pass-through/HBA mode.
The enclosure/HBA firmware combination is supported by the hardware vendor.
Test-Cluster storage validation completes successfully.

Microsoft specifically recommends validated hardware and requires the complete S2D configuration to pass cluster validation.

If Get-StorageEnclosure remains missing/unknown after a full provider refresh, I wouldn't recreate the pool just to repair the mapping. At that point this is more likely an SES/HBA/expander firmware discovery problem, and I'd involve the JBOD/HBA vendor before making changes to the S2D pool.

One other point: if by “redundant SAS JBOD” you mean that the same enclosure/drives are SAS-connected to multiple S2D nodes, that topology itself needs to be revisited because Microsoft documents shared SAS/MPIO as unsupported for Storage Spaces Direct.

Sharing with you these references:

Microsoft Learn – Storage Spaces Direct hardware requirements

Microsoft Learn – Update-StorageProviderCache

Microsoft Learn – Deploy Storage Spaces Direct

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.