Azure HPC Not Working, Diagnosed and Fixed (2026 Guide)

Why Azure HPC Is Not Working

You've submitted your Azure Batch job, the backbone of Azure HPC workloads, and nothing happens. Or worse, it crashes with an error code so cryptic it reads like a ransom note. I've seen this happen on everything from brand-new Batch pool deployments to production clusters that worked fine last Tuesday. The problem is almost never one thing. It's usually a chain of configuration decisions that made sense in isolation but break down the moment real compute pressure hits.

Let's be direct about what Azure HPC actually means in practice. Most Azure HPC setups run on Azure Batch, Microsoft's managed service for high-performance, large-scale parallel workloads. Whether you're running molecular dynamics simulations, financial risk models, or rendering pipelines, Batch is doing the heavy lifting. And Batch is deeply dependent on two other services: Azure Storage (for resource files, application packages, and output data) and Azure Virtual Networks (for node communication and security). When any one of those three legs wobbles, your entire HPC pipeline collapses.

The errors themselves don't help. ResourceContainerAccessDenied sounds like a permissions problem, and it is, technically, but the real cause is almost always a storage account firewall rule that doesn't account for how Batch routes its traffic. Then there are Azure Batch node creation delays, where your nodes sit in a "waiting" state for 20, 30, even 60 minutes before timing out entirely. That one's usually a Python package that's too large to install via start task, or a mismatch between your VM image generation (Gen1 vs Gen2) and the VM family you selected.

Enterprise teams running domain-joined clusters hit an additional layer of pain: managed identity configuration errors, subnet service endpoint gaps, and cross-region networking rules that silently drop traffic. The Azure portal gives you just enough visibility to know something is wrong, but rarely enough to pinpoint exactly why.

The good news? Every one of these issues is fixable. This guide walks you through the most common reasons Azure HPC is not working, from storage firewall misconfigurations to slow node provisioning, and gives you the exact steps to get your compute cluster running reliably. Browse all Microsoft fix guides →

The Quick Fix, Try This First

If your Azure HPC jobs are failing with an access denied error, specifically ResourceContainerAccessDenied on your Azure Blob containers, the fastest path to resolution depends on one key question: are your Batch pool and your storage account in the same Azure region?

Here's why that matters. When both are in the same region, traffic between your Batch nodes and the storage account travels over the Azure backbone network using private IP addresses, not public ones. That's actually good for performance. But it creates a nasty side effect: you cannot add private IP addresses to a storage account firewall allowlist. The firewall only accepts public IPs and subnet rules. So if your storage account has any firewall rules enabled at all, same-region Batch traffic gets silently dropped and you get ResourceContainerAccessDenied.

Same-region quick fix: Go to your storage account in the Azure portal → Networking → Firewalls and virtual networks. Switch Public network access to Enabled from selected virtual networks and IP addresses. Then add the subnet your Batch pool is running in. That's it. The traffic routes through the subnet's service endpoint instead of a public IP, which the firewall can actually evaluate and allow.

Cross-region quick fix: If your pool and storage account are in different regions, your Batch node traffic exits over the public internet. In that case, you need a static public IP address assigned to your Batch pool. Navigate to Azure portal → Batch Account → your Pool → Properties to find the current public IP. Then add that IP directly to your storage account's firewall allowlist under Networking → Firewall → Add your client IP address (or manually enter it).

One important caveat before you start: if you are uploading application packages to this storage account, neither fix above applies. Application package uploads require the storage account to have no firewall configured at all. Microsoft's documentation is explicit on this point, it's not a workaround, it's a hard requirement.

Advanced Troubleshooting

When the standard fixes don't resolve your Azure HPC not working situation, it's time to go deeper. These scenarios typically affect enterprise environments, domain-joined Batch accounts, or deployments with complex networking topology.

Managed Identity Configuration Failures

Azure Batch now supports managed identities as a way to authenticate to storage accounts without storing credentials anywhere. This is the right approach for enterprise HPC, but it introduces a new failure mode. If you've assigned a managed identity to your Batch account or pool but forgot to grant it the correct RBAC role on the storage account, you'll get access denied errors that look identical to firewall errors on the surface.

