Secure both File Sync resources before closing their public paths

Source facts

Azure File Sync communicates with two separate resources: the storage account holding the share and the Storage Sync Service coordinating synchronization. Each has its own network endpoints.

Storage accounts can restrict a public endpoint with service endpoints, but Storage Sync Service does not support that model. Its VNet restriction uses private endpoints. Microsoft requires creating a private endpoint before disabling its public endpoint, otherwise sync cannot work. Microsoft Learn.

Applicability

Inventory both resources, their endpoint configuration and the agent’s route and name-resolution path. Do not use a successful share connection as the only evidence that the coordination service remains reachable.

DSE recommendation

DSE recommends a two-resource network change record with separate readiness checks and rollback decisions. Establish and test the intended private path before removing public access. Coordinate storage, network and file-service owners, and preserve the prior endpoint settings for comparison. Keep the resource names explicit so an operator cannot mistakenly apply a storage-account procedure to Storage Sync Service.

Verification

From the approved agent location, check resolution and connectivity for each resource and perform a harmless end-to-end synchronization test. Compare behavior before and after the authorized public-access change. Verify the intended restricted path and investigate any fallback or coordination failure. Retain both endpoint configurations and the observed synchronization result before extending the change to additional deployments.

Official references

Microsoft Learn: Configure Azure File Sync network endpoints. Source retrieved September 9, 2026.