Remove unsupported Fabric private link scripts and update docs

Author: Mike Swantek

azure.yaml

@@ -45,18 +45,6 @@ hooks:
       shell: pwsh
       continueOnError: false
 
-    # Stage 3.3: Create Private Link Service Resource (prerequisite for private endpoint)
-    - run: ./scripts/automationScripts/FabricWorkspace/SecureWorkspace/create_fabric_private_link_service.ps1
-      interactive: false
-      shell: pwsh
-      continueOnError: false
-    
-    # Stage 3.7: Setup Workspace Private Endpoint (for secure VNet access)
-    - run: ./scripts/automationScripts/FabricWorkspace/SecureWorkspace/setup_workspace_private_endpoint.ps1
-      interactive: false
-      shell: pwsh
-      continueOnError: false
-    
     # Stage 4: Assign Workspace to Domain
     - run: ./scripts/automationScripts/FabricWorkspace/CreateWorkspace/assign_workspace_to_domain.ps1
       interactive: false

docs/examples/azure.yaml.private-networking.sample

@@ -20,19 +20,7 @@ hooks:
       interactive: false
       continueOnError: false
 
-    # Step 1: Create or update the Fabric private link service resource in Azure
-    - shell: pwsh
-      run: ./scripts/automationScripts/FabricWorkspace/SecureWorkspace/create_fabric_private_link_service.ps1
-      interactive: false
-      continueOnError: false
-
-    # Step 2: Create/refresh the private endpoint and DNS configuration in the target VNet
-    - shell: pwsh
-      run: ./scripts/automationScripts/FabricWorkspace/SecureWorkspace/setup_workspace_private_endpoint.ps1
-      interactive: false
-      continueOnError: false
-
-    # Step 3: Lock down the Fabric workspace so that only private endpoints are allowed
+    # Step 1: Lock down the Fabric workspace so that only private endpoints are allowed
     - shell: pwsh
       run: ./scripts/automationScripts/FabricWorkspace/SecureWorkspace/enable_fabric_workspace_inbound_protection.ps1
       interactive: false

docs/fabric-onelake-private-networking.md

