Auditing and Enforcing RDMA configuration on S2D hosts

Question

Auditing and Enforcing RDMA configuration on S2D hosts

Amira Hammid 20

Has anyone seen this behavior with S2D clusters where operating system updates reset RDMA settings on host network adapters, causing storage resynchronization to drop back to TCP speeds ?

Successfully verifies RDMA adapters using PowerShell.

Finds RDMA‑enabled interfaces.

Confirms SMB Direct traffic flow.

Re‑enables RDMA if disabled.

PowerShell logs show Get‑NetAdapterRdma returning Enabled and Enable‑NetAdapterRdma completing successfully.

Therefore, host‑to‑host RDMA communication appears to be restored.

Cluster synchronization resumes, SMB throughput returns to RDMA levels, but administrators may want to audit configuration regularly using scheduled PowerShell checks to prevent future fallback.

Is there a recommended method or script to continuously enforce RDMA settings across all nodes after updates ?

0 comments

Answer accepted by question author

Harry Phan 32,995 Independent Advisor

Hello Amira,

Yes, this is a known behavior with Storage Spaces Direct clusters. After cumulative updates or driver refreshes, RDMA can silently revert to disabled on NICs, which forces SMB traffic back to TCP. The fact that you’re seeing Get‑NetAdapterRdma return Enabled after manual intervention confirms the adapters themselves are fine, but the OS update cycle is resetting the configuration.

The recommended approach is to enforce RDMA consistently through automation. Microsoft’s best practice is to use a scheduled task that runs at startup and after patching, which validates and re‑applies RDMA settings if they’ve been reset. A PowerShell script can be deployed cluster‑wide via Group Policy or a configuration management tool like DSC. The script should enumerate all adapters with Get‑NetAdapterRdma, check for Enabled, and if any return Disabled, run Enable‑NetAdapterRdma -Name <AdapterName>. Logging the results to a central share or event log channel ensures administrators can audit compliance.

For continuous enforcement, Desired State Configuration (DSC) is the more robust option. You can define RDMA as part of the node’s desired network configuration and DSC will automatically remediate drift after updates. Alternatively, a lightweight scheduled task triggered by system startup or patch completion is sufficient if DSC isn’t in use.

One important note: ensure that the NIC firmware and drivers are always aligned with the supported versions for your S2D build. If RDMA keeps resetting even after enforcement, it may indicate that the update process is re‑installing NIC drivers, which can overwrite RDMA state. In that case, pinning driver versions or re‑applying vendor‑certified drivers post‑update is necessary.

So in short, the recommended method is either DSC enforcement or a scheduled PowerShell job across all nodes. Both approaches are supported and prevent SMB Direct from silently falling back to TCP after servicing events.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!HP.

Amira Hammid 20 Reputation points

2026-09-17T01:59:33.2066667+00:00

thanks harry it's very informative

1 additional answer

Your answer

Amira Hammid 20 Reputation points

2026-09-17T01:59:33.2066667+00:00

thanks harry it's very informative

Answer 1

A practical self-service approach is to audit RDMA state on every node and re-enable it when updates or driver changes reset it.

Use these checks:

Verify RDMA-capable adapters:

Get-NetAdapterRdma -Name "*"

Find adapters that still have RDMA enabled:

Get-NetAdapterRdma -Name "*" | Where-Object -FilterScript { $_.Enabled }

If an adapter is disabled, re-enable it:

Enable-NetAdapterRdma <name>

or:

Set-NetAdapterRdma -Name "<adapter name>" -Enabled $True

Enable-NetAdapterRdma is the preferred cmdlet for that operation.

If SMB Direct itself was disabled, re-enable it:

Enable-WindowsOptionalFeature -Online -FeatureName SMBDirect

If SMB Multichannel was disabled, re-enable it on both sides as needed:

Set-SmbServerConfiguration -EnableMultiChannel $true
Set-SmbClientConfiguration -EnableMultiChannel $true

If RDMA was disabled globally, re-enable Network Direct:

Set-NetOffloadGlobalSetting -NetworkDirect Enabled

Important points:

RDMA must be enabled on both the client and the server to be used again.
When RDMA is disabled on either side, the systems cannot use it.
SMB Direct is enabled by default, but once disabled it must be manually re-enabled.

For ongoing enforcement, the supported method in the available guidance is regular PowerShell auditing and re-enabling RDMA where needed after updates. The context supports using a validation checklist, but it does not provide a Microsoft-published continuous enforcement script or built-in policy mechanism for automatic remediation across all nodes.

A minimal audit/remediation pattern is:

Get-NetAdapterRdma -Name "*" |
Where-Object { -not $_.Enabled } |
ForEach-Object { Enable-NetAdapterRdma $_.Name }

Run that on each S2D host after OS, NIC driver, or firmware updates. Also verify SMB Direct state with:

Get-WindowsOptionalFeature -Online -FeatureName SMBDirect