Azure Advisor flags Batch account for Azure Disk Encryption retirement, but pools have no disk encryption configured. Is recreating the pool with a new VM size the correct remediation?

Daniel-4204 335 Reputation points
2026-10-02T20:02:35.5533333+00:00

Azure Advisor is showing the recommendation "Migrate Azure Batch Pools to VMs that support encryption at host" (Azure Disk Encryption retirement, 9/14/2028) against both of our Batch accounts. The Service Retirement workbook also lists our Batch accounts under the same ADE retirement.

Our setup:

  • Batch account in Batch service pool allocation mode (Azure-managed compute nodes, not user subscription mode)
  • Windows Server 2025 Datacenter Core pools, fixed size, VNet-integrated, no public IPs
  • Pool VM size: Standard_D2s_v3
  • diskEncryptionConfiguration on the pools are empty ({}), so no OsDisk or TemporaryDisk targets are set

The migration guide (Migrate from Azure Disk Encryption to encryption at host) covers standalone VMs and AVD host pools, but has no guidance for Batch pools, where we don't manage the underlying VMs or disks directly.

My questions:

  1. If diskEncryptionConfiguration is empty, is the pool actually using ADE, or is the recommendation triggered by something else, such as the VM size or the pool's encryption at host status?
  2. Is the correct remediation to create a new pool with a VM size that supports encryption at host and set virtualMachineConfiguration.securityProfile.encryptionAtHost to true?
  3. Since Dsv3 is also retiring on 15 November 2029, is there any reason not to move to a v5 or newer size (for example Standard_D2s_v5) as part of the same change?
  4. Pool VM size and encryption settings can't be updated in place. So if number 3 is true, I think we should delete the pools and recreating them with the same pool ID name? Many of our reports and queries reference the pool by name, so we'd like to keep it with out updating things downstream.
  5. Is registering the Microsoft.Compute/EncryptionAtHost feature on the subscription required for Batch service mode pools, given the nodes run in a Microsoft-managed subscription? I would assume no, since these are Microsoft Managed and not user.

Any clarification on the expected remediation path for Batch specifically would be appreciated.

User's image

Azure Batch
Azure Batch

An Azure service that provides cloud-scale job scheduling and compute management.

0 comments
Answer accepted by question author
Andriy Bilous 12,276 Reputation points MVP
2026-10-05T04:44:23.23+00:00

Hello Daniel-4204

Your diskEncryptionConfiguration: {} does not mean that ADE is enabled. It means you haven't configured the Batch disk-encryption targets through that property. The disks are still encrypted at rest by Azure's default storage encryption. diskEncryptionConfiguration.targets represents configuration intent, not a reliable indication of the actual encryption mechanism used underneath. (Microsoft Learn)

Recommendation itself is published against the Batch account and says to migrate Batch pools to VMs that support Encryption at Host; Microsoft does not publish the exact detection logic. So proof that your existing nodes are running ADE. (Microsoft Learn)

For your case, I would do this:

  1. Check whether the current SKU supports Encryption at Host. Microsoft exposes the VM capability EncryptionAtHostSupported=True. Do not assume D2s_v3 or D2s_v5 support based only on the family name; verify the specific SKU/region. (Microsoft Learn)
  2. If you are changing the pool anyway, moving off Standard_D2s_v3 now is sensible. Dv3/Dsv3 retire on 15 November 2029. Microsoft recommends v5 for the smoothest migration, while v6/v7 are the more current generations. (Microsoft Learn)
  3. You probably do not need to delete/recreate the pool. The current Batch Service API allows both vmSize and virtualMachineConfiguration to be changed when the pool has zero compute nodes. securityProfile.encryptionAtHost is part of that configuration. (Microsoft Learn)

So the preferred remediation is:

Drain jobs → scale pool to 0 → update vmSize + set securityProfile.encryptionAtHost=true → scale back up → validate.

Use the existing VM configuration when patching; the Batch API requires virtualMachineConfiguration for this update. This lets you keep the same pool ID, so reports and downstream references do not need to change. (Microsoft Learn)

For Microsoft.Compute/EncryptionAtHost registration: I would not register it pre-emptively for a Batch service-mode pool. Generic VM documentation requires registration in the subscription that owns the VM/VMSS, while Batch service allocation uses Batch-managed compute. If Batch returns an explicit feature-registration error, follow that error; otherwise it is not a documented prerequisite.

Finally, after reprovisioning the nodes with Encryption at Host, wait for the next Advisor refresh. If the recommendation still remains, open an Azure Support case and reference the Advisor recommendation ID 6c4cd580-41fb-4f20-977b-3be3cbead46e, because at that point the issue may be Advisor detection rather than the pool configuration. (Microsoft Learn)

Was this answer helpful?

1 person found this answer helpful.
0 comments

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

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.