Storage Firewall Troubleshooting

Troubleshooting → Storage Firewall Troubleshooting

This page is for administrators whose importer can't reach the solution's storage account, typically after a storage firewall was tightened by hand or by Azure Policy. It explains the symptoms, what breaks, why allow-listing IP addresses doesn't help, and the supported fixes.

Storage firewall blocks the importer (403 AuthorizationFailure)

The solution's storage account does more than hold files. Its Table service holds:

• the audit-import checkpoint, which records the audit content blobs already imported;
• the AnalyticsState table, which holds the importer's runtime state. That includes the Graph delta tokens (among them the user import's /users/delta checkpoint), the "last run" stamps that pace the periodic imports, and the Teams deep-analytics authorisations.

If the storage account's network rules stop the App Service reaching that Table endpoint, the importer keeps running but degrades. On a public install (no private endpoints), the usual cause is a storage firewall that was tightened after the install, often by Azure Policy or a security baseline. Either of these settings does it:

• Public network access → Enabled from selected virtual networks and IP addresses (the firewall's default action is Deny);
• Public network access → Disabled.

Symptoms

Search the importer's log (Application Insights traces or the WebJob log) for these lines:

Blob checkpoint: could not initialise the Azure Table store (RequestFailedException: This request is not authorized to perform this operation. ...). Storage firewall/network rules rejected the Table checkpoint request (HTTP 403 AuthorizationFailure). ... falling back to in-memory ...

User delta token store is unavailable and this process has no last committed checkpoint. Deferring user metadata/licence import rather than treating the outage as a cache miss and starting a full tenant crawl.

Import cadence: state store read failed for '...' (...); treating as not-yet-run so the import proceeds.

In the web portal, Administration → Service health shows the BlobCheckpoint component under Component health as Degraded: "The audit blob checkpoint is degraded because the storage account firewall rejected the Table request (HTTP 403 AuthorizationFailure)…".

What it breaks

Affected	What you see
Audit-import checkpoint	Falls back to an in-memory checkpoint. That checkpoint is lost on every WebJob restart or redeploy, so the importer downloads and parses the whole audit lookback window again each time. The repair that recovers metadata after an interrupted save is also switched off.
User and licence import	Deferred every cycle, deliberately. Without its checkpoint the import would otherwise start a full crawl of the tenant, so users, licences and the Graph imports that follow them stop updating.
Import pacing	The "last run" stamps can't be read, so the periodic imports run as if they had never run, i.e. more often than scheduled.
Teams deep analytics	Teams can't be authorised, and stored authorisations can't be read.

AuthorizationFailure is a network block, not a credential problem

A 403 looks like a permissions problem, but Azure Storage's error code tells you which kind it is:

ErrorCode	Meaning	Fix
AuthorizationFailure	The storage account's network rules rejected the request	This section
AuthorizationPermissionMismatch	The request got through, but the runtime identity lacks the data-plane role	Grant the runtime app registration Storage Table Data Contributor on the storage account. Storage Blob Data Contributor does not cover tables.
AuthenticationFailed	The key or credential was rejected	Check the Storage connection string, or the runtime app registration's secret
KeyBasedAuthenticationNotPermitted	Shared-key access is disabled on the account	Nothing, as long as the runtime identity has Storage Table Data Contributor: the importer switches to Entra ID (RBAC) automatically

Why allow-listing the App Service IP addresses doesn't fix it

The installer creates the App Service and the storage account in the same Azure region, and Azure Storage ignores IP rules for traffic from its own region:

"IP network rules have no effect on requests that originate from the same Azure region as the storage account. Use virtual network rules to allow same-region requests." — Azure Storage firewall: guidelines and limitations

So adding the App Service's outbound addresses to the storage firewall changes nothing. Same-region requests are matched by virtual-network rules only.

Supported configurations

Deployment	Storage networking that works
Public install	Public network access Enabled from all networks.
Private install (the installer's private networking)	Private endpoints for both the blob and the table sub-resources, with their privatelink.blob.core.windows.net and privatelink.table.core.windows.net DNS zones. Installers before build 1716 didn't create the table endpoint, so re-run the installer to add it to an older private deployment.
Locked-down public install (custom)	App Service VNet integration, with a subnet that has a Microsoft.Storage service endpoint, and a storage-account virtual-network rule for that subnet.

How to fix

1. In the Azure portal, open the solution's storage account, then Networking.

2. Public install: set Public network access to Enabled from all networks and save. If Azure Policy reverts it, raise a policy exemption for this storage account, or move to one of the stricter configurations above.

3. Stricter networking required: move the deployment to the installer's private networking (re-run the installer with private networking enabled), or set up VNet integration with a Microsoft.Storage service endpoint.

4. Run Test Configuration in the installer. On a public install it now warns, before anything degrades, when the storage firewall will block the importer:

   Storage account network rules will block the importer's Table storage because the storage firewall default action is Deny ('Enabled from selected virtual networks and IP addresses'). ...
   

   Re-run it after your change and confirm the warning has gone.

5. Restart the Office365ActivityImporter WebJob, so it opens the durable checkpoint and the state table again. When it starts, the importer logs Blob checkpoint: durable Azure Table store initialised (processed blobs persist across restarts)., and the BlobCheckpoint component on Service health goes back to Healthy ("Durable Azure Table checkpoint active.").

The installer never loosens your storage firewall for you. When it finds public network access Disabled, or a firewall default action of Deny, it logs a warning and leaves the setting alone ("The installer will not re-enable it automatically" / "The installer will not change the storage firewall rules automatically"), because that setting is often deliberate and enforced by policy.

---

Return to Troubleshooting · All topics in this guide

Previous: Web Portal Troubleshooting · Next: SQL Upgrade Troubleshooting