Forum Discussion
Copy activity fails with workspace level private link enabled (Error getting outbound access policy)
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.
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.