Validation failing at it is showing Provisioning state from previous validation

Question

Validation failing at it is showing Provisioning state from previous validation

Akanksha 0

We retried the Azure Local validation after resolving the issues identified during the previous attempt. However, the validation log from the previous run appeared to be stuck at a particular stage, even though the Azure portal showed the validation as Failed.

We deleted the stuck log file and rebooted the nodes before initiating a new validation attempt. However, the new validation is now failing because the deployment settings resource is still in a Provisioning state from the previous validation attempt.

Could you please advise us on the appropriate way to clear or reset this stale provisioning state so that we can proceed with a fresh validation? We would like to avoid making any changes that could impact the existing deployment configuration.

Manasa Akula 770 Reputation points Microsoft External Staff Moderator

2026-09-10T02:23:33.9166667+00:00

Dear Akanksha,

Thank you for contacting Microsoft Support.

Thank you for sharing the details.

The new validation appears to be blocked because the previous validation operation did not fully clear its Azure-side deployment state. To avoid affecting the existing deployment configuration, please do not manually delete or modify the deployment settings resource.

If the previous validation created stale network-switch information, please follow the Microsoft-documented cleanup procedure below on the first Azure Local machine, and then restart validation from the Azure portal:

Microsoft Learn: Troubleshoot Azure Local deployment validation issues

Before proceeding, please confirm whether the current error includes an Edge Device, VM switch, or deployment settings already provisioning message. If it only reports that the deployment settings resource remains in Provisioning, please share Us the latest validation error in Message, timestamp, correlation ID, and deployment settings resource ID so that we can validate the backend state before any resource cleanup.

Thanks,

Manasa

1 answer

Your answer

Manasa Akula 770 Reputation points Microsoft External Staff Moderator

2026-09-10T02:23:33.9166667+00:00

Dear Akanksha,

Thank you for contacting Microsoft Support.

Thank you for sharing the details.

The new validation appears to be blocked because the previous validation operation did not fully clear its Azure-side deployment state. To avoid affecting the existing deployment configuration, please do not manually delete or modify the deployment settings resource.

If the previous validation created stale network-switch information, please follow the Microsoft-documented cleanup procedure below on the first Azure Local machine, and then restart validation from the Azure portal:

Microsoft Learn: Troubleshoot Azure Local deployment validation issues

Before proceeding, please confirm whether the current error includes an Edge Device, VM switch, or deployment settings already provisioning message. If it only reports that the deployment settings resource remains in Provisioning, please share Us the latest validation error in Message, timestamp, correlation ID, and deployment settings resource ID so that we can validate the backend state before any resource cleanup.

Thanks,

Manasa

Answer 1

For this Azure Local validation issue, the supported reset path is to clean up the stale validation artifacts on the first machine and then restart validation from the Azure portal.

Use this sequence:

Remove the Arc machine lock on the first machine
- In Azure portal, open the machine under Machines - Azure Arc or from the resource group.
- Go to Settings > Locks.
- Delete the DoNotDelete lock.
Check for and remove any unintended VM switch on the first machine
- Run:
```
     Get-VMSwitch
```
- If an unexpected validation-created switch exists, remove it:
```
     Remove-VMSwitch -Name "<VM Switch Name>" -Force
```
- Risk: removing the wrong switch can affect networking. Remove only the unintended validation-created switch.

Inspect the Azure edgeDevices resource for stale switch data

On a client with Azure CLI installed, sign in and select the subscription:

     az login --tenant <tenant ID> --use-device-code
     az account set --subscription "<Subscription ID>"

Show the resource:

     az resource show --ids "/subscriptions/<Subscription ID>/resourceGroups/<Resource Group Name>/providers/Microsoft.HybridCompute/machines/<Machine Name>/providers/Microsoft.AzureStackHCI/edgeDevices/default"

In the output, check for stale switchDetails, such as: "switchName": "ConvergedSwitch(managementcompute)", "switchType": "External"

Delete the stale edgeDevices resource so it can be refreshed

This deletion is documented as safe only when explicitly performing this remediation.

Run:

     az resource delete --ids "/subscriptions/<Subscription ID>/resourceGroups/<Resource Group Name>/providers/Microsoft.HybridCompute/machines/<Machine Name>/providers/Microsoft.AzureStackHCI/edgeDevices/default"

Verify deletion:

     az resource show --ids "/subscriptions/<Subscription ID>/resourceGroups/<Resource Group Name>/providers/Microsoft.HybridCompute/machines/<Machine Name>/providers/Microsoft.AzureStackHCI/edgeDevices/default"

Expected result: ResourceNotFound.

Refresh the cloud-side device data
- On the first machine, restart the service:
```
     Restart-Service DeviceManagementService
```
- Wait a few minutes, then verify the edgeDevices data is repopulated and no longer contains the unexpected switch information.
Restart validation from the Azure portal
- On the Basics tab, re-enter the deployment inputs by selecting the dropdown values again.
- Uncheck the nodes at the bottom of the page.
- Reselect and revalidate the nodes.
- On the Networking page, the earlier management virtual switch error should no longer appear.
- On the Validation page, the prior stale validation error should no longer appear.
- If validation completes, continue with deployment.
Recreate the lock on the first machine after remediation
- In Azure portal, go to Settings > Locks.
- Add a lock named DoNotDelete with lock type Delete.

Also avoid selecting Try again while validation tasks are still running, because that can produce inaccurate results in this release.

References: