Episode 317 – January 2026 News Catch-Up: Hidden Gems in the M365 Admin Center

Welcome back from the holiday break! Jason and John are kicking off 2026 with a news roundup episode that caught them by surprise. Where did they find some of the juiciest Power BI and Fabric news? Not in the usual places—but hidden away in the Microsoft 365 Admin Center Message Center. From retirement announcements that aren’t what they seem to real-time intelligence pricing deep dives, this episode covers the quirky corners of Microsoft’s ecosystem that even seasoned pros might miss.

Travel Tales: From Colombia to Costa Rica

Before diving into the tech news, the hosts caught up on their recent adventures. John had just returned from his first trip to South America—Colombia specifically—making it six continents checked off his travel list. “I just need that Arctic now,” he noted. Jason immediately jumped on that: “I’m in the same boat. We’re going to have to plan that trip. I think that’s going to have to be a BIFocal show remote recording episode or something.”

Jason had been in Costa Rica and Arizona with his family over the break, and at recording time was sitting in Santa Monica, California bright and early for some work. The conversation touched on the winter storms heading to the southern United States—something John, up in the snowy north, found amusing. “For you, we just call that a Thursday,” Jason quipped about the weather John experiences regularly.

The M365 Admin Center: An Unexpected News Source

Here’s where things get interesting. Jason discovered several Power BI-related announcements in a place many BI professionals don’t regularly check: the Microsoft 365 Admin Center Message Center.

For those unfamiliar, as Jason explained, “You’re going to go into admin.cloud.microsoft, and then you’re going to go on the left rail, you’re going to find the health section, and then you’re going to find Message Center.”

The Message Center is where Microsoft publishes notifications about changes to the M365 ecosystem—Exchange, OneDrive, SharePoint, Entra ID, and more. Service updates, retirements, big changes—they all get posted there. And since Power BI is technically part of Microsoft 365, that’s where some announcements land.

As John noted with some irony: “This is all coming from that office dashboard. It’s not an announcement in the Fabric blog or Power BI blog because it’s kind of hidden that way.”

News Item #1: End of Support for On-Prem SharePoint Web Part

Message Center ID: MC1217651
Classification: Major Update, Retirement, Admin Impact

The title reads “Power BI: End of Support for On-Prem SharePoint Web Part,” which sounds alarming at first. But here’s the twist—this isn’t actually about Power BI at all.

John’s reaction was priceless: “Well, isn’t that funny? For years, literally since it first showed up in 2015, 2016, I’ve been telling people that there is no on-premises SharePoint web part for Power BI. So this was… not only is it going away, I didn’t know it existed.”

The confusion stems from naming. What’s actually being retired is the SQL Server Reporting Services (SSRS) Report Viewer SharePoint web part—not a Power BI component at all. As Jason clarified, “It’s the SSRS report viewer SharePoint part… which never existed in the cloud, by the way.”

This web part dates back to around 2005 when SSRS first launched with SharePoint 2003/2005. It’s been working in various SharePoint on-premises versions for nearly 20 years. As John put it: “It’s basically 20 years old, so it’s leaving the house.”

The key takeaway? Don’t panic about Power BI web parts going away. This is purely about legacy SSRS integration with on-premises SharePoint servers.

News Item #2: Retirement of Power BI Q&A

Message Center ID: MC1218421
Retirement Date: December 31, 2026

This one is actually about Power BI, and it’s worth paying attention to—though Jason and John disagree on just how big a deal it is.

Power BI Q&A has been around since 2015 when Power BI first launched. As John explained, it was “pre-AI, pre-LLM, an attempt at being able to enable natural language queries essentially so that you could ask a question of the data that you’re connected to and get a result.”

The results were mixed. “You had to do a lot of prep to make it work,” John noted. It was primarily exposed through Power BI dashboards (the old-style dashboards that nobody really loves), and it was very workspace-based. “I don’t think we’ve got a lot of love,” John admitted.

