Category: Microsoft Fabric

Tom Peplow makes an announcement:

In October 2025, we introduced OneLake diagnostics—a powerful capability that helps teams “answer who accessed what, when, and how” across your Fabric Lakehouse environment. OneLake diagnostics streams JSON-based activity logs into a Lakehouse you choose, enabling rich analysis, governance, and compliance workflows. A powerful capability that helps teams “answer who accessed what, when, and how” across your Fabric Lakehouse environment. OneLake diagnostics streams JSON-based activity logs into a Lakehouse you choose, enabling rich analysis, governance, and compliance workflows.

We are strengthening that foundation with the introduction of immutable diagnostic logs—a new capability that ensures diagnostic events cannot be altered or deleted for a defined retention period, giving you tamper-proof data for the entire lifecycle of your logs.

I do like the idea, but beware the additional costs: immutable also means you can’t delete it later, so 10 years from now, you’re still going to be paying for this diagnostic data.

Gilbert Quevauvilliers puts on the lab coat and safety goggles:

I was recently part of a discussion (which I have heard of multiple times), which was which semantic model to use in Microsoft Fabric.

This was the source for this blog post where I am going to compare Microsoft Direct Lake (DL) to an Import Semantic Model. The goal is to first explain how I set up and configured the comparison.

And in the next blog post I will show the tests and the outcome based on my testing.

This is the first part in a series and covers the setup process for testing. We’ll have to wait until next time for the results.

Laura Graham-Brown continues a series on variable libraries in Microsoft Fabric:

This post walks through how to access a variable library in a notebook in Microsoft Fabric. I recommend a Microsoft Fabric project starts by creating a variable library to store the common values different artifacts need and could be changed if a deployment pipeline gets involved. So when we create a notebook we need to be able to use these variables. This means we need load the variable library in a notebook and then get the variable values.

Read on for two ways to retrieve information on variables, as well as some recommendations around naming.

Kristina Mishra digs into the Fabric Unified Admin Monitoring tool:

Recently a colleague of mine was inquiring about creating a service principal to use with a Microsoft Fabric Rest APIs proof of concept project we were wanting him to develop for some governance and automation. Since he was still in the research phase, I told him we already had one he could use and did a brief demo on how we use it with FUAM (Fabric Unified Admin Monitoring tool). It occurred to me that others may find this a useful way to learn how to use Fabric or PBI Rest APIs. If you are also fairly new to using pipelines and notebooks in Fabric, then you can get the added bonus of learning through an already created, well-designed and active live Fabric project in your own enviroment. If you do not have FUAM installed in a Fabric capacity, or do not have permissions to see the items in the FUAM workspace, or have no intention/ability do change either of those blockers, then you can stop reading here. Unless you are just generally curious – then feel free to read-on. Or not. You do what works for you.

I personally recommend reading on. It’s kind of a thing I do here.

Laura Graham-Brown opens a library:

This post to help you get started creating a variable library. When multiple dataflows, notebooks and pipelines are using the same details to perform tasks it helps if those values are stored in one place. When you move to use deployment pipelines and those values change from your development workspace to your test workspace to your prod, it helps if that is easy. The solution in Microsoft Fabric is a Variable Library to store those common values.

Click through for step-by-step instructions on the process.