Check this in the Azure portal: Storage Account → Access Control (IAM) → Role assignments. Your Batch account's managed identity needs at minimum Storage Blob Data Contributor on any container it needs to write to, and Storage Blob Data Reader on containers it only reads from. If the role assignment is missing or scoped to the wrong level (e.g., container vs account level), Batch jobs will fail with access denied regardless of firewall settings.

Subnet Service Endpoint Propagation Delays

When you enable a Microsoft.Storage service endpoint on a subnet, Azure says it takes "up to 15 minutes." In practice, on subnets attached to large virtual networks with many route table entries, propagation can take closer to 25–30 minutes. If you're validating a fix and giving it exactly 15 minutes before concluding it didn't work, try waiting longer before reverting changes.

You can monitor service endpoint status via Azure CLI:

az network vnet subnet show \
  --resource-group yourRG \
  --vnet-name yourVNet \
  --name yourSubnet \
  --query "serviceEndpoints"

Look for "provisioningState": "Succeeded" on the Microsoft.Storage entry. If it says Updating, keep waiting.

Cross-Subscription Storage Account Access

Some enterprise HPC deployments use a storage account that lives in a different Azure subscription than the Batch account. In this scenario, virtual network rules work differently. The storage account's virtual network firewall can only reference virtual networks in the same subscription by default. Cross-subscription VNet rules require setting up resource provider registrations in both subscriptions and using the full resource ID format when adding the VNet rule.

Azure Batch Pool Deletion Failures

If an old pool is stuck in a Deleting state and blocking you from recreating it, this is usually caused by nodes that are still running jobs or are in a transitional state. You cannot delete a pool that has running tasks. Force-stop all tasks first via Jobs → [job] → Terminate, then wait 2–3 minutes before attempting pool deletion again. If the pool still won't delete, open a support ticket, forced pool deletion at the infrastructure level is not something the portal can always handle gracefully.

Event Log Analysis for Node-Level Failures

For Windows Batch nodes, RDP into a failed node (if it's still accessible) and check the Windows Event Viewer under Windows Logs → Application. Filter by Source = MicrosoftAzureBatch. Node agent events are verbose and will tell you exactly which command in your start task failed and why, including full paths and return codes that don't appear in the portal UI.

Prevention & Best Practices

Once you get Azure HPC working, the goal is to keep it working. The issues covered in this guide are almost entirely preventable with the right upfront architecture decisions. Here's what to put in place before your next deployment.

Co-locate Batch Accounts and Storage Accounts

Always create your Azure Batch account and its associated Azure Storage account in the same region. Yes, cross-region storage access is technically possible, but it routes over the public internet, requires static public IP management, and introduces latency into your HPC data pipeline. Same-region deployments use the Azure backbone and resolve the IP allowlist problem at the subnet level, which is far more maintainable at scale.

Build Custom Images, Not Heavy Start Tasks

Define a clear boundary: start tasks should handle configuration, not installation. If your start task takes more than 2–3 minutes on a clean node, you're doing too much there. Move application installation into a custom VM image using the managed image pipeline. This gives you faster node provisioning, reproducible environments, and eliminates an entire class of timeout-related failures.

Use Static Public IPs for Cross-Region Scenarios

If you genuinely need cross-region storage access, perhaps because your data lives in a specific region for compliance reasons, always assign a static public IP to your Batch pool at creation time. Never rely on dynamically assigned IPs and then try to keep the storage firewall allowlist current manually. That breaks every time you scale to zero and back out.

Validate Gen1 Compatibility Before Pool Creation

Before you create any Batch pool against a custom image, check the image's Hyper-V generation and cross-reference it against Microsoft's VM family compatibility list. H-series (HB, HC, HBv2, HBv3) and N-series (NC, ND, NV) are the VM families most commonly used in HPC workloads, and several of them only support Gen1 images. Catching this mismatch before pool creation saves hours of debugging.

Frequently Asked Questions