Forum Discussion
Copy activity fails with workspace level private link enabled (Error getting outbound access policy)
Hi,
In our Fabric environment we've set up Workspace level Private link according the setup documentation. We are only able to access the workspace from our VPN, so the setup seems succesful.
When i run a copy activity in a data pipeline i get the following error:
Error occured while trying to get workspace outbound access policies. Please retry later. Detailed Message: 'StatusCode: Forbidden, WorkspaceId: ****, ArtifactId: , Error Code: , Message: , Request ID: , Content: '
Below some more details about our setup and what i've tried
This error occurs even when we try to copy data from and to a lakehouse within the same workspace. (only internal resources)
We've also whitelisted the urls on this page. I've verified for some endpoints in both a notebook and pipeline that the endpoints are accessible (though i get unauthorized errors).
We have not enabled outbound access protection or tenant level private link.
I am running the pipeline as workspace admin. When running even as fabric admin it still does not work.
Copy jobs give the same error.
When workspace level private link is disabled, the pipeline works again. Enabling it causes the pipeline to fail again.
I am at a loss for how to solve this issue. I can not find any documentation or forum posts on this error. Any help would be appreciated.
Hi all,
I've had contact with Microsoft support, and they have provided me with a solution for this issue. It appears to be a bug in the current copy data activity, for which they are currently developing a new version.
For now you can work around this issue by, in the destination settings, selecting a lakehouse connection from the dropdown instead of clicking 'browse all' and then selecting your lakehouse from the catalog. (see image)
Why this solves the issue i'm not sure, but i think that in this way the UI registers that it should use the connection instead of direct lakehouse access. Microsoft is aware of the issue and a more complete fix is on its way.
6 Replies
Hi FabricConsult ,
Thank you for reaching out to the Microsoft Fabric Forum Community, and special thanks to deborshi_nag for prompt and helpful response.
If the issue still persists, I’d recommend raising a support ticket with Microsoft. The support team can look into the backend and provide more in-depth assistance tailored to your environment.
https://learn.microsoft.com/en-us/power-bi/support/create-support-ticketThanks & Regards,
Prasanna Kumar
I'm on a same boat as you (perhaps with some minor differences).
Both secured workspaces have inbound networking policies enabled (with PE), lakehouses in secured workspaces created via api, gateway is configured and works (semantic model sitting in unsecured workspace can pull data from both secured workspaces with proper global connection configuration {same connection is attempted to be used for pipeline} like .zxx.datawarehouse.. endpoint adjustments, etc., incl. connection binding to gateway).
Topology looks like this
LakeHouseInSecuredWorkspaceA - > CopyDataPipelineInSecuredWorkspaceB - > LakeHouseInSecuredWorkspaceB
When trying to execute pipeline - getting the same error as yours.
Will have to ask how our PE are configured and will probably explore adding ip/address configurations (new option has appeared recently at the bottom of Inbound networking section) for additional whitelisting.
Sadly Fabric pipeline implementation is much more limited vs ADF in this context as it does not allow to select IR to shortcut VNet directly for pipeline activity therefore connectivity configuration becomes non-existent.Hi all,
I've had contact with Microsoft support, and they have provided me with a solution for this issue. It appears to be a bug in the current copy data activity, for which they are currently developing a new version.
For now you can work around this issue by, in the destination settings, selecting a lakehouse connection from the dropdown instead of clicking 'browse all' and then selecting your lakehouse from the catalog. (see image)
Why this solves the issue i'm not sure, but i think that in this way the UI registers that it should use the connection instead of direct lakehouse access. Microsoft is aware of the issue and a more complete fix is on its way.
That's an interesting finding with the way to select destination lakehouse, I've examined json code and indeed - sink settings do differ depending on approach taken (e.g. feels like properties "linkedService" vs "connectionSettings" are treated differently by backengine).
Although as a temporary solution I'm currently taking a bit simpler path : just using python/pyspark notebook where I have slightly more control over endpoint addresses.
Hello FabricConsult
I think you're hitting one of the limitations of using a workspace level private link of Microsoft Fabric. Please refer to this doc.
Supported scenarios for workspace private links - Microsoft Fabric | Microsoft Learn
It says, APIs with endpoints containing v1/workspaces/{workspaceId} support workspace-level private links because they operate within the context of a specific workspace. In contrast, admin APIs use admin/workspaces/{workspaceId} in their endpoints and aren't covered by workspace-level private links.
I think your pipeloine is referncing one of the admin APIs behind the scenes, hence it is failing.
Please also check that Tenant setting “Configure workspace-level inbound network rules” is enabled in the Fabric admin portal.Hope this helps - please appreciate leaving a Kudos or accepting as a Solution!
Hi deborshi_nag,
Thanks for reaching out.
If i continue reading in the same documentation you quoted i see: Admin APIs remain accessible even for restricted workspaces, because the tenant-level setting for blocking public access governs them.It would seem that admin api's should always be available, and the other api's should be accessible through private link
Besides, pipelines are documented as a supported feature. What use are pipelines if i can't even access data in a lakehouse
