Before you begin
- Owner or Contributor on the resource group that holds the Atlas AVD app (the App Service named like atlasavd-app-…), and Network Contributor on the virtual network you will connect it to
- Permission to change the storage account's Networking settings
- A free address range of at least /28 (a /27 or /26 is recommended) in a virtual network that can reach the storage account
Why Atlas is blocked when the session hosts are not
Your session hosts mount the profile share over SMB from inside your virtual network, so a storage account set to Enabled from selected virtual networks and IP addresses, or to Disabled with a private endpoint, lets them through. Atlas is not a VM in that network. It runs as an Azure App Service in your subscription and reads the share over HTTPS (port 443) using the Azure Files REST API and the storage account key. Out of the box that request comes from the App Service's public outbound addresses, which your storage firewall does not allow, so Azure answers 403 AuthorizationFailure and Atlas reports the share as Unreachable.
Nothing is wrong with the profiles, and the session hosts are unaffected. Only Atlas's read-only view of the share is missing.
Atlas doesn't need a virtual network of its own
You don't build a separate network for Atlas. App Service has a feature called VNet integration that plugs the Atlas app into one small, empty subnet in a virtual network you already have, usually the one your session hosts or your private endpoints live in. Once it is connected, Atlas's traffic to your private addresses leaves from that subnet, and the storage account sees it exactly as it sees any other workload in your network.
VNet integration is outbound only. It does not put the Atlas website on your network or change who can sign in to it, and Atlas keeps reaching Azure, Microsoft Graph and the Atlas control plane over the internet as before.
Why not just add Atlas's outbound IP addresses to the storage firewall? Azure ignores storage firewall IP rules for requests that come from the same Azure region as the storage account, and Atlas is usually deployed in the same region as your session hosts and their storage. The IP rule saves without error but Atlas stays blocked. IP rules only work when the Atlas app is in a different region from the storage account; VNet integration works in every case.
Step 1: Create a subnet for Atlas
VNet integration needs a subnet that nothing else uses, delegated to App Service. It must be in a virtual network in the same Azure region as the Atlas app (App Service → Overview → Location). In the Azure portal open that virtual network, choose Subnets → + Subnet, give it a name such as snet-atlas-avd and a /27 address range, set Subnet delegation to Microsoft.Web/serverFarms, and under Service endpoints add Microsoft.Storage. Or run this in Cloud Shell:
az network vnet subnet create \
--resource-group <vnet-resource-group> \
--vnet-name <vnet-name> \
--name snet-atlas-avd \
--address-prefixes 10.10.5.0/27 \
--delegations Microsoft.Web/serverFarms \
--service-endpoints Microsoft.StorageIf the session hosts' virtual network is in a different region from the Atlas app, create a small virtual network in the Atlas app's region for this subnet and peer it with the network that holds the storage account's private endpoint, then follow Option B in Step 3.
Step 2: Connect the Atlas app to the subnet
In the Azure portal open the Atlas AVD App Service, go to Settings → Networking, and under Outbound traffic configuration click Virtual network integration → Add virtual network integration. Pick the virtual network and the snet-atlas-avd subnet and click Connect. Or:
az webapp vnet-integration add \
--resource-group <atlas-resource-group> \
--name <atlas-app-name> \
--vnet <vnet-resource-id> \
--subnet snet-atlas-avdYour Atlas App Service plan must be Basic (B1) or higher, which every Atlas deployment is. If your Atlas app has a staging slot, connect it too (add --slot staging) so the integration is in place whichever slot is serving. The integration is part of the App Service, so updating Atlas keeps it.
Step 3: Allow the subnet on the storage account
How you finish depends on how the storage account is locked down. Open the storage account and go to Security + networking → Networking to see which one you have.
Option A: Enabled from selected virtual networks and IP addresses
The storage firewall lists the virtual networks it trusts. Add the Atlas subnet to it.
- On the storage account's Networking page, under Virtual networks, click Add existing virtual network.
- Pick the virtual network and the snet-atlas-avd subnet. (If you skipped the service endpoint in Step 1, the portal offers to enable Microsoft.Storage on the subnet; accept it.)
- Click Add, then Save.
az storage account network-rule add \
--resource-group <storage-resource-group> \
--account-name <storage-account-name> \
--vnet-name <vnet-name> \
--subnet snet-atlas-avdOption B: Public network access disabled (private endpoint only)
Atlas reaches the private endpoint through the integrated subnet, just like a session host does. Traffic to private addresses is routed into your virtual network by default, so there is no route to add. What Atlas needs is to resolve the storage account's name to the private endpoint's address instead of its public one.
Open the private DNS zone your session hosts use for the file endpoint (privatelink.file.core.windows.net, or privatelink.file.core.usgovcloudapi.net in Azure Government) and, under Virtual network links, make sure the virtual network holding snet-atlas-avd is linked. If your network uses custom DNS servers (for example domain controllers that forward to Azure DNS), the Atlas app uses them automatically once it is integrated, so names resolve the same way they do for your session hosts.
az network private-dns link vnet create \
--resource-group <dns-zone-resource-group> \
--zone-name privatelink.file.core.windows.net \
--name atlas-avd-link \
--virtual-network <vnet-resource-id> \
--registration-enabled falseIf Atlas shows "Atlas couldn't resolve the FSLogix file server" instead of the network-rules message, the integration is working but the private DNS zone is not linked to the Atlas subnet's virtual network (or the custom DNS servers can't resolve it).
Step 4: Check it in Atlas
Network changes take a minute or two to apply. Open the user again under Entra → Users and click Retry on the FSLogix Profile card, or open Workspace → FSLogix → Profiles, select the host pool and click Scan sizes & orphans. The profile's size and last write appear and the Unreachable badge clears.
If it still doesn't load
- Still "blocked … by the storage account's network rules": check the storage firewall lists the snet-atlas-avd subnet itself (not only the session host subnet), and that the Atlas app's Networking page shows the integration as Connected. A rule that only adds Atlas's outbound IP addresses does not work from the same region (see above).
- "The storage account rejected the access key": the network path is fine, but the key Atlas holds is out of date. Update it on the host pool's FSLogix settings, or grant the Atlas app registration the Reader and Data Access role on the storage account so Atlas fetches the current key itself. Atlas reads the share with the account key, so Allow storage account key access must stay enabled on the storage account (Settings → Configuration).
- "The FSLogix storage account has no share named …": the share on the host pool's FSLogix settings must be the Azure Files share name only, not a folder inside it.
- Reading timed out: a network security group on snet-atlas-avd, or a firewall that the subnet's traffic is forced through, is dropping outbound TCP 443 to the storage account or its private endpoint. Allow it.
Atlas only reads the share to show profile details and sizes. It never needs SMB (port 445) and never mounts the share. Profile reset is the one action that changes the share, and it moves the old container aside rather than deleting it.