On the surface, it’s not a huge loss because Copilot does everything Q&A did, but better. However, Jason saw a bigger implication: “This is a very big deal… because I think this is the last vestige of the pre-AI, not really AI, that when you have Power BI and you had just Pro—not even Premium—you had something that was AI. It was not AI, but it was the predecessor to it that they’re removing from the toolset to say, we want you completely over in Copilot.”

The strategic play here? Microsoft is stripping features from Power BI Pro and pushing users toward Copilot-enabled Fabric with capacity licensing. “So you have to have capacities and all of that,” Jason pointed out. “They’re retiring some of these things.”

It’s not just about cleaning up redundant capabilities—though John appreciates that Microsoft is finally doing some housecleaning. It’s about license migration strategy. As John noted, “There’s definitely an argument about the licensing thing.”

News Item #3: Copilot Capacity Designation Enabled by Default

Message Center ID: MC217152
Published: January 13, 2026
Action Required by Admins: February 8, 2026

This one caught both hosts’ attention because it’s relatively new functionality that has admin implications.

The announcement is about tenant settings allowing capacities to be designated as Fabric Copilot capacities. As Jason explained, “You can take an existing capacity and say, this is my Copilot capacity.”

This feature started requiring F64 capacities but has since been lowered to F2. You can spin up a capacity as low as F2 and grow it as needed, designating it specifically for Copilot usage across all users.

John clarified what this actually does: “It’s just the ability to flag a default capacity… as an admin. So when someone comes in, it’s going to automatically send them to the right capacity for processing Copilot queries.”

Why this matters: If admins don’t turn this on and set a default, users won’t have Copilot automatically configured when they try to use it in Fabric. They’ll have to manually select a capacity they have access to.

As Jason explained, “It’s one more layer of obfuscation from being able to do it… If you have rights to a capacity, you can go in and there’s not a way to stop you from sending your Copilot queries to any capacity that you have access to.”

Notably, there’s no flag that says “do not let Copilot run in this capacity.” Jason’s take on why? “Microsoft doesn’t want to do that. They make more money off of running Copilot.”

John’s response was succinct: “They want you to use Copilot. Front and center here. You want some more Copilot with this? You want another Copilot then?”

Deep Dive: Understanding Fabric Event Stream Pricing

Moving from the Message Center discoveries to the Fabric blog, the hosts tackled a comprehensive article about Event Stream pricing published on January 12, 2026.

Jason initially looked at it and thought, “Oh great, another pricing update.” But John saw something more valuable: “It’s a very good article, very well thought out. And I like the intent of helping you understand cost—the cost implication of design decisions, which we don’t always do, right?”

This isn’t about Microsoft changing how they charge for Event Stream. Instead, it’s an educational resource helping users understand how design choices impact capacity unit consumption.

The Runaway Cost Problem

Jason made a critical point about real-time intelligence: “Never has there been something that you could have a runaway cost in the analytics side of the world faster than real-time intelligence. The fact that you could go make a design decision and not realize the cost implication to it is staggering.”

John immediately agreed, noting that “the only times that we’ve been throttled in our tenant has been running Event Streams.”

Jason added Data Factory as the runner-up for runaway costs: “Setting something and running it and saying, oh, just go off and do this process and let it consume your CUs. And all of a sudden it’s like, where did my CUs go? What happened? Why am I shut down?”

Event Stream Components Explained

John provided helpful context on what Event Stream actually is under the hood. It’s fundamentally a combination of two Azure services:

• Event Hub: Where producers send data signals and consumers pick them up
• Azure Stream Analytics: The processing layer (like “SSAS in Azure, but not SSAS proper”) that operates on real-time data, performing operations like sliding window aggregations

“Event Stream is those two things fundamentally put together,” John explained. “When you’re doing that, you’re firing up two different processes and those are using two different sets of resources.”

In the old Azure world, those would be two different billing items. In Fabric, it’s unified under Event Stream, but those underlying resource consumptions still exist.

The Critical Design Decision: Direct Ingestion vs. Transformation

This is where the cost implications get dramatic. John walked through a scenario that perfectly illustrates the problem:

