Azure cluster deployment fails at Config storage step

Gopal Dogra (gdogra) 25 Reputation points
2025-12-02T03:26:17.1166667+00:00

While deploying Azure Kubernetes cluster, SBE package had a wrong Model defined in StorageDisks.xml file. Validation had passed successfully. But cluster deployment failed at the Config storage step.

After that, I have tried multiple things - updating StorageDisks.xml file with correct Model, rebooting server. But the Storage Subsystem remains unhealthy with Reason - Your solution vendor doesn't allow adding this model of drive to storage pool.

What can be done to help unblock this cluster deployment? How to re-trigger the health check for the Storage SubSystem?

Azure Arc
Azure Arc
A Microsoft cloud service that enables deployment of Azure services across hybrid and multicloud environments.
{count} votes

Answer accepted by question author
  1. Shraddha Pandey 540 Reputation points Microsoft External Staff Moderator
    2025-12-09T14:00:59.5666667+00:00

    Hi @Gopal Dogra (gdogra)

    This error usually means the cluster’s SBE “seed” content and the CSV copy no longer match what the deployment engine expects, often because of a manual/custom SBE drop or missing files in the SBE path.

    To resolve this, restore a clean and expected SBE payload and allow the deployment process to re-stage it, instead of using content manually copied to C:\SBE.

    • Stop the current deployment action plan so no further SBE steps run against the corrupted content.​
    • On the seed node, obtain the correct SBE package from the OEM/Microsoft‑provided source (for DataON, use the SBE download/manifest endpoint or OEM guidance) and extract it under the standard CloudDeployment path, not C:\SBE with custom edits.​
    • Delete or rename any existing content under C:\ClusterStorage\Infrastructure_1\Shares\SU1_Infrastructure_1\CloudMedia\SBE\Staged so that Metadata/Content will be freshly repopulated on the next run.

    Correct staging steps

    • Follow the documented “Later deployment” SBE flow: copy SBE from the extracted location (for example C:\CloudDeployment\ExtractedSBE or OEM‑documented equivalent) to the CSV path ...\CloudMedia\SBE\Staged using the provided scripts/workflow, not a manual folder copy or custom build.​
    • Ensure that once the ...\SBE\Staged\Content and ...\SBE\Staged\Metadata folders are populated on CSV, they are not modified; any edits or missing files will cause the integrity check (hash/manifest validation) to fail again.

    What to check if it still fails

    • Confirm on the seed node that the SBE you are deploying exactly matches the OEM version validated for your Azure Local/Azure Stack HCI build and hardware; mixing versions or editing files is unsupported and will trigger integrity failures.
    • If the integrity check still fails with a clean SBE package and fresh Staged folder, collect the metadata files from ...\SBE\Staged\Metadata and the cluster deployment logs, then open a support case; these files are specifically referenced in Microsoft’s Azure Local SBE troubleshooting guides for deeper triage.

    Documents:

    Please let me know if the steps above were helpful, or if you have any questions feel free to reach out to me.

    Thank You!

    1 person found this answer helpful.
    0 comments No comments

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.