Logic App Standard to on‑prem file shares — no OPDG, no ASEv3

Goodbye (good riddance) to the On‑Prem Data Gateway (OPDG)

Logic App Standard workflows can use either managed or built‑in connectors. Historically, if you needed to access an on‑prem Windows file share, you had to use the File System managed connector with the OPDG — unless you were running in ASEv3. That guidance is now out of date: the built‑in File System connector works on Logic App Standard when the app is VNET‑integrated, without OPDG.

Why this matters:

• Simpler setup — no API connection resource with opaque parameters and no gateway footprint on‑prem.
• Lower complexity in ops — source/target locations are declared directly on the built‑in connection, easy to inspect.
• Cost clarity — built‑in actions run on your App Service Plan. Managed connectors are metered per action call and add an API connection resource.

Managed vs built‑in: how they differ

Key differences:

• Managed connector
  • Requires an API connection resource and (for on‑prem) the OPDG.
  • Per‑action billing applies; config lives outside the workflow.
• Built‑in connector
  • No API connection resource, no OPDG. Uses the app’s network path (VNET integration/ASEv3) to reach the SMB share.
  • Configuration (root folder, credentials) is part of the built‑in connection in the workflow.

How the built‑in File System connector actually works

The built‑in connector does not sync via an Azure Storage account or Azure Files as an intermediary. It connects directly to the target SMB share over the network path available to the Logic App Standard runtime. In practice that means:

• Your app must be Windows‑based, VNET‑integrated, and have line‑of‑sight to the file server’s FQDN/IP on TCP 445.
• DNS must resolve the FQDN you provide in the connection’s root path.
• You authenticate with domain\username and password that has share and NTFS permissions.

From the Microsoft reference for the built‑in File System connector:

• Expects FQDN in the root folder path; supports Windows file systems; mapped network drives aren’t supported; and the built‑in connector has a limit of up to 20 connections per Logic App resource. See “File System built‑in connector” docs.

Note: App‑level storage mounts (such as App Service “Azure Storage” mounts under azureStorageAccounts) are not required for the built‑in File System connector. Some teams still use mounts for other scenarios, but the built‑in connector itself can authenticate and access the UNC path directly when the network path is reachable.

Prerequisites and network checklist

• Logic App Standard (Windows) on an App Service Plan
• Private VNET integration into a subnet that can reach the file server
• DNS resolution for the file server’s FQDN
• Firewall/routes permit SMB (TCP 445) end‑to‑end
• Service account with correct share and NTFS permissions
• Recommended app settings:
  • WEBSITE_CONTENTOVERVNET=1 (when content or mounts are accessed over VNET)
  • Always On = true
  • FUNCTIONS_EXTENSION_VERSION = ~4
  • Workflows extension bundle configured

Creating the built‑in File System connection in a workflow

Provide these values when creating the connection (Built‑in > File System):

• Root folder: \fileserver.domain.local\ShareName
• Username: domain\svc_logicapp
• Password: your secret
• Mount path: optional (a logical path under the sandbox used by the connector; not a mapped drive)

Once connected, use triggers/actions such as “When files are added or modified”, “Get file content (V2)”, and “Create file”.

Limitations and tips (from the docs):

• Windows file systems only; mapped network drives aren’t supported
• Up to 20 connections per Logic App resource; no duplicate root paths with different credentials
• Prefer FQDN over short names

Why we prefer the built‑in connector over the on-premises data gateway

• Transparency: Source/destination paths and credentials are right in the connection you see in the workflow designer.
• Simpler ops: No separate API connection resource; no OPDG to install/maintain.
• Predictable cost: Runs on your App Service Plan compute rather than per‑action managed connector billing.

Deployment Woes

After studying the blog posts and video found in the references section of this post, I was able to configure a working PoC solution via the Azure Portal quite quickly. However, promoting this to a slick DevOps process was a major struggle!

The reason for this is that during deployment the logic app will attempt to reach its storage account. In order for smb file share mapping to work, the storage account needs to be private. This means that an A record for the ip address of the storage account is required in a private dns zone.

I hit a problem with sequencing which I was able to overvcome using the following:

1. The resources pipeline ran and created the private storage account that was open to external connections
2. The logic app pipeline ran to deloy the logic app the the workflows zip
3. The above pipeline then updated the config of the storage account to limit access to only connections from the private endpoint

References

• Great blog post from Tim D’haeyer: Bridging the gap: Azure Logic Apps meets on-prem fileshares

• Built‑in File System connector reference (Standard)
• “Connect to on‑premises file systems from workflows” overview
• Community updates confirming support on Logic App Standard with VNET (no ASEv3 required):
  • Using File System connector in Logic Apps Standard (original guidance mentioning ASEv3)
  • File Systems connector support on Workflow Standard plans (update)