“If you’ve got a data stream coming in—let’s call it weather data—and I want to take that and put it into an Event House (Kusto), I can look at my Event Stream and say, ‘Hey, I’m going to transform my data. I want to convert temperature units, or I don’t need all this data, I want to filter it out.’ I can do that in the Event Stream and then pick Event House as my destination.”

“But I could also just say, take the raw data, don’t do anything at all to it, and put it directly into Event House. And then I could process it using the tools available in Event House, which gives lots of flexibility there within the context of Event House.”

What’s the difference? Cost. Massive cost difference.

When you connect a destination without performing transformations in Event Stream, you can use direct ingestion. But if you transform prior to ingestion, “you’re invoking that Azure Stream Analytics bit and that means you’re going to be paying more. And it just costs at least twice as much. Actually, I think it’s more than twice as much.”

John’s recommendation: “If my Event House can do everything I need to do—and it can, it’s quite good at what I want—I’m going to use that preferentially.”

The implementation isn’t entirely straightforward, though. “You pick the direct ingestion option, you have to publish your Event Stream, and that’s going to show you an error because it has to have further configuration.” The key difference is that Event House pulls the data from the Event Hub rather than the Event Hub pushing it.

Not all data services support this pull model, but Event House does, which is why this optimization strategy works so well there.

ETL vs. ELT: The Cost Conversation

This led to a broader discussion about ETL (Extract, Transform, Load) versus ELT (Extract, Load, Transform)—a topic Jason and John have debated many times.

Jason offered a memorable analogy: Think about moving houses. You’ve bought a new house and need to move all your stuff from the old one. You’re also going to make changes to the new house—painting, carpeting, construction work.

“Are you going to hire the movers to go and at the same time rip up the old carpet, put down new carpet, do any type of construction at the same time, and then deliver the stuff into a new configuration in the new house? Or are you simply having the movers do the job of pick up the stuff, move it in, and then you’re going to go ahead and make the changes?”

John expanded on it: “Or do I want the movers to make decisions about what to throw out before they move it into the new house? Or will I just deal with it afterwards?”

Jason shared a real-world horror story: “We’ve had people do pack and move for us in history and I had someone pack a garbage can with trash in it. Wrapped it. Packed it. Wrapped the trash in paper, put it in the trash can, wrapped the trash can, put it in a box, and moved it.”

John’s response captured the essence of the ETL/ELT debate: “That’s actually a good illustration of we’re just going to bulk move and then process versus we have to make decisions prior.”

John also clarified an important point: “ELT is not free. You’re still doing that transformation in Event House, but you’re not paying anywhere near as much to do that. That’s kind of part and parcel of what Event House does, but the CUs are being consumed.”

The article breaks down the specific billing components:

• Input source: The base, the default stream
• Operator: Where the transformation happens (this is the expensive part)
• Derived stream: The result of transformations
• Destination: Where the data lands

As Jason summarized: “The next two is where the expense comes in. The operator is what makes the transformation happen into a derived stream, which gives you the destination.”

The article also covers different billing models for different sources—pulling from an Event Hub uses a different model than using “smarter sources” like the weather sample connector. These nuances matter when designing streaming solutions.

SQL Tools Investment Announcement

On January 15th, Ana Hoffman from the Microsoft SQL team published an article about investing in SQL tools and experiences. Jason’s take was direct: “You can kind of jump right to the end of it. There’s a bunch of links to their roadmap and to some discussion forums and some interesting things that you can participate in to help give feedback.”

The article essentially says: “Hey, we’re building all of these things. We’re not really telling you much about what they are, but we recognize that we need to keep building all of this stuff. So if you want to know more, go here.”

John pointed out something interesting: “One thing that’s not in their list is Azure Data Studio because it’s gone.”

For context, Azure Data Studio was the Visual Studio Code fork geared directly at querying data. Jason asked if it was related to SSDT (SQL Server Data Tools), and John confirmed: “Similar situation, right? The article is about that suite of tools.”

The article signals Microsoft’s continued investment in SQL tooling but doesn’t reveal many specifics about what’s coming. For those interested in providing feedback or staying informed, the links in the article provide access to roadmaps and discussion forums.

Copy Job Enhancements for Incremental Copy and CDC

A blog post dropped about simplifying data movement across clouds with Copy Job enhancements for incremental copy and Change Data Capture (CDC).

The big message: expanded source store support for incremental copy. New additions include Google services, folders, Azure Files, and—notably—SharePoint lists.

John saw this as part of a larger pattern: “It’s the march toward consistency in the connector model for all of the Fabric artifacts really. All of the engines are kind of converging on a single list of connectors and that’s good. That’s good.”

Jason highlighted what he called “burying the lede”: Incremental copy from Fabric Lakehouse now supports Change Data Feed (CDF)—what Microsoft calls Delta Change Data Feed—as well as watermark-based methods. And Microsoft’s preference? They want you to switch to CDF.

The rest of the announcement focused on additional data sources getting support for these capabilities, continuing Fabric’s expansion of data connectivity options.

Managed OneLake Security for Mirror Databases (Preview)

The final news item came from Aaron Merrill’s article published January 20th about managed OneLake security for mirror databases moving into preview.

The announcement: Microsoft has expanded OneLake security to cover mirror databases. This brings role-based access control to mirrored data at the OneLake layer.

Jason pointed out: “This is a new layer of security that you have to set. It’s not at the engine level, it’s at the OneLake security layer.”

John had some caveats: “If you haven’t used OneLake Security already… I’d also use the word additional. Because the first question that came to my mind on this is: are they synchronizing the permission model within the source database with OneLake security? No is the answer to that.”

It’s a different permission set. You define roles in OneLake security and then apply those roles to the data, which is consistent with everything else OneLake security does.

The upside? “It allows you to implement a different permission to the mirrored data than you would’ve had on your source table.”

The downside? “If you wanted to have exactly the same permission set in that destination you had in the source table, you might be a little annoyed that you have to go configure it again.”

OneLake security is still relatively new—it’s been in preview for less than four months at this point—so Jason’s calling it new is fair. This extension to mirror databases shows Microsoft is methodically expanding the OneLake security model across all Fabric data types.

Looking Ahead to 2026

As they wrapped up, Jason noted, “My expectation is that at some point we’ll see a new version of Desktop come out as a companion to an update blog for Fabric and for Power BI.”

With less than two months until the next Fabric Community Conference (March 16-20, 2026 in Atlanta), Jason expects Microsoft to release updates before going into conference lockdown. “I’m excited to see what 2026’s roadmap’s going to look like.”

John agreed: “It’s about to kick into gear again.”

The Bottom Line

This episode highlighted a critical lesson for Power BI and Fabric professionals: important announcements don’t always show up where you expect them. The M365 Admin Center Message Center contained significant Power BI news that many in the community might have missed.

Key takeaways:

• The SSRS Report Viewer web part for on-prem SharePoint is retiring—not Power BI web parts
• Power BI Q&A is being retired in December 2026, signaling Microsoft’s push toward Copilot
• Copilot capacity designation is becoming enabled by default—admins need to act by February 8th
• Event Stream design decisions can dramatically impact costs—direct ingestion is significantly cheaper than transformation-based approaches
• OneLake security continues expanding, now covering mirror databases
• Connector consistency is improving across all Fabric engines

And perhaps most importantly: sometimes the movers pack your garbage.

---

Links

Microsoft 365 Admin Center:

• M365 Admin Center (Message Center under Health section)
  • Message Center ID MC1217651: Power BI End of Support for On-Prem SharePoint Web Part
  • Message Center ID MC1218421: Retirement of Power BI Q&A
  • Message Center ID MC217152: Copilot Capacity Designation Enabled by Default

Microsoft Fabric Blog Posts:

• Understanding Fabric Event Stream Pricing
• Managed OneLake Security for Mirrored Databases (Preview)
• Fabric January 2026 Feature Summary

Previous Episodes:

• Episode 316 – 2024 Recap and 2026 Predictions
• Episode 315 – Fabric November 2025 Feature Summary (Part 3)

Subscribe: SoundCloud | iTunes | Spotify | TuneIn | Amazon Music