@@ -38,7 +38,7 @@ When deploying AI Search, AI Foundry, and Purview within a VNet (as configured i
 │  │  │  Lakehouse   │  │  Lakehouse   │  │  Lakehouse   │     │ │
 │  │  └──────────────┘  └──────────────┘  └──────────────┘     │ │
 │  │                                                              │ │
-│  │  Private Link Resource: privateLinkServicesForFabric        │ │
+│  │  Private Link Resource: Service-managed (no ARM RP)         │ │
 │  └─────────────────────────────────────────────────────────────┘ │
 └───────────────────────────────────────────────────────────────────┘
 ```
@@ -47,12 +47,12 @@ When deploying AI Search, AI Foundry, and Purview within a VNet (as configured i
 
 ### 1. Fabric Workspace Private Links
 
-Microsoft Fabric supports **workspace-level private links** that enable secure, private connectivity from Azure VNets to specific Fabric workspaces and their OneLake lakehouses.
+Microsoft Fabric supports **workspace-level private links** that enable secure, private connectivity from Azure VNets to specific Fabric workspaces and their OneLake lakehouses. This is a **service-managed** experience: there is currently **no customer-facing ARM/Bicep resource provider** to deploy or manage these objects.
 
 > **Important:** As of November 2025 Azure AI Search cannot complete a shared private link where `group-id = "workspace"`. Our automation detects the failure message `Cannot create private endpoint for requested type 'workspace'` and skips the shared private link stage so OneLake indexers continue to work over public endpoints. Follow the steps in [Phase 2](#phase-2-configure-shared-private-link-from-ai-search-automated) to re-run the script when Microsoft enables the feature, and keep the workspace communication policy in **Allow** mode until the link can be provisioned.
 
-- **Resource Provider**: `Microsoft.Fabric/privateLinkServicesForFabric`
-- **Target Subresource**: `workspace` (workspace-specific) or `tenant` (tenant-wide)
+- **Resource Provider**: _Not available in ARM/Bicep; service-managed only_
+- **Target Subresource**: `workspace` (workspace-specific) or `tenant` (tenant-wide) — managed by the service
 - **Workspace FQDN Format**: `https://{workspaceid}.z{xy}.blob.fabric.microsoft.com`
   - `{workspaceid}` = Workspace GUID without dashes
   - `{xy}` = First two characters of workspace GUID
@@ -83,7 +83,7 @@ Private DNS zones are required to resolve Fabric workspace FQDNs to private IPs:
 
 ### Phase 1: Enable Fabric Workspace Private Link (Manual - Post-Deployment)
 
-> **Note**: Fabric workspace private links cannot be configured via ARM/Bicep as of October 2025. This must be done manually after workspace creation.
+> **Note**: Fabric workspace private links cannot be configured via ARM/Bicep. This must be done manually after workspace creation in the Fabric portal.
 
 1. **Create Fabric Workspace** (via postprovision script: `create_fabric_workspace.ps1`)
 
@@ -95,79 +95,17 @@ Private DNS zones are required to resolve Fabric workspace FQDNs to private IPs:
 
 > **Note**: Once Microsoft enables workspace-targeted shared private links, the connection from AI Search should auto-approve because both resources live in the same subscription/tenant. Until then, the script will exit with a warning and no shared private link is created.
 
-### Phase 2: Configure Shared Private Link from AI Search (Automated)
+### Phase 2: Configure Shared Private Link from AI Search (Not yet supported)
 
-This is handled by the Bicep infrastructure in **Stage 7: Fabric Private Networking** and the **`setup_fabric_private_link.ps1`** postprovision script.
-
-**Resources created (when supported)**:
-1. Private DNS zones for Fabric endpoints
-2. DNS zone virtual network links
-3. Shared private link from AI Search to Fabric workspace (via PowerShell script)
+Workspace-targeted shared private links from AI Search are not supported today; the automation path is disabled/no-op to avoid failures. Keep workspace communication policy in **Allow** mode until Microsoft enables the feature, then re-enable private access manually.
 
 **RBAC tip:** Add Azure AD group object IDs to the `aiSearchAdditionalAccessObjectIds` parameter (or `azd env set aiSearchAdditionalAccessObjectIds "<objectId>"`) so interactive users inherit the same Search roles that the automation assigns to managed identities.
 
-**Key Benefits of Automatic Approval**:
-- ✅ **No manual approval needed** - Connection is auto-approved because both resources are in the same subscription/tenant
-- ✅ **Consistent with other private endpoints** - Works like Storage, Cosmos DB, AI Search private endpoints
-- ✅ **Faster deployment** - No waiting for manual approval step
-- ✅ **Production-ready** - Fully automated end-to-end
-
-**Bicep Configuration** (Stage 7):
-```bicep
-// Private DNS zones created
-resource analysisDnsZone 'Microsoft.Network/privateDnsZones@2020-06-01'
-resource capacityDnsZone 'Microsoft.Network/privateDnsZones@2020-06-01'
-resource powerQueryDnsZone 'Microsoft.Network/privateDnsZones@2020-06-01'
-
-// VNet links for DNS resolution
-resource analysisVnetLink 'Microsoft.Network/privateDnsZones/virtualNetworkLinks@2020-06-01'
-```
-
-**PowerShell Script** (`setup_fabric_private_link.ps1`):
-```powershell
-# Step 1: Automatically creates shared private link with same-subscription auto-approval
-az search shared-private-link-resource create \
-  --resource-group <rg-name> \
-  --service-name <search-name> \
-  --name fabric-workspace-link \
-  --group-id workspace \
-  --resource-id <fabric-workspace-resource-id>
-
-# Connection status will be "Approved" automatically (2-3 minutes provisioning time) once Azure supports workspace shared private links
-
-# Step 2: Configure workspace to deny public access (allow only private link connections)
-$policyBody = @{
-  inbound = @{
-    publicAccessRules = @{
-      defaultAction = "Deny"
-    }
-  }
-} | ConvertTo-Json
-
-Invoke-RestMethod `
-  -Uri "https://api.fabric.microsoft.com/v1/workspaces/$workspaceId/networking/communicationPolicy" `
-  -Headers $headers `
-  -Method Put `
-  -Body $policyBody `
-  -ContentType 'application/json'
-
-# Policy takes effect in up to 30 minutes
-```
-
-**What Gets Automated (once the platform supports workspace shared private links)**:
-1. ✅ Shared private link creation (AI Search → Fabric)
-2. ✅ Automatic approval (same subscription/tenant)
-3. ✅ Workspace communication policy (deny public access)
-4. ✅ Verification of connection status
-
-**Current Behavior (End of 2025)**:
-- ⚠️ Shared private link creation fails with `Cannot create private endpoint for requested type 'workspace'`
-- ⚠️ Script logs a warning and skips the shared private link stage
-- ✅ Workspace remains in **Allow** mode so indexing continues over public endpoints
-- ✅ You can re-run the script after Microsoft releases support; no additional changes required
-
-**Remaining Manual Step** (one-time):
-- Enable workspace-level private link in Fabric portal (required before shared private link can be created)
+**Current Behavior**:
+- ⚠️ Workspace shared private link creation fails with `Cannot create private endpoint for requested type 'workspace'`.
+- ⚠️ Scripts that tried to deploy `Microsoft.Fabric/privateLinkServicesForFabric` are now disabled and act as no-ops.
+- ✅ Keep workspace in **Allow** mode so indexing continues over public endpoints until Microsoft delivers a supported path.
+- ✅ You can re-run the connectivity scripts later if the platform exposes a supported resource provider.
 
 ### Phase 3: Configure OneLake Data Source (Automated Script)
 

docs/fabric_private_endpoint_setup.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-This guide explains how to configure private endpoint access to Microsoft Fabric workspaces from Azure VNet resources (e.g., Jump VM). This enables secure, private access to Fabric when tenant-level private link is enabled.
+This guide explains how to configure private access to Microsoft Fabric workspaces from Azure VNet resources (e.g., Jump VM). **Fabric workspace private endpoints are currently service-managed and not deployable via ARM/Bicep/CLI**; customer automation cannot create or poll a `Microsoft.Fabric/privateLinkServicesForFabric` resource. Use the manual steps to enable workspace-level private link in the Fabric portal.
 
 ## Architecture
 
@@ -57,20 +57,9 @@ Run the post-provision script (happens automatically):
 ./scripts/automationScripts/FabricWorkspace/CreateWorkspace/create_fabric_workspace.ps1
 ```
 
-### Step 4: Set Up Private Endpoint
+### Step 4: Set Up Private Endpoint (Manual)
 
-Run the private endpoint setup script:
-
-```powershell
-./scripts/automationScripts/FabricWorkspace/SecureWorkspace/setup_workspace_private_endpoint.ps1
-```
-
-This script will:
-1. ✅ Get Fabric workspace ID
-2. ✅ Enable workspace-level private link
-3. ✅ Create private endpoint in jumpbox-subnet
-4. ✅ Configure private DNS zones
-5. ✅ Set workspace to deny public access (allow only private endpoint)
+Automation is not available because the Fabric private link resource is service-managed. In the Fabric portal, enable workspace-level private link and approve the connection when Microsoft exposes it. Keep workspace communication policy in **Allow** mode until private link is functional.
 
 ### Step 5: Enable Tenant-Level Private Link
 
@@ -90,37 +79,16 @@ In Fabric Admin Portal:
 3. Navigate to `https://app.powerbi.com` or `https://app.fabric.microsoft.com`
 4. Verify you can access the Fabric workspace
 
-## Manual Steps (If Automation Fails)
-
-### Enable Workspace-Level Private Link
+### Manual Steps (Required)
 
-If the script cannot enable workspace-level private link automatically:
+Enable workspace-level private link in the Fabric portal (portal-only until Microsoft exposes an API/RP):
 
 1. Go to https://app.fabric.microsoft.com
 2. Open your workspace
 3. **Workspace Settings** → **Security** → **Private Link**
-4. Enable **"Workspace-level private link"**
-5. Click **Apply**
-
-### Approve Private Endpoint Connection
-
-If the connection is pending approval:
-
-1. Go to https://app.fabric.microsoft.com
-2. Open your workspace
-3. **Workspace Settings** → **Security** → **Private Link** → **Private Endpoints**
-4. Find the pending connection
-5. Click **Approve**
-
-### Configure Workspace to Deny Public Access
-
-If the script cannot set the communication policy:
-
-1. Go to https://app.fabric.microsoft.com
-2. Open your workspace
-3. **Workspace Settings** → **Inbound networking**
-4. Select **"Allow connections only from workspace level private links"**
-5. Click **Apply**
+4. Enable **"Workspace-level private link"** and save
+5. If/when private endpoints are exposed, approve the connection in the same blade
+6. Set inbound networking to **Allow** until a working private endpoint path exists; then switch to **Deny** once verified
 
 ## Verification
 
@@ -164,14 +132,14 @@ Invoke-RestMethod `
 
 ### Issue: DNS_PROBE_FINISHED_NXDOMAIN when accessing Fabric
 
-**Cause**: Private DNS zones exist but no A records (private endpoint not created)
+**Cause**: Private DNS zones exist but no private endpoint records (because Fabric private link is not exposed via ARM/CLI).
 
 **Solution**:
-1. Run `setup_workspace_private_endpoint.ps1`
-2. Or delete empty DNS zones if not using private endpoints:
-   ```bash
-   az network private-dns zone delete --name privatelink.analysis.windows.net --resource-group rg-{env}
-   ```
+1. Use public access (workspace in **Allow** mode) until Fabric exposes a supported private endpoint path.
+2. If you prefer public-only, delete empty DNS zones:
+  ```bash
+  az network private-dns zone delete --name privatelink.analysis.windows.net --resource-group rg-{env}
+  ```
 
 ### Issue: Connection Pending Approval
 

docs/fabric_private_networking_atomic_scripts.md

@@ -42,38 +42,8 @@ azd env set virtualNetworkId "/subscriptions/.../virtualNetworks/vnet-myproject"
 ./create_fabric_private_dns_zones.ps1
 ```
 
-### 2. `create_fabric_workspace_private_endpoint.ps1`
-**Purpose:** Create private endpoint for Fabric workspace in VNet
-
-**What it does:**
-- Checks if private endpoint is needed (VNet + Fabric capacity deployed)
-- Creates private endpoint in jumpbox subnet
-- Automatically calls DNS zone script if `FABRIC_AUTO_CREATE_DNS_ZONES=true`
-- Links private endpoint to DNS zones
-- Gracefully exits if prerequisites not met
-
-**When to use:**
-- After Fabric workspace is created (`FABRIC_WORKSPACE_ID` available)
-- In network-isolated deployments
-- When VNet and Fabric capacity are both deployed
-
-**Usage:**
-```powershell
-# Automatic usage (in azd post-provision)
-# Prerequisites: Workspace created, FABRIC_WORKSPACE_ID exported
-./create_fabric_workspace_private_endpoint.ps1
-
-# With auto-DNS creation
-azd env set FABRIC_AUTO_CREATE_DNS_ZONES "true"
-./create_fabric_workspace_private_endpoint.ps1
-
-# Standalone usage in external environment
-azd env set FABRIC_WORKSPACE_ID "12345678-1234-1234-1234-123456789012"
-azd env set AZURE_RESOURCE_GROUP "rg-myproject"
-azd env set AZURE_SUBSCRIPTION_ID "..."
-azd env set virtualNetworkId "..."
-./create_fabric_workspace_private_endpoint.ps1
-```
+### Fabric workspace private endpoints (not automated)
+Fabric workspace private endpoints are **service-managed** today. There is no customer-facing ARM/Bicep/CLI resource to deploy or poll. The previous automation scripts have been removed to avoid failed runs. Enable workspace-level private link in the Fabric portal when the platform supports it.
 
 ## Deployment Scenarios
 
@@ -94,21 +64,19 @@ azd env set virtualNetworkId "..."
 2. User runs `create_fabric_workspace.ps1` → Workspace created
 3. User exports workspace ID: `azd env set FABRIC_WORKSPACE_ID "..."`
 4. User runs `create_fabric_private_dns_zones.ps1` → DNS zones created ✓
-5. User runs `create_fabric_workspace_private_endpoint.ps1` → Private endpoint created ✓
+5. Enable workspace-level private link manually in the Fabric portal (no script available)
 
-**Result:** Manual orchestration, but atomic scripts handle each step
+**Result:** Manual orchestration with DNS zones automated; private link enablement is portal-only until Microsoft exposes an API/RP.
 
 ---
 
 ### Scenario 3: Auto-Create DNS Zones
 **Flow:**
 1. Bicep deployment without stage 7 (network isolated but no DNS zones)
 2. Post-provision stage 3.5 with `FABRIC_AUTO_CREATE_DNS_ZONES=true`
-3. Private endpoint script detects missing zones
-4. Automatically calls DNS zone script
-5. Both DNS zones and private endpoint created ✓
+3. DNS zone script creates missing zones; private endpoint remains a manual portal step
 
-**Result:** Self-healing automation
+**Result:** DNS zones can self-heal; private link remains manual until platform support.
 
 ---
 
@@ -155,21 +123,13 @@ module fabricNetworking = if (deployToggles.virtualNetwork && deployToggles.fabr
 - If stage 7 runs → DNS zones exist → scripts skip creation
 - If stage 7 skipped → Scripts can create DNS zones via CLI
 
-## Conditional Logic Summary
+### Conditional Logic Summary
 
 ### Bicep (Stage 7)
 ```
 Deploy DNS zones IF (virtualNetwork AND fabricCapacity)
 ```
 
-### PowerShell (Private Endpoint Script)
-```
-Create private endpoint IF:
-  1. virtualNetworkId exists (network isolated design)
-  AND
-  2. FABRIC_CAPACITY_ID exists (Fabric deployed)
-```
-
 ### PowerShell (DNS Zone Script)
 ```
 Create DNS zones IF:
@@ -191,13 +151,13 @@ Create DNS zones IF:
    - Both scripts are idempotent (safe to re-run)
 
 3. **For automation:** Use `FABRIC_AUTO_CREATE_DNS_ZONES=true`
-   - Self-healing if DNS zones missing
-   - No manual intervention required
+  - Self-healing if DNS zones missing
+  - Private link remains a manual portal step until platform support
 
 4. **For testing:** Run scripts independently
-   - Each script has clear prerequisites
-   - Graceful error handling
-   - Detailed logging
+  - Each script has clear prerequisites
+  - Graceful error handling
+  - Detailed logging
 
 ## Troubleshooting