Provision Azure VM with SQL Server Fails

Question

Provision Azure VM with SQL Server Fails

Alan Whitehouse 45

I have tried 4 times now to provision an Azure VM (from the market place) that has SQL Server on it. I have tried different combinations of Regions and Zones (all US regions). Each time the SQL Server portion of the provisioning failed. I tried 2 different VMs as well (Windows 2022 and SQL 2022 vs. Windows 2025 and SQL 2025)

In the json I see:

"properties": {
        "statusMessage": "{\"status\":\"Failed\",\"error\":{\"code\":\"ResourceOperationFailure\",\"message\":\"The resource operation completed with terminal provisioning state 'Failed'.\",\"details\":[{\"code\":\"Ext_StorageConfigurationSettings_ApplyNewTempDbSettingsError\",\"message\":\"Error: 'System Drive returned status not ready for use '\"}]}}",
        "eventCategory": "Administrative",

Any idea what is going on here?

Alan Whitehouse 45 Reputation points

2026-04-23T21:59:55.6+00:00

I was attempting to setup an E8ads_v6. Test box so was just taking the defaults for drive locations.
Manoj Kumar Boyini 19,590 Reputation points Microsoft External Staff Moderator

2026-04-23T22:06:04.3966667+00:00
Hi @Alan Whitehouse

Since you're using E8ads_v6 with default settings, the deployment is attempting to place TempDB on the local NVMe SSD by default. On this VM series, that disk is not initialized at the time of provisioning, which leads to the failure you’re encountering.

To resolve this, you can:

During deployment, go to SQL Server settings → Storage configuration → Change configuration and set TempDB to use the OS disk or a data disk instead of “local SSD”

Alternatively, deploy using E8as_v6, and then resize to E8ads_v6 after the VM is created

Either of these approaches should allow the deployment to complete successfully.
Alan Whitehouse 45 Reputation points

2026-04-23T22:13:55.5466667+00:00

Is there a unique process I need to follow to move the tempdb to the nvme drive after the provisioning is done if I do either of the above choices? Or would it just be like any other database location move?
Manoj Kumar Boyini 19,590 Reputation points Microsoft External Staff Moderator

2026-04-24T20:31:12.63+00:00

Hi @Alan Whitehouse

Moving TempDB to the NVMe (ephemeral) disk is the same as any standard SQL Server move (using ALTER DATABASE + restart).

In fact, placing TempDB on ephemeral storage is a recommended best practice for better performance.

Documentation: https://learn.microsoft.com/azure/azure-sql/virtual-machines/windows/tempdb-ephemeral-storage
Alan Whitehouse 45 Reputation points

2026-04-25T13:41:34.8+00:00

Thanks. I just wanted to make sure that moving to an ephermeral storage after initial creation didn't require anything special or unique.
Manoj Kumar Boyini 19,590 Reputation points Microsoft External Staff Moderator

2026-04-27T18:51:44.1+00:00
Hi @Alan Whitehouse

There’s nothing unique about the SQL Server operation itself. Moving TempDB to the NVMe (ephemeral) disk is done using the standard SQL Server method (ALTER DATABASE + restart).

The only additional consideration comes from the nature of ephemeral storage, not the move itself.

Because the NVMe disk is temporary (non-persistent) in Azure:

Its contents are cleared on VM stop/deallocate or host move

The disk may come back without the folder structure

Permissions may need to be reapplied

So in practice, the only “extra” step is to ensure that after a restart:

The TempDB folder exists

The SQL Server service account has permissions on that folder

Please let us know if you have any questions or concerns.
Manoj Kumar Boyini 19,590 Reputation points Microsoft External Staff Moderator

2026-04-28T18:59:50.3433333+00:00

Hi @Alan Whitehouse

Just checking in to see if the information provided earlier was helpful. Please let us know if you need any additional details or assistance, and we’ll gladly continue supporting you.
Santhosh Kumar Machukuri 0 Reputation points Microsoft External Staff Moderator

2026-05-02T00:11:10.3633333+00:00

Hi @Alan Whitehouse

I hope you are doing well. Please consider this as a follow up, let us know If the response shared by earlier engineer Manoj Kumar Boyini, helped. If it doesn't work, feel free to let us know.

1 answer

Your answer

Alan Whitehouse 45 Reputation points

2026-04-23T21:59:55.6+00:00

I was attempting to setup an E8ads_v6. Test box so was just taking the defaults for drive locations.
Manoj Kumar Boyini 19,590 Reputation points Microsoft External Staff Moderator

2026-04-23T22:06:04.3966667+00:00

Hi @Alan Whitehouse

Since you're using E8ads_v6 with default settings, the deployment is attempting to place TempDB on the local NVMe SSD by default. On this VM series, that disk is not initialized at the time of provisioning, which leads to the failure you’re encountering.

To resolve this, you can:

During deployment, go to SQL Server settings → Storage configuration → Change configuration and set TempDB to use the OS disk or a data disk instead of “local SSD”

Alternatively, deploy using E8as_v6, and then resize to E8ads_v6 after the VM is created

Either of these approaches should allow the deployment to complete successfully.
Alan Whitehouse 45 Reputation points

2026-04-23T22:13:55.5466667+00:00

Is there a unique process I need to follow to move the tempdb to the nvme drive after the provisioning is done if I do either of the above choices? Or would it just be like any other database location move?
Manoj Kumar Boyini 19,590 Reputation points Microsoft External Staff Moderator

2026-04-24T20:31:12.63+00:00

Hi @Alan Whitehouse

Moving TempDB to the NVMe (ephemeral) disk is the same as any standard SQL Server move (using ALTER DATABASE + restart).

In fact, placing TempDB on ephemeral storage is a recommended best practice for better performance.

Documentation: https://learn.microsoft.com/azure/azure-sql/virtual-machines/windows/tempdb-ephemeral-storage
Alan Whitehouse 45 Reputation points

2026-04-25T13:41:34.8+00:00

Thanks. I just wanted to make sure that moving to an ephermeral storage after initial creation didn't require anything special or unique.
Manoj Kumar Boyini 19,590 Reputation points Microsoft External Staff Moderator

2026-04-27T18:51:44.1+00:00

Hi @Alan Whitehouse

There’s nothing unique about the SQL Server operation itself. Moving TempDB to the NVMe (ephemeral) disk is done using the standard SQL Server method (ALTER DATABASE + restart).

The only additional consideration comes from the nature of ephemeral storage, not the move itself.

Because the NVMe disk is temporary (non-persistent) in Azure:

Its contents are cleared on VM stop/deallocate or host move

The disk may come back without the folder structure

Permissions may need to be reapplied

So in practice, the only “extra” step is to ensure that after a restart:

The TempDB folder exists

The SQL Server service account has permissions on that folder

Please let us know if you have any questions or concerns.
Manoj Kumar Boyini 19,590 Reputation points Microsoft External Staff Moderator

2026-04-28T18:59:50.3433333+00:00

Hi @Alan Whitehouse

Just checking in to see if the information provided earlier was helpful. Please let us know if you need any additional details or assistance, and we’ll gladly continue supporting you.
Santhosh Kumar Machukuri 0 Reputation points Microsoft External Staff Moderator

2026-05-02T00:11:10.3633333+00:00

Hi @Alan Whitehouse

I hope you are doing well. Please consider this as a follow up, let us know If the response shared by earlier engineer Manoj Kumar Boyini, helped. If it doesn't work, feel free to let us know.

Answer 1

Hi @Alan Whitehouse

This issue typically occurs with newer VM SKUs (especially those with a lowercase “d”, such as Ddsv6, FXmdsv2, E8ads_v6). These SKUs expose a raw NVMe local SSD, and during provisioning the SQL IaaS extension attempts to place TempDB on it before the disk is initialized, which causes the deployment to fail

We observed the same behavior. After deleting the failed deployment and recreating the VM with an updated TempDB configuration (placing it on a different disk instead of local SSD), the deployment completed successfully and the VM came up healthy.

Workarounds:

Use a VM size without the “d/ads” suffix so TempDB is placed on a ready disk
Change TempDB location during deployment (avoid “Use local SSD”)
As an alternative workaround, deploy using a non-local disk SKU (e.g., E8as_v6) and then resize to E8ads_v6 after deployment
If local SSD is required, deploy a Windows-only VM, initialize the disk, and then install SQL Server manually

Could you please confirm:

Which VM size you are currently using?
Whether TempDB was left as default or customized during deployment?

Reference:
https://learn.microsoft.com/troubleshoot/sql/azure-sql/sql-deployment-fails-drive-not-ready
https://learn.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/tempdb-ephemeral-storage?view=azuresql
https://learn.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/performance-guidelines-best-practices-vm-size?view=azuresql#ebdsv5-series

Hope this helps, Please let us know if you have any questions and concerns.