Possible regression in OneLake File Explorer 1.1.1.0 with B2B Guest cross-tenant access
Hi Fabric Community, I am seeing what appears to be a regression in OneLake File Explorer 1.1.1.0 when accessing Fabric resources as an Entra ID B2B Guest in another tenant. Scenario My enterprise account belongs to my corporate tenant and is configured as a B2B Guest in a customer's tenant. The same account can: switch to the customer tenant in the Fabric web portal; access the expected customer workspaces; successfully authenticate directly against the customer tenant through PowerShell and Fabric REST APIs. Issue with OneLake File Explorer 1.1.1.0 I sign out and authenticate using: Use another account → Sign-in options → Sign in to an organization → Customer tenant → My enterprise B2B Guest account Authentication succeeds and the OneLake logs show no 401, 403, AADSTS, token refresh, or authorization errors. The client successfully reaches: Auth completed via interactive flow Auth completed via silent flow Fetching artifacts list Starting sync engine Application initialization completed successfully However, Windows File Explorer only shows workspaces from my home corporate tenant. The customer workspaces are missing. Fabric REST validation I explicitly authenticated against the customer tenant: Connect-AzAccount -Tenant "<CUSTOMER_TENANT_ID>" $token = Get-AzAccessToken ` -ResourceUrl "https://api.fabric.microsoft.com" if ($token.Token -is [System.Security.SecureString]) { $accessToken = [System.Net.NetworkCredential]::new("", $token.Token).Password } else { $accessToken = $token.Token } $response = Invoke-RestMethod ` -Method GET ` -Uri "https://api.fabric.microsoft.com/v1/workspaces" ` -Headers @{ Authorization = "Bearer $accessToken" } $response.value | Select-Object id, displayName, type | Sort-Object displayName This correctly returns all customer workspaces I am authorized to access. So the current status is: Entra B2B Guest membership : OK Customer tenant login : OK Fabric permissions : OK Fabric REST API : OK OneLake 1.1.1.0 : Wrong tenant workspace enumeration A/B test I then downgraded OneLake File Explorer from: 1.1.1.0 to: 1.1.0.0 and repeated exactly the same B2B authentication flow. Result: OneLake File Explorer 1.1.0.0 → Customer workspaces visible → WORKING OneLake File Explorer 1.1.1.0 → Only home-tenant workspaces visible → NOT WORKING No Fabric permissions, Entra configuration, or tenant settings were changed between the two tests. Current workaround Downgrading temporarily to OneLake File Explorer 1.1.0.0 restores B2B cross-tenant workspace navigation through Windows File Explorer. I understand that only the latest version is officially supported, so I consider this a temporary workaround and diagnostic evidence. Question Can Microsoft confirm whether OneLake File Explorer 1.1.1.0 introduced changes related to: B2B Guest authentication; MSAL account/tenant selection; tenant resolution; cross-tenant workspace enumeration; MultiCloud authentication? The A/B test strongly suggests that 1.1.1.0 authenticates successfully but enumerates Fabric artifacts from the home tenant instead of the explicitly selected B2B customer tenant. Is this a known issue or regression? Thanks.
DP-600 Voucher
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } Hi everyone, I recently passed the DP-700 Microsoft Fabric Data Engineer Associate certification and am now planning to take DP-600 (Microsoft Certified: Fabric Analytics Engineer Associate) while the Fabric concepts are still fresh in my mind. Unfortunately, I wasn't able to use a previous DP-600 voucher when I first received it as I wasn't ready for the exam at the time. I was wondering if anyone is aware of any current voucher opportunities for DP-600, or has an unused voucher that they won't be using and is transferable (if permitted by the voucher terms). Any guidance would be greatly appreciated. Thanks in advance! Regards, Amanul
Microsoft Fabric Materialized Lake Views (MLVs) – Looking for Confirmation on a Few Points
Microsoft Fabric Materialized Lake Views (MLVs) – Looking for Confirmation on a Few Points Hi everyone, I'm currently working with Materialized Lake Views (MLVs) in Microsoft Fabric and trying to establish the right approach for implementing them in a proper Dev → UAT → Production setup. I have gone through the available documentation, but I would appreciate confirmation from people who are already using MLVs in real projects. MLV Refresh Failure and Monitoring My current understanding is that if an MLV fails during its initial execution or during a scheduled refresh: The MLV run will be marked as Failed. The failure can be investigated through the MLV run history/monitoring experience. The error code, error message and execution details can be used for troubleshooting. If an upstream MLV fails, dependent MLVs may be skipped. Questions: Is there a recommended/native way to send an email or Teams notification whenever an MLV refresh fails? What is the recommended production monitoring approach for MLV refresh failures? Is anything else required in addition to configuring the MLV schedule? ON MISMATCH FAIL vs ON MISMATCH DROP My current understanding is that ON MISMATCH is related to handling schema/structure mismatches encountered during MLV processing, rather than being a general data-quality validation mechanism. For example: ON MISMATCH FAIL would cause the MLV operation to fail when the applicable mismatch occurs, whereas: ON MISMATCH DROP would allow processing to continue while dropping the affected/incompatible data. Questions: Is this understanding correct? What exactly constitutes a "mismatch" for an MLV? What are the recommended scenarios for using FAIL vs DROP? Does ON MISMATCH FAIL affect the entire MLV refresh or only the affected data/operation? Dev → UAT → Production Deployment This is probably my biggest area of uncertainty. Suppose I create and test the following in DEV: DEV Workspace Lakehouse Source tables MLV 1 MLV 2 My expectation is that I should not manually recreate the MLVs in UAT and Production. Instead, I would use Fabric lifecycle/deployment capabilities to promote the artifacts: DEV → UAT → PROD Questions: Are MLV definitions currently supported for this type of Dev → UAT → Prod deployment? Does Deployment Pipeline automatically handle the corresponding Lakehouse/item dependencies? If the workspace names, Lakehouse names and item IDs are different between environments, how are those references handled? Does Fabric automatically rebind supported dependencies to the corresponding target-environment resources? Which MLV-related properties/configurations need to be manually configured or validated after deployment? For example: DEV Workspace: BI_DEV Lakehouse: Sales_LH_DEV ↓ UAT Workspace: BI_UAT Lakehouse: Sales_LH_UAT ↓ PROD Workspace: BI_PROD Lakehouse: Sales_LH_PROD How much of this environment-specific mapping is automatically handled by Fabric? MLV Refresh Schedules Across Environments Suppose my DEV MLV has a refresh schedule of every 1 hour. When I deploy it to UAT and Production: Is the schedule also deployed? If it is, can or should it be different between environments? What is the recommended approach for managing MLV schedules separately in DEV, UAT and PROD? Is schedule configuration considered part of the deployable MLV artifact or environment-specific configuration? MLV Dependencies / MLV on top of MLV Can we create an MLV that references another MLV? For example: Source Tables → MLV 1 – Silver → MLV 2 – Gold → MLV 3 – Aggregation Is this a supported and recommended architecture? If yes: Are there any limitations on the number or depth of MLV dependencies? How does refresh orchestration work? If MLV 1 fails, are MLV 2 and MLV 3 automatically skipped? How is the dependency and lineage handled during deployment from DEV → UAT → PROD? SQL View on top of MLV Can we create a regular SQL View on top of an MLV? For example: Source Tables → Materialized Lake View → SQL View → Semantic Model / Power BI If this is supported: Are there any performance implications? Does the SQL View remain virtual while the MLV remains materialized? Is this a recommended pattern for exposing MLV data to downstream consumers? View → MLV Conversely, can an MLV be created on top of a regular SQL View? For example: Source Tables → SQL View → MLV If supported, are there any restrictions around the types of views or queries that can be used as an MLV source? Recommended Production Architecture For a production implementation, would the following architecture be considered a reasonable pattern? Source Tables → MLV Layer → Silver MLVs → Gold MLVs → SQL Views (if required) → Semantic Model → Power BI Or is it generally better to consume MLVs directly from the semantic model where possible? General Best Practices For anyone using MLVs in production: What are the main limitations you have encountered? What should be considered when designing MLV dependencies? How do you handle monitoring and alerting? How do you manage Dev/UAT/Prod deployment? Are there any MLV-specific CI/CD considerations that are easy to miss? What would you recommend avoiding when designing an MLV architecture? I'd particularly appreciate confirmation from anyone who has implemented MLVs across multiple Fabric environments such as DEV, UAT and PROD. Thanks in advance!
From SAP, FSM and SharePoint silos to a Fabric Lakehouse: Medallion + Direct Lake
We recently moved a building-services client at DataToBiz off a reporting setup where data sat across SAP S/4HANA, SAP FSM, SharePoint, and flat files. Pulling together a single report meant manual extraction and reconciliation, with some reporting cycles taking up to two weeks. We rebuilt this on Microsoft Fabric. Dataflows Gen2, Pipelines, and Notebooks handle ingestion from the four source types through automated batch workflows, landing in a single Lakehouse on OneLake with a Bronze/Silver/Gold structure. Spark notebooks and pipelines handle large-scale transformation, cleansing, and KPI standardization across the source systems. Power BI semantic models with DAX and RLS handle role-based access. Reports use Direct Lake mode to work with data in OneLake without the traditional import-based refresh approach. Result: reporting went from 10–14 days to under a day, with 20+ reports automated across roughly 60 users. The interesting part wasn't just bringing the data into Fabric. It was standardizing KPIs when different enterprise systems represented the same metric differently. Question for the group: how are you handling KPI standardization when multiple enterprise systems define the same metric differently? If anyone has a scalable, metadata-driven approach for that, please share.
OAP for MLVs cross workspace
Hi all, I have a question regarding OAP implementation across multiple workspaces. My current setup consists of three layers: Bronze: OAP enabled Silver: OAP enabled Gold: OAP not enabled In the Bronze layer, I extract all source data using specific endpoints and gateways, with the required connection rules configured. In the Silver layer, I use shortcuts to access the source lakehouses in Bronze. This works as expected. Within Silver, I then create Materialized Lake Views (MLVs) for my entities. For example, I create a Person entity based on multiple source tables and store the result in LH_Silver. This also works correctly. The issue occurs in the next step. On top of the Silver entity, I want to create dim_Person. The MLV reads the entity from LH_Silver, but the output should be written to LH_Gold in the Gold workspace. When OAP is disabled on all workspaces, this cross-workspace setup works and I can successfully write the MLV to Gold. However, as soon as OAP is enabled on the Silver workspace, I can no longer write the MLV to the Gold workspace. I've already tried several connection rules, including: FabricMaterializedLakeView FabricSqlEndpointMetadata Fabric SQL Analytics Endpoint Lakehouse Notebook Web V2 I've also configured an MPE for the Gold (3000) workspace, but so far none of these options have resolved the issue. Does anyone know which connection rule, MPE, or configuration is required to allow an MLV running from an OAP-enabled Silver workspace to write to a Lakehouse in another workspace? Ideally, I would like to keep the notebooks and MLV logic in the Silver layer rather than moving them to the Gold workspace. Thanks in advance! Cel 1: %%pyspark spark.conf.set("spark.sql.caseSensitive", "true") workspace = spark.conf.get("trident.workspace.name") environment = "DEV" if "DEV" in workspace else "TEST" if "TEST" in workspace else "PRD" spark.sql(f"SET TargetEnvironment = 3000_CURATED ({environment})") Cel 2: CREATE OR REPLACE MATERIALIZED LAKE VIEW `${TargetEnvironment}`.LH_3000.Algemeen.dim_Persoon AS SELECT * FROM test.`02_entity`.PersonFabric Welcome Popup - Hide/Disable
Team - I am back with another requirement from my end users. They dont want to see the "Welcome to Fabric View " pop-up when they log in using Fabric apps URL. I have gone through all the tenant setting and I dont see any way to hide or disable this pop-up. Did anyone come across similar requirement? Any thoughts or suggestions? -PattFabric IQ: Do Ontology entity synonyms work with Data Agent?
Hi, everyone! Short intro Currently I'm using the "super-duper-mega-nano-ultra" product - Microsoft Fabric to build natural language processing flow on-top of Microsoft Fabric Warehouse data. As for now It's rather a POC than production solution. I found a lot of the official Microsoft' documentation related to my task, but I have a little problem... The solution architecture (high-level) I made some investigations and as the result is the following architecture, which I want to implement (picture below): The idea is the next: the Microsoft Fabric Warehouse schema is connected to Microsoft Fabric Lakehouse, using shortcut; the Microsoft Fabric Ontology consumes the Microsoft Fabric Lakehouse as a data source for data binding; the Microsoft Fabric Data Agent uses a Microsoft Fabric Ontology (enriched with business context) to process natural language questions. The Microsoft Fabric Warehouse contains the following (dummy) objects (picture below): Tenant settings Microsoft documentation says, that specific tenant configurations should be applied to use Microsoft Fabric Ontology with Microsoft Fabric Data Agent (https://learn.microsoft.com/en-us/fabric/data-science/data-agent-tenant-settings) - everything is configured properly. Ontology configuration My Microsoft Fabric Ontology is configured as below (the configuration is influenced by Microsoft Fabric Ontology tutorial, which can be found here - https://learn.microsoft.com/en-us/fabric/iq/ontology/overview). Main view - two entities with a single relationship: ETLEntity entity configuration - the entity has the description, one synonym, metadata: ETLEntityRun entity configuration - the entity has the description, one synonym, metadata: As for now the Microsoft documentation says, that Microsoft Fabric Ontology descriptions, synonyms, metadata help Microsoft Fabric Data Agent to better understand the context (https://learn.microsoft.com/en-us/fabric/iq/ontology/how-to-add-semantic-enrichment). The problem My Microsoft Fabric Data Agent is connected to my Microsoft Fabric Ontology, which is described above, but the agent can't answer the simple questions about entities and the questions examples are provided below (the Microsoft Fabric Ontology Graph model was refreshed successfully before questions were asked): ETLEntity successful question without synonym usage: ETLEntityRun successful question without synonym usage: ETLEntity failed question with synonym usage: ETLEntityRun failed question with synonym usage: Looks like Microsoft Fabric Data Agent can't figure out, which entities are unicorn/wizard, even if they have appropriate synonyms. It's not my first iteration - I tried a lot, but result still the same every time. I feel like I missed something obvious in my configuration, but what... What are your thoughts? P.S.: the provided configuration is simple; objects and their metadata has no business context - It's just a sample, which I built to test some scenario; I think It's enough to check such use-case.
