M365.FM | Microsoft 365, Azure Cloud, Power Platform & AI

Power BI Dataflows - Simply Explained

Fri, 06 Nov 2026 18:00:02 +0000

Your Power BI reports keep redoing the same cleanup a dataflow could do once. Every refresh reruns the same steps, every report keeps its own copy, and that duplication slows things down and hammers your source system.

In this episode of Simply Explained you will learn:

The Messy Data Problem Everyone Hits First
What A Dataflow Actually Is
Where Your Data Actually Sits
How Dataflows Fit With Datasets And Reports
The License And Capacity Part, In Plain Terms
When A Dataflow Is Worth It, And When It Isn't
The Traps That Catch People Out
The Two Generations, And Which One To Learn
What To Take Away, And One Question For You

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Fabric Capacity Pricing - Simply Explained

Fri, 06 Nov 2026 16:00:02 +0000

Somewhere tonight, a Microsoft Fabric capacity is running with nobody using it, and the meter is still ticking. Fabric doesn't charge per person, because you're buying a pool of computing power called a capacity, sold in sizes like F2, F8, and F64.

In this episode of Simply Explained you will learn:

Why Fabric Capacity Pricing Feels Confusing
What Microsoft Fabric Actually Is
What A Capacity Actually Buys You
What Fabric Capacity Actually Costs
The F64 Line That Changes Everything
Bursting, Smoothing, and What Happens When You Go Over
How To Keep The Bill Under Control
The Mistakes That Catch Most Beginners
The Recap And A Question For You

Hybrid Identity in 2026: Entra Connect Sync vs Cloud Sync and When to Move

Fri, 06 Nov 2026 14:00:02 +0000

Hybrid identity is still the reality in many organizations, but the sync options and the reasons to move have evolved. In this episode of M365 FM, we compare Entra Connect Sync and Entra Cloud Sync: architecture, supported scenarios, limitations and migration considerations.
You will learn how to decide when to stay, when to move and how to plan the transition.
Who it is for: Identity admins, Entra ID architects and infrastructure teams.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Fabric Lakehouse - Simply Explained

Fri, 06 Nov 2026 12:00:03 +0000

Your sales team has a spreadsheet. Finance has a database.

In this episode of Simply Explained you will learn:

Opening: The Data Problem and the Head Fake, 100 words
The Old Split: Data Lake vs. Data Warehouse, 550 words
What a Fabric Lakehouse Actually Is
OneLake and Delta Tables: The Shared Foundation
From Raw Files to Trusted Tables: The Medallion Flow
SQL Analytics Endpoint and Power BI: Using the Data
Why Beginners Should Start With the Lakehouse
Conclusion: One Place, One Shared Story

Microsoft Graph PowerShell SDK - Simply Explained

Fri, 06 Nov 2026 10:00:15 +0000

Microsoft retired two of the admin modules that PowerShell scripts relied on for years, and the replacement is friendlier than it sounds. That replacement is the Microsoft Graph PowerShell SDK, the same Microsoft Graph layer that sits behind a lot of the admin tools you already click.

In this episode of Simply Explained you will learn:

What the Microsoft Graph PowerShell SDK actually is
The single front door that is Microsoft Graph
How you sign in and what permissions really mean
Your first commands, from listing users to messaging Teams
The everyday admin jobs it quietly replaces
The mistakes and limits that catch almost everyone
Why the old Azure AD modules are gone for good
Where this fits next to Azure, the portal, and Graph Explorer
What to remember and where to go next

Intune Security Baselines: Hardening Endpoints Without Breaking Users

Fri, 06 Nov 2026 08:00:04 +0000

Security baselines harden devices quickly, and they can also break line-of-business apps if rolled out blindly. In this episode of M365 FM, we cover how to evaluate, pilot and deploy Intune security baselines: versions, conflicts, exceptions and monitoring.
You will learn how to raise the endpoint security level step by step without disrupting users.
Who it is for: Intune and endpoint security administrators, device security architects.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Copilot Studio Multi-Agent Workflows - Simply Explained

Fri, 06 Nov 2026 06:00:02 +0000

Multi-agent sounds like a swarm of robots passing work around. Inside Copilot Studio, it's closer to one agent playing manager and handing jobs to a few specialists.

In this episode of Simply Explained you will learn:

Why one AI agent hits a wall
What Copilot Studio actually is
What makes an agent multi-agent
Child agents versus connected agents
How a request moves through the system
Where this fits in Microsoft 365 and Azure
The mistakes that break multi-agent setups
A quick recap and a question for you

Azure VPN Gateway - Simply Explained

Thu, 05 Nov 2026 18:00:02 +0000

The Azure service that scares beginners the most turns out to be the simple one. It's called Azure VPN Gateway, and the name is heavier than the job.

In this episode of Simply Explained you will learn:

What Azure VPN Gateway Actually Is
Site-to-Site Versus Point-to-Site
Gateway SKUs and Tunnels
Route-Based Versus Policy-Based
BGP and Active-Active
VPN Gateway Versus ExpressRoute
Common Troubleshooting
Recap and Open Question

Microsoft Copilot Studio Triggers - Simply Explained

Thu, 05 Nov 2026 16:00:02 +0000

Most people picture an AI agent as something you talk to, a chatbot that sits there until you type. Triggers are the part that lets it move first.

In this episode of Simply Explained you will learn:

What a trigger actually is
The two families of triggers, one you start and one that starts itself
How a topic trigger figures out what you mean
How an event trigger lets your agent act on its own
Three everyday examples that make triggers click
What triggers cost, because they are not free
The limits and the mistakes beginners make
Where all of this lives in Microsoft 365 and Azure
A quick recap and one question for you

Measuring Copilot Value: Adoption Metrics That Go Beyond Active Users

Thu, 05 Nov 2026 14:00:02 +0000

Active users tell you who tried Copilot, not whether it helped. Value needs better questions. In this episode of M365 FM, we discuss adoption metrics beyond active use: task-level outcomes, time effects, quality, role-based scenarios and how to avoid vanity numbers.
You will learn how to define useful success measures and report them credibly.
Who it is for: Copilot program owners, adoption managers and IT leaders accountable for results.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Power BI Performance Optimizer - Simply Explained

Thu, 05 Nov 2026 12:00:02 +0000

Your Power BI report isn't slow because of a bug. It's slow because of a decision somebody made long before that report existed, and it's rarely the decision people blame first.

In this episode of Simply Explained you will learn:

Why a slow Power BI report is rarely a Power BI problem
What people mean by a performance optimizer
The optimizer already sitting in your ribbon
The biggest lever sits under the report
Import, DirectQuery, and Direct Lake
Fewer visuals, tighter filters
The layer nobody thinks about
Copilot as a first-pass optimizer
What to remember, and one question for you

Power BI DAX - Simply Explained

Thu, 05 Nov 2026 10:00:15 +0000

Power BI hides over two hundred and fifty functions behind one small formula bar, and the name for that whole toolbox is DAX. It stands for Data Analysis Expressions, and it's the language that turns your imported tables into answers clicking can't reach.

In this episode of Simply Explained you will learn:

Why DAX Looks Harder Than It Is
What DAX Actually Is
How DAX Is Different From Excel
Measures and Calculated Columns
The One Idea That Trips Everyone Up
What People Actually Build With DAX
Where Beginners Get Stuck, and the Honest Limits
Where DAX Fits in Microsoft 365, Fabric, and Azure
The Short Version, and a Question for You

Microsoft 365 Backup and Recovery: What Native Tools Do Not Protect

Thu, 05 Nov 2026 08:00:04 +0000

Microsoft protects the service, but recovery of your own data is a shared responsibility with limits worth knowing. In this episode of M365 FM, we examine what native tools like retention, recycle bins and versioning cover, where they stop, and when backup is justified.
You will learn how to define recovery objectives, close the gaps and test restore scenarios.
Who it is for: Microsoft 365 admins, backup owners, risk and compliance teams.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Intune App Protection Policies - Simply Explained

Thu, 05 Nov 2026 06:00:04 +0000

Your phone buzzes with a work email, you tap in a short PIN, and your personal apps never even notice. That tiny moment is an Intune app protection policy doing its job, and almost nobody who taps through it understands what just happened.

In this episode of Simply Explained you will learn:

Why your work email asks for a PIN
What an app protection policy actually is
Why companies let work live on personal phones
How the policy follows the app, not the device
What it feels like on a normal day
Where you run into this in Microsoft 365
Where it stops working, and where people get it wrong
How it fits with the rest of Microsoft 365
The one idea worth keeping

Power Automate AI Builder - Simply Explained

Wed, 04 Nov 2026 18:00:02 +0000

It's a Monday morning, and someone on your team is typing invoice totals into a spreadsheet by hand. That exact job is what AI Builder was built to delete, and the tool is sitting inside Power Automate right now, unused.

In this episode of Simply Explained you will learn:

Why Everyone's Suddenly Talking About AI Builder
What AI Builder Actually Is
The Prebuilt Models You Can Use Today
Building a Model From Your Own Documents
Using AI Inside a Power Automate Flow
The Prompt Side, Where You Just Ask
What It Costs, and Why the Rules Just Changed
Where AI Builder Stops and Azure Begins
What To Remember and Where to Start

Microsoft 365 Licensing: How to Stop Overpaying

Wed, 04 Nov 2026 16:00:02 +0000

Overpaying for Microsoft 365 usually comes from unused licenses and overlapping bundles, not from one big mistake. In this episode of M365 FM, we cover how to review license assignments, bundles, add-ons and usage signals, and how to build a repeatable review process.
You will learn where savings typically hide and how to avoid trading savings for lost capabilities.
Who it is for: Microsoft 365 admins, IT procurement, license managers and finance partners.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Power Automate with Teams - Simply Explained

Wed, 04 Nov 2026 14:00:02 +0000

The tool that eats your busywork is already sitting in your Teams app. Power Automate is the part of Microsoft 365 that runs the boring steps for you, and it doesn't ask you to write any code.

In this episode of Simply Explained you will learn:

The Work You Keep Doing By Hand
What Power Automate Actually Is
How Teams and Power Automate Fit Together
Your First Real Example: The Approval That Runs Itself
The Small Chores People Automate Every Day
The Limits Nobody Mentions Until It Breaks
The Mistakes Beginners Make
Where It Fits: Microsoft 365 Today, Azure Tomorrow
What to Take Away and One Question for You

Microsoft Defender XDR: Building Detection Beyond the Defaults

Wed, 04 Nov 2026 12:00:03 +0000

Default detections are a starting point. Good detection engineering adds your context on top. In this episode of M365 FM, we discuss how to build detection beyond the defaults in Microsoft Defender XDR: custom detections, advanced hunting, tuning and response automation.
You will learn how to move from alert handling to a repeatable detection practice.
Who it is for: SOC analysts, security engineers and Defender administrators.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Researcher and Analyst Agents in Microsoft 365 Copilot - Simply Explained

Wed, 04 Nov 2026 10:00:15 +0000

Two agents, Researcher and Analyst, sit inside your Copilot, and almost nobody opens them. You use Copilot for the quick stuff, the summaries and the short drafts, and you assume that's all it does.

In this episode of Simply Explained you will learn:

Two new agents just landed inside your Copilot
What Researcher actually does
What Analyst actually does
Researcher or Analyst: which one do you reach for
How they actually reason under the hood
What you need to get started, and what it costs
The honest limits and common mistakes
Where this fits in Microsoft 365 and Azure
What to remember before you try them

Microsoft Loop and Copilot Pages: Where Collaboration Content Should Live

Wed, 04 Nov 2026 08:00:04 +0000

Loop components and Copilot Pages add new places where content can live, and new questions about where it should. In this episode of M365 FM, we look at how Loop, Copilot Pages, SharePoint, OneDrive and Teams fit together and how storage, sharing and lifecycle behave.
You will learn how to set practical guidance for where collaboration content belongs and how to govern it.
Who it is for: Microsoft 365 admins, collaboration managers and information governance teams.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Copilot Studio - Simply Explained

Wed, 04 Nov 2026 06:00:04 +0000

You can build a working AI agent without writing a single line of code. Copilot Studio is Microsoft's workshop for that, a place where you describe the assistant you want and connect it to the documents and systems it should know about.

In this episode of Simply Explained you will learn:

Why Copilot Studio Feels Complicated Before You Start
What Copilot Studio Actually Is
The Pieces That Make an Agent Work
Building Your First Agent Without Writing Code
What People Actually Use It For
How Copilot Studio Fits With Microsoft 365 and Azure
The Mistakes Beginners Keep Making
The Limits You Should Know Before You Start
A Short Recap and One Question for You

Power BI Get Data - Simply Explained

Tue, 03 Nov 2026 18:00:02 +0000

Your Power BI report is showing last month's numbers, and the reason is hiding in the very first thing you clicked. That first click is called Get Data, and it's the moment Power BI reaches out and pulls your information in.

In this episode of Simply Explained you will learn:

The Front Door To Your Data
What Get Data Actually Means
The Four Steps Behind Every Connection
Where Your Data Can Come From
Import Or DirectQuery: The Choice That Shapes Everything
Keeping Your Data Fresh
The Mistakes Beginners Actually Make
Where This Fits In Microsoft 365, Azure, And Fabric
What To Take Away

Microsoft Edge for Business - Simply Explained

Tue, 03 Nov 2026 16:00:02 +0000

Microsoft Edge for Business is not a second browser you have to install. It's the same Edge you already use, quietly told to behave differently the moment you sign in with a work account.

In this episode of Simply Explained you will learn:

What Edge for Business Actually Is
The Work Profile and the Personal Profile
Who Controls the Browser
Internet Explorer Mode, Explained Simply
Managing Extensions Without the Chaos
The Security Layer Underneath
Copilot in Edge, and What It Does
How It Gets Rolled Out
Recap and One Question

Microsoft Secure Score: Improving Security Posture Without the Checkbox Trap

Tue, 03 Nov 2026 14:00:02 +0000

Secure Score can guide your priorities, or it can turn into a checkbox exercise. The difference is how you use it. In this episode of M365 FM, we examine how to read Secure Score recommendations in context: impact, user effect, risk reduction and ownership across teams.
You will learn how to prioritize improvements, avoid chasing points for their own sake and report progress that leadership can follow.
Who it is for: Security administrators, Microsoft 365 admins and CISOs.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Graph API Permissions - Simply Explained

Tue, 03 Nov 2026 12:00:03 +0000

One Graph permission can hand an app every mailbox in your company. Most people never notice that line until a security review points at it, because the permission sits quietly inside an app somebody set up months ago.

In this episode of Simply Explained you will learn:

The Checkpoint Every App Has to Pass
What a Graph Permission Actually Is
The Two Kinds of Permission Nobody Separates at First
How to Read a Permission Name Like a Sentence
Who Gets to Say Yes
The Trap of Asking for Too Much
Where This Breaks Down
How This Fits Into Your Microsoft 365 and Azure World
What to Take Away

Microsoft Copilot Actions - Simply Explained

Tue, 03 Nov 2026 10:00:16 +0000

Copilot Actions is the part of Copilot that stopped answering and started doing. It's a set of specific, defined things Copilot is allowed to do inside your calendar, your files, and your business systems.

In this episode of Simply Explained you will learn:

The Part of Copilot That Stopped Answering
The One Idea That Makes All of This Make Sense
Agents, Actions, and Connectors, Explained Simply
How a Plain Request Becomes a Real Task
What This Looks Like in a Normal Workday
Where This Lives in Microsoft 365 and Azure
The Limits Nobody Puts in the Demo
The Risk Worth Knowing Before You Let It Act
What to Do Next

Phishing-Resistant MFA: Rolling Out Passkeys in Microsoft Entra

Tue, 03 Nov 2026 08:00:03 +0000

Not every MFA method protects against modern phishing. Passkeys change what is possible, and what is required in rollout planning. In this episode of M365 FM, we cover rolling out passkeys and other phishing-resistant methods in Microsoft Entra: authentication strengths, registration, conditional access and recovery.
You will learn how to sequence a rollout, handle edge cases and avoid locking users out during the transition.
Who it is for: Identity architects, Entra ID admins and security teams.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Agent 365 Admin Center - Simply Explained

Tue, 03 Nov 2026 06:00:04 +0000

Somewhere in your company, an AI agent is reading your files, and the only place that knows who owns it is a page most people never open. That sounds dramatic, but it is just the normal state of AI at work right now.

In this episode of Simply Explained you will learn:

What an AI agent actually is
Why agents pile up and why that becomes a problem
What the Agent 365 admin center actually is
The agent registry: one list for every agent
What an admin can actually do to an agent
Reading the dashboard: usage, risk, and the agent map
Common mistakes and honest limits
How it fits with Microsoft 365 and Azure
A quick recap and a question for you

Power BI Workspace Roles - Simply Explained

Mon, 02 Nov 2026 18:00:02 +0000

You gave your teammate a seat in Power BI without reading the rules. Most of us assume the share button controls what people see, but the real control sits in a role you picked in one click.

In this episode of Simply Explained you will learn:

What a Power BI Workspace Role Actually Is
The Four Seats in a Workspace
What Each Role Can and Cannot Do
The Viewer Role Sees More Than You Think
Apps, Sharing, and the Wider Audience
Why the License Question Keeps Coming Up
Roles Are Not the Same as Row-Level Security
Where This Sits in Microsoft 365 and Azure
The Mistakes Beginners Make With Roles
The Short Version, and a Question for You

Power Automate Governance: Managing Flows at Enterprise Scale

Mon, 02 Nov 2026 16:00:03 +0000

Cloud flows are easy to create and easy to forget, which is exactly why governance has to be designed early. In this episode of M365 FM, we discuss governing Power Automate at enterprise scale: environments, DLP policies, ownership, connectors, monitoring and lifecycle.
You will learn how to keep citizen automation productive while keeping an overview of risk, ownership and cost.
Who it is for: Power Platform admins, center-of-excellence teams and automation architects.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Fabric Mirrored Databases - Simply Explained

Mon, 02 Nov 2026 14:00:03 +0000

Microsoft Fabric can keep a copy of your database current within about fifteen seconds. That copy sits next to the rest of your data, and it stays in sync without you building pipelines or running jobs overnight.

In this episode of Simply Explained you will learn:

What a Mirrored Database Actually Is
Why This Exists at All
How the Copy Stays in Sync
What You Get Once It's Running
Where Your Data Can Come From
Where This Pays Off in Real Life
What It Costs, and Why That Surprises People
The Limits You Should Know Before You Start
How This Fits With Azure, Microsoft 365, and Power BI

Microsoft Fabric Real-Time Hub - Simply Explained

Mon, 02 Nov 2026 10:00:16 +0000

The most useful tool in Microsoft Fabric is one you never have to install. Real-Time Hub is the one place where all your live, flowing data shows up, and every Fabric tenant already has it switched on.

In this episode of Simply Explained you will learn:

The Tool That's Already Switched On
What Real-Time Hub Actually Is
The Three Jobs It Does
Meet the Four Pieces That Do the Work
A Real Example, Step by Step
Where It Fits With Microsoft 365 and Azure
The Honest Limits and What It Costs
The Mistakes Beginners Make
What to Take Away

Purview Insider Risk Management: Setting It Up Without Alienating Employees

Mon, 02 Nov 2026 08:00:04 +0000

Insider risk tooling touches people, not just systems, so the rollout needs trust as much as configuration. In this episode of M365 FM, we explore how to set up Microsoft Purview Insider Risk Management responsibly: scope, policies, privacy settings, roles and communication with HR and legal.
You will learn how to start with a narrow, well-explained scope and build a program employees can accept.
Who it is for: Security, compliance, HR and legal stakeholders and Purview administrators.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Copilot Pages - Simply Explained

Mon, 02 Nov 2026 06:00:03 +0000

You asked Copilot something brilliant, and the answer vanished the moment you closed the chat. That's the quiet problem with every AI chat, because once you scroll away, the good stuff is gone for good.

In this episode of Simply Explained you will learn:

What Copilot Pages actually is
Where Copilot Pages came from
How Copilot Pages actually works
How you actually use it day to day
Working with your team on a page
Where Copilot Pages sits in Microsoft 365
How it fits with Azure and the platform underneath
The mistakes people make and the honest limits
What this means for you

Microsoft Dataverse Tables - Simply Explained

Sun, 01 Nov 2026 18:00:02 +0000

The spreadsheet holding your team together is one accidental delete from disaster. Two people open it at once and the numbers drift apart.

In this episode of Simply Explained you will learn:

What a Dataverse table is
Why a table beats a spreadsheet or a SharePoint list
The parts of a table you'll work with
How tables connect through relationships
The different kinds of tables you'll meet
How Dataverse keeps your data safe
Where Dataverse sits in Microsoft 365 and Azure
The limits and mistakes that catch beginners
A short recap and a question for you

Power BI Gateways - Simply Explained

Sun, 01 Nov 2026 16:00:02 +0000

Picture a finance team opening their Power BI dashboard on a Monday morning and finding numbers from last Thursday. The data was fine, but the machine holding the connection had gone to sleep.

In this episode of Simply Explained you will learn:

Why Your Reports Sometimes Stop Updating
What a Gateway Actually Is
Why Your Data Can't Just Float Into the Cloud
The Round Trip Your Data Takes
The Three Kinds of Gateway
Where Gateways Fit in Microsoft 365 and Azure
The Limits Worth Knowing Before You Plan
The Mistakes That Cause Most Gateway Trouble
How to Think About Gateways as You Grow

Sensitivity Labels Rollout Playbook: From Pilot to Production

Sun, 01 Nov 2026 14:00:02 +0000

Sensitivity labels succeed or fail on rollout design, not on the licensing line item. In this episode of M365 FM, we outline a practical path from pilot to production: label taxonomy, default behavior, user communication, auto-labeling and how to measure adoption.
You will learn how to keep the label set small, avoid common user frustration and move from a pilot group to the whole organization.
Who it is for: Information protection owners, Purview admins, compliance and security teams.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Copilot Agents - Simply Explained

Sun, 01 Nov 2026 12:00:02 +0000

The Copilot on your screen can now do more than answer questions. It can finish the task, and that version has a name.

In this episode of Simply Explained you will learn:

What Copilot Agents Are
How a Copilot Agent Actually Works
Where Copilot Agents Live in Microsoft 365 and Azure
What Copilot Agents Look Like in Real Work
How to Build One Without Writing Code
The Mistakes Beginners Make
The Limits You Should Know About
What to Remember and One Question for You

Azure Web Application Firewall - Simply Explained

Sun, 01 Nov 2026 10:00:15 +0000

Azure Web Application Firewall is not the firewall you are picturing. A normal firewall mostly watches where traffic is going, while this one reads what the traffic says.

In this episode of Simply Explained you will learn:

What Azure Web Application Firewall Actually Does
Why a Website Needs Its Own Kind of Firewall
Where Azure Web Application Firewall Actually Lives
How the Rules Decide What to Block
Detection Mode, Prevention Mode, and the Tuning Window
Bots, Floods, and What This Tool Cannot Do
What Azure Web Application Firewall Costs
Watching the WAF Do Its Job
Where This Fits in Your Microsoft 365 World
The Short Version, and One Question for You

SharePoint Information Architecture That Survives Copilot

Sun, 01 Nov 2026 08:00:03 +0000

Copilot can only work with what your SharePoint structure lets it find and what your permissions let it see. In this episode of M365 FM, we look at information architecture for SharePoint Online in the Copilot era: sites, hubs, content types, metadata, navigation and permissions.
You will learn how to structure content so that it stays findable, governable and safe to surface through Copilot.
Who it is for: SharePoint architects, information managers, Microsoft 365 admins and Copilot rollout teams.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Power BI Relationships - Simply Explained

Sun, 01 Nov 2026 06:00:03 +0000

You can build a clean Power BI report that hands you the wrong numbers. You have five tables, clean columns, a report that looks finished, and every row still shows the same total.

In this episode of Simply Explained you will learn:

Why your numbers go wrong when tables don't talk
What a relationship is, in plain terms
Cardinality, the word that decides which table leads
Which way the filters travel
Reading the solid and dashed lines
The star shape that keeps a model simple
The rules a relationship has to follow
Where beginners get burned
What a relationship can't do
Where this fits in Microsoft 365 and Fabric

SAML - Simply Explained

Sat, 31 Oct 2026 18:00:02 +0000

Last Tuesday, someone at your company opened Salesforce without typing a password. There was no reset email and no help desk ticket.

In this episode of Simply Explained you will learn:

One Login That Opens Every Door
What SAML Actually Means
The Two Sides of the Handshake
The Round Trip Behind That Login
What's Inside the Signed Note
Two Ways the Trip Can Start
Where SAML Lives in Microsoft 365 and Azure
When SAML Breaks
SAML, OAuth, and OpenID Connect
The Short Version

SAP S-4HANA - Simply Explained

Sat, 31 Oct 2026 16:00:02 +0000

SAP S/4HANA sounds intimidating, yet most companies running SAP ECC have to decide where it lives and how to migrate before the 2027 deadline. This plain-language episode is for IT and business people who need to understand what S/4HANA is, how it connects to Microsoft tools, and where projects usually go wrong.

In this episode

00:00 – What SAP S/4HANA actually is
01:42 – Why the in-memory database changed everything
03:57 – Fiori, the Universal Journal and end-to-end flows
06:56 – On premise, private cloud, public cloud or hybrid
08:28 – Migration paths and the 2027 deadline
10:04 – Keeping the core clean
11:00 – Where S/4HANA meets Microsoft
12:56 – Honest limits and common mistakes

Key takeaways

SAP S/4HANA is an ERP system rebuilt on the in-memory, column-based HANA database, which lets analytics and transactions run on one shared copy of the data.
Every company on SAP ECC must choose a deployment model and a migration path (greenfield, brownfield or bluefield) before mainstream maintenance ends in 2027.
Keeping a clean core and integrating through Microsoft Fabric, Entra ID and Power Platform connectors pays off in upgrades, while data cleanup and process change are the real cost of migration.

Worth quoting

“S four Hana isn't one product so much as a shared set of processes built on one shared source of data, and the value comes from how tightly those pieces fit together.” – Mirko Peters (06:52)

“Public cloud gives you fewer upgrade headaches and less control, while private cloud and on premise give you more control and more work to carry.” – Mirko Peters (08:08)

Explore more on M365.FM

Episode page: the full plain-language episode with chapters, quotes and FAQ on SAP S/4HANA
Microsoft Fabric – pulls SAP data in through built-in connectors and mirroring so reports stay current
Microsoft Entra ID – handles sign-on and MFA for SAP apps like Fiori, while SAP keeps authorization
Power Platform – connects to SAP through connectors and templates so makers build approval flows without code
Power BI – refreshes reports with new SAP figures via Fabric so readers never log into SAP
Related episode: What Happens When Sales Promises an Urgent Order

Follow and rate M365.FM in your podcast app, and join the free M365 community at m365con.net.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Teams Phone Migration: Moving From a PBX to Cloud Calling Without Surprises

Sat, 31 Oct 2026 14:00:02 +0000

Moving from a PBX to cloud calling is rarely a pure technology project. Numbers, devices, sites and people all have their own timelines. In this episode of M365 FM, we cover how to plan a Teams Phone migration: inventory and number planning, calling plans or direct routing, devices, emergency calling and user adoption.
You will learn how to sequence the migration, which surprises tend to appear late in the project, and how to reduce them early.
Who it is for: Telephony and collaboration engineers, Microsoft Teams admins and IT project leads replacing a legacy PBX.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Fabric Direct Lake - Simply Explained

Sat, 31 Oct 2026 12:00:02 +0000

Power BI used to force a choice between fast but stale import reports and fresh but slow DirectQuery. This episode explains Direct Lake in Microsoft Fabric for analysts and admins who want both. You learn how framing works, which of the two flavours to pick, what licensing it needs and which mistakes make it slow.

In this episode

00:00 – Why fast and fresh rarely happen together
02:15 – What Direct Lake actually is
04:31 – How it works under the hood
06:49 – The two flavors of Direct Lake
08:59 – Where Direct Lake fits in the Microsoft stack
10:42 – Mistakes that make Direct Lake slow
13:10 – What to remember

Key takeaways

Direct Lake lets Power BI read Delta tables straight from OneLake, combining import-like speed with data that stays close to live.
A Direct Lake refresh is called framing: it only updates pointers to the newest files, while transcoding loads just the columns a query needs.
Direct Lake requires a paid Fabric capacity and rewards tidy Delta tables, so overwrites, tiny files and poor partitioning make it feel slow.

Worth quoting

“A stale number doesn't announce itself. It looks exactly like a fresh one, and someone makes a decision on it before anyone notices.” – Mirko Peters (01:28)

“Instead of dragging your data into the report, direct lake points the report at those files and reads them where they sit.” – Mirko Peters (03:02)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Direct Lake
Power BI – the reporting layer whose new Direct Lake storage mode replaces the import versus DirectQuery trade-off
Microsoft Fabric – the home of Direct Lake, which needs a paid Fabric capacity to run
Microsoft Azure – where Fabric capacities are bought and billed by the second, per the episode
Related episode: Bad Machine Data: Fixing Data Quality Before It Reaches Power BI

The Dataverse Security Model Explained for Architects

Sat, 31 Oct 2026 10:00:12 +0000

Most Dataverse security problems start when access is granted one ticket at a time instead of by structure. This episode walks architects through business units, security roles, teams, ownership, column and hierarchy security, and sharing, and shows how to design a model that survives reorgs, audits and Copilot.

In this episode

00:00 – The question Dataverse security actually answers
03:11 – The four layers and the environment boundary
08:34 – Business units and why trees break at scale
18:15 – Security roles, privileges and access depth
25:10 – Record ownership and teams
37:15 – Column-level security and hierarchy security
51:45 – Sharing, its cost and how access is evaluated
64:01 – Role and team design, anti-patterns and governance

Key takeaways

Dataverse security decides which rows a user can reach by combining identity, privilege, scope and record ownership, and access is always additive.
Business units should model real data boundaries such as legal, regulatory or contractual walls, not the org chart, and teams should own long-lived data.
Sharing, organization depth and one-off roles are shortcuts that erode the model, so roles, teams and profiles belong in solutions with reviews and auditing.

Worth quoting

“A Dataverse security model only scales when it's designed around ownership and hierarchy, not around individual access requests.” – Mirko Peters (00:12)

“So treat organization depth the way you treat a master key. A small number of people need it admins, integration accounts, maybe a data steward or two.” – Mirko Peters (24:28)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ
Dataverse – the platform whose row-level security model of units, roles, teams and ownership is dissected
Microsoft Entra – security groups gate who can enter an environment, and Entra group teams drive team membership
Governance – solutions, reviews, access recertification and documentation that keep roles and teams from drifting
Related episode: Dataverse - Simply Explained

Azure Virtual Desktop - Simply Explained

Sat, 31 Oct 2026 08:00:03 +0000

Azure Virtual Desktop runs your Windows desktops up in Microsoft's cloud, not on the laptop in front of you. The name makes it sound like one big product, but it's really a handful of simple pieces, and each piece has a plain job.

In this episode of Simply Explained you will learn:

What Azure Virtual Desktop Actually Is
The Pieces You Actually Touch
Two Ways to Hand Out a Desktop
Where Your Files Live When the Machine Isn't Yours
How a User Actually Connects
Why the Bill Changes Every Month
The Mistakes and the Real Limits
When It Beats Windows 365 and Plain VDI
What to Take Away From All of This

Windows 365 or Azure Virtual Desktop: Choosing the Right Cloud PC Model

Sat, 31 Oct 2026 06:00:02 +0000

Choosing between Windows 365 and Azure Virtual Desktop is less about features and more about who will run the platform and how the workload behaves. In this episode of M365 FM, we compare the operating models behind both cloud PC options: management effort, cost behavior, scaling, image handling and user experience.
You will learn which workloads fit a Cloud PC and which fit a pooled host pool, and which questions to answer before you commit.
Who it is for: Microsoft 365 and Intune admins, end-user computing architects and IT managers planning a virtual desktop strategy.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Windows Update Management: Autopatch, Update Rings and Feature Updates Explained

Fri, 30 Oct 2026 17:00:02 +0000

Most teams still treat Windows patching as a monthly event, while updates now run continuously and exploits arrive within days. This episode walks IT admins through Windows Update for Business, Intune update rings, feature update policies, Windows Autopatch, expedited updates, drivers, reporting and troubleshooting. You will leave with an operating model that turns patching into governed, measurable change.

In this episode

00:00 – Patching is not an event
01:12 – The old model and why it breaks
06:04 – Desired state and Windows Update for Business
15:56 – Update rings, deadlines and feature update policies
32:33 – What Windows Autopatch actually is
49:18 – Expedited updates and drivers
59:50 – Failures, reporting and metrics
83:47 – From patching devices to governing change

Key takeaways

Modern Windows updates run as a continuous, client-side system: Intune declares the policy and Windows Update for Business delivers, wherever the device is.
Design staged rings with real deadlines, pin feature versions deliberately against the support calendar, and use Autopatch to automate execution, not accountability.
Measure exposure windows and time to patch instead of a single compliance percentage, and give policy, pilots and exceptions named owners with a monthly review.

Worth quoting

“Patch Tuesday was never meant to be a deadline. It was a signal. Microsoft was telling you that new updates were available and that the clock had started.” – Mirko Peters (01:59)

“The cost of delay is invisible. Nothing happens until it does. And when it does, it's not a ticket. It's an incident.” – Mirko Peters (05:35)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Windows update management
Microsoft Intune – the policy plane where update rings, feature update policies, expedites and reports live
Microsoft Entra ID – devices must be Entra ID joined or hybrid joined before Windows Autopatch accepts them
Governance – the closing argument that continuous change needs continuous governance with named owners
Mirko Peters – host of this episode, who asks listeners for their next topic in the outro
Related episode: Group Policy - Simply Explained

Azure AI vs Copilot vs Fabric AI - Simply Explained

Fri, 30 Oct 2026 13:55:01 +0000

Azure AI, Copilot and Fabric AI sound like rivals, and Microsoft's constant renaming makes it worse. This episode untangles the three for beginners and career changers, showing what each layer does, its honest limits and costs, and how they fit together. You'll know which one you'll actually touch first and where to start learning.

In this episode

00:00 – The three names that confuse everyone
02:00 – Copilot, the assistant in your apps
04:01 – How Copilot knows about your work
05:40 – The honest limits of Copilot
07:32 – Fabric, where your data lives
09:22 – Fabric AI: Copilot for your data
11:01 – Azure AI Foundry, the builders' workshop
12:51 – How the three fit together

Key takeaways

Copilot, Fabric and Azure AI (now Microsoft Foundry) are three stacked layers of one Microsoft stack, not competing products.
Copilot only surfaces what a user can already access, so cleaning up overshared permissions and training people matter more than buying licenses.
Start with Copilot where your work already happens, add Fabric if you live in reports and data, and turn to Foundry only when you need to build custom AI tools or agents.

Worth quoting

“Copilot only sees what you can already see. It doesn't get a master key to the company” – Mirko Peters (05:08)

“Copilot is a capable tool, and it isn't a magic wand. The first limit is that copilot doesn't fix bad permissions. It exposes them.” – Mirko Peters (05:47)

Explore more on M365.FM

Microsoft 365 Copilot – the assistant inside Word, Excel, Outlook and Teams that most listeners will touch first
Microsoft Fabric – the data platform where company numbers land, get shaped and turn into Power BI reports
Microsoft Foundry – the current name for Azure AI Studio and Azure AI Foundry, the builders' workshop
Microsoft Azure – the cloud behind Azure AI and Azure OpenAI, though Fabric needs no Azure account
AI agent – a model with instructions and tools that takes action, mostly built in Foundry or Copilot Studio
Related episode: Power Platform Copilot Integration - Simply Explained

FinOps for Manufacturing IT: Controlling Cloud Cost for Industrial Workloads

Fri, 30 Oct 2026 06:25:02 +0000

Factories running the same machines often pay more to collect, process and keep the data those machines produce each shift. This episode is for manufacturing IT, platform engineers and finance teams who need to control Azure and Microsoft Fabric costs without losing the evidence behind downtime and quality investigations. It walks through baselines, telemetry, retention, capacity, commitments and fair allocation across plants.

In this episode

00:00 – Why factory cloud costs grow
04:08 – FinOps ownership in manufacturing
07:32 – Building a shared cost baseline
14:05 – Telemetry, gateways and delivery
32:06 – Retention and storage tiers
44:03 – Fabric capacity and shared compute
56:38 – Commitments and reservations
70:33 – Allocation, showback and chargeback

Key takeaways

In manufacturing, cloud spend follows data handling decisions, so every cost change needs a named owner who understands the evidence and service level the plant depends on.
A shared cost baseline, deliberate retention and storage-tier choices, and tested Fabric capacity sizing prevent savings that silently remove fault or quality evidence.
Commitments, allocation rules and showback before chargeback only work when unused commitment, shared fixed costs and funding authority are made explicit.

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on factory cloud cost control
FinOps – framed as shared engineering work between platform, plant, finance and procurement owners
Microsoft Fabric – its shared capacity units, smoothing and throttling decide how plant workloads get sized
Microsoft Azure – where machine readings land, with Cost Management, Blob Storage tiers and reservations discussed
Fabric workspace – workspaces on one capacity share compute, so placement and ownership become cost decisions
Related episode: FinOps - Simply Explained

Single Sign-On (SSO) - Simply Explained

Fri, 30 Oct 2026 05:50:02 +0000

You've signed in twice today and never typed a single password. One login is replacing the dozens of accounts you used to juggle, and it's happening in almost every company.

In this episode of Simply Explained you will learn:

Why One Login Feels Like Magic
The Two Players in Every Login
What Happens When You Click Sign In
Tokens: The Signed Notes That Prove Who You Are
SAML vs OpenID Connect
Microsoft Entra SSO at Work
The Honest Risks
Wrapping Up With One Question

Microsoft Fabric Shortcuts - Simply Explained

Fri, 30 Oct 2026 04:15:01 +0000

Your customer data sits in several clouds and apps, and nobody knows which copy is real. This episode explains Microsoft Fabric shortcuts for beginners and data teams: what they are, where they live, what they can reach, and the trade-offs and mistakes to avoid. You'll learn how to keep one authoritative copy while every team still gets a clean view of the data.

In this episode

00:00 – Why your data lives in too many places
00:41 – What a Fabric shortcut really is
02:46 – Where a shortcut lives: Tables vs Files
04:22 – What you can point a shortcut at
06:19 – A real-company workspace pattern
07:55 – Trade-offs: speed, caching and dependency
09:56 – Mistakes that trip people up
12:00 – Fit with Microsoft 365, Azure and licensing

Key takeaways

A Fabric shortcut is a pointer to data at a target path, so deleting the shortcut never deletes the source data.
Place shortcuts under Tables when the target is Delta and must be queryable in SQL and Power BI, and under Files for raw data you plan to process.
Shortcuts trade copies for dependency and first-read latency, so copy data instead when it needs heavy transformation, must stay in a region, or needs full maintenance control.

Worth quoting

“A shortcut is a pointer, not a copy. And that single idea is the foundation for everything else.” – Mirko Peters (02:35)

“If two teams each keep their own copy of the customer records, you pay to store it twice. Worse, you end up with two versions that drift apart the moment someone updates one copy and forgets the other.” – Mirko Peters (02:07)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on Fabric shortcuts
Microsoft Fabric – the platform whose OneLake storage layer hosts shortcuts that point at data without copying it
Fabric workspace – the unit of the four-workspace pattern with one shared source-of-truth workspace
Microsoft Azure – covers ADLS Gen2 and Blob targets, OneLake's storage base and how Fabric capacity is bought
Power BI – reads Tables shortcuts through a semantic model, including in Direct Lake mode
Related episode: Microsoft Fabric for Microsoft 365 Admins: What You Need to Know

Power Query - Simply Explained

Fri, 30 Oct 2026 02:50:01 +0000

If you clean the same spreadsheet by hand every month, Power Query can turn that ritual into a process that repeats itself. This beginner-friendly episode explains the four phases, applied steps, the M language, merge versus append and the habits that keep queries fast, for Excel and Power BI users who want to stop doing manual cleanup.

In this episode

00:00 – What Power Query actually is
02:06 – Where you'll run into it
03:06 – The problem it solves
04:28 – The four phases and applied steps
07:07 – The M language underneath the buttons
08:18 – Merging, appending, data types and locale
10:40 – Refresh
11:43 – Where beginners go wrong and recap

Key takeaways

Power Query is the data transformation engine built into Excel, Power BI and other Microsoft tools, and every click becomes a recorded, replayable step.
The workflow follows four phases—connect, transform, combine and load—and refresh reruns the saved steps without changing the source data.
Setting data types (with locale) early, filtering at the top and understanding query folding keep queries correct and fast.

Worth quoting

“The real problem is that your clean up can't run itself again, so every new file drags you back to the same manual steps.” – Mirko Peters (03:44)

“The manual cleanup lives in your memory and disappears when you close the file, while the recorded one waits for you and runs again on demand.” – Mirko Peters (06:58)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a beginner FAQ
Power Query – the data preparation engine this episode explains, from applied steps to query folding
Microsoft Excel – where Power Query sits on the Data tab under Get & Transform, with manual refresh
Power BI – the second front door to Power Query, shaping data before reports and offering scheduled refresh
Connector – how Power Query reaches hundreds of sources, from text files to SQL Server databases
Related episode: What Happens When Sales Promises an Urgent Order

Traceability and Genealogy: Tracking Every Part From Supplier to Customer

Thu, 29 Oct 2026 22:50:01 +0000

When a supplier reports a suspect batch, many manufacturers cannot prove which products actually contain it. This episode is for quality managers, MES and ERP owners and manufacturing IT teams who need traceability that holds up in recalls and audits. You will learn how to design identities, genealogy records, integrations and investigations that support defensible decisions.

In this episode

00:00 – What the quality team needs to decide
03:35 – A pump plant as the reference example
07:14 – Traceability, genealogy and provenance
10:53 – Tracking depth and identity rules
18:50 – Receipt, containers and material consumption
33:48 – Splits, rework and process evidence
53:30 – Ownership, integration and the Azure architecture
73:47 – Evidence, compliance, investigation and rollout

Key takeaways

Write traceability requirements backward from the recall and containment decisions your quality team must be able to defend.
Record material contributions as explicit relationships captured at the moment of use, with identities, quantities and evidence sources, instead of copying planned bills of materials.
Cloud services such as Azure and Microsoft Fabric can carry and analyze the records, but owners, tested event contracts, mock recalls and human approval decide whether the evidence holds.

Explore more on M365.FM

Episode page: the full episode with chapters and FAQ on genealogy, integration and recalls
Microsoft Azure – the cloud platform whose services are placed around capture, replay and reconciliation duties
Azure Event Hubs – suggested for streams of production events that several consumers process independently
Microsoft Fabric – brings production, shipment and quality data together for investigations without owning holds
Azure Service Bus – suggested for application messages that need queues, topics, locks and dead letter handling
Related episode: Azure Event Grid - Simply Explained

Defender for Office 365: Tuning Anti-Phishing and Safe Links Policies

Thu, 29 Oct 2026 18:10:01 +0000

Most tenants run Microsoft Defender for Office 365 on defaults and assume they are protected while attackers test their filters every day. This episode is for email security admins, security engineers and SOC teams who want to tune anti-phishing, Safe Links, Safe Attachments and quarantine into a measurable loop that reduces both missed threats and false positives.

In this episode

00:00 – Why defaults fail: tuning as a measurement loop
03:48 – Plan 1 versus Plan 2 and what you are licensed for
07:04 – Preset security policies and policy precedence
17:20 – Impersonation and anti-phishing policy anatomy
27:35 – SPF, DKIM, DMARC and phishing thresholds
34:20 – Safe Links, Safe Attachments and exception debt
50:25 – Quarantine, false positives and investigation
67:27 – Attack simulation, metrics and the operating rhythm

Key takeaways

Start with the standard and strict preset policies, check which policy actually applies to each user because the first match wins, and keep custom policies only for documented, owned exceptions.
Impersonation protection, Safe Links and Safe Attachments only work as well as the protected lists, DMARC enforcement and do-not-rewrite exceptions behind them, so every exception needs an owner, a reason and an expiry date.
Measure delivered phish, report rate, time to remediate and false positives on a monthly and quarterly rhythm, and use attack simulation and Threat Explorer to tune instead of setting policies once and forgetting them.

Worth quoting

“Tuning isn't a configuration event, it's a measurement loop. You set a policy, you measure what it catches and what it misses. You adjust and you do it again.” – Mirko Peters (00:31)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on policy tuning
Microsoft Defender – the product family behind this episode, from Defender for Office 365 to Defender XDR incidents
Exchange Online – the mail platform whose built-in Exchange Online Protection forms the base layer under Defender
Microsoft Teams – where Safe Links checks shared links and, once switched on, Safe Attachments scans files
Related episode: Data Loss Prevention in Microsoft 365: Policies That Actually Work
Related episode: When Microsoft Messaging Looks Secure but Isn’t — Exchange Server, Hybrid and Microsoft 365 Security with Thomas Stensitzki [MVP]

Azure OpenAI Service - Simply Explained

Thu, 29 Oct 2026 17:50:01 +0000

Azure OpenAI Service is not ChatGPT with a Microsoft logo on it. It runs the same models, but Microsoft hosts them inside your own Azure space, with your own keys, your own limits, and your own privacy rules.

In this episode of Simply Explained you will learn:

What Azure OpenAI Service Is
The Models Behind It
Deployments: Your Own Copy of a Model
Endpoints and Keys: How Apps Connect
Tokens: The Unit Everything Is Measured In
Quotas and Rate Limits: Why You Hit a Wall
Content Filtering: The Guardrails Built In
Data Privacy: The Part That Sells It to IT
How It Differs From the OpenAI API
What People Build With It
A Quick Recap and One Open Question

Microsoft Defender for Business - Simply Explained

Thu, 29 Oct 2026 16:05:01 +0000

Attackers prefer small businesses because fewer people are watching. This episode explains Microsoft Defender for Business for small and medium companies without a security team: what it does, how to set it up, what it costs and where it stops. You will know whether it fits your organization.

In this episode

00:00 – Why attackers target small businesses
00:30 – What Defender for Business is
02:27 – Why antivirus alone isn't enough
04:06 – The four jobs on every device
06:08 – Setting it up
08:22 – Limits before you buy
10:12 – Defender for Business vs. Defender for Endpoint
11:59 – Cost, licensing and recap

Key takeaways

Part of the Microsoft Defender family, Defender for Business brings the same engine as Defender for Endpoint to companies with up to 300 users, packaged with a setup wizard and default policies.
Unlike plain antivirus, its EDR capabilities show what happened, where and what to do next, and can disrupt attacks automatically.
Know the limits before buying: the 300-user cap, five devices per user, separate server licensing and no mixing with Defender for Endpoint Plan 2.

Worth quoting

“A small business isn't too small to be a target, and it's often the easiest way in.” – Mirko Peters (02:18)

“Antivirus answers whether something bad was blocked and EDR answers what happened, where it happened, and what needs to happen next.” – Mirko Peters (03:53)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on setup, limits and cost
Microsoft Defender – the product family here: Defender for Business runs on the Defender for Endpoint engine
Microsoft Intune – one way to onboard Windows and Mac devices and to manage some security settings
Microsoft 365 – Business Premium includes Defender for Business; E3 or E5 suit organizations over 300 users
Related episode: Data Loss Prevention in Microsoft 365: Policies That Actually Work

Exchange Online - Simply Explained

Thu, 29 Oct 2026 15:50:01 +0000

Exchange Online is the email engine inside Microsoft 365, wrapped in words nobody explains. It's the service that holds your mailbox, your calendar, and your contacts, and it runs on Microsoft's servers instead of a machine in your office.

In this episode of Simply Explained you will learn:

What It Actually Is
Inside Your Mailbox
Shared Mailboxes
How Mail Travels
SPF, DKIM, DMARC
Mail Flow Rules
Hybrid or Cloud Only
The Admin Center
Recap and One Question

Microsoft Fabric for Microsoft 365 Admins: What You Need to Know

Thu, 29 Oct 2026 14:55:01 +0000

Microsoft Fabric often appears in a tenant before anyone has planned its governance. This episode gives Microsoft 365 admins the platform view: how capacities, OneLake, workspaces, tenant settings, identity, labels and licensing fit together. It ends with a practical 30-day plan to put owners and guardrails in place before data and costs drift.

In this episode

00:00 – Why Fabric lands on the M365 admin's desk
06:36 – Capacities, throttling and monitoring
18:57 – OneLake: one copy for the tenant
22:09 – Workspaces, items and tenant settings
38:11 – Identity and the layered security model
57:09 – Connecting Microsoft 365 data, Copilot and auditing
75:39 – A 30-day admin plan and common failures

Key takeaways

Fabric runs as one shared platform inside your tenant, so a single capacity is at once a billing object, a performance boundary and a blast radius.
Workspaces are the real unit of control, so every workspace needs a name, an owner, group-based roles and a lifecycle before sprawl sets in.
Security, labels and AI agents only protect what is configured at every layer, so review tenant settings, OneLake access paths and copied Microsoft 365 data early.

Worth quoting

“A capacity unit isn't a server or a machine. It's a measure of how much work the platform can do for you per second, and every action in fabric costs some amount of it.” – Mirko Peters (06:56)

“You stop controlling data by controlling where it lives. You start controlling it by controlling who can reach it.” – Mirko Peters (20:56)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes, FAQ and the 30-day admin plan
Microsoft Fabric – the SaaS data platform running inside your tenant on one compute pool and one bill
Fabric workspace – the real unit of control, needing a name, an owner, group roles and a lifecycle
Microsoft Purview – supplies the sensitivity labels, DLP policies for semantic models and the audit log for Fabric activity
Related episode: Data Loss Prevention in Microsoft 365: Policies That Actually Work

Power BI Calculated Columns vs Measures - Simply Explained

Thu, 29 Oct 2026 14:05:01 +0000

You can build the exact same number in Power BI two different ways, and they behave nothing alike. One of them gets stored inside your data model and follows every single row.

In this episode of Simply Explained you will learn:

Two Ways To Do The Same Thing
What Power BI Is Really Doing When You Click
What A Calculated Column Actually Is
What A Measure Actually Is
The Real Difference Is Where The Calculation Stands
Where Each One Lives In Your Report
The Memory Bill Behind Your Slow Report
The Mistakes Beginners Keep Making
Where This Fits In Microsoft 365, Fabric, And Azure
A Quick Recap And One Question For You

Robotic Process Automation (RPA) - Simply Explained

Thu, 29 Oct 2026 13:20:02 +0000

Every Monday, someone in finance retypes the same numbers into a fifth screen, and nobody checks the result. Software can do that job now, one click at a time, and it doesn't need a developer to set it up.

In this episode of Simply Explained you will learn:

What robotic process automation actually does
Why this suddenly matters right now
How a bot actually does the work
The jobs bots are genuinely good at
Where RPA breaks
The mistakes that sink automation projects
Where RPA fits in Microsoft 365 and Azure
What this means for your career
The short version and one question for you

Group Policy - Simply Explained

Thu, 29 Oct 2026 12:35:02 +0000

Somewhere in your company right now, a rule is telling a computer what to do. You've felt it in the password that has to be long, the drive that appears on its own, and the settings you're not allowed to touch.

In this episode of Simply Explained you will learn:

What Group Policy Actually Does
Why the Same Setting Can Come From Three Places
How Windows Decides Which Rule Wins
When Your Changes Actually Show Up
What This Looks Like in a Real Company
The Mistakes That Trip People Up
Where Group Policy Stops Working
How Group Policy Fits With Microsoft 365 and Azure
The Short Version and a Question for You

Microsoft Dev Box - Simply Explained

Thu, 29 Oct 2026 11:15:02 +0000

Your next work computer might never sit on a desk. Microsoft Dev Box is a full Windows workstation that runs in a Microsoft data center, and you reach it from whatever screen you already own.

In this episode of Simply Explained you will learn:

Why your next work computer might not be in the room
What Microsoft Dev Box actually is
The four pieces that make Dev Box work
What makes a dev box feel like your own PC
A normal Tuesday on a dev box
How Dev Box fits with Microsoft 365 and Azure
The mistakes people make with Dev Box
The honest limits, including the one Microsoft just announced
What to take away, and a question for you

CI/CD Pipelines - Simply Explained

Thu, 29 Oct 2026 10:15:02 +0000

A CI/CD pipeline is a factory line for software, and once you see it that way you can't unsee it. Raw material goes in at one end, a checked and packaged product comes out the other, and the same steps run in the same order every single time.

In this episode of Simply Explained you will learn:

What A Pipeline Actually Is
The Problem It Was Built To Solve
What Continuous Integration Really Means
Delivery Versus Deployment
Walking Through The Stages
Environments And The Gate Before Production
When A Deploy Goes Wrong
The Mistakes That Break Pipelines
Where This Leaves You

Microsoft Teams Governance: Stopping Sprawl Before It Starts

Thu, 29 Oct 2026 09:55:02 +0000

Teams sprawl does not start with bad intent. It starts when creating a team is easy and retiring one is not. In this episode of M365 FM, we look at lifecycle, naming, ownership, templates and expiration for Microsoft Teams, and how they connect to Microsoft 365 groups and SharePoint.
You will learn how to put guardrails in place before sprawl takes hold, and what to do when it already has.
Who it is for: Microsoft Teams admins, collaboration owners and governance leads.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

REST APIs - Simply Explained

Thu, 29 Oct 2026 09:05:01 +0000

You've been using REST APIs for years without knowing their name. Every time Power Automate grabs your calendar or Copilot Studio reads a file, one program is asking another for information.

In this episode of Simply Explained you will learn:

What an API really is
The round trip
The verbs
Resources and addresses
Status codes
JSON: the shared language
Proving who you are
What REST really means
Where you already meet REST

Quality Nonconformance Workflows With Power Platform: From Defect to Corrective Action

Thu, 29 Oct 2026 06:25:02 +0000

A defect becomes expensive when the workflow from detection to corrective action is slow or unclear. In this episode of the iFAKT series, we show how Power Platform can support nonconformance workflows: capture, triage, approvals, corrective and preventive actions, and reporting.
You will learn how to model the process, involve quality teams and integrate with existing systems.
Who it is for: Quality managers, Power Platform makers and manufacturing IT.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

A Pragmatic Industrial Data Platform Roadmap for Mid-Sized Manufacturers

Thu, 29 Oct 2026 06:00:02 +0000

A roadmap for an industrial data platform has to fit mid-sized organizations, not only large enterprises. In this episode of the iFAKT series, we outline a pragmatic sequence: use cases, foundations, governance, ownership and incremental delivery.
You will learn how to prioritize and avoid platform projects that outgrow the team.
Who it is for: CIOs, IT and OT managers and data leaders in mid-sized manufacturers.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure Role-Based Access Control (RBAC) - Simply Explained

Thu, 29 Oct 2026 04:40:02 +0000

Azure role-based access control is really just a keycard, not a light switch. A light switch is either on or off for a whole room, while a keycard opens specific doors for a specific person.

In this episode of Simply Explained you will learn:

What RBAC Actually Does
The Three Pieces of Every Role Assignment
The Four Sizes of Scope
The Roles You'll Actually Meet
Least Privilege Is the Whole Point
Built-In or Build Your Own
Azure Roles Are Not Entra Roles
The Mistakes Everyone Makes
Recap and One Open Question

Low-Code vs Pro-Code - Simply Explained

Thu, 29 Oct 2026 01:55:01 +0000

Most people treat low-code and pro-code as a contest between real development and a shortcut. That framing is the reason so many beginners freeze before they build anything.

In this episode of Simply Explained you will learn:

Two Ways to Build the Same App
What Low-Code Actually Means
What Pro-Code Actually Means
It's a Spectrum, Not a Switch
How You Actually Build With Each
Where Low-Code Wins and Where Pro-Code Wins
The Mistakes and the Honest Limits
How This Fits Microsoft 365 and Azure
The Short Version, and a Question for You

OAuth 2.0 - Simply Explained

Wed, 28 Oct 2026 22:35:01 +0000

Every time you click Sign in with Microsoft, OAuth 2.0 keeps your password out of the app. This episode explains the four players, the flows, tokens and scopes, and how it all works in Microsoft Entra ID and Microsoft Graph, for anyone who approves permission screens or builds apps. You will understand what you are really granting and which mistakes to avoid.

In this episode

00:00 – Why apps never ask for your password
01:56 – The four players in every OAuth handshake
03:31 – What happens when you click Sign in with Microsoft
05:28 – Why there isn't just one OAuth flow
07:16 – Access tokens, refresh tokens and scopes
08:56 – OAuth in Microsoft 365 and Azure
11:21 – Common mistakes and limits

Key takeaways

OAuth 2.0 grants an app limited, temporary access through scoped tokens instead of sharing your password, but it does not prove identity.
The authorization code flow with PKCE is the modern default for user sign-in, while the implicit flow and password grant are deprecated.
In Microsoft 365, Microsoft Entra ID issues the tokens and Microsoft Graph accepts them, with delegated or application permissions granted by least privilege.

Worth quoting

“OAuth stands for open Authorization, and it's the standard that lets one app reach your data inside another app without ever holding your password.” – Mirko Peters (00:31)

“You might think OAuth is about signing you in, and it's actually about granting access, not proving identity.” – Mirko Peters (01:40)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on OAuth 2.0
Microsoft Entra ID – the authorization server that shows the permission screen and issues tokens in Microsoft 365
Microsoft Graph – the single doorway apps use, carrying an OAuth access token, to reach Microsoft 365 data
Microsoft 365 – where delegated and application permissions decide what apps may read and write
SharePoint – one of the data sources behind Microsoft Graph that an app reaches with a token
Related episode: Microsoft Fabric for Microsoft 365 Admins: What You Need to Know

Entra ID Governance: Access Reviews, Entitlement Management and Lifecycle Workflows

Wed, 28 Oct 2026 18:55:01 +0000

Access that is never reviewed keeps growing, and yearly recertifications end in rubber stamps. This episode shows identity architects, IAM and compliance teams how access packages, access reviews, lifecycle workflows and PIM in Microsoft Entra ID Governance work together as one event-driven system.

In this episode

00:00 – The thesis: governance is a behavior problem
03:21 – The old model and the map of Entra ID Governance
10:00 – Identity data and licensing
17:01 – Entitlement management, access packages and guests
33:40 – Access reviews that people actually complete
47:10 – Lifecycle workflows: joiners, movers and leavers
67:45 – Privileged access with PIM
74:56 – One system: ownership, metrics, rollout and failure patterns

Key takeaways

Entra ID Governance works when it is designed around real behavior: named owners, safe defaults and review tasks small enough to finish.
Access packages with expiry, scoped access reviews with recommendations and auto-apply, and lifecycle workflows driven by clean HR attributes replace the yearly cleanup.
Privileged roles should be eligible and activated just in time through PIM, and the whole program should be rolled out in phases starting with data quality.

Worth quoting

“Attribute quality is the first architecture decision, not the last one. Most teams treat it as cleanup.” – Mirko Peters (12:35)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Entra ID Governance
Identity lifecycle management – the joiner, mover and leaver events that lifecycle workflows turn into automatic access changes
Microsoft Entra ID – the directory whose attributes, P1 and P2 licenses and governance add-on drive every control here
Governance – framed here as a behavior problem solved with owners, safe defaults and small review tasks
Related episode: Microsoft Entra Agent ID - Simply Explained

Power Platform Copilot Integration - Simply Explained

Wed, 28 Oct 2026 16:35:01 +0000

Copilot was supposed to clear busy work, yet in Power Platform it often feels like one more thing to check. This episode explains the four Copilot surfaces for makers, analysts and admins, what Copilot Studio agents really cost, and where they work or fall apart. You'll learn how to prepare your data and design agents so the bill and the answers stay under control.

In this episode

00:00 – Why Copilot in Power Platform feels hard
02:16 – Copilot in Power Apps, Power Automate and Power BI
04:12 – Copilot Studio and agents
06:21 – Preparing data for good answers
07:57 – Costs and Copilot credits
10:01 – Where Copilot Studio works and where it stops
12:26 – Beginner mistakes in the first month
13:51 – Fit with Microsoft 365, governance and Azure

Key takeaways

Copilot in Power Platform is four surfaces, not one: Power Apps, Power Automate and Power BI help you build, while Copilot Studio builds agents that answer on their own.
Answer quality is capped by your data and instructions, so prepare semantic models and name Dataverse tables and columns clearly before relying on Copilot.
Agent cost is a design decision: credits vary by answer type, internal agents for Microsoft 365 Copilot seat holders consume no credits, and exceeding prepaid capacity can disable agents.

Worth quoting

“You probably think this is a licensing problem, but the real tension is that copilot is only as good as the data underneath it.” – Mirko Peters (00:19)

“Copilot removes the blank page problem and the syntax problem, and it doesn't remove the thinking problem because you still have to know what question you're asking” – Mirko Peters (03:52)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes, key takeaways and FAQ
Power Platform – where Copilot meets the apps, flows, reports and agents a business builds
Copilot Studio – the fourth Copilot surface, a separate low-code product for building agents, formerly Power Virtual Agents
Microsoft 365 Copilot – the per-person seat that covers internal agents without consuming Copilot Credits
Related episode: From Copilot Rollout to AI Workplace: Adoption, Agents & Real Business Value with Christoffer Besler Hansen [MVP]

Fabric Dataflows Gen2 - Simply Explained

Wed, 28 Oct 2026 16:12:15 +0000

Your reports don't fail because the business lacks data — they fail because someone still has to open that Excel export, fix the dates, delete blank rows, rename columns, and then hope nothing changed before the next refresh. The real tension here isn't access, it's trust.

In this episode of Simply Explained you will learn:

Opening: Your Data Is Ready, Until Someone Has to Clean It
What Dataflows Gen2 Actually Does
From Messy Source to Fabric Table
Gen1 vs Gen2: More Than a New Name
The Compute and Staging Decision Most Teams Miss
When Dataflows Gen2 Wins, and When It Doesn't
Build a Dataflow That People Can Trust
Conclusion: Start With One Repeated Mess

OpenID Connect - Simply Explained

Wed, 28 Oct 2026 14:55:01 +0000

You've used OpenID Connect more times this week than you realize, and you never knew its name. It answers one simple question every app has to ask, and that question is who is this person.

In this episode of Simply Explained you will learn:

The sign-in you never think about
Why OAuth 2.0 wasn't enough on its own
What actually happens when you click sign in
What's inside the ID token
Where this shows up in Microsoft 365 and Azure
The mistakes people make and the honest limits
How it stacks up against the older way
What this means for your own work

Passkeys and FIDO2 - Simply Explained

Wed, 28 Oct 2026 10:55:01 +0000

Passwords and one-time codes can still be phished, and Microsoft is now making passkeys the default sign-in for Microsoft 365. This Simply Explained episode is for everyday users and IT admins who want to understand passkeys and FIDO2 without the jargon. You will learn how passkeys work, which type to choose and what to plan for before rolling them out.

In this episode

00:00 – A newer way to sign in that Microsoft made the default
00:46 – What a passkey actually is
02:20 – How the keys work without sharing a secret
04:30 – Why phishing stops working
06:20 – Synced versus device-bound passkeys
08:25 – When your phone or key goes missing
10:05 – Passkeys in Microsoft 365 and Azure
12:25 – The honest catches and a recap

Key takeaways

A passkey is a key pair whose private half never leaves your device, so there is no shared secret that a phishing page could steal.
Synced passkeys suit most users because they survive a lost device, while administrators and privileged accounts should use device-bound passkeys such as security keys or Microsoft Authenticator.
Passkeys are becoming the default sign-in in Microsoft Entra ID, so set up a backup passkey early and plan for limits such as visibility of synced copies.

Worth quoting

“A passkey is a matched pair of keys, and the two of them do very different jobs. One key is private. It lives on your device and it never leaves.” – Mirko Peters (01:04)

“Phishing works by getting you to hand over a secret, and a passkey leaves you with no secret to hand over.” – Mirko Peters (04:00)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on passkeys
Microsoft Entra ID – the identity service where organizations manage passkeys, policies and attestation
Microsoft Entra – where passkeys became the default authentication experience as of September 1, 2026
Multifactor authentication (MFA) – the password-plus-code sign-in that synced passkeys beat on speed, according to Microsoft
Microsoft 365 – the work apps like Teams and Outlook that now prompt users to set up a passkey
Related episode: Microsoft Entra Tenant Governance - Simply Explained

Azure SQL Database - Simply Explained

Wed, 28 Oct 2026 08:30:02 +0000

Running your own database server means patching, backups and late-night failovers. This beginner-friendly episode explains Azure SQL Database: how the DTU and vCore models differ, which tier to pick, when elastic pools and serverless save money, and how backups and security work by default. You'll know when to choose the managed service and when a virtual machine is the better fit.

In this episode

00:00 – What Azure SQL Database is
02:22 – DTU vs vCore purchasing models
04:12 – Picking your service tier
06:03 – Elastic pools
07:28 – Backups and high availability
09:31 – Security without the jargon
11:08 – Managed database or virtual machine
12:42 – Beginner mistakes and wrap-up

Key takeaways

Azure SQL Database runs the familiar SQL Server engine as a managed service, so patching, backups and high availability become Microsoft's job.
Choose between the simple DTU bundle and the flexible vCore model, start small, and use serverless or elastic pools only for intermittent or spiky workloads.
Safe settings such as a closed firewall and encryption at rest are the defaults, so your main job is controlling who gets in, ideally with Entra ID.

Worth quoting

“You aren't renting a box and doing the work yourself. You're renting an outcome and someone else keeps the lights on.” – Mirko Peters (00:44)

“The rule of thumb that saves beginners a lot of stress is this start small, watch the numbers and grow later.” – Mirko Peters (05:50)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on Azure SQL Database
Microsoft Azure – the cloud where Microsoft runs the SQL Server engine as a managed database service
Microsoft Entra ID – the recommended sign-in option for Azure SQL Database instead of plain SQL usernames and passwords
Multifactor authentication (MFA) – one of the protections you gain by signing in to the database with Entra ID
Conditional Access – rules that apply to database sign-ins once you use Entra ID authentication
Related episode: Microsoft Entra ID Protection - Simply Explained

Microsoft 365 Tenant-to-Tenant Migration - Simply Explained

Wed, 28 Oct 2026 07:55:02 +0000

A merger or divestiture can turn two Microsoft 365 tenants into one, and copying files is the easy part. This episode explains in plain language what moves, what breaks and why the domain flips last, for IT leads and project owners who need to plan a tenant-to-tenant migration without surprises.

In this episode

00:00 – What a tenant really is
02:27 – Why companies leave one tenant for another
03:53 – What actually moves
05:36 – The Teams problem
07:14 – The domain move
08:38 – Running both tenants at once
10:00 – Cutover weekend
11:21 – What usually goes wrong and recap

Key takeaways

A tenant is your organization's sealed space in Microsoft's cloud, so mergers, divestitures and rebrands force content to be carried from one tenant to another.
Identity moves first, then mail and files in waves, while Teams chats, permissions, Planner, Forms and Power Automate connections are the wiring that breaks.
The custom domain can live in only one tenant at a time, so coexistence bridges the gap and the domain flips last during a short cutover window.

Worth quoting

“The reframe that matters is that the data usually isn't lost, and what breaks instead is the wiring around it.” – Mirko Peters (06:54)

“a domain can only live in one tenant at a time because it works like a single front door and you can't hang the same front door on two different houses.” – Mirko Peters (07:45)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on tenant moves
Tenant-to-tenant migration – the topic of the episode: what moves, what breaks and in which order
Custom domain in Microsoft 365 – can live in only one tenant at a time, so it flips last at cutover
Microsoft Teams – where migrations turn into rebuilds, because chats, channels and permissions don't travel cleanly
OneDrive – personal files that move with each user, part of the well-trodden migration work
Related episode: Microsoft Teams Governance: Stopping Sprawl Before It Starts

Predictive Maintenance on Azure for Manufacturers: What You Actually Need Before the Model

Wed, 28 Oct 2026 05:30:02 +0000

A correct bearing warning is useless if it arrives after the safe maintenance window has passed. This episode walks manufacturing, OT and data teams through everything predictive maintenance on Azure needs before the model, from sensors and edge gateways to IoT Hub, Event Hubs and approved work orders.

In this episode

00:00 – Start with the maintenance decision
04:00 – A pump scenario and the fault hypothesis
11:40 – Baselines and simple rules first
19:16 – Sensors, sampling and capture
27:23 – OT access, edge gateway and timing
47:30 – Ingestion, processing and storage on Azure
80:29 – Model selection, inference and monitoring
101:16 – Costs, rollout and readiness gates

Key takeaways

Define the maintenance decision, its owner and the warning horizon first, then test whether the target fault produces observable evidence early enough to act.
Reliable asset identity, suitable sensors and sampling, safe OT access, store-and-forward gateways, event-time stamps and data contracts matter before any model on Azure.
Compare any model against simple rules on maintenance events, route warnings into reviewed work orders, and expand only through explicit readiness gates and shadow operation.

Explore more on M365.FM

Microsoft Azure – the cloud platform this pump scenario follows from sensor reading to approved work order
Azure Event Hubs – the high-throughput ingestion option when an upstream plant service already handles devices
Microsoft Fabric – where Eventhouse is weighed as a home for time-stamped pump data
Azure Functions – suggested for bounded event-driven tasks like validating outputs, not window state
Related episode: IoT Hub Message Routing vs Event Grid — Why Telemetry and Events Are Not the Same Problem

Terraform - Simply Explained

Wed, 28 Oct 2026 03:20:01 +0000

Terraform exists because your Azure portal clicks can't be rebuilt twice. It writes that infrastructure down as a file you can read, review, and run again.

In this episode of Simply Explained you will learn:

What Infrastructure as Code Really Means
What Terraform Actually Is
Providers: How Terraform Talks to Your Cloud
Plan and Apply: The Safety Net
The State File: Terraform's Memory
Modules: Stop Rebuilding the Same Thing
Remote State: Working With Other People
Drift: When Reality Quietly Changes
When Terraform Is the Right Choice
A Quick Recap, and One Question for You

Power Apps Component Framework - Simply Explained

Tue, 27 Oct 2026 22:40:02 +0000

Every Power Apps maker eventually hits a wall where the standard controls are not enough. This episode explains the Power Apps component framework in plain English for makers, business users and aspiring developers: what code components are, how they work and when they are worth the effort. You will learn to spot the limits early and plan custom controls without creating fragile apps.

In this episode

00:00 – The hidden half of Power Apps
00:38 – The wall every Power App hits
02:17 – What the component framework is
04:00 – How a component works
06:04 – From idea to shipped component
08:05 – Where you meet code components
09:33 – Limits and mistakes to avoid
11:36 – Where PCF fits in the Microsoft world

Key takeaways

The Power Apps component framework lets developers build custom code components that behave like any other control in model-driven apps, canvas apps and Power Pages.
Building a code component is real developer work with a manifest, lifecycle methods, TypeScript, the Power Platform CLI and packaging into a Dataverse solution.
Use PCF only when standard controls or canvas components cannot do the job, and plan for ownership and maintenance before a custom control becomes a black box.

Worth quoting

“Makers build the app, developers build the components, and the two meet inside a single solution. Neither one has to pretend to be the other.” – Mirko Peters (03:52)

“A code component is a self-contained piece of user interface. It has its own look, its own behavior, and it's packaged so it can be reused across different apps and different environments.” – Mirko Peters (02:47)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on code components
Power Apps – the low-code platform whose standard controls hit a ceiling that code components fill
Canvas app – the drag-and-drop app style where code components run alongside maker-built canvas components
Model-driven app – the data-driven app style where PCF first became generally available, before canvas apps
Related episode: Power Platform Environments - Simply Explained

Windows Subsystem for Linux (WSL) - Simply Explained

Tue, 27 Oct 2026 16:40:02 +0000

Many tutorials assume you are not on Windows, and that leaves beginners stuck at the first bash command. This episode explains Windows Subsystem for Linux for IT pros and learners in the Microsoft world: what it is, how WSL 1 and WSL 2 differ, how to install it, where it slows down and how it fits into Azure. You will know whether WSL can replace that second machine you thought you needed.

In this episode

00:00 – Why Linux tools keep showing up in Windows tutorials
01:05 – What WSL actually is
02:41 – WSL 1 versus WSL 2
04:30 – Installing WSL with one command
06:05 – How Linux and Windows share your files
08:04 – What you can do with WSL
09:50 – Where it breaks and what to watch out for
12:18 – How WSL fits into Azure and Microsoft 365

Key takeaways

WSL runs a real Linux environment on Windows 10 and 11, and WSL 2 uses a genuine Linux kernel inside a lightweight virtual machine that starts in seconds.
Keep project files on the same side as the tools that use them, because crossing the Windows-Linux file boundary is the slow path.
WSL is a free local workshop for building and testing, not a production server, and the same Linux and Azure CLI commands carry over to real cloud systems.

Worth quoting

“W s l is a windows feature that runs a Linux environment right on your PC. It does that without a separate virtual machine, and it does it without wiping your drive to install a second operating system.” – Mirko Peters (01:10)

“Microsoft is direct about this in its own documentation. The guidance is to store your files in the same operating system as the tools you use on them.” – Mirko Peters (06:45)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on WSL
Microsoft Azure – the Azure CLI and Azure Linux run inside WSL with no Azure subscription required
Visual Studio Code – its Remote WSL extension edits projects kept inside the Linux file system from Windows
Microsoft 365 – mentioned to make clear that WSL is not part of any Microsoft 365 plan
GitHub – where Microsoft published the source code of the WSL 2 Linux kernel
Related episode: Dynamics 365 Business Central AL Development

FinOps - Simply Explained

Tue, 27 Oct 2026 15:17:33 +0000

Most companies discover they are overspending on cloud only when the invoice lands. This episode explains FinOps in plain language for beginners, IT pros and finance teams: its principles, its inform-optimize-operate loop and the tools already inside Microsoft 365 and Azure. You will learn how to start with one alert and one owner, and which mistakes to avoid.

In this episode

00:00 – Why cloud costs feel out of control
01:34 – What FinOps actually means
03:49 – The six FinOps principles
05:47 – Inform, optimize, operate
07:29 – FinOps on a normal Tuesday
09:06 – FinOps tools in Microsoft 365 and Azure
11:37 – Mistakes that sink a FinOps practice
12:58 – What FinOps cannot fix

Key takeaways

FinOps is a shared cultural practice between the people who build with technology and the people who pay for it, aimed at getting the most value rather than only cutting costs.
The practice runs on six principles and a repeating loop of inform, optimize and operate, with visibility through tagging and showback as the foundation.
Microsoft Cost Management, Azure Advisor, commitment discounts and the Microsoft 365 admin center give you the starting tools, but only ownership and habits keep the savings.

Worth quoting

“FinOps isn't a product you buy, and it isn't a single job title you can hire for.” – Mirko Peters (01:52)

“Sometimes the smart move is to spend more on something that earns more, and the practice gives you the numbers to make that call with confidence.” – Mirko Peters (02:15)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on FinOps
FinOps – explained from scratch with its six principles, the inform-optimize-operate loop and common mistakes
Microsoft Azure – home of Cost Management, Azure Advisor, savings plans, reservations and Azure Hybrid Benefit
Microsoft 365 – where license cleanup and overlapping subscriptions belong in the same FinOps discipline
Microsoft 365 admin center – shows who is assigned which license and gives access to Cost Management
Related episode: FinOps for Manufacturing IT: Controlling Cloud Cost for Industrial Workloads

Power Automate Desktop Attended vs Unattended - Simply Explained

Tue, 27 Oct 2026 11:39:18 +0000

Power Automate gives you two kinds of robot, and they don't cost the same. One sits with you at your desk and works while you watch.

In this episode of Simply Explained you will learn:

Two Robots, One Job
What Power Automate Desktop Actually Is
When the Robot Works While You Watch
When the Robot Works While You're Gone
The Real Difference Between Them
How the Robot Signs In and Runs Alone
Choosing the Right One for Your Job
What It Costs and the Trap Most Beginners Hit
Where It Breaks and What People Get Wrong
The Short Version, and a Question for You

Intune and Autopilot at Scale: What Breaks in Real Rollouts

Tue, 27 Oct 2026 10:05:05 +0000

Autopilot pilots of fifty devices look perfect, then ten thousand devices start failing in ways nobody predicted. This episode is for endpoint engineers, Intune admins and service desk leads who run large Windows rollouts. You will learn where enrollment, ESP, apps, networks and update rings break, and how to design, test and operate for scale.

In this episode

00:00 – Why the pilot lies
06:15 – Enrollment paths and hardware hash registration
16:33 – Network reality and join types
22:58 – The enrollment status page and app deployment order
36:25 – Policy conflicts and pre-provisioning
43:00 – Update rings, deadlines and user trust
49:20 – Troubleshooting, logs and fleet reporting
59:50 – Operations, governance and the new model

Key takeaways

Autopilot rollouts fail at scale because a device is a sequence of dependent steps with different owners, not a thing you configure once.
Most stalls trace back to networks, group timing, app dependencies or conflicting policies, so name the failing layer before reading logs or chasing error codes.
Treat every profile, app and update change as a small ring-based deployment, with named owners, rollback notes and metrics such as time to productive desktop.

Worth quoting

“Autopilot doesn't fail because of bugs. It fails because of the model behind it. The assumption that a device is a thing you configure instead of a sequence you orchestrate.” – Mirko Peters (00:12)

“The enrollment status page isn't there to show progress. It's there to hold the door shut, a gate that stays closed until the things you marked as required are finished.” – Mirko Peters (23:05)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Autopilot at scale
Microsoft Intune – the endpoint service where enrollment, the enrollment status page, app order and reports play out
Microsoft Entra – the cloud join target in the Autopilot chain, set against hybrid join's extra dependencies
Active Directory – the on-premises half of hybrid join, needing domain controller line of sight and a connector
Related episode: Group Policy - Simply Explained

Microsoft Agent 365 - Simply Explained

Tue, 27 Oct 2026 08:25:02 +0000

AI agents are multiplying across companies faster than anyone can track them, often without an owner or a clear list. This episode explains Microsoft Agent 365 in plain language for beginners and business users, showing how it treats agents like employees with an identity, rules and real-time oversight. You will learn why agent sprawl matters and how much of it touches your own workday.

In this episode

00:00 – Employees nobody hired
00:47 – What an AI agent is
01:57 – Agent sprawl and shadow AI
03:46 – Manage agents like employees
05:36 – The Agent Registry
07:13 – Agent identity with Entra Agent ID
08:58 – Governance, security and real-time oversight
12:25 – Who needs it and what it costs

Key takeaways

Microsoft Agent 365 is a control plane that lets an organization see, govern and secure every AI agent it runs, on top of Entra, Defender, Purview and the Microsoft 365 admin center.
The Agent Registry and Entra Agent ID give every agent a listed entry, an owner and its own least-privilege identity, so unsanctioned agents can be quarantined or blocked.
Agent 365 is licensed per person rather than per agent, so anyone who uses or sponsors agents at work is part of the governance picture.

Worth quoting

“Most of us assume the hard part of AI is making it smarter, but the harder problem is keeping track of what it's allowed to do.” – Mirko Peters (00:15)

“An agent is a piece of software that doesn't stop at an answer. It reads information, makes a decision, and then takes a real action inside the tools you already use every day.” – Mirko Peters (00:50)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a plain-language FAQ on Agent 365
Microsoft Agent 365 – the control plane at the center of the episode for seeing, governing and securing every agent
AI agent – software that reads information, decides and takes real actions in the tools people use daily
Microsoft Entra Agent ID – gives each agent its own identity and permissions, with blueprints and least privilege
Governance – covers an agent's whole life, from policy templates at creation to expiry and blocking
Related episode: Microsoft Entra Agent ID - Simply Explained

Data Loss Prevention in Microsoft 365: Policies That Actually Work

Tue, 27 Oct 2026 05:39:57 +0000

A new DLP policy blocks everything on Monday, and by Friday half the finance team is mailing files from personal accounts. This episode is for Microsoft 365 admins and compliance owners who want Purview DLP policies people actually accept. You'll learn how to detect the right data, guide users with tips and overrides, test safely, triage alerts and measure what really works.

In this episode

00:00 – Why block-first DLP fails
06:46 – The new model: context, not content alone
12:37 – Detection: SITs, EDM, classifiers and labels
25:29 – Policy tips and user overrides
31:27 – Simulation, tuning, scoping and exceptions
47:26 – Endpoint DLP, Teams, Copilot and cloud apps
57:10 – Alert triage and measuring effectiveness
73:48 – Phased rollout and common failure patterns

Key takeaways

DLP policies built to block drive users to invisible workarounds, so design policies that use context and guide people with tips before enforcing.
Run every policy in simulation for weeks, then with tips but no enforcement, and block only high-confidence, high-volume risks with a reporting path.
Treat DLP as an ongoing practice with a named owner, weekly tuning from overrides and triage, owned and expiring exceptions, and metrics like true positive rate instead of block counts.

Worth quoting

“it's failing for one reason. Not the tools, the model behind it. Policies built to block lose to policies built to guide.” – Mirko Peters (00:22)

“A credit card number in an email to a payment processor is business. The same number in an email to a personal address is a problem.” – Mirko Peters (02:17)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on Purview DLP
Data loss prevention (DLP) – the core topic, rebuilt from block-first rules into context-aware policies that guide users
Microsoft Purview – the portal where DLP policies, simulation, alerts, Activity Explorer and policy reports live
Sensitivity labels – one policy condition that replaces many detectors and keeps labeled files out of Copilot
Microsoft Defender – shares its sensor with endpoint DLP and correlates DLP alerts in the Defender XDR queue
Related episode: Microsoft Fabric for Microsoft 365 Admins: What You Need to Know

SharePoint Embedded - Simply Explained

Tue, 27 Oct 2026 05:36:45 +0000

Discover SharePoint Embedded in M365. Learn what it is, how file containers and security work, billing, and how apps use it without a standard user interface.

There's a whole part of Microsoft 365 that has no screen at all. It's called SharePoint Embedded, and it stores files for apps instead of for people.

In this episode of Simply Explained you will learn:

What It Actually Is
The Container Idea
Where Your Files Live
The Security Story
What You Get Built In
It's Not a SharePoint Site
How the Billing Works
Where You'll Meet It
The Recap and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Git Branching Strategies - Simply Explained

Tue, 27 Oct 2026 04:55:02 +0000

Master Git Branching Strategies with a clear breakdown of Gitflow, GitHub Flow, and trunk-based development. Learn pull requests, merging, and rebasing.

Branching sounds like a small detail until two people change the same file. Then someone has to figure out which version is the real one, and that's a branching problem.

In this episode of Simply Explained you will learn:

What a branch is
Why branching strategies exist
The three building blocks
Git Flow, the structured one
GitHub Flow, the simple one
Trunk-based development, the fast one
Pull requests explained
Merge versus rebase
Choosing a strategy for small and large teams
Common mistakes beginners make
Which one fits you

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Teams Premium - Simply Explained

Tue, 27 Oct 2026 02:15:02 +0000

Discover what Microsoft Teams Premium actually is, how the add-on license works, intelligent meeting recaps, pricing, security features, and who needs it.

You might think Teams Premium is just Microsoft Teams with a bigger price tag. It's actually a separate add-on license that switches on features your normal Teams license leaves off.

In this episode of Simply Explained you will learn:

What Teams Premium Actually Is
Meetings That Think
Keeping the Meeting in the Room
Looking Like Your Company
Big Events
Appointments and Bookings
The IT Team Features
Who Actually Needs It
The Licensing Basics
Teams Premium or Copilot
Recap and a Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

OT-IT Convergence on Azure: Connecting PLCs Without Breaking Production

Tue, 27 Oct 2026 01:17:15 +0000

Learn architecture patterns for OT IT convergence on Azure. Connect PLCs safely without breaking production or exposing your plant to operational risks.

Connecting PLCs to IT systems adds value and risk if production is not protected. In this episode of the iFAKT series, we discuss architecture patterns for OT-IT convergence on Azure, with safe boundaries and data flows.
You will learn how to connect equipment without breaking production.
Who it is for: OT engineers, IT architects and plant managers.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure Migrate - Simply Explained

Tue, 27 Oct 2026 01:16:19 +0000

Learn how Azure Migrate works for cloud migration. Discover server assessment, dependency analysis, agentless setup, and cost optimization.

Azure Migrate is free, and it will tell you what your own servers are really costing you. That sounds simple, but the hard part of a migration usually happens before anyone opens the cloud portal, because nobody mapped what was connected to what.

In this episode of Simply Explained you will learn:

What Azure Migrate Actually Is
How Discovery Works
The Assessment: Readiness, Sizing, Cost
Dependency Analysis
Agentless or Agent-Based
Moving in Waves
The Hub and Its Tools
The Pitfalls to Avoid
The Recap

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Bad Machine Data: Fixing Data Quality Before It Reaches Power BI

Tue, 27 Oct 2026 01:09:50 +0000

Learn how to fix bad machine data, missing values, timestamps, and data quality issues before they reach Power BI dashboards in manufacturing.

Dashboards are only as good as the machine data feeding them. In this episode of the iFAKT series, we cover common data quality problems: missing values, naming, timestamps and units, and how to fix them before they reach Power BI.
You will learn how to build data quality checks into the pipeline.
Who it is for: Data engineers, BI developers and manufacturing analysts.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Power Automate Desktop - Simply Explained

Tue, 27 Oct 2026 00:50:01 +0000

Learn what Power Automate Desktop is, how desktop vs cloud flows work, recording actions, attended vs unattended modes, pricing, and where flows break.

Power Automate Desktop is a free robot already sitting on your Windows PC, and most people never switch it on. It's Microsoft's answer to work you do the same way, over and over, in apps that were never built to talk to anything else.

In this episode of Simply Explained you will learn:

What Power Automate Desktop Actually Is
Desktop Flows Versus Cloud Flows
How the Recorder Turns Your Clicks Into Actions
Attended Versus Unattended
Connecting Desktop Flows to Cloud Flows
What It Costs
What People Actually Use It For
Where It Breaks
The Recap

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Mail Flow Rules - Simply Explained

Tue, 27 Oct 2026 00:45:30 +0000

Learn how Microsoft 365 mail flow rules work, how to set conditions and actions, avoid common pitfalls, and test transport rules safely in Exchange Online.

Every email in your company is being checked by rules you've never seen. They're called mail flow rules, and they sit between the send button and the inbox.

In this episode of Simply Explained you will learn:

The Rules You Never See
What A Mail Flow Rule Really Is
The Three Questions Every Rule Asks
When A Rule Fires And What Happens Next
The Jobs People Actually Give These Rules
The Limits Nobody Warns You About
Testing A Rule Before It Bites
Where This Sits In Microsoft 365 And Azure
The Mistakes Beginners Make
What To Remember

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft OneDrive - Simply Explained

Tue, 27 Oct 2026 00:38:05 +0000

Discover how Microsoft OneDrive works, the difference between personal and work accounts, file syncing, sharing, version history, and its relation to SharePoint

Microsoft's OneDrive is one name hiding two completely different products. You might think the OneDrive on your home laptop is the same as the one your job handed you, but they are two separate accounts that only look alike.

In this episode of Simply Explained you will learn:

What OneDrive Actually Is
Two OneDrives, One Name
How Your Files Get Onto Your Computer
Sharing and Permissions
The Folder Backup You Didn't Ask For
Undo: Versions and the Recycle Bin
OneDrive vs SharePoint
Who's Really in Charge
Closing: The Short Version and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure Bicep - Simply Explained

Tue, 27 Oct 2026 00:34:16 +0000

Learn Azure Data Factory fundamentals, from pipelines, activities, and linked services to pricing and Fabric comparisons in plain English.

Learn what Azure Bicep is, how it compares to ARM templates and Terraform, and how to use infrastructure as code safely with the what-if command.

Your Azure setup lives in your memory, and that's a problem. You clicked it into place once, on screens you'll never find again, and nothing was ever written down.

In this episode of Simply Explained you will learn:

What Bicep actually is
Why not just use ARM JSON or the portal
How Bicep works under the hood
Reading a Bicep file in plain words
Modules, your reusable building blocks
Deploying, and the what-if safety net
Bicep versus ARM versus Terraform
The mistakes beginners make
Recap and one question for you

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

GitHub Copilot - Simply Explained

Tue, 27 Oct 2026 00:16:39 +0000

Learn what GitHub Copilot actually is, how its three main modes work, pricing options, privacy settings, and common beginner mistakes to avoid.

Most of us assume GitHub Copilot writes code so we don't have to. That assumption misses what's actually happening inside the editor.

In this episode of Simply Explained you will learn:

What Copilot Actually Is
Three Ways to Talk to It
How It Knows About Your Code
What It Costs
Privacy and Who Owns the Code
Mistakes Beginners Make
Recap and a Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure Data Factory - Simply Explained

Mon, 26 Oct 2026 23:25:53 +0000

Learn Azure Data Factory fundamentals, from pipelines, activities, and linked services to pricing and Fabric comparisons in plain English.

Azure Data Factory is a courier service for your company's data. It picks up raw information from wherever it lives, cleans it on the way, and drops it off somewhere your reports can actually use it.

In this episode of Simply Explained you will learn:

What Azure Data Factory Actually Is
The Building Blocks: Pipelines and Activities
Linked Services and Datasets: The Keys and the Address
Integration Runtimes: The Engine Room
Triggers and Scheduling: Making It Run on Its Own
Mapping Data Flows: Transforming Without Code
Azure Data Factory Versus Fabric Pipelines
What It Costs and How to Keep It Cheap
Best Practices That Save You Pain Later
A Quick Recap and a Question for You

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Fabric vs Synapse vs Databricks - Simply Explained

Mon, 26 Oct 2026 21:15:02 +0000

Confused by Microsoft Fabric, Azure Synapse, and Databricks? Compare teams, workloads, control, and cost to choose the right data platform.

Imagine betting your entire data strategy on a platform that leaves your reports crawling, your engineers fighting for control, or your budget blowing up every time a new team needs access. One wrong decision can create years of unnecessary work, and the ongoing friction adds up fast.

In this episode of Simply Explained you will learn:

Opening: The Platform Choice That Creates Years of Extra Work, 100 words
Start With the Simple Mental Model: One Data Journey, Three Approaches, 420 words
Fabric: The Managed Analytics Home for Power BI Teams
Synapse: The Azure Build-Your-Own Analytics Platform
Databricks: The Engineering and AI Workshop
The Comparison That Actually Decides It: Team, Workload, Control, and Cost
Choose Your Starting Point: Four Real-World Patterns
Conclusion: Choose the Work, Then Choose the Platform

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Forms - Simply Explained

Mon, 26 Oct 2026 18:27:46 +0000

Learn how to use Microsoft Forms for surveys, quizzes, and automated workflows. Discover templates, branching, Excel integration, and built-in limits.

Microsoft Forms is the survey and quiz builder you already own. Welcome to the M365 FM podcast, where we explore the people, ideas, and technologies shaping the future of work.

In this episode of Simply Explained you will learn:

The Tool You Already Own
Building Your First Form
When a Survey Becomes a Quiz
Branching: The Form That Rewrites Itself
Collecting Answers Without the Headache
Answers That Land in Excel by Themselves
Letting Power Automate Do the Follow-Up
The Limits Worth Knowing
Where Forms Fits in Your Microsoft World

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Viva Insights - Simply Explained

Mon, 26 Oct 2026 16:44:53 +0000

Discover what Microsoft Viva Insights actually is, how the four data views work, and what managers, leaders, and analysts see regarding your productivity.

Microsoft Viva Insights is probably already switched on inside your Microsoft 365 account. You might think it's a tool for your manager to watch you, but the first view it opens is the one that's just for you.

In this episode of Simply Explained you will learn:

What Viva Insights Actually Is
The Four Views of the Same Data
Your Own Insights: Focus Time, Quiet Time, and Switching Off
What Your Manager Sees
What Leaders See Across the Company
The Analyst Role: Where the Real Questions Get Answered
Privacy: What Viva Insights Can and Cannot See
What Teams Actually Do With It
Recap and One Question for You

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Serverless Computing - Simply Explained

Mon, 26 Oct 2026 15:33:20 +0000

Learn serverless computing in plain language. Understand Azure Functions, event-driven architecture, Power Automate integration, costs, and common pitfalls.

The word serverless is a lie, and the truth behind it is far more useful. There's no such thing as computing without servers, but there's a way to stop renting machines you barely use.

In this episode of Simply Explained you will learn:

Why the word serverless trips almost everyone up
What serverless computing actually means
How serverless decides when to run and what it costs
Where serverless already lives in Microsoft 365
The jobs serverless is genuinely good at
The limits that surprise people
The mistakes beginners make with serverless
How to start with serverless without overthinking it

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure Application Gateway - Simply Explained

Mon, 26 Oct 2026 14:55:48 +0000

Learn how Azure Application Gateway handles Layer 7 load balancing, SSL termination, WAF security, routing rules, and autoscaling in plain English.

Most load balancers never read the request they're delivering. Azure Application Gateway does, and that single habit changes where your traffic lands.

In this episode of Simply Explained you will learn:

What It Actually Is
Listeners and Routing Rules
Backend Pools and Health Probes
Where HTTPS Gets Handled
What Stops the Attacks
Scaling Without Thinking
The Three Azure Load Balancers
Recap and a Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Docker and Containers - Simply Explained

Mon, 26 Oct 2026 14:11:05 +0000

Learn what Docker and containers actually do, how images and layers work, and why they beat virtual machines in this jargon-free, beginner guide.

Docker is the most-used tool in cloud development, and it's not even close. You've probably heard the word thrown around like it's basic knowledge everyone else already has.

In this episode of Simply Explained you will learn:

The Problem Docker Actually Solves
What a Container Really Is
Images, Dockerfiles, and the Power of Layers
Registries: Where Images Live and Travel
Containers vs Virtual Machines
Where People Actually Use Docker
The Mistakes Beginners Make
When You Should Not Reach for Containers

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Entra Agent ID - Simply Explained

Mon, 26 Oct 2026 13:32:14 +0000

Learn how Microsoft Entra Agent ID gives AI agents their own identity, securing your tenant with blueprints, lifecycle governance, and least privilege.

Somewhere in your Microsoft 365 tenant, an AI agent is signing in with an account nobody can name. It reads your mail, opens your files, and answers questions in Teams, and when something goes wrong, there's no person on the other end to ask.

In this episode of Simply Explained you will learn:

The Agent Nobody Can Name
Why Agents Need Their Own Identity
What An Agent Identity Actually Is
Blueprints: One Template, Many Agents
Agent Identities vs Service Principals vs Managed Identities
Conditional Access For Agents
Governing The Agent Lifecycle
Least Privilege, Explained Simply
The Pitfalls That Catch People Out
The Recap And One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure Managed Identities - Simply Explained

Mon, 26 Oct 2026 11:58:50 +0000

Learn how Azure Managed Identities eliminate hardcoded secrets in your cloud apps. Discover system and user-assigned types, token flow, and best practices.

Your Azure app probably has a password written into its settings right now. Every database login, API key, and secret copied into a config file is a key left out in the open, and millions of them leak every year.

In this episode of Simply Explained you will learn:

Why Secrets in Code Are a Problem
What a Managed Identity Actually Is
System-Assigned and User-Assigned
How Your App Gets a Token
Granting Access with Role Assignments
Reaching Key Vault Without a Password
Where Managed Identities Work
The Pitfalls to Watch For
A Quick Recap and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Multi-Factor Authentication (MFA) - Simply Explained

Mon, 26 Oct 2026 10:48:43 +0000

Learn why passwords aren't enough and how multi-factor authentication blocks over 99% of attacks. Explore factors, text codes, apps, and passkeys.

Nearly nine in ten attacks on the web start with a stolen password. That's one secret you type into every site you use, so one leak spreads everywhere.

In this episode of Simply Explained you will learn:

Why a password on its own isn't enough
The three things a factor can be
What actually happens when you sign in
Authenticator apps, text messages, and security keys
Why phishing-resistant is the phrase that matters
Rolling it out without a mutiny
The mistakes that undo the whole thing
Where this leaves you

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

GitHub Actions - Simply Explained

Mon, 26 Oct 2026 09:50:53 +0000

Learn GitHub Actions from scratch. Understand workflows, events, jobs, runners, secrets, and real-world automation in clear, jargon-free language.

More than ten thousand ready-made building blocks are sitting inside GitHub right now. They're called actions, and they plug into a tool called GitHub Actions that runs your work for you whenever something happens in your project.

In this episode of Simply Explained you will learn:

What GitHub Actions Really Is
Where The Instructions Live
What Wakes It Up: Events
Jobs, Steps, And Runners
The Marketplace And Reusable Workflows
Secrets: Keeping Passwords Out Of The Code
What People Actually Automate
What It Costs
A Quick Recap, And One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure Confidential Computing - Simply Explained

Mon, 26 Oct 2026 09:15:02 +0000

Learn Azure Confidential Computing simply. Discover how Trusted Execution Environments and data-in-use encryption protect your workloads in the cloud.

Hello everyone, and welcome to another episode of Microsoft Knowledge Nuggets here on m365.fm. I’m your host, Mirko Peters.

In this episode of Simply Explained you will learn:

The Encryption Gap: Data in Use
Why the Cloud Needs a Private Room
The Trusted Execution Environment, Plain English
Attestation: Checking the Room Before You Trust It
Azure Building Blocks: VMs, Containers, and Services
Where Confidential Computing Fits, and Where It Doesn't
Put the Third Lock in Place

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure Virtual Machine Scale Sets - Simply Explained

Mon, 26 Oct 2026 04:55:02 +0000

When one virtual machine can't keep up with traffic, pages slow down and users leave. This episode explains Azure Virtual Machine Scale Sets, load balancing, autoscale and orchestration modes in plain language, for beginners and cloud admins deciding when a pool of matching VMs is the right design.

In this episode

00:00 – Why one virtual machine isn't enough
02:40 – What a virtual machine scale set actually is
05:30 – How requests reach healthy instances
08:25 – Autoscale: adding and removing instances
12:15 – Uniform and flexible orchestration
15:50 – Keeping the fleet healthy during failures and updates
18:55 – When to use a scale set
21:10 – Conclusion

Key takeaways

Virtual machine scale sets create matching VM instances from one shared setup, enabling horizontal scaling instead of ever-larger single machines.
A load balancer or Application Gateway with health probes routes traffic to healthy instances, while autoscale rules and availability zones handle demand and failures.
Scale sets fit stateless, repeatable workloads such as web front ends, APIs and queue workers; stateful data must live outside the instances.

Worth quoting

“So instead of making one computer bigger, you add more computers running the same app that's horizontal scaling or scaling out” – Mirko Peters (01:52)

“The goal isn't a maze of automation. You want enough VM's to handle, demand no more than you need, and rules that someone else can still read six months from now.” – Mirko Peters (12:08)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on scale sets
Microsoft Azure – the cloud that creates, balances, autoscales and replaces the scale set's VM instances
Mirko Peters – host of this Microsoft Knowledge Nuggets episode explaining virtual machine scale sets
Related episode: Building Azure That Survives the Real World — with Mike Martin [MVP]
Related episode: Azure Bicep - Simply Explained
Related episode: Fabric SQL Database - Simply Explained

Azure Event Grid - Simply Explained

Mon, 26 Oct 2026 04:15:02 +0000

Learn Azure Event Grid in plain English. Discover event-driven architecture, push vs pull delivery, retries, and how it compares to Event Hubs and Service Bus.

Azure Event Grid is the part of Azure that tells your apps what already happened. A file lands in storage, a device connects, an order comes in, and instead of your code asking over and over, Event Grid just delivers the news.

In this episode of Simply Explained you will learn:

Why Event-Driven Keeps Coming Up
What Azure Event Grid Actually Is
The Four Words You Need
Three Kinds of Topics
Push or Pull
When Delivery Fails: Retries and Dead-Lettering
Event Grid vs Service Bus vs Event Hubs
A Simple Picture to Keep
Recap and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Entra ID Protection - Simply Explained

Mon, 26 Oct 2026 02:10:02 +0000

Learn how Microsoft Entra ID Protection detects password attacks, evaluates sign-in and user risk, and automates security to protect your cloud environment.

Microsoft says more than 97 percent of identity attacks are just password attacks. The usual way into a Microsoft 365 account is a password that leaked somewhere else, not a clever hack.

In this episode of Simply Explained you will learn:

What Identity Protection Actually Watches
Two Kinds of Risk: The User and the Sign-In
What the Risk Levels Mean
How Risk Turns Into a Decision
How People Fix It Themselves
What the Admin Actually Sees
What It Costs and What You Need
Best Practices That Actually Matter
A Quick Recap and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Foundry Agent Service - Simply Explained

Mon, 26 Oct 2026 01:35:01 +0000

Learn what Microsoft Foundry Agent Service is, how it works with AI models and tools, and how to build production-ready agents without server headaches.

Microsoft's Foundry catalog now holds more than ten thousand AI models. That number only matters if you can turn a model into something that actually does work.

In this episode of Simply Explained you will learn:

What an AI agent actually is
What Microsoft Foundry Agent Service is
Models, the brain you can swap
Tools and knowledge, how agents take action
Threads, runs, conversations, and responses
Hosting and scaling, where the agent lives
Safety, identity, and evaluation
How it relates to Copilot Studio
What people actually build with it
Recap and one question for you

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure Availability Zones - Simply Explained

Sun, 25 Oct 2026 22:25:02 +0000

Master Azure Availability Zones, region pairs, and availability sets. Learn how to design resilient cloud architectures and improve your uptime SLAs.

Azure runs more than 70 regions, and every one that supports zones hides at least three separate buildings inside it. Most of us assume that putting an app in the cloud keeps it running no matter what, and that's not how it works.

In this episode of Simply Explained you will learn:

Regions, the Big Picture
Inside a Region, Availability Zones
Why One Datacenter Isn't Enough
Availability Sets, the Older Tool
Zonal Versus Zone-Redundant Services
What the SLAs Actually Mean
Designing for Resilience
Region Pairs
The Costs and Trade-offs
Recap and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Entra Tenant Governance - Simply Explained

Sun, 25 Oct 2026 18:15:02 +0000

Learn Microsoft Entra tenant governance simply explained. Discover how to find forgotten tenants, stop shadow IT, and secure your M365 cloud environment.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure Dedicated Host - Simply Explained

Sun, 25 Oct 2026 18:05:02 +0000

Learn how Azure Dedicated Host works, providing physical server isolation, security, and maintenance control in the Microsoft cloud. Simply explained.

Why would you rent an entire physical server in Azure when you could just create a virtual machine and pay for that?

In this episode of Simply Explained you will learn:

Opening: Why Would You Rent the Whole Server?
The Problem Dedicated Host Solves
What Azure Dedicated Host Actually Is
How the Building Blocks Fit Together
Isolation, Security, and Maintenance Control
Pricing, Licenses, and the Capacity Trap
When Dedicated Host Fits, and When It Doesn't
Conclusion: Choose the Right Level of Control

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Power Platform Environments - Simply Explained

Sun, 25 Oct 2026 14:35:01 +0000

Every licensed user can build in the default environment, yet Microsoft says not to run production work there. This episode explains Power Platform environments, types, Dataverse, roles and governance in plain words for makers and admins. You will know which environment to build in and why.

In this episode

00:00 – Why the default environment is a trap
00:25 – What an environment actually is
02:30 – Environment types
04:53 – Dataverse: one database per environment
05:56 – Roles and access
07:55 – Environment groups and Managed Environments
10:00 – ALM, solutions and data policies
13:40 – Best practices

Key takeaways

An app can only reach data sources in its own environment, so many broken connections are boundaries rather than bugs.
Use the default environment only for personal experiments, build in developer or sandbox environments and ship managed solutions to production.
Maker rights and data access are separate, and data policies, environment groups and Managed Environments add tenant-wide guardrails.

Worth quoting

“An app can only connect to data sources that live in the same environment. If you build an app in one environment and the data sits in another, the app can't see it.” – Mirko Peters (01:59)

“Being allowed to build in an environment isn't the same as being allowed to read its data, and those are two separate doors.” – Mirko Peters (06:16)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes, key takeaways and FAQ
Power Platform – the platform whose environments, roles, groups and data policies this episode explains
Dataverse – each environment holds at most one Dataverse database, and it never holds two
Connector – the bridge an app uses to reach services, sorted into groups by data policies
Data loss prevention (DLP) – data policies that group connectors as business, non-business or blocked to stop leaks
Model-driven app – an app type that leans on the Dataverse tables of its own environment
Related episode: Power Platform Copilot Integration - Simply Explained

Fabric Data Pipelines - Simply Explained

Sun, 25 Oct 2026 14:15:02 +0000

Learn how Fabric Data Pipelines work in Microsoft Fabric. Master ETL vs ELT, control flow, dataflows, and notebooks in clear, jargon-free language.

Your sales file arrives at seven AM, customer records update at eight, and the app data shows up whenever it feels like it, while someone on your team is opening spreadsheets, pressing refresh, fixing columns, and hoping the report tells the same story as yesterday.

In this episode of Simply Explained you will learn:

Opening: The Data Is Moving, but Who Is in Control?
ETL and ELT: Two Routes for the Same Data
What a Fabric Data Pipeline Actually Does
Dataflows, Notebooks, and Pipelines: Who Does Which Job?
A Beginner Pipeline Story: From Raw File to Usable Table
Running the Same Pipeline Without Rebuilding It
Monitoring, Errors, and the First Build
Conclusion: Build the Routine Before You Automate It

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

AI Builder - Simply Explained

Sun, 25 Oct 2026 09:45:02 +0000

Many business users think AI needs engineers and months of setup. This Simply Explained episode is for Power Platform beginners who want to use AI Builder inside Power Apps and Power Automate. You will learn which models fit which tasks, how document processing and prediction work, and how credits and licensing affect your plans.

In this episode

00:00 – AI already inside the tools you use
00:31 – What AI Builder actually is
02:13 – Ready-made models versus models you build
04:10 – Why this is not just another chatbot
05:17 – What document processing really does
06:50 – How prediction works
09:23 – What credits are and why they matter
11:10 – Where AI Builder fits in real work

Key takeaways

AI Builder adds task-focused AI models to Power Apps and Power Automate, so you can automate business chores without writing code.
Use pre-built models for common, generic problems and train custom models such as document processing when your documents or data are specific to your business.
Building and testing models is free, but running them in a live app or flow consumes credits and makes the flow or app premium.

Worth quoting

“AI builder is a feature inside Microsoft Power Platform. It lets you create and use AI models to take over business tasks you'd normally do by hand.” – Mirko Peters (00:33)

“Most beginners assume custom always means better, and that assumption is wrong. Custom means more specific, and more specific is only better when your problem is specific to.” – Mirko Peters (03:55)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ
AI Builder – the Power Platform feature this episode explains, from pre-built models to credits
Power Apps – where AI Builder models run inside apps through Power Fx formulas
Power Automate – where an AI Builder action in a cloud flow processes invoices and makes it premium
Power Platform – the low-code platform that AI Builder is built into as a feature
Related episode: Power Platform Copilot Integration - Simply Explained

Microsoft Teams Phone - Simply Explained

Sun, 25 Oct 2026 02:25:02 +0000

Discover how Microsoft Teams Phone transforms business communication. Learn about calling features, configuration, and modern cloud telephony strategies.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Licensing in Microsoft 365 - Simply Explained

Sat, 24 Oct 2026 20:50:01 +0000

Demystify Microsoft 365 licensing. Learn how business and enterprise plans, E3 vs E5, add-ons, and Copilot fit together without the confusion.

Microsoft 365 licensing isn't as complicated as the price sheet makes it look. Underneath all those tiers, there are really just two layers to understand.

In this episode of Simply Explained you will learn:

What a license really is
Business plans and Enterprise plans
E3 versus E5
The add-on layer
Where Copilot fits
How licenses get assigned
The overlap trap
Staying clean
The short version

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Business Central Fabric Integration - Simply Explained

Sat, 24 Oct 2026 17:25:01 +0000

Learn how Business Central Fabric Integration works, connect your ERP data to OneLake, and avoid common analytics pitfalls in Microsoft's cloud ecosystem.

Your accounting system is the worst place to answer the big questions about your business. That sounds backwards, because Business Central already holds every number that matters.

In this episode of Simply Explained you will learn:

What Business Central Really Is
What Fabric and OneLake Are
Why Analytics Live Outside the ERP
Three Ways the Data Gets Across
What the Flow Looks Like
What Usually Goes Wrong
When You Need It and When You Don't
A Quick Recap and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

KQL Databases in Fabric - Simply Explained

Sat, 24 Oct 2026 13:40:01 +0000

Learn how KQL databases in Microsoft Fabric help you query log and telemetry data without SQL overwhelm. Get clear, jargon-free insights today.

Your team can collect every alert, every click, every device signal, then still miss the one change that needed a response. The data keeps arriving, but it lands as noise because nobody can ask it a clear question.

In this episode of Simply Explained you will learn:

Opening: The Query Language That Makes Noise Useful
Eventhouse, KQL Database, and Tables
When KQL Is the Right Tool
KQL Without the SQL Overwhelm
Working With Time-Series and Log Data
Getting Started in Fabric and Putting Insight to Work
Conclusion: Start With One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Defender Threat Intelligence - Simply Explained

Sat, 24 Oct 2026 09:25:01 +0000

Learn what Microsoft Defender Threat Intelligence is, how indicators of compromise work, and how analysts track threat actors and infrastructure.

The alert on your screen never tells you who is attacking you. It tells you something broke, and then it leaves you guessing.

In this episode of Simply Explained you will learn:

What Threat Intelligence Actually Is
Indicators of Compromise: The Breadcrumbs
Threat Actors: Who Is Behind the Attack
Infrastructure Analysis: Following the Trail
Using It in an Investigation
Community Versus Premium: What Is Free and What Is Not
Where This Leaves You

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Teams Rooms - Simply Explained

Sat, 24 Oct 2026 06:10:01 +0000

Discover what Microsoft Teams Rooms are, how meeting spaces sign into Teams independently, and the differences between Windows, Android, Basic, and Pro.

Your meeting room has its own Microsoft 365 account, and nobody told you. A Microsoft Teams Room is a meeting space where the room itself signs into Teams, so nobody has to plug in a laptop.

In this episode of Simply Explained you will learn:

What a Teams Room Really Is
What's Inside the Room
How the Room Knows Your Meeting
Windows or Android
Basic, Pro, and the Portal
Rooms That Actually Work
Keeping the Fleet Alive
The Recap and a Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Predictive Maintenance on Azure for Manufacturers: What You Actually Need Before the Model

Sat, 24 Oct 2026 04:00:02 +0000

Learn what manufacturers actually need before building a predictive maintenance model on Azure, from maintenance decisions to data and process evidence.

Predictive maintenance on Azure only pays off when a warning arrives early enough for your team to act on it. In this episode of the iFAKT series, we start with the maintenance decision and work backward to the evidence, data and process you need before choosing a model on Azure.

We follow one hypothetical asset from sensor reading to approved work order and ask the questions most projects skip: What action should a warning trigger? How much warning horizon do spares, permits, isolation and production planning really need? Can the fault produce evidence early enough to change the plan?

You will learn how to define the maintenance decision first, how to separate preparation time from hands-on repair time, how to judge whether a failure signal is usable, and how to connect Azure data and machine learning to the maintenance process your technicians already follow.

Who it is for: maintenance managers, reliability engineers, plant and production leaders, OT and IT architects, and data teams planning predictive maintenance, condition monitoring and industrial AI on Microsoft Azure in manufacturing.

Full transcript available via the transcript link.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Fabric Notebooks - Simply Explained

Sat, 24 Oct 2026 00:55:01 +0000

Learn how to use Fabric Notebooks without a developer background. Discover non-developer workflows, spark notebooks, and data transformation basics.

Imagine opening a Fabric notebook for the first time and seeing code, data, strange errors, and words you’ve never used before. It feels like you’ve walked into a room built for developers, while your job is simply to get data you can trust.

In this episode of Simply Explained you will learn:

Opening: The Code Wall Is Not the Real Problem
What a Fabric Spark Notebook Actually Is
The Five Parts of the Notebook Screen
The Non-Developer Workflow: Explore Before You Transform
Transform Data Without Turning the Notebook Into a Mystery
From Personal Experiment to Repeatable Fabric Process
When You Should Use a Notebook, and When You Shouldn’t
Conclusion: Start With One Question, Not a Huge Build

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Log Analytics - Simply Explained

Fri, 23 Oct 2026 20:54:29 +0000

Discover how Log Analytics works in Azure and M365. Learn about tables, KQL queries, data collection rules, costs, and retention strategies simply.

Log Analytics is a filing cabinet for everything your systems whisper to each other. Every sign-in, every file open, and every error becomes a record in that cabinet, and on its own one record is nearly useless.

In this episode of Simply Explained you will learn:

What Log Analytics actually is
Where all these logs come from
Inside a workspace and its tables
Asking questions with a few lines of KQL
What teams actually do with it
Where the money actually goes
How long your data sticks around
How it fits into Microsoft 365 and Azure
The honest limits, and one question for you

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Subnetting and CIDR - Simply Explained

Fri, 23 Oct 2026 19:58:50 +0000

Master subnetting and CIDR notation easily. Learn how IP addresses, subnet masks, and network blocks work in your home router and Azure cloud.

Your home Wi-Fi router has been subnetting this whole time, and nobody told you. Every device on your network sits inside a block of 256 addresses, and that block is what people mean when they say subnet.

In this episode of Simply Explained you will learn:

Why Your Home Router Is Already Doing Subnetting
What an IP Address Is Made Of
The Slash Number Is Just a Size
Why We Split a Network at All
The Math Without Fear
Where the Classes Went and Why CIDR Won
Subnetting in Real Life: Your Office, Your Home, Your VPN
Subnetting in Azure
What This Means for Microsoft 365
What to Remember, and One Question for You

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Purview Compliance Manager - Simply Explained

Fri, 23 Oct 2026 19:25:32 +0000

Learn how Microsoft Purview Compliance Manager turns messy compliance questions into a single score. Understand assessments, templates, and actions.

There's a question that makes most companies go quiet, and it's the one about whether they're actually compliant. Compliance Manager lives inside Microsoft Purview, and it takes that messy question and turns it into a single number you can watch move.

In this episode of Simply Explained you will learn:

What Compliance Manager Is
The Compliance Score
Assessments
Regulations and Templates
Improvement Actions
Who Does What
The Workflow End to End
A Quick Recap and One Open Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Windows Autopilot - Simply Explained

Fri, 23 Oct 2026 18:46:39 +0000

Learn how Windows Autopilot streamlines new laptop setup for IT teams. Discover hardware hashes, deployment profiles, Intune, and device preparation.

Imagine unboxing a brand-new work laptop and watching it set itself up for your company without an IT person in the room. That's the promise behind Windows Autopilot, and it's why a new hire can be productive on day one instead of day five.

In this episode of Simply Explained you will learn:

What Autopilot Actually Is
Why IT Teams Made the Switch
How a Device Gets Claimed: The Hardware Hash
Deployment Profiles: The Instructions the Device Follows
Joining the Organization: Entra Join and Intune
The Deployment Modes, Explained Simply
The Newer, Simpler Flavor
Where It Can Trip You Up
Recap and One Question for You

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft AI Center of Excellence - Simply Explained

Fri, 23 Oct 2026 16:42:08 +0000

Learn why organizations need a Microsoft AI Center of Excellence to govern, secure, and scale Copilot, Power Platform, and Azure AI initiatives safely.

Copilot pilots are spreading through M365, Power Platform, and Azure faster than most organizations can map them. One team uses Copilot to prepare meetings.

In this episode of Simply Explained you will learn:

Stakes, the AI Problem Teams Can’t See Yet
What an AI Center of Excellence Actually Is
Why Organizations Need One Before AI Spreads Further
Pillar One, Governance: Decisions, Guardrails, and Proof
Pillar Two, Security: Protecting Data, Identity, and AI Actions
Pillar Three, Adoption: Turning AI Access Into Useful Habits
Build the First Version of Your CoE
Implementation Challenge and Next Step

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

IoT Hub vs Event Hubs — Why Most Manufacturers Pick the Wrong Service

Fri, 23 Oct 2026 16:00:03 +0000

1. THE SHOP FLOOR SYMPTOM & CORE CHALLENGETeams frequently send plant telemetry into Azure using whatever service sounds right in initial workshops, only to discover months later that the data path cannot support actual plant operations. This often results in multiple dashboards showing conflicting values (such as 5-minute averages compared against maximum values or alarms) derived from copies of the same signal. Ultimately, this technical disconnect creates an issue of trust rather than a simple software bug. The root mistake lies in treating all incoming machine data as generic telemetry instead of separating device control, configuration state, commands, and stream processing.

2. CLASSIFYING FACTORY TRAFFICBefore selecting Azure services, traffic must be categorized by name, direction, and ownership to ensure proper handling.

Events represent facts tied to a specific point in time, detailing what happened and when, such as a completed press cycle or a vibration reading crossing a limit. These are append-only records that should not be edited downstream.
Commands are requests telling a device or gateway to perform an action with specific intent, such as collecting diagnostics or testing a connection. They carry execution responsibility and must respect local programmable logic controller (PLC) and safety boundaries.
State reflects the current known condition of a device, like its software version or active recipe mapping, rather than its complete chronological history. State is typically managed via desired and reported properties.
Business messages involve operational work that must happen and be tracked, including quality holds and maintenance requests. These should never be mixed directly into raw sensor event pipelines.

3. MENTAL MODEL: IDENTITY GATE VS. DATA HIGHWAYAzure IoT Hub acts as the controlled gate, focusing primarily on device relationships and life cycles through an identity registry, authentication, and enabled or disabled status. This allows security teams to isolate or disable a single compromised or suspect gateway—such as a line 4 gateway—during an incident without shutting down the entire plant's telemetry path. Conversely, Azure Event Hubs serves as the data highway, focusing entirely on stream processing and high-volume movement for many independent readers. Event Hubs does not manage device lifecycles, firmware, or desired configurations; its primary job is keeping traffic moving efficiently through partitions and consumer groups.

4. DEVICE MANAGEMENT & SECURITYAuthentication options depend heavily on hardware capabilities and security architecture. Symmetric keys using SAS tokens are well-suited for constrained hardware and gateways, but they require secure hardware storage to prevent key theft. Alternatively, X.509 certificates provide cleaner chains via a trusted Certificate Authority for larger fleets, though they demand robust rotation and lifecycle management. The device lifecycle follows an enrollment, change, disable, and replace pattern, ensuring a replacement hardware unit links cleanly to its operational role and cloud identity without breaking downstream pipelines or creating phantom assets. Furthermore, device twins utilize desired and reported states for configuration management and health status, though high-frequency telemetry should never be stored within device twins.

5. STREAM PROCESSING & ROUTING MECHANICSPartitions divide streams into ordered lanes where ordering guarantees apply strictly within a single partition, typically partitioned by machine, line, or gateway ID according to business logic. Consumer groups allow multiple downstream systems—such as OEE calculators, condition monitoring tools, and data lake ingestion services—to read the same stream independently without competing for read positions. Stream retention provides a working window for short-term recovery, fault tolerance, and logic correction through replay. However, stream retention does not replace a durable historian or lakehouse for long-term record-keeping.

6. ARCHITECTURAL DECISION SUMMARYWhen evaluating services, Azure IoT Hub is best used for managed edge gateways, remote configurations, and device security isolation via a per-device registry and native device twins. Azure Event Hubs is best used for continuous, high-volume telemetry distributed to multiple consumers using namespace-level access policies without native device lifecycle management. A robust factory architecture frequently combines both options, using IoT Hub at the connection boundary to manage trust, identity, and configuration while utilizing Event Hubs downstream to safely distribute the high-volume event stream across independent consumers.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Semantic Kernel - Simply Explained

Fri, 23 Oct 2026 14:10:00 +0000

Learn what Microsoft's Semantic Kernel is, how plugins and function calling work, and how to connect your code to LLMs. Plain English guide.

Semantic Kernel is the layer under Microsoft's AI tools that almost nobody explains. It's a free, open-source kit that lets your own code talk to a large language model, and lets that model call your code back.

In this episode of Simply Explained you will learn:

What Semantic Kernel Actually Is
The Kernel and the Name
Plugins and Functions
Planning and Function Calling
Memory and RAG
Connectors and Prompts
One Kit, Three Languages
Copilot, Foundry, and What Comes Next
When to Use Semantic Kernel
The Recap and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Connect ERP, MES, and IoT — Without Replacing Anything

Fri, 23 Oct 2026 04:00:03 +0000

When a bottleneck machine stops, ERP, MES and IoT data can all be correct and still not tell the factory what to do next. This episode is for manufacturing IT, OT and data architects who need to connect existing systems without a replacement program. You will learn how ownership, context, data contracts, a unified namespace and Microsoft building blocks turn machine signals into trusted production decisions.

In this episode

00:00 – ERP, MES and IoT: three views of one machine stop
18:36 – The context gap between data and meaning
24:48 – Re-planning after a bottleneck failure
30:48 – Point-to-point integration and keeping system ownership
50:54 – Choosing data flows and protocols by the decision
63:46 – Brownfield equipment and the PLC, MES, edge and cloud boundaries
76:31 – ISA-95, the unified namespace and its governance
100:42 – Manufacturing integration platform and Microsoft's role

Key takeaways

ERP owns the business commitment, MES owns the execution record and the PLC and IoT layer own the physical signal, so integration should connect their meaning rather than replace any of them.
Asset identity maps, shared state models, named ownership and versioned data contracts matter more than any single protocol such as OPC UA, MQTT, REST or digital I/O.
A governed unified namespace and a manufacturing integration platform, built with services such as Azure, Microsoft Fabric and Power BI, reduce point-to-point coupling while control authority stays with the PLC and approved workflows.

Explore more on M365.FM

Episode page: the full episode with chapters, takeaways and FAQ on connecting ERP, MES and IoT
Microsoft Fabric – the shared analysis space where edge telemetry, MES events and selected ERP records meet
Power BI – the decision-end view with drill-through, which should consume governed models instead of hidden report formulas
Power Platform – Power Apps and Power Automate for bounded tasks like downtime reasons, not uncontrolled writes
Microsoft Azure – the building block for cloud infrastructure, integration, identity, monitoring and industrial data connectivity
Related episode: What Happens When Sales Promises an Urgent Order

Power Platform Governance - Simply Explained

Fri, 23 Oct 2026 03:44:39 +0000

Learn what Power Platform governance really means. Discover environments, data policies, ownership, and how to control apps without killing innovation.

Somewhere in your organization, an app is running that nobody remembers building. It still works, so nobody asks.

In this episode of Simply Explained you will learn:

What Governance Really Means
Why Anyone Bothers
Environments Are Just Rooms
Data Policies: The Rules of the Road
Who Actually Owns This
Watching What Happens
Control Without Killing Freedom
The Short Version

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Edge vs. Cloud in Manufacturing- Why the Wrong Architecture Costs You More

Thu, 22 Oct 2026 16:00:02 +0000

When a production line halts mid-shift, the real cost isn't just measured on a cloud billing dashboard. It manifests as physical scrap, operators standing idle at a stopped station, and networks flooded with unneeded data. Most cloud-first projects fail because they immediately push everything upward, ignoring the reality of the factory floor where milliseconds and local constraints dictate whether a product makes it or gets scrapped.

THE FACTORY CLOCK: MATCHING WORKLOADS TO TIME HORIZONSA manufacturing plant does not run on a single timeline; it operates on multiple concurrent clocks that handle delay differently. Treating these timelines as a neat hierarchy where slow always means cloud and fast always means edge is a critical design flaw.

Milliseconds: Dedicated to control loops and local detection where actions must occur while the process is actively moving.
Seconds: Allocated for operator alerts and supervised responses, giving human workers time to interpret conditions safely.
Minutes and Hours: Fit shift management, production reviews, line balancing, and MES workflows.
Days and Weeks: Designed for maintenance planning, long-term quality trends, capacity analysis, and model training.

SIX QUESTIONS FOR EVERY WORKLOAD PLACEMENTBefore assigning any workload to the edge or the cloud, you must run it through six strict operational criteria to avoid architecture failures during production:

Response Deadline: What is the exact physical consequence if the response arrives late? Does a part move beyond the rejection point, or does the decision just show up later in a report with no physical consequence?
Outage Behavior: Does the function need to survive and continue locally through an unannounced network or firewall drop? You want graceful degradation where production continues within defined local limits.
Data Gravity: How much data is created, and what format does it actually need to take when moving upstream? A design that collects everything forever ends up paying for every unnecessary byte more than once.
Scope: Is the decision constrained to a single sensor, an individual asset, an entire line, or multi-site fleet operations? Local scope favors local placement, while broader scope pushes work upward.
Context: What information (such as work orders, recipes, or material lots) is required to trust the decision without creating brittle live dependencies? Synchronize context as controlled reference data rather than forcing queries to a distant business system for every local choice.
Risk and Governance: Who owns the source data, who approves rule changes, and what audit trail is legally or operationally required? Vague ownership inevitably becomes a production problem later.

THE HYBRID SWEET SPOT: CONTROL AT THE EDGE, HISTORY IN THE CLOUDA resilient architecture does not duplicate the same system on-site and in the cloud. Instead, it roots workloads where they perform best:

The Controller: Handles deterministic control, safety loops, and direct machine sequences.
The Edge Layer: Collects local signals, enforces bounded rules, buffers events securely during outages, and handles fast inspection and inference.
Plant Systems (MES/ERP): Manage local execution, work orders, workflow context, and enterprise business records.
Cloud and Fabric: Maintain shared multi-site history, fleet-wide asset analytics, supply chain context, and governed semantic layers.

By respecting these boundaries, you stop treating edge versus cloud as a platform popularity contest and start building a dependable, graceful manufacturing system that protects your plant when it matters most.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Windows Hello for Business - Simply Explained

Thu, 22 Oct 2026 14:15:02 +0000

Discover how Windows Hello for Business replaces vulnerable passwords with secure biometric sign-ins, hardware-backed keys, and TPM chips in Microsoft 365.

Microsoft's cloud sees over three hundred million fraudulent sign-in attempts every day, and almost all of them are aimed at passwords. You might think the fix is a longer password, but the real fix is to take the password out of the picture.

In this episode of Simply Explained you will learn:

Why passwords fail
What Windows Hello for Business is
Your PIN is not a password
Where your face and fingerprint go
The chip that holds the key
How the sign-in works
Key trust, certificate trust, cloud trust
Windows Hello vs Windows Hello for Business
What this means for you

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Fabric Mirroring - Simply Explained

Thu, 22 Oct 2026 13:35:01 +0000

Learn how Microsoft Fabric Mirroring delivers near real-time database updates to OneLake in 15 seconds. Compare mirroring with shortcuts and pipelines.

Changes to your database can land in Microsoft Fabric as fast as fifteen seconds later. That is the promise of Fabric Mirroring, and it is not the same thing as copying your data once.

In this episode of Simply Explained you will learn:

Why Your Data Is Stuck
How the Copy Actually Gets There
What You Get Once It's There
Which Sources You Can Mirror
Mirroring vs Shortcuts vs Pipelines
What It Costs and Where It Stops
When Mirroring Is the Right Move
Recap and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Microsoft Purview Unified Catalog - Simply Explained

Thu, 22 Oct 2026 13:30:02 +0000

Discover how the Microsoft Purview Unified Catalog simplifies data discovery, governance, and quality across your organization in plain English.

Your company's data isn't missing, it's just impossible to find. Most teams keep their data spread across different systems, and when someone needs the right numbers, they end up asking around instead of searching.

In this episode of Simply Explained you will learn:

The Data Problem
What It Actually Is
Domains
Data Products
Glossary Terms
Data Quality
Who Uses It
Recap and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Power BI Semantic Models - Simply Explained

Thu, 22 Oct 2026 11:20:02 +0000

Learn what a Power BI semantic model really is. Master tables, relationships, star schemas, storage modes like Direct Lake, and reuse in this guide.

You think your Power BI problem is the chart, but the chart is the easy part. Every report you build is powered by a layer underneath it called a semantic model, and it holds the tables, the links, and the calculations that turn raw data into business-ready numbers.

In this episode of Simply Explained you will learn:

What a Semantic Model Really Is
Tables, Relationships, and Measures
Star Schema, Minus the Jargon
Import, DirectQuery, and Direct Lake
Build It Once, Reuse It Everywhere
The Quick Recap

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Windows Autopatch - Simply Explained

Thu, 22 Oct 2026 09:15:02 +0000

Learn what Windows Autopatch is, how it solves monthly update chores, where Intune fits in, and how deployment rings work in this clear, jargon-free guide.

Every company that runs Windows is stuck with the same unpaid chore: patching hundreds of machines, every month, forever. Most IT teams don't fall behind because they're careless, they fall behind because that job never actually ends.

In this episode of Simply Explained you will learn:

What It Actually Is
The Problem It Solves
Where Intune Fits In
The Rings
The Groups
Readiness Checks
The Reports
What It Updates
Who Gets It
The Benefits
What It Doesn't Do
The Short Version

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

PowerShell for Microsoft 365 - Simply Explained

Thu, 22 Oct 2026 07:33:56 +0000

Learn PowerShell for Microsoft 365. Discover modules, cmdlets, pipelines, and safe scripting habits to automate admin tasks without the fear.

An hour of clicking in Microsoft 365 does the job of one typed line. That typed line is PowerShell, and it's the difference between doing a task once and doing it a hundred times.

In this episode of Simply Explained you will learn:

What PowerShell Actually Is
Why Admins Reach For It
The Modules: Graph PowerShell and Exchange Online
Connecting and Signing In
Cmdlets and the Pipeline
Safe Scripting Habits
Common Tasks You Can Automate
Where to Start as a Beginner
Recap and One Open Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

What Is a PPR Knowledge Graph — and Why Manufacturing AI Needs One

Thu, 22 Oct 2026 04:00:02 +0000

Factory AI can read ERP, MES and historian data but still does not know how a product, process and resource came together at one moment. This episode shows manufacturing data architects and plant engineers how a product-process-resource knowledge graph adds that context and enables root cause analysis, prediction and change impact work.

In this episode

00:00 – The factory question hidden inside an AI project
08:22 – What PPR actually models
15:11 – A graph is not yet manufacturing knowledge
29:14 – Product, process and resource in depth
49:37 – Time, change and ISA-95
63:42 – OPC UA, AAS and where Microsoft Fabric fits
77:47 – A practical PPR architecture in layers
84:47 – Use cases: root cause, prediction and change impact

Key takeaways

A PPR knowledge graph links product, process and resource facts from ERP, MES, historian and maintenance systems so an operating situation can be reconstructed instead of guessed.
Planned and actual facts must stay separate and the model must preserve effective time, because the same machine, route or product name can mean different things after a revision or tool change.
Standards like ISA-95, OPC UA and the Asset Administration Shell and platforms like Microsoft Fabric provide structure and plumbing, but the PPR semantics still need deliberate mappings from people who know the factory.

Explore more on M365.FM

Episode page: the full episode with chapters, takeaways and FAQ on PPR knowledge graphs
Microsoft Fabric – brings records into OneLake, processes streams and offers a graph capability, but PPR mappings stay manual
Related episode: From Financial Data to AI-Ready Decisions: Power BI, Microsoft Fabric, Semantic Models & AI Agents with Rishi Sapra [MVP]
Related episode: Microsoft Fabric Direct Lake - Simply Explained
Related episode: Can Value Stream Mapping Become a Live Data Model?

Should You Buy Another Machine—or Change the Production System?

Wed, 21 Oct 2026 16:00:02 +0000

Here are the show notes based on the transcript provided, organized by key themes and structured to provide a clear summary of the core arguments against reactive machine purchases and for a systems-based approach using simulation.

Episode Notes: Machine Capacity vs. System OutputOverviewA growing queue, slipping lead times, and sales demanding answers often trigger a reflex: "We need another machine." This reaction is rational—local activity looks busy, overtime is climbing, and that specific work center seems to be at its limit.

However, before making a capital investment that will sit on the books for years, there is a crucial question to ask: Do you have a machine capacity problem, or a production system problem?

This episode explores why high utilization at a single work center does not prove that a machine is the plant's overall bottleneck. We discuss how simple capacity calculations (planned hours divided by rated speed) create false confidence and explain why investment decisions must follow the logic of the entire production system, from material release to final shipment.

We argue for a decision-testing approach using simulation (specifically Discrete Event Simulation). By modeling orders moving through time and respecting finite constraints (like labor, shared fixtures, and material availability), simulation allows manufacturers to test alternative solutions—like shift pattern changes, different release rules, or modified batch sizes—before committing capital.

Key Themes1. Throughput is More Than Local ActivityA factory can look full and still waste capacity. True throughput is the finished product leaving the system in a form the customer accepts (commercial throughput), not the number of parts processed at a single operation.

A machine may run all day just because planners keep feeding it work, even if that output then gets blocked or creates inventory further down the route.
Material waiting in a queue represents cash tied up; material entering early but waiting longer for shipment damages cash flow.

2. The Problem with "Bottleneck Math"Simple capacity calculations create false confidence by using theoretical averages that hide the reality of everyday production disruption.

The flawed formula: Planned production hours / cycle time = output number of parts.
What this formula misses: Actual production runs on actual orders with specific due dates, setup needs, missing material, quality holds, experienced operator cover, and maintenance work. Available time is not always unusable time.
Rated vs. actual speed: Rated cycle times come from stable runs under defined conditions. Only the production system can predict what work will reach the equipment, in what sequence, and whether it can keep moving afterward.

3. The Moving ConstraintA constraint is anything that limits turn-demand into shippable product. I's not always a machine.

The limiting condition often sits outside the work center itself:
- Staffing: A trained operator on a specific shift, or a technician handling test samples and first-piece checks.
- Shared Fixtures/Tooling: A test rig or fixture sufficient for old flow but insufficient for new capacity.
- Quality Steps: Limited test technicians or inspection fixtures creating backlogs.
- Material Shortages: Stopping the route before production even starts.
The constraint moves when you touch the system: Adding physical capacity at a work center changes the rhythm of the route. Once you increase flow in one part, you expose the next downstream limit that cannot keep up (starvation and block).

4. Decoding the QueueA utilization number only tells you if a resource is working, while a queue tells you that work is waiting for a reason. Tracking queues over time provides more decision information.

WIP as a false indicator: Large WIP piles don't automatically prove a lack of machine capacity. They often point to a production control problem, where work is released based on a date in ERP rather than the system's ability to absorb it.
Little’s Law: When more work stays inside a stable production system, the average time spent there rises. Double the floor work (without lifting commercial shipping rate) and that work will wait longer, increasing searching, status checks, and exceptions.
Buffers are Not Just Inventory: Useful buffers protect a known point in the route from expected variation (normal disruptions). They hold time, not just material. The distinction is between a planned amount of work and an accidental pile.

5. Simulation as a Decision TestA capacity investment is a production system change, not an equipment purchase. Simulation (specifically Discrete Event Simulation) offers a safe, controlled environment to test these changes without disrupting customer delivery.

Test logic, not animation: The value sits in the rules, not moving vehicles or machines.
Discrete Event Simulation: Models orders moving through time, where events (material arrivals, machine states, inspection finishes) trigger the next decision logic.
Asking decision questions: Use the model to compare scenarios under defined conditions:
- What happens to ship orders if demand rises but a new operator is not available on every shift?
- Does a shift change provide similar delivery protection as buying a machine?
- Where does work wait after the machine starts running?

The Decision-Testing Frame: Product, Process, ResourceTo move simulation from theory to decision value, you must first build a shared description of the production system using three backbones:

Product: Beyond part numbers, this carries demand, due dates, batch size, variant rules, and commercial risk context.
Process: The required operations, their sequence (routing logic), setup families, alternative routes, quality specifications, first-piece checks, and quality-hold rework paths.
Resource: Machines, but also trained labor, fixtures, tools, test rigs, and physical buffer space. It holds crucial dependencies: two resources needed at once, calendars (downtime/support window), and rules that may change by quality state.

This shared description 개선 before software choices are made. It turns disconnected facts (IT/OT) into operational context needed to reason about causes and effects.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Copilot+ PCs - Simply Explained

Wed, 21 Oct 2026 15:55:02 +0000

Learn what makes a Copilot+ PC different from ordinary AI laptops. Discover the 40 TOPS NPU requirement, privacy safeguards, and who actually benefits.

One number decides whether your next laptop gets the AI features, and it's forty. Every new Windows laptop claims to be an AI PC, but only a special few earn the Copilot+ badge.

In this episode of Simply Explained you will learn:

What Makes a PC a Copilot+ PC
The Chip Most People Have Never Heard Of
What Runs Right on Your Laptop
Where Your Data Actually Goes
Copilot+ PC vs an Ordinary AI PC
Who Actually Benefits, and Who Can Wait
The Recap and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Fabric IQ - Simply Explained

Wed, 21 Oct 2026 15:41:08 +0000

Discover Fabric IQ in Microsoft Fabric. Learn how ontology, semantic models, and AI grounding stop data drift and unify your organization's data meaning.

Somewhere in your Fabric workspace, two teams are calling the same customer two different things. Your data is fine, but the meaning behind it has quietly drifted apart.

In this episode of Simply Explained you will learn:

What Fabric IQ Actually Is
Why Data Alone Isn't Enough
The Ontology, Explained
How It Connects to Semantic Models
How It Grounds AI Agents
Where It Stops
What This Means For You
Recap and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Work IQ: Simply Explained

Wed, 21 Oct 2026 15:09:52 +0000

Discover Work IQ in Microsoft 365 Copilot. Learn how it gives AI memory, understands team relationships, protects your data, and powers autonomous agents.

The AI on your desk is missing the most important thing about your work. It reads the one file you paste in, then forgets your team and your projects.

In this episode of Simply Explained you will learn:

What Work IQ Actually Is
Why Copilot Needed A Memory
The Three Layers, In Plain Words
How It Understands People And Relationships
It Only Sees What You Are Allowed To See
Where Your Data Lives
What It Means For Agents
What It Does Not Do
Recap And One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Fabric SQL Database - Simply Explained

Wed, 21 Oct 2026 14:53:42 +0000

Learn what a Fabric SQL Database is, how it compares to Azure SQL, how mirroring works, and how it powers your analytics without extra pipelines.

Fabric and SQL sound like two different things, but Microsoft built them into one. It's called a SQL database in Fabric, and underneath it runs the same engine that powers Azure SQL Database.

In this episode of Simply Explained you will learn:

What a Fabric SQL Database Really Is
Why It Feels Like Azure SQL, and Where It Doesn't
The Copy That Makes Itself
One Database, Two Jobs
How It Uses Your Fabric Capacity
Where It Fits, and Where It Stops
The Short Recap, and One Question for You

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Power Platform Solutions - Simply Explained

Wed, 21 Oct 2026 14:15:17 +0000

Learn how Power Platform solutions work. Master managed and unmanaged modes, environment deployment, publishers, prefixes, and application lifecycle management.

The app you spent months building can disappear the moment someone uninstalls the wrong thing. That happens when nothing is holding the app's pieces together, so one cleanup can take the whole thing with it.

In this episode of Simply Explained you will learn:

What a Solution Actually Is
Managed and Unmanaged: The Two Modes
Publishers and Prefixes
Moving Your App Between Environments
Solution Layers
Dependencies: Why You Sometimes Can't Remove Things
ALM Best Practices for Beginners
A Quick Recap and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure Resource Graph - Simply Explained

Wed, 21 Oct 2026 13:07:11 +0000

Learn Azure Resource Graph in plain language. Discover how to query, filter, and inventory thousands of cloud resources using Kusto Query Language.

Azure Resource Graph is a service inside Azure that lets you ask questions about your resources and get fast answers, even when you have thousands of them. The name sounds heavier than the thing really is.In this episode of Simply Explained you will learn:

What Azure Resource Graph Actually Is
Why the Normal Way of Asking Azure Breaks Down
The Query Language, Explained Without the Scary Parts
Your First Query in Resource Graph Explorer
What People Actually Use It For
The Limits Nobody Warns You About
A Quick Recap and One Question For You

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure Databricks - Simply Explained

Wed, 21 Oct 2026 12:46:52 +0000

Learn what Azure Databricks actually is, how Apache Spark powers it, and when to use Lakehouse architectures over traditional data warehouses.

Apache Spark started as a research project at a university in 2009, and it grew into the engine most big data platforms still run on today. Azure Databricks is how Microsoft and the people who built Spark turned that engine into a service you can spin up inside Azure.In this episode of Simply Explained you will learn:

What Azure Databricks Actually Is
Why the Lakehouse Idea Exists
Apache Spark, in Plain Words
Notebooks, and Where You Actually Work
Clusters: The Machines That Do the Heavy Lifting
Delta Lake: Why Your Table Doesn't Fall Apart
Workspaces, Accounts, and Unity Catalog
When to Use It: Databricks, Fabric, or Synapse
The Recap, and One Question for You

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure Lighthouse - Simply Explained

Wed, 21 Oct 2026 10:16:40 +0000

Managed service providers and multi-tenant enterprises have long juggled separate logins in every customer tenant. This episode explains how Azure Lighthouse replaces that with delegated, auditable access that the customer controls, and where its limits are. You will be able to explain the handshake, the security model and the naming trap with Microsoft 365 Lighthouse.

In this episode

00:00 – The two houses problem
02:35 – What Azure Lighthouse actually is
04:40 – The handshake: how the door gets built
07:15 – Who uses it and who approves it
09:45 – The security story: who holds the keys
12:08 – What Azure Lighthouse is not
13:55 – Recap and one question

Key takeaways

Azure Lighthouse lets a provider manage a customer's Azure resources from its own tenant through a registration definition and a registration assignment, with no account in the customer's directory.
The customer chooses the scope and built-in role, sees every provider action in its own activity log and can remove the delegation at any time.
Lighthouse covers Azure Resource Manager operations only, does not support the Owner role or data-access roles, and is a different product from Microsoft 365 Lighthouse.

Worth quoting

“Azure lighthouse lets one organization manage another organization's Azure resources from its own environment without needing an account inside the other organizations directory.” – Mirko Peters (02:36)

“What makes this different from simply handing somebody your password is that the door is written down. It has a name, a scope, and a role attached to it.” – Mirko Peters (04:13)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on Azure Lighthouse
Microsoft Azure – the platform whose resources a provider manages through Azure Lighthouse without customer-tenant accounts
Microsoft Marketplace – one of two onboarding routes, where customers pick a managed service offer and delegate subscriptions
Microsoft – the vendor behind Azure Lighthouse, quoted for its least-privilege guidance and product limits
Related episode: Multi-Factor Authentication (MFA) - Simply Explained

Azure Management Groups and Subscriptions - Simply Explained

Wed, 21 Oct 2026 10:16:31 +0000

Once an Azure tenant grows past a handful of subscriptions, permissions, policies and costs drift out of control. This Simply Explained episode is for admins and cloud teams who need a clear map of the Azure hierarchy. It shows how management groups and subscriptions work together so you can set rules once and see costs in one place.

In this episode

00:00 – Why Azure turns into a mess without a map
02:35 – The subscription is where your Azure actually lives
04:36 – Management groups are the folder above your subscriptions
06:52 – How permissions and policies flow down the tree
09:43 – What a good structure actually looks like
12:05 – Naming, cost boundaries and keeping it sane
14:05 – A quick recap and one question

Key takeaways

Subscriptions carry billing, quotas and the link to one Microsoft Entra tenant, while management groups sit above them purely for governance.
Access (RBAC) and Azure Policy assigned at a management group are inherited by every subscription and resource below it, and a deny higher up cannot be overridden lower down.
Follow the landing zone pattern: keep the hierarchy flat with platform, landing zones, sandbox and decommissioned branches, and use management group views to roll up usage costs.

Worth quoting

“Azure isn't hard because the individual pieces are complicated because most of them aren't. It gets hard because the pieces multiply and multiplication without structure turns into noise.” – Mirko Peters (00:50)

“You might think more subscriptions means more control, but the opposite is true because more subscriptions means more places for the rules to drift.” – Mirko Peters (04:22)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on the Azure hierarchy
Azure landing zone – Microsoft's blueprint whose management group hierarchy the episode uses as the model structure
Microsoft Azure – the cloud platform whose tree of management groups, subscriptions and resources the episode maps
Governance – the rules and permissions that management groups exist to apply across many subscriptions
Related episode: Microsoft Entra Tenant Governance - Simply Explained

Azure Reservations and Savings Plans - Simply Explained

Wed, 21 Oct 2026 10:01:39 +0000

Learn the difference between Azure Reservations and Savings Plans. Discover how to cut cloud costs, choose the right term, and avoid wasted spending.

Normally the cloud bills you after the fact. You start a virtual machine, it runs for a month, and the bill arrives based on what you used.In this episode of Simply Explained you will learn:

Why Pay Before You Use It
Azure Reservations, Simply Explained
Azure Savings Plans, the Looser Option
What Each One Actually Covers
Which One Fits
One Year or Three
Where Your Discount Applies
The Only Math That Matters
The Mistakes That Waste Money
A Quick Recap and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

SPF, DKIM and DMARC - Simply Explained

Wed, 21 Oct 2026 10:01:23 +0000

Learn how SPF, DKIM and DMARC work together in Microsoft 365 to stop email spoofing, prevent Business Email Compromise, and secure your domain.

Anyone with a laptop can send email that pretends to be your company. The email system we all rely on was built to move messages, not to check who the sender really is.

In this episode of Simply Explained you will learn:

Why Anyone Can Send Email as You
SPF: The Guest List for Your Domain
DKIM: The Tamper-Proof Seal
DMARC: The Rule That Ties It Together
What the Records Actually Look Like
None, Quarantine, and Reject in Plain Words
The Reports That Tell You What's Happening
The Right Order to Roll This Out
The Mistakes That Trip People Up in Microsoft 365
Recap and One Question for You

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure App Service - Simply Explained

Wed, 21 Oct 2026 10:00:16 +0000

Master Azure App Service with our plain-English guide. Learn how App Service plans, pricing tiers, deployment slots, and scaling work to avoid costly traps.

The tier you pick on Azure App Service decides what your app is even allowed to do. It's Microsoft's managed home for web apps and APIs, so you bring the code and Microsoft runs the machines underneath.

In this episode of Simply Explained you will learn:

What It Actually Is
The Plan Is the Product
Web Apps and APIs
Pricing Tiers, Decoded
Deployment Slots
Scaling Up Versus Out
Domains and Certificates
Mistakes Beginners Make
The Short Version

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

Azure Machine Learning - Simply Explained

Wed, 21 Oct 2026 09:53:41 +0000

Learn how Azure Machine Learning simplifies building, training, and deploying ML models in the cloud. Demystify workspaces, data, compute, and MLOps.

Machine learning is a program that finds patterns in examples instead of following rules a person wrote by hand. That's the whole idea.In this episode of Simply Explained you will learn:

What Machine Learning Really Is
What Azure Machine Learning Actually Does
The Workspace
Data and Compute
Building a Model
Turning It Into Predictions
Keeping It Working
What You'd Actually Build
Recap and One Question

Simply Explained by M365.FM breaks down Microsoft 365, Azure and modern IT topics in clear, jargon-free language. Hosted by Mirko Peters.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

This episode includes AI-generated content.

MQTT and OPC UA in Microsoft Manufacturing: Azure IoT Operations + Fabric Architecture

Wed, 21 Oct 2026 04:00:03 +0000

UNTANGLING THE PLANT FLOOR: MQTT vs OPC UA & THE TRUTH ABOUT DISCONNECTED MANUFACTURING DATAWhy are modern factories still running on manual exports and guesswork despite having ERP, MES, and Azure systems in place? This episode cuts through the technology hype to address the core problem: a fundamental lack of trust in manufacturing data. People try to frame industrial connectivity as a winner-takes-all battle between MQTT and OPC UA, but that misses the point entirely. If your operators trust the local HMI more than the corporate dashboard, or if every OEE review devolves into an argument about whose numbers are right, you don't have a protocol problem—you have a semantic problem. Technology alone does not create meaning; to build a truly connected factory, you must start with the production problem first and define a shared language for production events before scaling up your technology stack.

In This Episode, We Discuss:

The Trust Gap on the Plant Floor: Why planners work from spreadsheets and operators rely on local HMIs despite heavy investment in ERP and Azure.
The Battle of the Numbers: Why morning, afternoon, and night shifts often arrive at three different production counts, and why none of them are necessarily wrong, just descriptive of different points in the process.
MQTT vs. OPC UA – Two Different Jobs, Not Rivals:
- MQTT (Transport): A lightweight, published/subscribe protocol that excels at routing messages efficiently, decoupling publishers from consumers, and handling unstable networks. It doesn't care what is in the payload; it just delivers the envelope.
- OPC UA (Meaning): Defines what the thing is and what a value represents. It exposes a browsable address space with structured models, variable types, engineering units, and security built into the application layer.
Why New Dashboards Fail to Solve Disconnected Data: A clean chart doesn't create meaning. A dashboard cannot guess if state code "one" means running, idle, or faulted without context from the machine.
The Practical Role of the Edge: Why it is critical to normalize data once near the source, rather than mapping it five times in different downstream systems.
ISA-95 as a Naming Contract: Using the enterprise-to-cell hierarchy as a stable map to locate assets consistently before applying changing business context like work orders and products.
The Unified Namespace (UNS) Hype: Understanding UNS as a common event space for IT and OT to publish facts, not a new master database or a magic bullet that creates a shared operating model without effort.
MQTT Topic and Payload Design:
- The dangers of stuffing transient context (product codes, order numbers) into static topic paths.
- Why topic names are case-sensitive and demand strict lowercase conventions.
- The "cost of casual JSON" and why semantic contracts (types, units, lineage) are essential.
Sparkplug B: How it adds industrial rules to MQTT (defined topics, birth/death lifecycle state) but still doesn't replace the need to define what your production events actually mean.
Azure IoT Operations & Microsoft Fabric: Microsoft's edge data plane pattern, running modular services on Arc-enabled Kubernetes, and why a production-ready deployment demands hybrid IT/OT skills.
The Control vs. Data Plane Boundary: Why local control loops must remain independent of the cloud, and why a broker is never a safety controller.

Key Quote"transport and meaning are different jobs. MQTT roots messages where they need to go, and OPC UA provides machine data with structure and context."

Tags: #ManufacturingData #MQTT #OPCUA #UnifiedNamespace #ISA95 #IndustrialIoT #OEE #AzureIoTOperations #MicrosoftFabric #ITOTconvergence #SmartFactory

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Your Machine Data Never Becomes a Decision. Here's the Missing Pipeline.

Tue, 20 Oct 2026 16:00:03 +0000

Many factories stream machine data to the cloud and build live dashboards, yet a stopped line still ends with someone calling the planner. This episode is for manufacturing, OT and data architects who want to connect a machine fault to a changed production decision. It walks through the full pipeline from edge and event transport through Fabric Real-Time Intelligence, context, APS and governed write-back.

In this episode

00:00 – Why Excel still sits between alarm and action
04:33 – Capture, interpret, decide, act
09:34 – From the edge to meaningful events
24:44 – Fabric Real-Time Intelligence, Eventhouse and KQL
44:42 – Shared data model, digital twin and knowledge graph
64:37 – Copilot explains, APS tests feasible plans
73:40 – The line three scenario and what an event does not know
94:40 – Closing the loop, Activator and decision quality

Key takeaways

A machine event is a fact, not a decision: value only appears when it changes a named decision with a clear owner in time.
Shared asset identities, data contracts and context joins to MES, ERP and planning data must come before AI or automated escalation.
Use Fabric Real-Time Intelligence and Activator for awareness and tracked workflows, APS for feasible plans, and keep machine control local and safe.

Worth quoting

“A temperature reading, a fault code, or a machine stop does not create value just because it entered a cloud platform. It creates value when it changes a named decision in time for that decision to matter.” – Mirko Peters (83:25)

“If those names don't resolve to a single approved asset identity, any AI system will get four partial stories about one physical machine. That's not an AI problem, it's a data model problem” – Mirko Peters (45:07)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ on the pipeline
Microsoft Fabric – Fabric Real-Time Intelligence as the shared layer between machine events, production context and action
Fabric Data Activator – watches defined stop, fault and reject conditions and triggers alerts or tracked workflows
Kusto Query Language (KQL) – used in Eventhouse to measure stop duration, find repeat faults and spot related conditions
Related episode: KQL Databases in Fabric - Simply Explained

From Sensor to Dashboard: The MQTT Pipeline Through Azure IoT Hub

Tue, 20 Oct 2026 04:00:03 +0000

Most factory dashboards start at the wrong end: they show a temperature or an OEE number, but nobody can explain where the message came from or whether it can be trusted. This episode is for OT and IT architects, data engineers and manufacturing leaders building industrial IoT on Azure. Follow one telemetry message from a PLC through an edge gateway, MQTT and Azure IoT Hub into Event Hubs, storage, Microsoft Fabric and a dashboard people can act on.

In this episode

00:00 – A sensor signal is not yet manufacturing information
05:28 – The edge layer between PLCs and the cloud
10:57 – MQTT basics and why fleets change the problem
21:53 – Azure IoT Hub, identity, TLS and the MQTT connection
44:27 – Topics, payload contracts and time
60:05 – QoS, routing, Event Hubs, storage and Fabric
88:20 – OEE, ERP, MES and context models
103:12 – Dashboards, alerts and edge resilience

Key takeaways

A raw sensor reading only becomes manufacturing information when the pipeline preserves its source, unit, quality state and source timestamp and links it to production context.
Azure IoT Hub uses MQTT as a managed device connection with per-device identity, fixed topics, QoS 0 or 1 and routing, so it complements rather than replaces a local MQTT broker.
Route telemetry by consumer need into Event Hubs, raw storage and Microsoft Fabric, design consumers to handle duplicates and late data, and keep safety-critical control local at the edge.

Explore more on M365.FM

Episode page: the full episode with chapters, takeaways and FAQ on the MQTT pipeline
Azure Event Hubs – the routed streaming path where consumer groups read alarm candidates, checkpoint and replay telemetry
Microsoft Fabric – where Eventstream, Eventhouse and lakehouse patterns turn routed IoT Hub telemetry into queryable data
Power BI – the consumption layer for role-based factory reports, not the system of record for machine state
Related episode: IoT Hub Message Routing vs Event Grid — Why Telemetry and Events Are Not the Same Problem

Azure DPS: Why Provisioning 100,000 IoT Devices Is an Architecture Problem

Mon, 19 Oct 2026 16:30:02 +0000

Provisioning ten IoT devices by hand is easy, but at 100,000 devices every shortcut becomes a security and support problem. This episode explains Azure Device Provisioning Service for IoT architects and manufacturing IT teams, from device identity and attestation to enrollment groups and IoT Hub allocation. Learn how to build a zero-touch onboarding path that survives factories, suppliers and field replacements.

In this episode

00:00 – Why 100,000 devices change everything
05:23 – What Azure DPS actually does
11:14 – Zero-touch provisioning step by step
17:19 – The identity model behind the device
23:50 – Attestation and TPM
36:30 – X.509 certificates and symmetric keys
59:44 – Enrollments, initial state and first boot
77:55 – IoT hub allocation and capacity planning

Key takeaways

Do not bake an IoT Hub connection string into the device image; let Azure DPS assign the hub on first boot after the device proves its identity.
Choose TPM, X.509 or symmetric key attestation based on hardware, supplier chain and service process, and plan certificate renewal, revocation and replacement from day one.
Design enrollment groups and allocation policies around real trust, data residency and capacity boundaries rather than portal convenience.

Worth quoting

“At fleet scale, that engineer becomes part of the runtime architecture, which is a polite way of saying the design has already failed.” – Mirko Peters (02:02)

“zero touch removes manual setup from the field. It does not remove the trust check. If anything, it puts more pressure on the trust model because there may be no technician there to catch a bad enrollment.” – Mirko Peters (10:10)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ on Azure DPS
Microsoft Azure – the cloud platform behind Azure DPS and IoT Hub, which admit and connect device fleets
Related episode: Building Azure That Survives the Real World — with Mike Martin [MVP]
Related episode: Azure Bicep - Simply Explained
Related episode: Fabric SQL Database - Simply Explained

Digital Twins on Azure: What Should You Actually Model?

Mon, 19 Oct 2026 04:34:53 +0000

Many digital twin projects start with a 3D factory scene or every PLC tag and end up with a graph nobody can use. This episode is for manufacturing IT and OT architects building on Azure and explains what deserves a twin, how to model identity, state, events and relationships, and where Azure Digital Twins fits next to ERP, MES and APS. You will leave with five questions to test any twin before you build it.

In this episode

00:00 – Start with the decision, not the asset
05:20 – What a twin really is: an instance with context
10:40 – Digital twin, device twin, 3D model and simulation
16:35 – Model identity before telemetry
21:40 – State, telemetry and events
37:20 – Relationships, structures and the order twin
63:40 – DTDL, model boundaries and five questions
91:40 – Azure Digital Twins as the context layer and source ownership

Key takeaways

Start a digital twin with a repeating decision and the person who makes it, then model only the entities, state and relationships that change that decision.
Give every entity one stable twin ID, keep raw telemetry in time series storage and put only trusted current state with source, time and quality on the twin.
Azure Digital Twins is the context layer that connects ERP, MES, APS and PLC facts through DTDL models and relationships, while each source system keeps ownership of its own facts.

Explore more on M365.FM

Episode page: the full episode with chapters, key takeaways and an FAQ on digital twin modeling
Microsoft Azure – the platform hosting the twin graph, event paths, APIs and time series storage around the plant
Power BI – the view layer for OEE and downtime Pareto analysis, which needs no twin graph behind it
Azure Event Hubs – the route for streaming twin and event changes into processing or analytics
Azure Service Bus – the route when a workflow needs reliable message handling and controlled delivery of twin events
Related episode: Traceability and Genealogy: Tracking Every Part From Supplier to Customer

What Happens When Sales Promises an Urgent Order

Sun, 11 Oct 2026 07:10:02 +0000

When sales promises an urgent delivery date, the order lands in a factory schedule that is already full, and other customers quietly absorb the delay. This episode is for manufacturing planners, operations leaders and data architects who connect ERP, MES and analytics. It shows how to turn urgent requests into visible, tested trade-offs with a shared promise process and a layered decision architecture.

In this episode

00:00 – The urgent order and the factory scenario
05:45 – A promise is not a production plan
10:10 – Machine time, displaced orders, material and labor
34:00 – Shifting bottlenecks, OEE and cascading delivery dates
52:50 – Excel, missing context and Microsoft Fabric as the data layer
70:30 – Simulation, prediction and optimization
79:05 – Who defines priority: governance and a shared promise process
88:10 – Decision architecture, Copilot and human judgment

Key takeaways

A priority flag in ERP does not create capacity: an urgent order always takes machine time, material, people or inspection slots from existing commitments.
Finite capacity scheduling and simulation make the trade-off visible before the plant moves, while OEE dashboards and Excel recovery files only describe parts of the situation.
Microsoft Fabric, Power BI, Power Platform and Copilot can connect ERP and MES facts and route approvals, but the feasibility decision needs scheduling logic, defined urgency categories and an accountable human owner.

Explore more on M365.FM

Episode page: the full episode with chapters, key takeaways and an FAQ on urgent order promises
Microsoft Fabric – the shared data layer tying ERP orders, MES events and supply data together, without solving scheduling
Power BI – the shared view of order exposure and capacity pressure for sales, planning and production
Microsoft Excel – the planner's emergency control room when ERP and MES do not talk to each other
Microsoft 365 Copilot – a safer interface once data, scheduling logic and approvals exist, for questions and customer update drafts
Related episode: Power Platform Copilot Integration - Simply Explained

Why AI Can't Optimize a Factory It Doesn't Understand

Sat, 10 Oct 2026 04:50:02 +0000

A machine stops and ERP, MES, maintenance and the PLC each know part of the story, so AI cannot safely optimize the response. This episode shows manufacturing and data leaders how semantic layers, knowledge graphs, digital twins and clear constraints give AI the factory context it needs to support real production decisions.

In this episode

00:00 – A machine stops: why AI needs factory context
05:07 – Every system knows something
09:50 – Data versus context
14:30 – Dashboards, prediction and optimization
27:50 – Knowledge graphs and digital twins
41:40 – Asset identity, constraints and data quality
65:50 – Architecture with Azure, Fabric and Power BI
79:40 – Semantic layer, simulation and accountable decisions

Key takeaways

Factory AI fails less from weak models than from missing context: which asset, operation, order, tool, person and rule an event belongs to.
A semantic layer or knowledge graph should connect facts across ERP, MES, maintenance, quality and machine data while the source systems keep ownership.
Prediction, simulation, optimization and generative AI have different jobs, and a named person still approves decisions while safety and control stay in the operational layer.

Explore more on M365.FM

Episode page: the full episode with chapters, key takeaways and an FAQ on factory AI context
Microsoft Fabric – the shared place to combine ERP, MES, maintenance and quality data, which still lacks shared meaning
Microsoft Azure – the layer for secure event intake, integration and processing, kept outside safety and control paths
Semantic model – the fix for conflicting terms like available, complete and done across ERP, MES and quality
Power BI – the consumption end that shows OEE, downtime and impact but cannot decide what production moves next
AI assistant – the planner's helper that can only answer grounded questions once orders, assets and rules are connected
Related episode: Microsoft Fabric Shortcuts - Simply Explained

Production Schedule Optimization - How to Build Better Production Schedules

Fri, 09 Oct 2026 07:08:54 +0000

A production schedule can look correct while the factory has already moved on. A machine runs slower than expected, a setup takes longer, material is still waiting for release, or an urgent order enters the plan. ERP still shows the original dates, MES shows current execution, and the supervisor has already started adjusting the sequence on the floor. The real challenge is keeping the schedule connected to what production can actually do now.

FROM PRODUCTION PLAN TO EXECUTABLE SCHEDULE
A production plan describes what the business intends to make. A production schedule turns that demand into real work on specific machines, during specific shifts, with the required materials, tools, people, and approvals available.

That means a schedule needs more than due dates and work-order numbers. It needs routes, operation times, setup rules, resource capability, material status, quality gates, calendars, tooling, and enough execution information to understand whether the next operation can really start.

ERP, MES, AND SHOP-FLOOR REALITY
ERP should remain the source for customer demand, production orders, due dates, inventory, purchasing, and commercial commitments. MES works closer to execution and tells the scheduling process which operations are running, what quantities are complete, where work is blocked, and what actually happened during the shift.

Neither system provides the complete scheduling picture alone. A credible schedule combines business priorities from ERP with current execution information from MES and relevant shop-floor events from OT systems.

FINITE-CAPACITY AND CONSTRAINT-BASED SCHEDULING
Constraint-based scheduling begins with what the factory can actually support. Instead of loading orders against preferred dates and discovering overload later, the scheduler checks whether the work fits the real capacity available.

Typical constraints include:
• Machine availability and capability
• Setup and changeover time
• Material and batch availability
• Operator skills and shift calendars
• Fixtures, tools, gauges, and secondary resources
• Maintenance periods
• Quality holds and inspection requirements
• Operation sequence and routing rules

A machine may have eight available hours. The schedule should not quietly assign twelve hours of work and leave production to solve the difference.

HARD CONSTRAINTS VS SOFT CONSTRAINTS
Some rules cannot be broken. A machine without the required capability cannot run the operation, material on quality hold cannot be consumed, and an operation cannot begin before a required predecessor is complete.

Other rules are preferences. Production may prefer fewer changeovers, similar products grouped together, or a stable sequence through the current shift. Those preferences matter, but they may be overridden when an urgent customer order or major disruption requires it.

The scheduler therefore needs to distinguish between what is impossible and what is simply undesirable.

CAPACITY IS MORE THAN AN EMPTY MACHINE
An idle machine is not automatically usable capacity. The required fixture may be somewhere else, the machine may lack approval for the product revision, the gauge may be out of calibration, or the qualified operator may not be on shift.

This is why detailed scheduling needs capability data rather than only resource groups and calendar hours. The important question is not whether the machine is free. It is whether the complete operation can be executed under the conditions that apply to that specific order.

REAL-TIME RESCHEDULING WITHOUT CONSTANT CHAOS
Real-time data does not mean the entire schedule should change every time a machine sends an alarm. Production needs stability long enough for people to prepare materials, install tools, perform setups, and execute the work.

Rescheduling should therefore be exception-based. A confirmed breakdown, serious material shortage, quality hold, major execution delay, or approved priority change may justify a scheduling review. Minor deviations can simply remain in the execution history.

Freeze zones can protect near-term work that has already been staged or started, while work farther into the future remains more flexible.

OBJECTIVES AND TRADE-OFFS
A feasible schedule is not automatically the best schedule. The factory may want to protect delivery dates, reduce setups, maximize bottleneck utilization, control work in process, or keep the schedule stable.

Those objectives can conflict. Moving an urgent order forward may protect one customer commitment but create another setup, delay another order, and disturb work already prepared on the floor.

Optimization can calculate alternatives quickly, but planners still need to decide which trade-offs the business is willing to accept.

WHERE MICROSOFT FITSAzure can provide the integration layer connecting ERP, MES, OT systems, and a scheduling or optimization service. Microsoft Fabric can bring historical scheduling, execution, quality, maintenance, and selected machine data together for analysis and governance.

Power BI can help teams review schedule adherence, bottlenecks, repeated delays, planned versus actual operation times, and the reasons schedules change. Power Platform can support controlled workflows around urgent orders, route changes, quality decisions, and other exceptions that require human approval.

Microsoft technologies support the scheduling architecture, but a specialized APS or optimization engine is still needed when the factory requires finite-capacity scheduling, constraint solving, sequencing, and optimization.

KEY TAKEAWAYS
• ERP provides the business plan while MES provides execution reality.
• Detailed scheduling needs finite capacity, not generic available hours.
• Resource capability matters more than simple machine availability.
• Tools, skills, quality, materials, and maintenance can all become scheduling constraints.
• Not every shop-floor event should trigger a new schedule.
• Freeze zones help protect work already prepared or underway.
• Optimization should expose trade-offs rather than silently move work.
• Fabric, Azure, Power BI, and Power Platform can support the surrounding data, integration, analytics, and workflow architecture.
• Human judgment remains part of the scheduling process.

better production schedule is not one that never changes. It is one that reflects the real constraints of the factory, changes only when necessary, and gives planners and production teams a clear view of what can actually happen next.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

What Is an Industrial Data Model

Thu, 08 Oct 2026 15:05:02 +0000

A factory can collect mountains of data and still struggle to answer what a single machine stop really affects. This episode is for manufacturing, IT/OT and data architects who need ERP, MES, maintenance and quality data to share one meaning. Learn how an industrial data model built on product, process and resource links your systems into decision-ready context for planning, digital twins and AI.

In this episode

00:00 – A factory full of data but no shared model
02:10 – Plenty of systems, no shared meaning
05:59 – What an industrial data model actually is
11:14 – The model is not the data platform, and why tables alone break down
21:40 – PPR: product, process and resource
52:06 – From PPR to knowledge graphs, ontologies and ISA-95
66:40 – OPC UA, Asset Administration Shell, digital thread and digital twins
91:40 – AI, Microsoft Fabric, end-to-end architecture and ownership

Key takeaways

An industrial data model gives factory objects stable identities, states and relationships across ERP, MES, maintenance and quality without replacing those source systems.
Product, process and resource (PPR) is a practical core structure: it links what the plant builds, how the work must happen and what can perform it under real conditions.
Platforms like Microsoft Fabric, graph databases, digital twins and AI depend on this model and on clear ownership of each definition; they cannot infer factory rules by themselves.

Explore more on M365.FM

Episode page: the full episode with chapters, takeaways and FAQ on industrial data models
Microsoft Fabric – the shared data and analytics layer that holds factory data but cannot define its meaning
Power BI – management reporting that makes data visible but can combine records describing different things
Related episode: From Financial Data to AI-Ready Decisions: Power BI, Microsoft Fabric, Semantic Models & AI Agents with Rishi Sapra [MVP]
Related episode: Microsoft Fabric Direct Lake - Simply Explained

How Machine Data Reaches Microsoft Fabric - From OPC UA to Real-Time Analytics

Wed, 07 Oct 2026 13:55:02 +0000

Machine data can reach the cloud faster than ever, yet a red machine status still does not tell production which order is at risk. This episode follows one OPC UA signal through the edge, MQTT and Azure IoT into Microsoft Fabric for manufacturing IT, OT and data teams. Learn where context belongs so real-time analytics can support real production decisions.

In this episode

00:00 – From machine signal to production decision
01:23 – A machine stoppage is never just a stoppage
11:26 – What OPC UA brings from the shop floor
23:35 – The OT boundary and the industrial DMZ
35:24 – Azure IoT Edge and Azure IoT Operations
41:33 – MQTT and the unified namespace
71:28 – Eventstream, Eventhouse and KQL
89:12 – Closing the production context gap

Key takeaways

Getting OPC UA signals into Microsoft Fabric is the easy part; the hard part is linking each event to the active order, product, process and resource.
Keep source identity, timestamps and quality codes on every event, and use the edge, MQTT and a unified namespace as governed contracts rather than tag dumps.
Use Eventhouse and KQL for live investigation and the lakehouse for history, while ERP, MES and maintenance systems keep ownership of the business context.

Worth quoting

“Telemetry describes what a machine reports, while production context explains what that report means in the flow of work.” – Mirko Peters (05:40)

“If a sensor value arrives late or the server reports a bad quality status, hiding that fact creates a clean looking data set that may be wrong. For industrial analysis, an honest, uncertain value beats a false precise one.” – Mirko Peters (15:35)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ
Microsoft Fabric – where OPC UA machine events land through Eventstream, Eventhouse and the lakehouse for analysis
Kusto Query Language (KQL) – used in Eventhouse to investigate machine states, faults and time windows on live events
Microsoft Azure – Azure IoT Edge, Azure IoT Operations and IoT Hub carry shop floor events to the cloud
Related episode: Your Machine Data Never Becomes a Decision. Here's the Missing Pipeline.

Connectivity Is Not Integration — Why Your Connected Factory Still Can't Answer the Right Questions

Tue, 06 Oct 2026 11:10:02 +0000

A packaging machine stops, every system is connected, and still nobody can say which customer shipment is at risk. This episode is for manufacturing IT/OT architects and data teams who have invested in connectivity but still answer key questions with phone calls and spreadsheets. Learn how to move from moving signals to connecting meaning with context models, knowledge graphs and the Azure industrial stack.

In this episode

00:00 – One alarm, five systems, no shared answer
05:49 – Connectivity: what OPC UA, MQTT and Azure IoT Operations solve
11:39 – Unified namespace: a better highway, not the factory map
17:28 – The tag naming trap and why ERP and MES do different jobs
29:07 – Following one work order and the cost of point-to-point integration
39:56 – Context: asset, process, order, material and quality
62:25 – Standards, ontologies, knowledge graphs and semantic governance
84:50 – Data quality, Fabric, contextualization, Azure Digital Twins and time

Key takeaways

Connectivity with OPC UA, MQTT and a unified namespace moves signals reliably, but integration requires linking each event to assets, operations, work orders, material, quality and demand.
Names and topic paths are aliases, not identities: governed identifiers, ontologies, data contracts and clear ownership keep meaning intact across ERP, MES, maintenance and quality.
Azure IoT Operations, Microsoft Fabric and Azure Digital Twins provide the edge, data and relationship layers, but relationships must be time-aware and modeled deliberately around a real decision.

Explore more on M365.FM

Episode page: the full episode with chapters, takeaways and FAQ on industrial integration
Microsoft Fabric – the shared data plane for edge events and factory system data, which cannot infer context itself
Related episode: From Financial Data to AI-Ready Decisions: Power BI, Microsoft Fabric, Semantic Models & AI Agents with Rishi Sapra [MVP]
Related episode: Microsoft Fabric Direct Lake - Simply Explained
Related episode: Can Value Stream Mapping Become a Live Data Model?

Why Continuous Improvement Needs Better Data

Mon, 05 Oct 2026 04:51:23 +0000

Kaizen workshops often feel like progress, yet the same losses return a few weeks later. This episode is for lean leaders, plant engineers and manufacturing IT teams who want continuous improvement that lasts. Learn how to connect ERP, MES, machine data and shop-floor knowledge into a reliable PDCA check step that shows which countermeasures actually hold.

In this episode

00:00 – Why kaizen events lose momentum
05:36 – Lean as a learning system
10:32 – Why improvement programs stall
14:57 – PDCA needs a reliable check step
30:43 – ERP, MES, machine data and the shop floor
54:37 – The data model behind continuous improvement
65:40 – Scenario: reducing changeover loss
84:48 – A practical Microsoft data path

Key takeaways

Continuous improvement stalls when the PDCA check step lacks connected evidence, because completed actions are not the same as learning.
ERP shows intent, MES shows execution, machine data shows physical behavior and operators add meaning, so improvement needs all four linked through a shared data model.
Microsoft Azure, Fabric and Power BI can carry that evidence chain, but the factory itself must define what a stop, a changeover or good output means.

Worth quoting

“Treating OE as a root cause answer is like treating a warning light as a repair manual. It tells you where to look. It doesn't tell you what to change.” – Mirko Peters (24:58)

“If not, they adapt or stop it. Stopping a weak countermeasure isn't failure. It's preventing a weak habit from becoming standard.” – Mirko Peters (08:54)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on data-driven PDCA
Microsoft Fabric – the governed shared home where ERP, MES and machine data meet common definitions
Power BI – the reporting layer that gives supervisors, engineers and planners role-based views of one model
Microsoft Azure – the services for ingestion, storage, integration, identity and secure access along the data path
Microsoft Excel – the spreadsheet that fills gaps but turns reconciliation into one person's private process
Related episode: Connect ERP, MES, and IoT — Without Replacing Anything

IoT Hub Message Routing vs Event Grid — Why Telemetry and Events Are Not the Same Problem

Fri, 02 Oct 2026 19:35:16 +0000

A temperature reading, a vibration sample, a machine cycle, and a device disconnect may all be described as events, but they do not represent the same architectural problem. In industrial IoT and manufacturing environments, confusing continuous telemetry with discrete events can create noisy workflows, incomplete production histories, unnecessary processing, and systems that react without enough context.

In https://www.m365.fm/iot-hub-message-routing-vs-event-grid-why-telemetry-and-events-are-not-the-same-problem/, we break down the architectural difference between Azure IoT Hub Message Routing and https://www.m365.fm/azure-event-grid-explained/ by following a realistic manufacturing scenario. A press line continuously sends temperature, vibration, cycle count, energy consumption, and machine-state information through an industrial gateway. Those measurements create an operational history that engineers, data teams, maintenance teams, and production systems may need to analyze later. A device disconnect is different because it represents a change that may require another system or person to react.

TELEMETRY IS A RECORD, NOT AN ALERT
Telemetry represents repeated measurements over time. A single temperature value or vibration measurement usually tells you very little on its own. The real information exists in the sequence: how quickly values changed, what the machine was doing at that moment, what happened before a stop, whether measurements disappeared during a network interruption, and whether the same behavior appeared in earlier production runs.

Typical industrial telemetry includes:
• Temperature, vibration, pressure, energy consumption, and current draw
• Machine states such as running, idle, stopped, or faulted
• Cycle counts, production counters, and process measurements
• Source timestamps, device identifiers, sequence numbers, and correlation information

Those records may later support condition monitoring, quality investigations, energy analysis, OEE calculations, https://www.m365.fm/microsoft-fabric-simply-explained/ analytics, Power BI reporting, and production optimization. That is why telemetry needs retention, replay, duplicate handling, independent consumers, and a reliable way to reconstruct the production timeline.

IOT HUB MESSAGE ROUTING AS THE TELEMETRY DATA PLANE
Azure IoT Hub provides the controlled device-to-cloud boundary. Devices and gateways authenticate with their own identities, send device-to-cloud messages, maintain device-management state, and can participate in controlled cloud-to-device communication.

Once a telemetry message reaches IoT Hub, Message Routing determines where that data should go. Routing can inspect message properties, system properties, parts of the message body, and device twin information. This makes it possible to separate production telemetry, energy measurements, diagnostics, or other message classes before they reach downstream consumers.
A common architecture might look like this: Industrial gateway → Azure IoT Hub → Message Routing → Event Hubs or Storage → Processing → https://www.m365.fm/categories/copilot-talk/ Fabric.

One consumer may perform near-real-time analysis while another keeps a raw archive. A third consumer may prepare curated operational data for Microsoft Fabric. Each consumer can work independently without turning every telemetry reading into a workflow invocation.

WHY ORDERING MATTERS
Industrial telemetry is particularly sensitive to sequence. Imagine a machine reporting that it entered a running state, then transmitting several cycle counts, followed by a process deviation and finally a stopped state. If those records are reconstructed incorrectly, a downstream system could conclude that the machine produced parts while stopped or that a process deviation happened after production had already ended.

The same problem affects downtime calculations, OEE, production counts, and condition monitoring. You therefore need to distinguish between when the source observed something, when IoT Hub received the message, and when a downstream system processed it.

A robust telemetry architecture should therefore consider:
• Source timestamps and cloud receipt timestamps
• Stable partitioning appropriate to the asset or workload
• Message IDs or sequence numbers for duplicate detection
• Idempotent consumers capable of handling at-least-once delivery

Network interruptions make this especially important. A gateway may buffer telemetry and send it when connectivity returns, which means Azure arrival time may be much later than the actual machine timestamp.

EVENT GRID SOLVES A DIFFERENT PROBLEM
Azure Event Grid is designed around publish-and-subscribe notifications. Instead of continuously reconstructing the state of a machine from thousands of readings, Event Grid tells interested systems that something changed and gives subscribers an opportunity to react.
Examples in an IoT environment include device creation, device deletion, connection, disconnection, or carefully selected telemetry-derived conditions. A device-created event might trigger an asset onboarding process. A device-disconnected event might start a technical investigation. A detected engineering condition might trigger a maintenance workflow.

Typical subscribers include:
• https://www.m365.fm/azure-functions-simply-explained/
• Logic Apps
• Webhooks
• Security workflows
• Asset-management systems
• Operational applications

The fundamental architectural difference is simple: telemetry asks what an asset has been doing, while an event asks what changed and whether something should react.

EVENTS SHOULD START INVESTIGATIONS, NOT DEFINE REALITY
Event Grid should generally be treated as a notification mechanism, not as the final authoritative state of the physical world. Event delivery can be repeated, and events are not something a subscriber should blindly interpret as the final current state without checking.
A device-disconnected event should therefore usually trigger a state check. An Azure Function might verify the current device state, inspect recent telemetry, check relevant registry information, and then decide whether the investigation should remain open.

Handlers should be designed around:
• Idempotent processing
• Current-state verification
• Event identity and timestamps
• Clearly defined ownership of the resulting action

This matters because duplicate events should not create duplicate tickets, duplicate alerts, or conflicting operational records.

A DEVICE DISCONNECT DOES NOT MEAN THE MACHINE STOPPED
One of the most important distinctions in industrial IoT is the difference between cloud connectivity, data-collection health, and production state. If an industrial gateway disconnects from IoT Hub, the cloud has lost visibility into that gateway. That does not automatically mean that the physical machine stopped.

The PLC may continue controlling the equipment locally while the gateway temporarily loses connectivity. Production may continue normally, and the gateway may even buffer telemetry and upload it later. The opposite can also happen: a gateway may remain connected to Azure while its connection to the PLC or local equipment has failed.

A useful architecture therefore separates cloud connection state, gateway health, machine production state, and MES work-order state. Only by combining those sources can the business determine whether a technical connectivity issue actually affected production.

FILTERING IN IOT HUB VS FILTERING IN EVENT GRID
Both technologies support filtering, but the purpose is different. IoT Hub Message Routing filtering answers which operational messages should enter a specific data path. Event Grid subscription filtering answers which notifications a particular subscriber should receive.

For example, production telemetry may go to one Event Hubs stream while energy data goes to another destination. At the same time, a support workflow may subscribe only to disconnected events from a particular group of gateways.

Confusing those two types of filtering often results in an architecture where every subscriber creates its own interpretation of the telemetry stream. A cleaner design keeps broad telemetry classification governed centrally and keeps Event Grid subscriptions focused on clearly defined reactions.

THE MANUFACTURING CONTEXT LIVES OUTSIDE THE MESSAGE BUS
Neither IoT Hub nor Event Grid knows what a machine means to the business. A device ID may identify a gateway, but it does not inherently know which production line the gateway belongs to, which machine it observes, which work order is running, whether a stop is planned, or whether production is already at risk.

That context usually comes from multiple systems. MES provides execution context such as work orders, operations, recipes, production state, and shift information. ERP provides demand, commitments, inventory, and planning information. An asset model connects devices, gateways, PLCs, machines, cells, lines, and sites.

In more advanced architectures, a digital twin or knowledge graph can help maintain those relationships. The result is a more reliable operational picture in which telemetry explains what the equipment reported, MES explains what production was doing, ERP explains why it matters, and the asset model explains how the technical components relate to the physical plant.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Building Azure That Survives the Real World — with Mike Martin [MVP]

Thu, 01 Oct 2026 07:15:34 +0000

Azure architecture is easy when everything works; the real questions start when regions, dependencies and assumptions fail. In this episode, Microsoft MVP Mike Martin helps Azure architects and IT decision-makers tell resilience from high availability, set realistic SLA, RTO and RPO targets, and understand where Microsoft's responsibility ends. You get practical guidance on multi-region design, chaos testing and keeping solutions simple.

In this episode

00:00 – Azure architecture when things fail
01:21 – Thirty years of turning points
05:19 – What architecture really means
15:49 – RTO and RPO as business decisions
25:53 – Resilience versus high availability
28:31 – Shared responsibility and SLAs
51:29 – Multi-region and mission-critical design
56:37 – Identity, security and rapid fire round

Key takeaways

Resilience and high availability are different: a resilient system bends and recovers under stress, while high availability fails over to a second instance elsewhere.
No solution reaches 100% uptime because the composite SLA is the product of all dependent services, so define RTO and RPO with the business and design multi-region where it pays off.
Use the Azure Well-Architected Framework, mission-critical guidance and fault injection with Azure Chaos Studio, and keep designs simple instead of defaulting to Kubernetes.

Worth quoting

“for me, architecture is about knowing which pieces go together, which pieces to avoid, which pieces are necessary and which pieces are not.” – Mike Martin (07:10)

“never take a dependency on a single region. Always make a design for multiple regions. So that way you always have a plan B and even a plan C or a plan D” – Mike Martin (11:56)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure resilience
Mike Martin – Microsoft MVP with about 30 years in IT who separates resilience from high availability
Microsoft Azure – the cloud platform where multi-region design, zones and composite SLAs decide real uptime
Azure Chaos Studio – the fault injection service Mike recommends for fire drills such as a region outage
Related episode: Azure Platform Engineering, Azure Landing Zones, Cloud Adoption Framework & Building Enterprise Cloud Platforms Jev Suchoi [MVP]

Why Your Production Schedule Is Wrong Before It Even Starts

Mon, 28 Sep 2026 07:01:13 +0000

Production schedules look solid when they leave ERP, yet material delays, tool issues, missing skills and short machine stops make them outdated before the first order starts. This episode is for manufacturing planners, operations leaders and data architects who keep seeing Excel become the real control system. You will learn how a closed loop of execution data, production context, learning and controlled replanning keeps dispatch decisions feasible.

In this episode

00:00 – The familiar Friday afternoon scenario
04:47 – A production schedule is a decision about the future
09:34 – What ERP knows and where execution takes over
17:46 – Measuring, context and learning from plan versus actual
32:08 – Replanning, the closed loop and why Excel survives
49:13 – Production context: machine stops, material, quality and finite capacity
71:06 – Dashboards, Microsoft Fabric, OT data, digital twins and knowledge graphs
88:52 – Industrial AI, the planner's role and event-driven replanning

Key takeaways

A released ERP schedule is a decision based on yesterday's facts, so it needs a closed feedback loop of execution, measurement, learning and replanning to stay feasible.
Production events only become useful when they connect to order, operation, resource and time through explicit product, process and resource relationships, with shared definitions for words like complete and available.
Microsoft Fabric, Power BI, digital twins, knowledge graphs and industrial AI can support the loop, but feasible replans still need explicit constraints, trigger rules, freeze windows and named human decision rights.

Explore more on M365.FM

Episode page: the full episode with chapters, takeaways and FAQ on closed-loop production scheduling
Microsoft Excel – the planner's fast workaround that becomes the unofficial manufacturing control system
Microsoft Fabric – the shared data foundation for ERP, MES, quality and IoT data, not the factory brain
Power BI – dashboards showing plan versus actual that explain yesterday but don't choose the next move
Related episode: What Happens When Sales Promises an Urgent Order

Microsoft 365 Copilot Without the Hype: Adoption, Governance & Getting Your Tenant Ready with Paul Keijzers [MVP]

Thu, 24 Sep 2026 13:00:04 +0000

Buying Copilot licenses is easy, but Copilot then surfaces years of SharePoint, Teams and OneDrive content that was never meant to be shared. In this episode, Microsoft MVP Paul Keijzers explains to IT leaders and Microsoft 365 admins what a Copilot-ready tenant really means. You get practical advice on oversharing, Purview labels and DLP, content lifecycle, adoption and agent governance.

In this episode

00:00 – Is your tenant ready for Copilot?
02:37 – Paul's journey from car audio to SharePoint and Copilot
11:33 – What companies underestimate
15:11 – Old SharePoint content and content lifecycle
21:28 – Oversharing, Purview, labels and DLP
30:17 – Adoption, champions and Copilot costs
40:46 – Agents and Agent 365
45:08 – Focus weeks and rapid fire round

Key takeaways

Copilot readiness is a Microsoft 365 project: start with sharing settings, permissions, retention, sensitivity labels and DLP, including Power Automate DLP for connectors.
Old, unarchived SharePoint content and duplicate versions make Copilot look like it hallucinates, so archive or restrict content and keep metadata and folder structures simple.
Strong adoption comes from continuous, outcome-focused support in the business rather than one-time training days, while token-based tools like Copilot Cowork need cost awareness.

Worth quoting

“they forget about permissions they forget about retention they forget about a DLP they forget about the labeling aspect” – Paul Keijzers (11:46)

“copilot readiness isn't really a copilot project it's Microsoft 365 project it's understand your share point environment it's understand who can access what” – Mirko Peters (53:21)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Copilot readiness
Paul Keijzers – Microsoft MVP who explains what a Copilot-ready tenant needs before the rollout
Microsoft 365 Copilot – the AI assistant that surfaces whatever overshared or outdated content a tenant holds
SharePoint – the storage layer behind Teams and OneDrive, where old migrated files confuse Copilot
Related episode: Beyond Copilot: Building Enterprise AI Agents That Actually Work with Copilot Studio with Manpreet Singh [MVP-MCT]

When Microsoft Messaging Looks Secure but Isn’t — Exchange Server, Hybrid and Microsoft 365 Security with Thomas Stensitzki [MVP]

Thu, 24 Sep 2026 08:10:31 +0000

Many Microsoft messaging environments look secure on the surface but still run on defaults, weak identities and misunderstood mail flow. This conversation with Exchange MVP Thomas Stensitzki is for Exchange and Microsoft 365 administrators running on-premises, hybrid or cloud-only email. It covers identity protection, break glass accounts, SPF, DKIM and DMARC, Defender for Office 365 and the operational discipline that keeps messaging secure.

In this episode

00:00 – Introduction to messaging security and the guest
04:41 – Exchange Server, Exchange Online and hybrid differences
10:11 – Identity, admin roles and break glass accounts
15:32 – Legacy authentication and a realistic attack path
23:46 – Mail flow, SPF, DKIM and DMARC
37:37 – Phishing and Defender for Office 365
48:54 – Secure Score, operational discipline and compliance
57:48 – AI, Exchange migrations and rapid fire round

Key takeaways

Exchange Online starts with default settings, so mail flow, anti-spam, anti-phishing and anti-malware still need to be configured for the organization's needs.
Identity security comes first: protect every user and service account, use PIM for Exchange admins and secure break glass accounts with FIDO keys.
Configure SPF, DKIM and DMARC with real policies, use subdomains for third-party senders, and enable Safe Links in Defender for Office 365.

Worth quoting

“Here's a switch on and you can use email but you have to configure it depending on your needs.” – Thomas Stensitzki (07:40)

“So I'd say identity security comes first. So you do have to protect the identity of each user, even though regardless if it's a real person, so a human being or if it's a technical service account” – Thomas Stensitzki (10:18)

Explore more on M365.FM

Episode page: the full conversation with chapters, quotes and FAQ on messaging security
Thomas Stensitzki – Exchange MVP and consultant sharing more than 25 years of Exchange and hybrid experience
Exchange Online – starts with default transport and protection settings that admins still have to configure
Microsoft Defender – Safe Links and Email Explorer in Defender for Office 365 against phishing
Related episode: Data Loss Prevention in Microsoft 365: Policies That Actually Work

Content Understanding & Document AI - Simply Explained

Fri, 18 Sep 2026 10:20:56 +0000

Shared inboxes still fill with invoices, receipts and contracts that someone has to open and retype, and simple rules break as soon as layouts change. This episode explains for Power Platform makers and process owners how Content Understanding, Power Automate, Dataverse and Power Apps turn documents into trusted business data with human review where it matters.

In this episode

00:00 – Introduction: documents as business data
00:34 – Why documents break automation
03:04 – Content Understanding simply explained
07:01 – The Power Platform connection
10:32 – Trust, confidence and human review
13:28 – Choosing a first use case
16:11 – Where this changes your work

Key takeaways

OCR reads characters, but Content Understanding uses a schema to return the business fields a process actually needs, such as supplier, invoice number and total.
Power Automate moves extracted data through the process, Dataverse tracks each record and its history, and Power Apps gives reviewers a place to fix exceptions.
Confidence scores and validation rules decide when a document can move on and when a person must check it, and the first use case should be one document type with one clear decision and owner.

Worth quoting

“If the process is unclear before automation, it becomes unclear faster after automation, with more records moving through it.” – Mirko Peters (10:03)

“Even when the score looks strong, the rule should follow the consequence of an error, not just the score.” – Mirko Peters (11:17)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on document AI
Power Automate – the process engine that sends files to Content Understanding and routes the results
Power Platform – the action layer that turns extracted fields into a working business process
Dataverse – holds each document's record, status, owner, field confidence and review history
Human in the loop – reviewers fix uncertain fields in Power Apps when an error would be costly
Automation – why rules-based automation breaks on varied layouts and speeds up unclear processes
Related episode: Power Platform Copilot Integration - Simply Explained

IoT Hub Message Routing vs Event Grid — Why Telemetry and Events Are Not the Same Problem

Fri, 18 Sep 2026 08:15:38 +0000

Machine telemetry and device events both arrive through Azure IoT Hub, but treating them as the same thing either floods workflows with sensor noise or buries urgent signals in a pipeline nobody watches. This episode is for IoT, OT and Azure architects building manufacturing data platforms. You will learn when to use IoT Hub message routing, when to use Event Grid, and how MES and asset context turn signals into trustworthy production decisions.

In this episode

00:00 – A press line, a sensor stream and one missing signal
05:30 – Telemetry versus discrete events
22:10 – What Azure IoT Hub actually handles
27:30 – IoT Hub message routing as the telemetry data plane
44:50 – Azure Event Grid, IoT Hub events and the connection state trap
66:40 – Lifecycle events, filtering and ERP, MES and asset context
83:30 – Gateway offline during a work order and the two wrong designs
100:40 – Data plane, control plane, Fabric and Power BI

Key takeaways

Telemetry is a time-ordered production record that needs sequence, retention and independent readers, while a discrete event is a notice that something changed and someone may need to react.
IoT Hub message routing is the telemetry data plane into Event Hubs, storage and Microsoft Fabric, whereas Event Grid is a notification fabric with at-least-once, unordered delivery that handlers must treat as a prompt to check current state.
A device disconnect only proves lost cloud visibility, so production conclusions need MES, ERP and asset model context, shared device identity and explicit data contracts across both paths.

Explore more on M365.FM

Episode page: the full episode with chapters, the press line scenario and FAQ
Azure Event Hubs – the routed stream for production telemetry that several consumers can read independently
Microsoft Fabric – the analytics destination for prepared operational data, not the place where raw messages become facts
Azure Functions – event handlers that check current device state before acting on a disconnect notice
Related episode: Azure Event Grid - Simply Explained

The 5 Pillars of Data Transformation - Simply Explained

Fri, 18 Sep 2026 06:23:58 +0000

Many organizations have Copilot, Power BI and Fabric, yet decisions still stall because nobody trusts the numbers or owns the call. This episode gives data and business leaders five pillars, from governance to human judgment, to test any report, prompt or flow before the next AI rollout.

In this episode

00:00 – Why faster AI answers still stall decisions
00:50 – Pillar 1: Data governance
04:14 – Pillar 2: Semantic layer
07:20 – Pillar 3: Start with the decision
10:18 – Pillar 4: Psychological safety
13:42 – Pillar 5: Human judgment
16:50 – Implementation and payoff

Key takeaways

AI moves bad data faster, so governance with named owners, sources and access rules has to come before automation.
A semantic layer gives humans and AI one shared definition of business terms, and every report should start from a named decision and decision owner.
Data transformation needs psychological safety to challenge the numbers and a named person who owns the final judgment on every AI-supported decision.

Worth quoting

“AI doesn't clean up confusion by itself. It can search across more files, summarize more records and send a recommendation in seconds. But it also moves bad data faster.” – Mirko Peters (01:00)

“Simply explained, it's a shared business dictionary with pre-approved calculations baked right in. You define a term once, store the logic once and reuse it everywhere” – Mirko Peters (04:39)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a five-pillar FAQ
Data governance – pillar one, setting owners, sources, access rules and quality checks before AI uses the data
Semantic model – a Power BI semantic model holds approved measures, relationships and field names in one layer
Human in the loop – why human review only counts when the person can still change the outcome
Microsoft Purview – named as a tool for discovering data, applying sensitivity labels, tracking data movement and managing access
Related episode: Microsoft Purview Unified Catalog - Simply Explained

Your Factory Cloud Bill Is Much Higher Than You Think

Thu, 17 Sep 2026 09:33:11 +0000

Sending all factory data to the cloud looks cheap until egress, cross-zone traffic, replication and dashboards show up on the invoice. This episode shows manufacturing and cloud architects how to model the real cost of data movement and build an edge-first pattern that scales. You will learn which data should stay local and which earns a trip to the cloud.

In this episode

00:00 – The clean IoT diagram and the hidden bill
01:02 – Egress, boundaries and data paths
16:19 – Counting samples, not devices
28:08 – Data half-life and the value hierarchy
44:09 – Data gravity
49:06 – Zones, NAT, replication and return paths
82:17 – Edge processing, filtering and aggregation
110:35 – The three-layer factory data pattern

Key takeaways

Factory cloud cost is driven by data movement across boundaries, zones, gateways and return paths, not just by storage.
Estimate volume from sample rate, payload size and retention rather than device count, and move data only when a named consumer needs it for a named decision.
Use an edge, site and cloud layer pattern: filter, aggregate and infer near the machine, and send governed operational facts to the cloud.

Worth quoting

“It's not because the cloud failed, it's because that data path was never treated as part of the architecture in the first place.” – Mirko Peters (00:37)

“The rule behind all four tiers is simple. Move data only when a named consumer needs it to make a named decision.” – Mirko Peters (38:07)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on factory data costs
Microsoft Azure – cited for a public internet egress rate of roughly 8.7 cents per gigabyte
Governance – needed for cross-site history, shared definitions and owned retention of factory records
Power BI – mentioned once, as a plant dashboard that pulls cloud data back into the site
Related episode: Microsoft Purview is a Trap: The Hard Truth About Data Governance
Related episode: Power Platform Copilot Integration - Simply Explained

From Financial Data to AI-Ready Decisions: Power BI, Microsoft Fabric, Semantic Models & AI Agents with Rishi Sapra [MVP]

Wed, 16 Sep 2026 17:53:27 +0000

Finance teams have ERP data, Power BI reports, Excel everywhere and now AI agents, yet agents do not automatically understand what revenue or margin means in their business. This conversation with Rishi Sapra is for data, BI and finance leaders who want reliable AI answers. It explains how semantic models, ontologies, skills and automated governance in Microsoft Fabric and Copilot Studio ground agents in business context.

In this episode

00:00 – Welcome and Rishi's path into Microsoft data
06:52 – The CFO question: how documented is your context?
14:58 – Semantic models as the single source of truth
17:56 – The organizational brain and its five layers
23:23 – Data model, semantic model and ontology
31:15 – Fabric, OneLake and Direct Lake
38:49 – Persona-driven insights and storytelling with AI
50:10 – Agents, governance and the operating model

Key takeaways

Before adding AI agents to financial data, document the business context: personas, decisions and the questions they need answered.
Certified semantic models provide deterministic KPI logic, while ontologies, skills, tools and governance add the context agents need to explain why.
As agents become more capable, governance has to be automated into the context layer and managed through a hub-and-spoke operating model with a center of excellence.

Worth quoting

“Gen AI is really clever, but it's also quite clumsy in the sense of, you wouldn't trust it to really come up with your numbers that you need to be reliable every month and grounded in your business processes.” – Rishi Sapra (04:47)

“Once you start with the decisions you need to make and the business questions that you need answered, then you go from there into logic and into data and then you pass that to Gen AI” – Rishi Sapra (08:55)

Explore more on M365.FM

Episode page: the full conversation with chapters, quotes and FAQ
Rishi Sapra – former KPMG financial modeler who explains his organizational brain for grounding AI agents
Semantic model – the certified single source of truth for KPIs that agents should be grounded in
Microsoft Fabric – the core data and logic foundation, with OneLake, Direct Lake and data agents
Related episode: Power Platform Copilot Integration - Simply Explained

Why Your ERP Can't Build an Optimal Production Schedule

Wed, 16 Sep 2026 13:10:02 +0000

Your ERP shows every order with a date, yet the shop floor knows by Monday morning that the plan will not survive the week. This episode explains why ERP cannot build an optimal production schedule, what finite scheduling and APS add, and where Microsoft data platforms and AI fit. For manufacturing planners, IT and operations leaders who want schedules people actually trust.

In this episode

00:00 – The schedule that looks complete
08:52 – The infinite capacity assumption
21:42 – Sequence and the bottleneck
43:41 – Why Excel survives
52:55 – Finite scheduling and optimization
75:38 – ERP, MES and APS roles
80:24 – Microsoft architecture and context
89:55 – AI, stability and shop floor rules

Key takeaways

ERP plans material and dates against infinite capacity, so its dates are signals, not executable machine slots.
A feasible schedule must reserve real time on machines, tools and people, protect the bottleneck and account for sequence-dependent setups.
APS should own detailed scheduling with explicit rules and explanations, while Azure, Fabric and Power BI connect and analyze the data and AI supports rather than decides.

Worth quoting

“So infinite capacity isn't a defect and it isn't an attempt to mislead anyone. It's a boundary around what the planning logic is trying to do.” – Mirko Peters (09:58)

“So I'd be careful when people call Excel the problem. It survives because it lets a planner shape a local model around the factory they know” – Mirko Peters (45:14)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes, the pump factory scenario and FAQ
Microsoft Excel – why planners keep a spreadsheet beside ERP and what that private flexibility costs
Microsoft Fabric – a governed analytical place for ERP, MES and schedule data, not a scheduler
Microsoft Azure – secure integration of ERP, MES and machine events while keeping OT separate
Power BI – the reporting layer for schedule health, promise risk and plan versus actual
Microsoft 365 Copilot – an assistant that explains why orders moved but should not decide the schedule
Related episode: What Happens When Sales Promises an Urgent Order

Production Planning Software: When Does a Manufacturer Actually Need It?

Wed, 16 Sep 2026 10:15:02 +0000

Many factories run on a planner who stitches together ERP dates, spreadsheets, whiteboards and phone calls until the plan breaks. This episode helps manufacturing and operations leaders recognize the warning signs that manual planning has hit its limit and shows how to introduce planning software that produces feasible, explainable schedules.

In this episode

00:00 – The planner as the planning system
01:40 – What production planning means
06:20 – When spreadsheets and experience still work
11:07 – Six warning signs
40:31 – Where ERP and MES reach their limits
50:28 – What planning software does and the data model
65:04 – Fix the process, start with one decision
96:09 – Fabric, Power BI and Power Platform

Key takeaways

Production planning software becomes necessary when changes, shared resources and dependencies outpace what planners can test manually, not when the company reaches a certain size.
ERP owns demand and materials and MES records execution, while a planning layer must test feasible sequences against real capacity, setup, material and qualification constraints.
Start with one failing decision, a clear process and trusted product, process and resource data, run the new plan in parallel, and use Fabric, Power BI and Power Platform around the engine, not instead of it.

Worth quoting

“The word feasible matters more than fast. A schedule can look neat and still fail the moment production tries to follow it.” – Mirko Peters (03:38)

“The issue isn't whether people use Excel. It's whether Excel and experience can still keep pace with change.” – Mirko Peters (10:50)

Explore more on M365.FM

Episode page: the full episode with chapters, the six warning signs, quotes and FAQ
Microsoft Fabric – the governed data foundation around the planning engine, which does not generate schedules itself
Power BI – visibility before and after planning decisions, including plan versus actual analysis
Governance – why planning data quality is operational governance owned by people close to the work
Power Platform – the working layer for capturing exceptions and routing approvals around the scheduling engine
Related episode: What Happens When Sales Promises an Urgent Order

Can You Simulate Your Factory Before Changing It?

Wed, 16 Sep 2026 06:45:45 +0000

Adding a shift, a machine or more stock often just moves the bottleneck and creates overtime and late orders. This episode shows production leaders and planners how factory simulation tests changes against real routings, people, buffers and disruptions before the shop floor pays for them, and where ERP, MES, Fabric and AI fit.

In this episode

00:00 – Why factory changes are live experiments
06:24 – What factory simulation means
17:23 – ERP, MES and the shop floor question
36:57 – Start with one decision and a baseline
53:59 – Staffing, shifts and labor rules
64:59 – Buffers, product mix and sequence
87:34 – Disruptions and ranges instead of certainty
103:34 – Industrial AI, Fabric and digital twins

Key takeaways

Test a production change such as an extra shift, new machine or smaller buffer in a simulation first, because constraints often move rather than disappear.
Start with one concrete decision that has an owner, build a baseline that behaves like normal operations, and model qualified coverage, setups, queues and disruptions as ranges.
ERP, MES, Microsoft Fabric, Power BI and AI each support the decision, but only a factory model with explicit rules can rehearse how the plant will respond.

Worth quoting

“A machine can run flat out, while the factory creates a bigger queue somewhere else. You haven't removed the constraint, you've moved it.” – Mirko Peters (03:34)

“Simulation doesn't remove uncertainty. It gives that uncertainty a place in the decision before it shows up on the shop floor.” – Mirko Peters (07:45)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on factory simulation
Microsoft Fabric – a shared data foundation for ERP, MES, quality and maintenance inputs to simulation
Governance – needed once scenario results affect planning, from routing versions to approved inputs
Power BI – used to review the baseline and compare scenario results, but it does not simulate
Microsoft 365 Copilot – a Copilot-style assistant should explain approved scenario results rather than invent schedules
Related episode: Everyone Wants Copilot—but Is Your Data Ready: Microsoft Fabric Architecture with Walter Calcagno [MVP-MCT]

APS Software vs. ERP: What's the Difference?

Tue, 15 Sep 2026 21:10:02 +0000

An ERP plan full of dates can look certain while the factory cannot possibly meet it. This episode is for manufacturing planners, operations leaders and IT architects deciding between ERP scheduling and dedicated APS software. You will learn what each system does well, when APS becomes hard to avoid and how to divide ownership between ERP, APS and MES.

In this episode

00:00 – One order, two views of the factory
04:49 – What ERP does well
09:52 – Why ERP plans look more certain than they are
14:38 – What APS software actually does
24:27 – The Monday morning disruption test
34:28 – APS data: the constraint layer
73:37 – APS does not replace the planner
83:20 – Architecture and Microsoft's role

Key takeaways

ERP is the governed system of record for demand, supply, inventory and transactions, while APS tests whether the plan can actually run under finite capacity and real constraints.
A feasible schedule depends on detailed constraint data such as calendars, qualified labor, tools, setup rules and material readiness, plus explicit business priority rules.
APS supports rather than replaces the planner, and clear ownership across ERP, APS and MES matters more than the number of integrations.

Worth quoting

“Confusion starts when a planned ERP date gets treated as proof that the factory has the capacity to deliver.” – Mirko Peters (04:42)

“somebody still has to decide the order in which those jobs run, where the setup time goes, and which job waits when the day runs out. The date didn't solve those decisions, it postponed them to whoever releases the work.” – Mirko Peters (11:09)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on APS versus ERP
Microsoft Excel – why planners keep spreadsheets through APS projects and what those workbooks reveal
Microsoft – positioned around the planning process to carry, govern and analyze data, not inside scheduling logic
Microsoft Azure – described as an integration layer that routes ERP changes and production events to APS
Related episode: Why Your ERP Can't Build an Optimal Production Schedule

Constraint-Based Scheduling: The Architecture That Makes Production Plans Real

Tue, 15 Sep 2026 17:15:02 +0000

Production plans that look fine in ERP fall apart when a machine fails, a fixture is busy or material is still in inspection. This episode walks manufacturing planners, IT/OT architects and operations leaders through constraint-based scheduling in a hypothetical machining plant, showing how to turn factory facts into rules a scheduling engine can test and produce schedules people can actually run.

In this episode

00:00 – Intro: the ERP date isn't a factory promise
06:20 – Plan versus schedule
11:34 – Hard and soft constraints
22:16 – Routings, BOMs and resource modeling
34:10 – Machine state, tooling, labor and material release
68:55 – What the scheduling engine solves
79:42 – When the five-axis machine fails and constraints collide
102:30 – ERP, MES, the scheduling layer and Microsoft architecture

Key takeaways

An ERP date states intent; a finite, constraint-based schedule tests every operation against real resources, tooling, skills, material release and time windows.
Hard constraints decide feasibility first, while soft constraints and visible priority policies decide which feasible schedule the plant prefers.
ERP, MES and the scheduling layer each keep their own job, with Microsoft Fabric and Power BI providing governed history and visibility rather than acting as the scheduling engine.

Explore more on M365.FM

Episode page: the full episode with chapters, the machining plant scenario and FAQ
Microsoft Fabric – the governed data foundation for schedule history and plan-versus-actual analysis, explicitly not the scheduling engine
Power BI – where managers, planners and maintenance review bottleneck load and at-risk orders from governed facts
Microsoft Azure – the ingestion and integration path for machine events alongside MES, ERP, quality and maintenance data
Microsoft Excel – mentioned briefly as the shadow-schedule tool planners use when recording overrides is too slow
Related episode: Connect ERP, MES, and IoT — Without Replacing Anything

A Machine Goes Down. How Should Your Production Plan React?

Tue, 15 Sep 2026 13:01:10 +0000

When a critical machine goes down, ERP may still show capacity that no longer exists while the shop floor improvises. This episode guides production planners, plant managers and IT/OT architects from disruption detection and impact tracing to finite-capacity rescheduling, so the factory gets a revised plan it can actually execute.

In this episode

00:00 – Intro: a machine outage is a planning event
01:07 – Separating real disruption from shop floor noise
06:57 – How long is the capacity gone?
13:03 – Production context and affected orders
25:51 – Bottlenecks, priorities and constraints
45:16 – Response options and finite capacity rescheduling
75:27 – Information flow from machine to planner
88:00 – Microsoft Fabric, Power BI and automation boundaries

Key takeaways

Only a confirmed loss of capacity, judged by expected loss, recovery window and exposed orders, should trigger re-planning, not every PLC signal.
Planners need a repair range with a confidence level, an impact list that explains dependencies, and a small set of response options tested with finite capacity.
Fabric and Power BI provide governed facts and visibility, while scheduling logic proposes options and people approve the changes that reach the shop floor.

Explore more on M365.FM

Episode page: the full episode with chapters and FAQ on machine outages and re-planning
Microsoft Fabric – a governed shared data foundation for disruption facts, but not the scheduling engine itself
Power BI – shows planners current outages, affected orders and scenario results, but does not issue a plan
Microsoft Excel – useful for testing a planning idea, risky when it becomes the uncontrolled live schedule
Related episode: Why AI Can't Optimize a Factory It Doesn't Understand

Can Value Stream Mapping Become a Live Data Model?

Tue, 15 Sep 2026 11:48:53 +0000

Value stream maps are drawn in a workshop and start going stale the moment production moves on. This episode is for manufacturing, operations and data teams who want a map that regenerates itself from ERP, MES, quality and machine events. You will learn how to define the unit of flow, build a shared language and use Microsoft Fabric without inventing false precision.

In this episode

00:00 – Why wall maps go stale
07:22 – What a value stream map represents
18:02 – The decay problem
28:42 – Dashboard, process model and digital twin
48:47 – The shared language layer
66:07 – A late order and an invisible queue
88:17 – Microsoft Fabric as the data foundation
105:01 – Knowledge graphs for changing relationships

Key takeaways

A value stream map is a snapshot that decays quickly, but it can become a live model when it is regenerated from ERP, MES, quality, maintenance and shop floor events.
Shared definitions of states such as released and complete, data contracts and visible confidence markers matter more than refreshing data every second.
Microsoft Fabric can provide the governed data foundation, but the process meaning, ownership and decisions still come from manufacturing teams and an explicit product, process and resource model.

Worth quoting

“A traditional value stream map captures a snapshot of the flow at one point in time. Production keeps moving after the workshop wraps and the map starts going stale almost immediately.” – Mirko Peters (01:01)

“But a timestamp doesn't settle what ready for next operation means, who owns that state or whether physical material can move before a quality decision. Sensors are good at reporting signals. They don't negotiate operating definitions. People do.” – Mirko Peters (16:23)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on live value stream models
Microsoft Fabric – presented as the governed data foundation, not as the value stream model itself
Governance – framed as a working agreement on meaning, ownership and change, not a committee
Power BI – useful for presenting flow measures, but another report page cannot supply process meaning
Related episode: From Financial Data to AI-Ready Decisions: Power BI, Microsoft Fabric, Semantic Models & AI Agents with Rishi Sapra [MVP]

How Finite Capacity Scheduling Actually Works in Manufacturing

Mon, 14 Sep 2026 11:08:40 +0000

Your ERP assigns a finish date, but the machine that must make the parts is already buried under more work than it can finish. This episode explains for manufacturing planners and IT/OT teams how finite capacity scheduling works, from bottlenecks, changeovers and material release to rescheduling, APS and where Microsoft Fabric, Power Platform and Copilot fit.

In this episode

00:00 – Introduction: when the plan doesn't fit the machine
01:49 – Infinite capacity planning
05:56 – A factory scenario with one bottleneck
10:23 – What finite actually means and the data model
29:46 – Forward, backward scheduling and sequencing
40:08 – The morning shift decision, changeovers and constraints
73:08 – Breakdowns and rescheduling without chaos
90:08 – Where Microsoft fits, optimization and AI

Key takeaways

ERP and MRP plan against infinite capacity, so finite capacity scheduling is needed to test whether work actually fits the usable time of machines, people, tools and material.
Sequencing and changeovers are policy decisions with trade-offs between due dates, setups and downstream flow, and a good schedule makes those consequences visible to the planner.
Microsoft Fabric, Power BI, Power Platform and Copilot support data, exceptions and explanations, but the scheduling logic and plant-specific rules must live in an engine such as an APS system that the plant owns.

Worth quoting

“Finite capacity scheduling doesn't create capacity. It makes the competition for capacity visible while you still have time to choose.” – Mirko Peters (14:04)

“Late orders are useful information. Nobody likes them obviously. But a late flag from a finite schedule can tell you something a green plan date cannot.” – Mirko Peters (34:00)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ
Microsoft Fabric – the shared data hub for ERP, MES, maintenance and quality records, not the scheduler
Microsoft Azure – the connection layer that brings selected equipment and IoT events from OT into the architecture
Power BI – shows schedule adherence, queue growth at the bottleneck and recurring causes of late orders
Related episode: What Happens When Sales Promises an Urgent Order
Related episode: Power Platform Copilot Integration - Simply Explained

Why Your Critical Path Changes When Production Changes

Mon, 14 Sep 2026 00:59:46 +0000

A planned completion date looks reasonable until one operation runs late, a material release slips or a resource disappears, and every downstream promise moves with it. This episode shows manufacturing planners and IT/OT architects how to apply critical path thinking to live production, from shared machines and quality holds to MES, ERP, Microsoft Fabric and knowledge graphs, so they can see which dependency controls delivery now.

In this episode

00:00 – Introduction: when the plan meets production
05:20 – One late operation and the delivery date
11:16 – What critical path means on the shop floor
22:43 – Material, shared machines, people and readiness
51:41 – Quality holds and engineering changes
68:15 – Why dashboards don't solve dependency problems
85:27 – Data model, digital twin and knowledge graph
96:07 – Prediction, scheduling, optimization and trade-offs

Key takeaways

In production the critical path is the chain of remaining dependencies that controls the earliest completion date right now, and it moves when machines, material, people or quality conditions change.
A routing, a status dashboard or a Power BI report shows intent and symptoms, but a live dependency model with explicit links between orders, operations, resources and release conditions is needed to explain why a date moved.
Prediction, scheduling and optimization answer different questions, and generative AI should explain schedule results rather than invent the schedule itself.

Worth quoting

“An operation can report late and still not threaten the due date if there's time later in the route.” – Mirko Peters (09:44)

“The route tells you where the part should go, it doesn't tell you when the part can actually go there.” – Mirko Peters (19:21)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ
Power BI – useful for combining plan-versus-actual views, but it cannot calculate a feasible response on its own
Microsoft Excel – the 17-tab planner spreadsheet that survives because it holds context enterprise systems miss
Microsoft Fabric – a shared data layer for governed ERP, MES and operational data behind planning and reporting
Related episode: What Happens When Sales Promises an Urgent Order

How AI Changed Software Development Forever — Building the Agentic Future with Andre Baltieri [MVP]

Thu, 03 Sep 2026 16:25:14 +0000

AI has moved from autocomplete to agents that plan and write most of the code, and developers wonder what is left for them. Microsoft MVP Andre Baltieri shares how he builds with AI coding agents, Microsoft Agent Framework and .NET, and why context, RAG and security matter more than model choice. A practical episode for developers and architects moving existing applications into the agentic era.

In this episode

00:00 – AI is changing software development
02:21 – Software development since 2003
07:34 – AI coding assistants versus agents
13:39 – Microsoft Agent Framework and .NET
32:58 – Deterministic code, probabilistic AI
38:27 – Context, RAG and memory
51:21 – Security, least privilege and prompt injection
62:15 – Cost, generative AI and rapid fire

Key takeaways

AI agents now write most of the code, but developers are still needed to understand business rules, provide good context and orchestrate the agents.
Microsoft Agent Framework lets .NET teams expose existing functions to AI through MCP and connect multiple models with little code.
Security comes first: give agents least privilege, expose only small purpose-built functions and add guardrails against prompt injection.

Worth quoting

“this doesn't mean that we, we don't need programmers anymore. I think there's a bit of misconception out there, because AI can generate code for us.” – Andre Baltieri (05:58)

“I close the conversation and start another conversation because it starts with a clean context that, that would be say, you can clear the context, but I prefer to start a new, a new context.” – Andre Baltieri (49:11)

Explore more on M365.FM

Episode page: the full conversation with chapters, quotes and an FAQ
Andre Baltieri – the guest, a Microsoft MVP coding with .NET since 2003 and now mostly through agents
AI agent – the shift from coding assistants to agents that plan, split tasks and write the code
Retrieval-augmented generation (RAG) – why a good RAG with well-chunked data matters more than stuffing the context window
Prompt injection – the main risk when exposing AI to users, compared here to SQL injection
Related episode: Beyond Copilot: Building AI That Works in the Real World with Azure AI Foundry and Agentic AI for Frontline Workers with Fergus Kidd [MVP]

Architecting Power Platform for Complex Enterprise Solutions with Ian Tweedie [MVP]

Wed, 02 Sep 2026 14:36:43 +0000

Power Platform solutions often start as quick low-code apps and end up business-critical, integrated and hard to maintain. In this interview Ian Tweedie explains to Power Platform makers, developers and architects how modular features, server-side logic, Key Vault, Git-based ALM and intent-based governance keep enterprise solutions maintainable.

In this episode

00:00 – Intro: when low-code becomes enterprise
02:28 – Ian's path to Power Platform
08:14 – Breaking solutions into features and modules
20:14 – Just enough architecture for citizen developers
30:21 – AI, MCP and modular design
40:57 – Secrets, Key Vault and environment variables
46:03 – Git, ALM and source control
51:24 – Governance, the architecture playbook and rapid-fire

Key takeaways

Low-code is not no-code: once Power Platform solutions become business-critical, classic clean-architecture principles such as single-purpose, decoupled features apply just as in pro-code.
Business-critical logic should run server side, and secrets belong in a governed store such as Azure Key Vault rather than in reversible places like environment variables.
Governance works best when it defines intent and lets makers show how they meet it, while source control in Power Platform always means choosing the least-worst option.

Worth quoting

“if it's something that has to be right and always must be accurate then we need to execute that server side” – Ian Tweedie (07:44)

“If we're storing it in a place that's reversible then we potentially shouldn't be storing it there unless it's somewhere like key vault where it's got the right governance around it.” – Ian Tweedie (41:04)

Explore more on M365.FM

Episode page: the full interview with chapters, quotes and FAQ on Power Platform architecture
Ian Tweedie – solution architect who explains his feature-first playbook for enterprise Power Platform solutions
Power Platform – treated here as a low-code, not no-code, platform that needs clean architecture once solutions turn business-critical
Governance – framed by Ian as defining intent and letting makers show how they will meet it
Related episode: Power Platform Copilot Integration - Simply Explained

Copilot Inherits Your Mess: Modernizing Microsoft 365 for AI with Richard Harbridge [MVP]

Tue, 01 Sep 2026 15:20:03 +0000

Microsoft 365 Copilot doesn’t arrive in a clean Microsoft 365 tenant. It arrives in an environment that organizations have been building for years — full of SharePoint sites, Teams, OneDrive content, duplicate documents, historic migrations, guest accounts, inconsistent permissions, forgotten workspaces, broken ownership models, and content nobody has reviewed in years.For traditional Microsoft 365 management, much of this technical debt could remain relatively hidden. AI changes that.In this episode of M365.FM, Mirko Peters talks with Richard Harbridge, Microsoft MVP and industry advisor at ShareGate, about why AI readiness is fundamentally connected to Microsoft 365 modernization and governance.The conversation moves beyond the question of how to deploy Copilot and focuses instead on a more important question: What kind of Microsoft 365 environment are we actually giving AI access to?

COPILOT DOESN’T CREATE THE MESS — IT AMPLIFIES IT
One of the central ideas in this conversation is that Microsoft Copilot is not necessarily creating entirely new governance problems. Instead, AI makes existing problems significantly more visible and consequential.Organizations have accumulated years of decisions around permissions, sharing, workspace creation, ownership, migrations, external access, inactive content and collaboration.Richard describes this accumulation using the concept of “sprawl.”Sprawl itself is not automatically bad. A growing number of Teams, SharePoint sites and other resources can be evidence that people are successfully adopting Microsoft 365.The problem begins when that growth happens faster than the organization’s ability to manage it.Temporary permissions become permanent. Old collaboration spaces remain accessible. Ownership changes. Business structures evolve. Content stays online long after its original purpose has disappeared.Copilot then operates on top of that existing environment.

MICROSOFT 365 SPRAWL IS BIGGER THAN TEAMS AND SHAREPOINT
When people hear “Microsoft 365 sprawl,” they often immediately think about too many Teams or SharePoint sites.But Richard argues that sprawl is multidimensional.Organizations can experience workspace sprawl, permission and access sprawl, ownership problems, inactive resources, lifecycle problems, administrative complexity, conditional access sprawl and increasingly integration and connector sprawl.The rise of AI adds another dimension.Microsoft 365 environments increasingly connect data, applications, AI systems and agents. That means organizations need to think beyond individual workloads and start looking at Microsoft 365 as an interconnected ecosystem.Governance can no longer be treated purely as “SharePoint governance” or “Teams governance.”

THE CONFIDENCE GAP IN MICROSOFT 365 GOVERNANCE
Richard shares an especially interesting finding from ShareGate’s research.A very large percentage of IT leaders report being highly confident in their Microsoft 365 governance. Yet a significant portion of those same organizations report that Copilot has surfaced content that users arguably should not have been able to discover — or they suspect this may have happened but do not know how to verify it.That creates an important distinction between having governance controls available and actually having a continuously governed environment.Policies, configuration options and administrative controls alone do not guarantee that an organization understands its current Microsoft 365 state.AI can expose that gap very quickly.

DID MICROSOFT MAKE COLLABORATION TOO EASY?
Microsoft Teams, SharePoint and OneDrive are successful partly because Microsoft has made collaboration extremely easy.But easy collaboration also makes it easy to create more resources.One response organizations have traditionally used is restricting workspace creation. Richard explains why that alone does not solve the problem.A workspace created today may serve an entirely different purpose six months, one year or two years later.Its owners may change.The organization may restructure.The project may finish.The content may become irrelevant.The people who originally understood why the workspace existed may leave.Governance therefore cannot stop at provisioning.Organizations need lifecycle processes, reviews, attestations and signals that continuously determine whether resources are still appropriate.

GOVERNANCE HAS TO BECOME CONTINUOUS
One-time cleanup projects are not enough.An organization can spend months cleaning its Microsoft 365 environment before deploying Copilot, but without continuous governance, the same problems will gradually return.That means organizations need repeatable processes around ownership, permissions, inactivity, lifecycle management, archiving and retirement.The objective is not to eliminate Microsoft 365 sprawl completely.It is to turn unmanaged sprawl into managed sprawl.

WHERE SHOULD ORGANIZATIONS START BEFORE SCALING COPILOT?
Imagine an enterprise with 10,000 employees, thousands of Teams and SharePoint sites, years of accumulated content and inconsistent permissions.Where should it begin?Richard recommends looking at the specific types of sprawl and identifying where the organization carries the greatest risk.For one company, that might be access control and oversharing.For another, it might be inactive content and lifecycle management.For another organization, privileged identities or administrative management may represent the larger problem.Instead of treating Microsoft 365 governance as one enormous cleanup exercise, organizations can break the problem into measurable categories and prioritize the areas where improvement matters most.

COPILOT ADOPTION SHOULD BE TEAM-BASED
The conversation also challenges one traditional Microsoft technology adoption model.Organizations frequently deploy new technologies through distributed champions.Richard argues that Copilot benefits from a more team-oriented adoption model.Rather than distributing a small number of licenses across unrelated champions throughout an organization, companies can benefit from saturating teams with AI capabilities so that people learn together, develop shared practices and integrate Copilot into collaborative workflows.AI adoption is not only about giving individuals another productivity tool.It changes how teams work together.

MAKING MICROSOFT 365 RISK MEASURABLE
Governance initiatives often struggle because their value is difficult to communicate to business leaders.The conversation explores ShareGate’s Risk Radar, which is designed to help organizations evaluate different categories of Microsoft 365 sprawl, compare maturity against benchmarks and understand which areas deserve attention.An important part of this approach is translating governance risk into financial terms.Instead of asking leadership for time and resources simply because “we need better governance,” IT teams can connect improvements to the potential cost of unmanaged risk.That makes Microsoft 365 modernization and governance easier to position as a business investment rather than another administrative IT project.

AI AGENTS MAKE GOVERNANCE EVEN MORE IMPORTANT
Copilot is only part of the story.As organizations begin creating and deploying more AI agents, governance becomes substantially more complex.Agents can change over time. They can interact with tools, data and other systems. Their ownership can become unclear. Permissions can evolve, and organizations will eventually have to deal with agent lifecycle management at scale.Who owns an agent?Who reviews it?What resources can it access?What happens when its original owner leaves?When should an agent be retired?When should multiple agents be consolidated?These questions look remarkably similar to problems organizations already experience with Teams, SharePoint sites and other Microsoft 365 resources — except AI increases both the speed and potential impact.

GOVERNANCE FROM THE RESOURCE UP
Richard discusses the importance of looking at governance from the underlying resources upward.An AI experience may sit on top of SharePoint, Microsoft 365 data, Power Platform resources, connectors, permissions and other systems.Organizations therefore cannot govern only the visible AI interface.They need to understand the complete chain of resources, data and permissions supporting it.This becomes increasingly important as agents gain more capabilities and organizations move from relatively simple assistants toward agents that can take action.

THE FUTURE IS “EVERYTHING GOVERNANCE
”Looking several years ahead, Richard expects Microsoft governance to become significantly more holistic.Instead of separate conversations about SharePoint governance, Teams governance, Power Platform governance and AI governance, organizations increasingly need to understand how all of these layers interact.Microsoft Purview is highlighted as an important part of this evolution, particularly as Microsoft expands capabilities around data security and posture management.Governance professionals therefore need to broaden their perspective beyond the administration interface or workload they traditionally specialized in.AI sits across boundaries.Governance increasingly has to do the same.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Microsoft 365 Copilot: What Actually Makes People More Productive with Adrian Espes [MVP]

Sun, 30 Aug 2026 09:03:26 +0000

Buying Copilot licenses is easy; making people genuinely more effective with them is not. Microsoft MVP Adrian Espes shares what he sees in real adoption projects: prompting habits, data protection, a pragmatic rollout path and why efficiency is a better goal than productivity. For IT leaders and adoption teams planning or rescuing a Microsoft 365 Copilot rollout.

In this episode

00:00 – Does Copilot make people more productive?
03:32 – Adrian's path into Microsoft 365
08:45 – Copilot compared with other AI tools
20:14 – Prompting without being a prompt engineer
32:56 – Data protection and governance
38:25 – A 30-60-90 day rollout roadmap
48:41 – From productivity to efficiency
55:07 – Rapid fire: hype, useful or future

Key takeaways

Copilot's biggest advantage is that it lives inside Microsoft 365 tools and works with your emails, meetings and documents under enterprise data protection.
Good prompting is learned by practice: be clear about the goal, add context, and tailor prompt guidance to each department.
Before rollout, decide whether free Copilot Chat is enough, review tenant settings such as Anthropic models under GDPR, and talk about efficiency rather than productivity.

Worth quoting

“when we use, Microsoft co-pilot with an enterprise account, we are protected, uh, with a Microsoft EDP enterprise data protection.” – Adrian Espes (34:35)

“And my recommendation is try the Microsoft 365 Copilot chat, the free version, the free version.” – Adrian Espes (42:19)

Explore more on M365.FM

Episode page: the full conversation with chapters, quotes and an FAQ on Copilot adoption
Adrian Espes – Microsoft MVP and consultant who shares what he sees in real Copilot adoption projects
Microsoft 365 Copilot – the main topic, compared with other AI tools and evaluated in everyday work
Prompt – Adrian explains that good prompts come from practice, a clear goal and added context
Copilot adoption – rollout steps, department-specific training and the shift from productivity to efficiency
Related episode: Microsoft 365 Copilot Without the Hype: Adoption, Governance & Getting Your Tenant Ready with Paul Keijzers [MVP]

How Microsoft 365 & Copilot Are Redesigning the Way We Work with Tracy van der Schyff [MVP]

Sat, 29 Aug 2026 09:05:26 +0000

Many organizations switch on Copilot and expect it to fix a chaotic Microsoft 365 environment. In this conversation, Mirko Peters and Tracy van der Schyff discuss digital fluency, the Me, We, Us model, ontological design and permanent change management for adoption leads, IT managers and business leaders. You will learn why investing in people matters more than adding another tool.

In this episode

00:00 – Introduction and Tracy's path into the Microsoft ecosystem
02:09 – From PC literacy to digital fluency
04:00 – Where work belongs: the Me, We, Us model
11:30 – What changed when Copilot entered the workplace
19:20 – Ontological design: what we create shapes us
23:40 – Teams, noise and using AI to overcome fear of AI
35:50 – Copilot in a broken digital workplace and change management
59:30 – Rapid-fire round and closing

Key takeaways

Digital fluency goes beyond knowing which buttons to click: people need to use tools with purpose, efficiently and responsibly, and that now includes AI.
Copilot does not fix a messy Microsoft 365 environment; it amplifies what is already there, so storage habits, sharing and permissions have to be addressed first.
Change management works only as a permanent part of the company's strategy, explaining to people why practices matter rather than just telling them what to do.

Worth quoting

“I think in the era of AI, the responsible use of technology is going to become the most important thing, apart from all the skills that we should focus on.” – Tracy van der Schyff (03:44)

“And whether it's co-pilot or whatever it might be, as I mentioned, it doesn't fix things, okay, it amplifies. So, if you had a healthy environment, it's going to amplify that healthy environment.” – Tracy van der Schyff (37:46)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on digital fluency and Copilot
Tracy van der Schyff – Microsoft MVP from South Africa who frames technology adoption around digital fluency and people
Microsoft 365 Copilot – described as an amplifier and spotlight that exposes existing storage, sharing and permission problems
Copilot adoption – treated as permanent change management that explains why, not a one-off project
Related episode: Copilot Inherits Your Mess: Modernizing Microsoft 365 for AI with Richard Harbridge [MVP]

Stop Reinventing SPFx- Building Better SharePoint Solutions with PnP React Controls with Siddharth Vaghasia [MVP]

Fri, 28 Aug 2026 05:19:58 +0000

Many SharePoint developers keep rebuilding the same pickers, data calls and controls. In this interview, MVP Siddharth Vaghasia shows developers and architects how SPFx, PnPjs and the PnP React controls speed up secure, performant SharePoint solutions and where SPFx fits next to Power Apps and Copilot agents.

In this episode

00:00 – Intro and guest background
04:17 – What SharePoint Framework is
11:13 – SPFx or Power Platform?
15:18 – Inside an SPFx project: TypeScript, Fluent UI, PnPjs, PnP controls
33:31 – Microsoft Graph and permissions
39:45 – Security mistakes
47:09 – Performance, batching and accessibility
54:20 – Deployment, agents and rapid fire

Key takeaways

Before customizing SharePoint, check whether Microsoft or the PnP React controls already provide what you need, and only build custom components when they do not.
SPFx solutions run with the delegated permissions of the signed-in user, so request minimal permissions and never put secrets in client-side code; use a backend API instead.
With AI-assisted coding, SPFx has become a fast option for rich user interfaces, while Power Apps remains the better fit for simple forms without code maintenance.

Worth quoting

“So I would say if you need a very, very good user interface, you can basically go with SPFX and you can create a full-fledged application there” – Siddharth Vaghasia (13:35)

“Good thing about power apps is that you are not maintaining the code. You do not need a skill set with react or SPFX.” – Siddharth Vaghasia (14:55)

Explore more on M365.FM

Episode page: the full interview with chapters, quotes and an FAQ on SPFx development
Siddharth Vaghasia – Microsoft MVP and independent consultant who explains SPFx, PnPjs and the PnP React controls
Nanddeep Nachan – recommended by Siddharth in the rapid fire round as a next guest for Azure AI Foundry
SharePoint – the platform SPFx extends with web parts, extensions, form customizers and app catalog deployment
Microsoft Graph – used from SPFx to reach OneDrive, Planner, Outlook and meetings under delegated permissions
Power Apps – the low-code alternative to SPFx, better for simple forms without code to maintain
Related episode: Power Platform Copilot Integration - Simply Explained

SharePoint Isn't Boring Anymore: How Copilot Is Reinventing the Modern Workplace with Marcin Siewnicki [MVP]

Thu, 27 Aug 2026 07:25:04 +0000

SharePoint has long been seen as complicated and boring, but Copilot turns it into the knowledge layer of the modern workplace. In this conversation, MVP Marcin Siewnicki shares practical advice for IT pros, intranet owners and governance teams on information architecture, sprawl, metadata and permissions. You will learn what to fix before AI arrives and how Copilot, agents and Power Automate fit together.

In this episode

00:00 – Intro and Marcin's SharePoint journey
05:45 – Why SharePoint got a bad reputation
17:20 – Sprawl, Teams and SharePoint
27:47 – Governance policies for SharePoint and Teams
33:38 – Document management and metadata
41:09 – What Copilot changes in SharePoint
47:46 – SharePoint agents and Power Automate
54:35 – Rapid fire round

Key takeaways

SharePoint's bad reputation stems mostly from missing information architecture and IT-driven intranets rather than from the platform itself.
Simple governance such as site request forms with business justification, periodic usage and permission reviews, and controlled versioning keeps SharePoint and Teams manageable.
Copilot makes SharePoint the main knowledge source of the organization, so basic metadata and well-governed content directly improve AI answers, while Power Automate remains the choice for deterministic processes.

Worth quoting

“So usually SharePoint is a shared folder for huge bucket for everything. So there's no information architecture. And then it's hard to find information, hard to find documents.” – Marcin Siewnicki (08:17)

“I always encourage people to build or implement even basic metadata, policy metadata model, because it will help them later, and metadata are supported by copilot” – Marcin Siewnicki (38:26)

Explore more on M365.FM

Episode page: the full conversation with chapters, quotes and an FAQ on SharePoint and Copilot
Marcin Siewnicki – Microsoft 365 solution architect who shares 20 years of SharePoint project experience in this episode
SharePoint – the platform at the center of the talk, from its reputation problem to Copilot readiness
Microsoft 365 Copilot – turns SharePoint content into answers, so metadata and governed content directly shape its results
Related episode: Microsoft 365 Copilot Without the Hype: Adoption, Governance & Getting Your Tenant Ready with Paul Keijzers [MVP]

Microsoft Fabric End-to-End: From Raw Data to Business Decisions with Amit Chandak [MVP]

Tue, 25 Aug 2026 21:00:02 +0000

Many organizations run too many analytics tools and too many copies of the same data. In this interview, Mirko Peters and Microsoft Data Platform MVP Amit Chandak walk data engineers and BI teams through an end-to-end Microsoft Fabric architecture. You learn when to use lakehouse, warehouse, shortcuts, mirroring, Dataflow Gen2 and Spark, and how semantic models, security and data agents turn raw data into decisions.

In this episode

00:00 – Introduction and Amit Chandak's journey into data
02:30 – Why Microsoft Fabric: one platform, OneLake and Delta
07:25 – Domains, workspaces and OneLake shortcuts
16:40 – Lakehouse vs. warehouse and SQL database
24:00 – Ingestion: mirroring, pipelines, Dataflow Gen2 and Spark notebooks
33:40 – Medallion architecture and semantic models
44:50 – Security: workspaces, OneLake security and RLS
52:00 – Data agents, self-service BI and rapid fire

Key takeaways

Microsoft Fabric reduces data copies by storing lakehouse and warehouse data in OneLake in Delta format and by using shortcuts and mirroring instead of physical copies.
Choose lakehouse with Spark for unstructured data and large-scale data science, warehouse with T-SQL for structured data, and keep reusable measures in the semantic model.
Secure Fabric in layers from workspace to item to OneLake security and RLS, assign access through Entra security groups, and expect ontology-driven data agents to change self-service BI.

Worth quoting

“Today we are going to end to end with Microsoft Fabric. Not looking at one isolated feature, but at how the different parts of the platform come together to create a modern analytics architecture.” – Mirko Peters (00:07)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Fabric architecture
Amit Chandak – Microsoft Data Platform MVP with over 22 years in data analytics, guiding the Fabric walkthrough
Microsoft Fabric – the end-to-end platform discussed, from OneLake, shortcuts and mirroring to security and data agents
Semantic model – where Amit prefers to keep measures and KPIs, now also feeding data agents and Fabric apps
Related episode: Microsoft Fabric for Microsoft 365 Admins: What You Need to Know

Beyond Copilot: Building Enterprise AI Agents That Actually Work with Copilot Studio with Manpreet Singh [MVP-MCT]

Mon, 24 Aug 2026 15:00:02 +0000

Building an impressive agent demo is easy, but making agents work reliably in a global enterprise with sensitive data, governance and real users is something else. Microsoft MVP Manpreet Singh explains for architects, IT leaders and makers how to design Copilot Studio agents with clean knowledge, human in the loop, governance, observability and the adoption work that finally delivers ROI.

In this episode

00:00 – Introduction: from Copilot to agents
04:48 – Designing an enterprise AI agent
11:38 – Knowledge, grounding and data quality
14:20 – Actions, integrations and a first agent
20:02 – Human in the loop and governance
27:50 – Agent lifecycle, Agent 365 and the AI command center
45:23 – Observability, testing and multi-agent systems
56:22 – Rapid fire and adoption as the key to ROI

Key takeaways

An enterprise agent needs three pillars: a trigger, tools and actions, and clean, well-tagged knowledge sources rather than decades of unfiltered SharePoint content.
Governance, DLP and a Center of Excellence should be in place before agents roll out, with policies scoped to what each agent actually needs and tools like Agent 365 providing inventory and observability.
The return on AI agents depends mostly on adoption, so every user needs role-based training on what an agent does and what input it expects.

Worth quoting

“So with the AI's, we are not replacing people, we are just empowering them to do their job much better.” – Manpreet Singh (22:28)

“And that also means the difficult part for enterprise technology doesn't disappear. Identity matters, security matters, data quality matters, governance matters, architecture matters, testing matters.” – Mirko Peters (62:45)

Explore more on M365.FM

Episode page: the full interview with chapters, quotes and FAQ on Copilot Studio agents
Manpreet Singh – Microsoft MVP and MCT who shares how he designs enterprise agents for global clients
AI agent – the core topic, from a leave request agent to multi-agent networks
Copilot Studio – where Manpreet suggests building a first agent, and its evaluation feature for testing
Related episode: The Death of the Chatbot: Why Your Dataverse Strategy Is Broken

From Copilot Rollout to AI Workplace: Adoption, Agents & Real Business Value with Christoffer Besler Hansen [MVP]

Sun, 23 Aug 2026 15:20:02 +0000

Rolling out Microsoft 365 Copilot is easy; getting thousands of employees to use it and proving value is not. Microsoft MVP Christoffer Besler Hansen of Atea shares practical lessons for IT and business leaders on adoption, agents, Copilot Studio, governance and cost control on the way to a real AI workplace.

In this episode

00:00 – Introduction and guest
01:40 – Christoffer's journey into Microsoft technology
03:03 – What an AI workplace is and why training matters
06:07 – Expectations, licenses and measuring value
15:16 – Time savings, Researcher and preparing data
22:24 – From Copilot to agents and Copilot Studio
27:29 – Agents that take actions, guardrails and the Agent 365 SDK
41:45 – Agent lifecycle, shadow AI, FinOps and the future of work

Key takeaways

Buying Copilot licenses is not enough; continuous, role-based training is what keeps people using AI after the first few weeks.
Organizations should measure AI value against real business outcomes, prepare and label their data, and move step by step from informational agents to agents that take actions with guardrails.
Agent sprawl, shadow AI and rising token costs call for lifecycle policies, good sanctioned tools and FinOps thinking about which model and tool to use for each task.

Worth quoting

“Of course but the technology is moving very quickly. It's new modules and new things every week but getting people to actually change your habits takes time.” – Christoffer Besler Hansen (04:42)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Copilot adoption and agents
Christoffer Besler Hansen – Microsoft MVP and head of AI workplaces at Atea, sharing lessons from its internal rollout
Microsoft 365 Copilot – the main AI tool for Atea's more than 8,000 users and the focus of its training
AI agent – the step from informational agents to agents that take actions, with guardrails and lifecycle policies
Related episode: Power Platform Copilot Integration - Simply Explained

Azure Local and Landing Zones: How to Build Hybrid Cloud the Right Way with Christoffer Klarskov Jakobsen [MVP]

Sat, 22 Aug 2026 13:20:02 +0000

What happens when your cloud strategy cannot live entirely in the public cloud? Organizations are modernizing infrastructure with Azure, platform services, Infrastructure as Code, automated deployment pipelines, and Azure Landing Zones. At the same time, some workloads still need to remain close to factories, offices, regulated environments, existing infrastructure, or latency-sensitive systems. In this episode of M365 FM, Mirko Peters talks with Microsoft MVP Christoffer Klarskov Jakobsen about how Azure Local can become part of a broader Azure architecture rather than another isolated on-premises platform. They explore Azure Local, Azure Landing Zones, Azure Arc, governance, Infrastructure as Code, Bicep, Azure DevOps, modernization, and the realities of building hybrid cloud environments.

WHAT IS AZURE LOCAL?
Azure Local combines familiar infrastructure technologies with Azure-based management, governance, and security capabilities. At its core, organizations can run workloads such as virtual machines locally while connecting the environment back to Azure. Christoffer explains that the major difference compared with a traditional Windows Server environment is the Azure experience surrounding the infrastructure. Organizations can keep workloads and data locally while using Azure capabilities to manage and govern the environment.

IS AZURE LOCAL JUST AZURE IN YOUR DATA CENTER?
Not exactly. Azure provides a significantly larger catalog of cloud services, but Azure Local can bring selected Azure experiences closer to local infrastructure. Christoffer discusses running virtual machines and Kubernetes on Azure Local as well as scenarios involving SQL Managed Instance and Azure Virtual Desktop. The result isn't a complete copy of Azure running inside your building. It's a hybrid platform combining local compute requirements with selected Azure services and management capabilities.

WHEN DOES AZURE LOCAL MAKE SENSE?
Several scenarios stand out. Organizations may have regulatory requirements requiring data to remain locally. Others need extremely low latency between applications, machines, factories, or other infrastructure. Some organizations simply have workloads that cannot yet move completely into the public cloud. Christoffer also sees increasing potential around local AI workloads, including scenarios where organizations need AI capabilities while maintaining local control over their data.

AZURE LOCAL IS A LOCAL CLOUD
One of the important architectural lessons from the conversation is that Azure Local shouldn't be treated as simply another pair of servers. The environment includes multiple infrastructure and Azure-connected layers. Organizations therefore need people who understand the underlying hardware and operating technologies as well as Azure management. Christoffer describes Azure Local as effectively operating a local cloud rather than simply installing another traditional virtualization cluster.

WHY AZURE LANDING ZONES MATTER
Moving workloads into Azure doesn't automatically create a well-designed cloud environment. Organizations need structure, security boundaries, governance, permissions, networking, logging, and clear separation between workloads. Azure Landing Zones provide an architectural approach for establishing those foundations. Instead of placing unrelated applications, development environments, production systems, networking components, and shared services inside the same subscription, organizations establish clearer boundaries around workloads and responsibilities.

THINK DIFFERENTLY ABOUT AZURE SUBSCRIPTIONS
A subscription shouldn't simply become a container for everything an organization deploys. Christoffer recommends thinking about subscriptions as boundaries for specific environments and workloads. A development environment can have its own subscription. Testing can have another. Production can have another. Shared connectivity, logging, identity, and other platform services can be separated appropriately. This makes environments easier to secure, govern, understand, and eventually decommission.

MANAGEMENT GROUPS CREATE STRUCTURE
Management groups provide another layer for organizing Azure environments. They allow organizations to establish a hierarchy above subscriptions and apply governance at broader scopes. Policies and permissions can then be assigned at the management-group level rather than repeatedly configuring every individual subscription. Christoffer also discusses the local management group, which makes Azure Local increasingly relevant within the same Landing Zone architecture.

AZURE POLICY AS THE GUARDRAIL
Azure Policy plays a major role in this architecture. Policies can audit environments against organizational or regulatory requirements. They can identify non-compliant resources. They can deploy required configuration when something doesn't already exist. They can also deny configurations that organizations don't want users to create. Examples discussed include controlling Azure regions and preventing insecure storage configurations. Instead of relying entirely on documentation telling employees what they should do, organizations can encode many requirements directly into the platform.

DENTITY, RBAC AND ZERO TRUST
Landing Zones also provide a foundation for stronger access control. Christoffer emphasizes the principle of least privilege. Users and automated deployment identities should receive only the permissions required to perform their responsibilities. Application owners shouldn't automatically have access to connectivity infrastructure. Support personnel shouldn't automatically be able to modify logging systems. The objective is to establish clear security boundaries instead of making everybody an owner simply because that configuration is easier.

AZURE LOCAL MEETS AZURE LANDING ZONES
This is where the hybrid architecture becomes particularly interesting. Azure Local previously had limitations around how organizations could structure subscriptions and resources. Christoffer explains that newer capabilities make it possible to use multiple subscriptions and resource groups, enabling Azure Local to align much more closely with Landing Zone design principles. The Azure Local cluster itself can live within one subscription while different workloads use additional subscriptions. That enables organizations to apply clearer boundaries between the control plane and workloads.

TIER 0, TIER 1 AND TIER 2
The conversation goes deeper into separating workloads according to security requirements. For example, domain controllers can be treated as Tier 0 resources and placed into a dedicated subscription with particularly strict access controls. Member servers can occupy another tier. End-user workloads such as Azure Virtual Desktop can be separated again. This creates an architecture where local workloads don't simply exist inside one giant infrastructure bucket—they participate in a structured Azure governance model.

AZURE ARC CONNECTS THE TWO WORLDS
Azure Arc is one of the technologies making the traditional boundary between cloud and on-premises infrastructure increasingly less important. Arc can connect servers running outside Azure with Azure management capabilities. That can include Windows and supported Linux systems running locally, on virtualization platforms, or even with other infrastructure providers. Once connected, organizations can use Azure capabilities including Microsoft Defender for Cloud, Azure Policy, and Azure Update Manager across infrastructure that isn't physically running inside an Azure datacenter.

ONE MANAGEMENT PLANE FOR HYBRID INFRASTRUCTURE
Traditionally, organizations often accumulated separate products for monitoring, patching, security, configuration, and infrastructure management. Azure Arc changes that model. Instead of treating every location as an entirely separate environment, administrators can increasingly manage distributed infrastructure through Azure. The physical location of the workload still matters for latency, compliance, hardware, and availability—but it doesn't necessarily require an entirely separate management model.

INFRASTRUCTURE AS CODE FOR AZURE LOCAL
Infrastructure as Code isn't limited to Azure public cloud resources. Christoffer explains that Azure Local infrastructure and workloads can also be deployed using Infrastructure as Code. His principle is straightforward: If you're going to do something more than once, automate it. The initial investment may take additional time, but repeatable deployment becomes particularly valuable for environments requiring ongoing maintenance and consistent configuration.

WHY BICEP?
Christoffer primarily uses Bicep for Infrastructure as Code. Coming from a PowerShell background, he found the transition into Bicep relatively natural. Visual Studio Code and its supporting extensions also make the development experience easier by identifying syntax issues and helping developers understand available configuration. He doesn't argue that Bicep is universally better than Terraform—rather, Bicep fits naturally into the Microsoft-focused environments and workflows he works with.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Dynamics 365 Business Central AL Development

Sat, 22 Aug 2026 12:55:02 +0000

Business Central covers standard processes, but sooner or later a company needs an extra field, approval step or business rule. In this Knowledge Nugget Mirko Peters explains for beginners and functional consultants how AL and extensions customize Business Central safely without touching the base application.

In this episode

00:00 – Intro: one small change in Business Central
00:40 – Why businesses customize Business Central
03:35 – AL and extensions: the safe add-on model
06:39 – The main AL building blocks
11:04 – Events, triggers and business rules
14:59 – Where AL development happens
17:34 – Example: a customer rewards add-on
18:55 – Your AL development starting point

Key takeaways

AL is Microsoft's language for Business Central, and extensions keep custom work separate from the base application so updates do not turn into major rebuilds.
Tables, pages, table and page extensions, codeunits, triggers and event subscribers each have one job, and shared business rules belong in a codeunit.
AL development happens in Visual Studio Code with the AL language extension, testing belongs in a sandbox, and Git keeps a history of every change.

Worth quoting

“Instead of rewriting the standard application, developers build a separate add-on that connects to it, keeping the standard part in place while the company's own changes sit beside it” – Mirko Peters (01:44)

“changing something just because it looks different from an old system creates extra work later, so good custom work starts with a clear business reason.” – Mirko Peters (02:48)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on AL basics
Dynamics 365 Business Central – the ERP system that AL extensions customize without changing the base application
Visual Studio Code – the editor where AL code is written, compiled and published with the AL language extension
Mirko Peters – hosts this Knowledge Nugget and builds a customer rewards extension as the example
Related episode: Dynamics 365 Business Central Extensions - Simply Explained

Dynamics 365 Dual-write - Simply Explained

Sat, 22 Aug 2026 10:45:02 +0000

A salesperson updates a customer address in https://www.m365.fm/categories/power-platform-talk/ Sales. Later, someone in finance opens the same customer and still sees the old address. Which one is correct? When sales, service, finance, and operations work in different applications, shared business data can quickly become duplicated or inconsistent. In https://www.m365.fm/dynamics-365-dual-write-simply-explained/ of M365 FM, Mirko Peters explains how Dynamics 365 Dual-write connects Finance and Operations apps with Microsoft Dataverse so supported records such as customers, addresses, contacts, products, and orders can remain synchronized as teams work.

WHAT IS DYNAMICS 365 DUAL-WRITE?
Dual-write is Microsoft's built-in connection between https://www.m365.fm/dynamics-365-finance/ and Operations apps and Microsoft Dataverse. Think of an organization as having a front office and a back office. The front office includes salespeople, service agents, field workers, and other customer-facing teams. The back office handles finance, inventory, purchasing, orders, fulfillment, and other operational processes. Both sides work with many of the same customers and products, but they need different applications for their jobs. Dual-write creates a controlled connection between those environments so selected shared records can remain synchronized without employees manually copying information between applications.

THE BUSINESS PROBLEM DUAL-WRITE SOLVES
Without integration, one customer can quietly become two different records. Sales might have Northwind Bikes with the customer's new address. Finance might have Northwind Bicycle Company with the previous address. Both records can look correct when viewed independently, but they no longer describe exactly the same business relationship. Employees then become the integration layer. They export spreadsheets, send emails, compare records, re-enter information, and investigate which version is correct. Dual-write is designed to reduce that manual handoff.

FRONT OFFICE AND BACK OFFICE
Dynamics 365 applications support different types of work. Dynamics 365 Sales focuses on leads, opportunities, customer relationships, and sales conversations. Customer Service manages customer questions and cases. Field Service supports technicians and work performed at customer locations. Finance and Supply Chain Management handle areas such as accounting, inventory, products, purchasing, orders, and fulfillment. The objective isn't to force every employee into one giant application. Instead, employees continue using the application appropriate for their role while selected business information remains connected behind the scenes.

MICROSOFT DATAVERSE
Dataverse is the shared data foundation behind many Microsoft business applications. Dynamics 365 Sales, Customer Service, Field Service, parts of Project Operations, https://www.m365.fm/power-apps-simply-explained/, and https://www.m365.fm/power-automate-simply-explained/ can work with Dataverse. For understanding Dual-write, think of Dataverse as the common data area on the customer-application side. Finance and Operations remains the operational foundation on the other side. Dual-write connects selected records between these environments.

THINK OF DUAL-WRITE AS AN INTERNAL DOOR
Imagine an office building with customer-facing teams on one side and finance and operations on the other. Without integration, somebody has to carry information between them. They might send an email, move a spreadsheet, or manually enter the information again. Dual-write acts like a staffed internal door. When a supported record changes on one side, Dual-write can pass the related change through that door according to predefined rules. Each team keeps its own workspace while shared information remains connected.

WHAT ARE TABLE MAPS?
Dual-write doesn't blindly synchronize every piece of information. It works through defined connections called table maps. A table stores a particular type of record. A customer table contains customer records. A product table contains products. An address table contains address information. A table map tells Dual-write which table in Finance and Operations corresponds with which table in Dataverse. It also defines how relevant fields relate to each other. Think of the table map as the translation sheet between the two systems.

TWO-WAY SYNCHRONIZATION
The word dual reflects the ability of supported maps to synchronize changes in both directions. A supported update in Dataverse can update the corresponding record in Finance and Operations. A supported update in Finance and Operations can also update the related Dataverse record. However, this doesn't mean every table or every field should automatically move in both directions. Organizations still need clear rules about which system owns particular information.

NEAR REAL-TIME DATA
Dual-write is designed for business information employees need while they're actively working. Instead of waiting for an overnight synchronization job, supported changes can move between the environments in near real time. Near real time doesn't mean absolutely zero delay. It means the connection supports live operational processes rather than relying primarily on scheduled file exchanges. A salesperson shouldn't need to wait until tomorrow morning before finance sees an important customer update.

WHAT DATA CAN DUAL-WRITE CONNECT?
Common examples include customers, addresses, contacts, products, vendors, company information, organizational structures, and finance or tax reference information. The exact records depend on the Dynamics 365 applications and business processes an organization uses. The important principle is not to synchronize everything possible. Synchronize information that genuinely needs to represent the same business record across both environments. ㅤ

CUSTOMER RECORDS
Customers are one of the clearest examples. Sales needs information such as customer names, contacts, phone numbers, and delivery information. Finance needs the legal customer record, billing information, and the details required for orders and invoices. Dual-write can keep supported customer information connected while allowing each team to continue working inside the Dynamics 365 application designed for its responsibilities.

ADDRESSES AND CONTACTS
Customer information is more complicated than one company name. A customer can have a billing address, shipping address, and service location. The organization might also work with buyers, Accounts Payable contacts, service managers, and other people within the same customer organization. Connected address and contact structures help sales, service, finance, and operations work with related information without independently rebuilding those relationships in every application.

PRODUCT INFORMATION
Products provide an example where ownership frequently becomes important. Finance and Operations often owns product creation because operations controls product master information, stock units, and other details required to sell and deliver products. Once the product is prepared for customer-facing work, Dual-write can send related product information into Dataverse. Sales users can then work with those products without somebody manually recreating the product catalog in another application.

ONE-WAY VS TWO-WAY MAPS
Not every business record needs two-way synchronization. Some maps support changes in both directions because both sides have a legitimate reason to maintain information. Other records have a clearer owner. Products provide a useful example: operations might create and govern the product while sales simply receives and uses that information. The correct synchronization direction should follow the organization's actual data ownership model.

DATA OWNERSHIP MATTERS
Before synchronizing information, organizations need to answer: Where does this record begin? Who can change it? Which system wins when information conflicts? Who corrects an incorrect value? For example, sales might own relationship and contact information while finance owns payment-related information and operations owns products and inventory. The exact ownership model depends on the business. What matters is that the ownership is clearly defined before automation begins moving changes between applications.

HOW A CHANGE TRAVELS
Imagine a salesperson speaking with a customer who recently moved. The salesperson updates the customer's street address in Dynamics 365 Sales and saves the record. Sales stores that change in Dataverse. Dual-write checks the relevant table map and identifies the corresponding customer and address information in Finance and Operations. The supported update travels across automatically. When finance later opens the customer record, the updated address is available without somebody manually entering it again.

SYNCHRONOUS BUSINESS PROCESSES
For normal day-to-day operations, the connection is designed to process related updates as part of the current working process instead of placing everything into a background synchronization job that might execute much later. This matters because employees make decisions based on what they see now. Customer addresses, product details, and other shared information shouldn't quietly drift apart for hours before somebody discovers the difference. When synchronization fails, that failure needs attention rather than remaining hidden until another team discovers inconsistent data.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Dynamics 365 Accounts Payable - Simply Explained

Sat, 22 Aug 2026 04:30:02 +0000

A supplier invoice arrives. The goods may already be sitting in your warehouse or the service may already be complete—but what actually needs to happen before money leaves the company? https://www.m365.fm/categories/dynamics-talk/ Accounts Payable connects vendor records, invoices, purchase orders, receiving, invoice matching, approvals, payment runs, bank accounts, and settlement into one controlled financial process. In https://www.m365.fm/dynamics-365-accounts-payable-simply-explained/ of M365 FM, Mirko Peters explains how https://www.m365.fm/dynamics-365-finance/ manages the complete journey from receiving a vendor bill to recording the final payment.

WHAT IS DYNAMICS 365 ACCOUNTS PAYABLE?
Accounts Payable tracks money your company owes vendors for goods and services it has already purchased. Think of it as the payment office inside a large company. Bills arrive, somebody verifies them, the appropriate people approve them, finance determines when they should be paid, and finally the payment is sent to the supplier. Dynamics 365 keeps these individual activities connected so finance can follow the complete history of each vendor invoice.

WHY ACCOUNTS PAYABLE MATTERS
Most businesses don't pay suppliers immediately when they place an order. A supplier delivers goods or completes a service and then sends an invoice. The company now owes that amount, but the money hasn't left the bank account yet. That unpaid amount becomes a liability. A business can therefore have significant cash in its bank account while simultaneously owing substantial amounts to suppliers. Accounts Payable gives finance visibility into both what has already been paid and what will need to be paid in the future.

ACCOUNTS PAYABLE VS ACCOUNTS RECEIVABLE
The names sound similar, but they represent opposite sides of company cash flow. Accounts Payable = Money your company owes vendors. Accounts Receivable = Money customers owe your company. If your company buys printers from a supplier, the supplier invoice belongs in Accounts Payable. If your company sells desks to a customer and sends them an invoice, that customer invoice belongs in Accounts Receivable. One tracks money leaving the business. The other tracks money expected to enter it.

THE GOAL OF ACCOUNTS PAYABLE
The objective is straightforward: Pay the right vendor, the right amount, on the agreed date. Paying too early reduces available cash sooner than necessary. Paying too late can create supplier problems, reminders, disputes, or less favorable payment terms. Paying the wrong amount creates additional administrative work. Dynamics 365 provides the records and controls finance teams need to manage these decisions consistently.

THE VENDOR RECORD
Before Dynamics 365 can process an invoice, it needs to know who should receive the money. The vendor record acts as the supplier's file inside Dynamics 365. It can contain the vendor's name, address, contact information, currency, payment terms, payment method, and other financial settings. These settings don't simply describe the supplier. They influence what happens later when invoices and payments are processed.

PAYMENT TERMS
Payment terms determine when an invoice becomes due. One supplier might require payment within 14 days. Another might allow 30 days. Some vendors may offer discounts for early payment. Dynamics 365 uses the configured payment terms to calculate invoice due dates. That means employees processing invoices for the same vendor don't need to remember individual agreements or search old emails to determine when payment is required.

PAYMENT METHODS
Payment terms answer when the supplier should be paid. Payment methods answer how the money should reach them. Depending on the organization's processes, vendor payments can use methods such as electronic payments, cheques, or promissory notes. Dynamics 365 allows organizations to configure payment methods according to the financial processes they actually use.

VENDOR GROUPS
Large organizations can have hundreds or thousands of vendors. Creating every financial setting independently for every supplier would create unnecessary work and increase the risk of inconsistent configuration. Vendor groups allow organizations to group suppliers sharing common finance rules. The individual vendor still maintains its own identity and transaction history, while the group provides a common starting point for shared financial configuration.

VENDOR POSTING PROFILES
Posting profiles tell Dynamics 365 where vendor transactions belong in the General Ledger. When an invoice is posted, Dynamics 365 needs to record what the organization owes while also connecting the transaction with the appropriate financial accounts. The posting profile provides the accounting map behind this process. Finance employees therefore don't need to manually determine the relevant vendor ledger account every time they process an invoice.

HOW VENDOR INVOICES ENTER DYNAMICS 365
Invoices can enter the Accounts Payable process in several ways. A finance employee can manually enter information from an invoice received through email, paper, or another channel. The invoice record can contain the vendor, invoice number, invoice date, currency, amounts, lines, tax information, purchase order references, and supporting documents. For higher invoice volumes, invoice information can also enter electronically through data entities and connected invoice-processing solutions.

INVOICE NUMBERS AND DUPLICATE DETECTION
The vendor's invoice number is particularly important. Suppose Northwind Office Supplies sends invoice NWO148. If the same invoice enters the system again, Dynamics 365 can use the combination of vendor and invoice number to identify a potential duplicate. This matters because suppliers sometimes resend invoices when they aren't sure the first copy arrived. Employees can also accidentally process the same document twice. Duplicate detection helps prevent the same bill from being paid twice.

INVOICE ATTACHMENTS
Supporting documents can remain connected with the transaction. A PDF invoice, scanned document, or other supporting paperwork can be attached to the invoice record. The finance employee reviewing the transaction can therefore compare the information entered into Dynamics 365 with the original document without searching through shared mailboxes or filing cabinets. This also creates a clearer record when somebody needs to review the transaction later.

AUTOMATED INVOICE IMPORT
Organizations processing large numbers of invoices don't necessarily need employees to manually type every invoice. External invoice capture systems can send invoice information into Dynamics 365 using data entities. The invoice header contains information such as the vendor, invoice number, dates, currency, total amount, and purchase order reference. Invoice lines explain exactly what the supplier is charging for. Supporting documents can travel alongside the structured invoice information.

VENDOR INVOICE POLICIES
Before an invoice proceeds, Dynamics 365 can check whether it follows the organization's configured rules. Missing vendors, invalid dates, duplicate invoice numbers, incorrect totals, or imported data problems can prevent an invoice from proceeding normally. The objective isn't to automate every decision. Automation handles routine checks while finance employees investigate exceptions requiring human judgment.

INVOICE APPROVAL WORKFLOWS
Workflow determines who needs to approve an invoice. Instead of emailing a PDF to a manager and waiting for somebody to respond, Dynamics 365 can route the invoice according to predefined organizational rules. A small invoice might require a simple approval. A large invoice might require a senior manager. An invoice associated with a particular department can be routed toward the manager responsible for that department. The approval route follows configured rules instead of relying on somebody remembering who should receive the invoice.

AUTOMATION AND EXCEPTIONS
Invoices that satisfy established rules can move through routine parts of the process more efficiently. Invoices containing problems become exceptions. Perhaps the vendor is missing, an invoice number already exists, or imported information contains an error. Finance employees can investigate those exceptions rather than spending the same amount of time manually checking every invoice. The system handles repetition. People handle situations requiring judgment.

INVOICE MATCHING
Approval answers: Has the appropriate person approved this invoice? Invoice matching answers another question: Does the supplier's invoice agree with what the company actually ordered and received? When a purchase originates from a purchase order, Dynamics 365 already has information describing the agreed vendor, products, quantities, prices, and terms. That gives finance something concrete against which the vendor invoice can be checked.

PURCHASE ORDERS
A purchase order records what the organization agreed to purchase before the invoice arrives. Suppose the company orders ten office chairs at an agreed price. The purchase order establishes that agreement. When the supplier invoice eventually arrives, finance can compare the bill against the original purchase order instead of reviewing the invoice without any purchasing context.

PRODUCT RECEIPTS
For physical goods, another important record exists: the product receipt. When goods arrive, warehouse employees record what was actually received. If ten chairs were ordered but only eight arrive because two are backordered, the product receipt can

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Dynamics 365 Virtual Entities - Simply Explained

Sat, 22 Aug 2026 01:15:02 +0000

What happens when your sales team works in https://www.m365.fm/categories/power-platform-talk/, but inventory lives in a warehouse system, invoices live in finance, and product information lives in an ERP? You could copy all that information into Dataverse, but then you create duplicate records, synchronization jobs, delays, and another place where information can become outdated. In https://www.m365.fm/dynamics-365-virtual-entities/ of M365 FM, Mirko Peters explains how Dynamics 365 Virtual Tables, formerly known as Virtual Entities, provide live access to external business data without requiring Dynamics 365 to store another copy.

WHAT ARE DYNAMICS 365 VIRTUAL TABLES?
A Virtual Table is a table definition inside Microsoft Dataverse that points to records stored somewhere else. Dataverse understands what the information looks like—such as product name, available quantity, price, or invoice status—but the actual records remain in the external system. Think of it as a window into another business system. Dynamics 365 provides the familiar interface while the external application remains responsible for storing and managing the data.

VIRTUAL ENTITIES VS VIRTUAL TABLES
You may still encounter the term Virtual Entities in older documentation, implementations, and conversations. The current terminology is Virtual Tables. The underlying concept remains the same: Dynamics 365 and Dataverse can expose external information as though users were working with another Dataverse table, while the records themselves remain outside Dataverse.

WHY COPYING DATA CREATES PROBLEMS
Imagine your warehouse has ten units available when an overnight synchronization runs. The following morning, Dynamics 365 shows ten. At lunchtime, the warehouse ships all ten units. The warehouse system immediately knows inventory has reached zero, but Dynamics 365 could continue displaying ten until the next synchronization occurs. Your salesperson is now making decisions using outdated information. The problem isn't necessarily that synchronization failed. The problem is that the copied information became outdated between synchronization runs.

THE DUPLICATE RECORD PROBLEM
Copying information also creates another question: Which system owns the truth? The product exists in the ERP system, but another copy exists in Dataverse. Someone changes the description, price, status, or availability. Now somebody needs to determine which version should win. Virtual Tables avoid this problem by allowing the original business system to continue owning the record while Dynamics 365 users access that information when required.

THINK OF TWO FILING CABINETS
Imagine keeping identical documents in two filing cabinets. One cabinet belongs to sales and another belongs to the warehouse. Whenever somebody changes a document in one cabinet, they need to carry the updated copy to the other. Miss one update and the cabinets disagree. Traditional synchronization follows a similar pattern. Virtual Tables provide another approach: instead of maintaining the second copy, give the sales team a secure way to see information from the original cabinet.

ONE PLACE TO WORK DOESN'T REQUIRE ONE DATABASE
Organizations frequently say they want "one system." What employees often actually need is one place to work. A salesperson shouldn't need to open Dynamics 365, switch to the ERP to check inventory, open another application to check an invoice, and then return to the customer record. Virtual Tables can bring selected external information into the Dynamics 365 experience while allowing specialized systems to continue managing their respective business processes.

A LIVE WINDOW INTO EXTERNAL DATA
Suppose an account manager is discussing a large opportunity with a customer. The customer wants 500 units next month. While remaining inside Dynamics 365, the account manager opens related product availability information showing the item number, warehouse, available quantity, and expected replenishment date. That information can come directly from the external warehouse or ERP system rather than yesterday's imported inventory list. Dynamics 365 becomes the workspace while the warehouse system remains the inventory authority.

NORMAL DATAVERSE TABLE VS VIRTUAL TABLE
With a normal Dataverse table, the records are stored inside Dataverse. Accounts, contacts, opportunities, and cases are common examples. With a Virtual Table, Dataverse defines how the external information should appear and how to retrieve it, but the actual records remain somewhere else. The difference can be summarized as: Standard Table → Dataverse stores the record Virtual Table → Dataverse accesses the record from another system

THINK OF A LIBRARY CATALOG
A library catalog contains information describing a book. It tells you the title, author, and where to find it. But the catalog isn't the book. A Virtual Table works similarly. Dataverse understands the structure and knows how to request the record, but the external system contains the actual business data.

RUNTIME DATA ACCESS
Virtual Tables retrieve information when the application needs it. A user might open a view, search for particular records, apply a filter, or select an individual row. Dataverse then requests the relevant information from the external system. The objective isn't to fetch every external record and permanently store it. Instead, the application requests the information required for the current interaction.

THE THREE BUILDING BLOCKS
The episode explains three important components behind a Virtual Table: Data Provider → translates requests Data Source → identifies and connects to the external service Virtual Table → maps external information into a Dataverse table structure Together, these components allow Dynamics 365 to request external records and present them through a familiar user experience.

WHAT IS A DATA PROVIDER?
The Data Provider acts as a translator. Dynamics 365 and Dataverse send requests using their own concepts—tables, columns, filters, and record IDs. The external system might use another API or data format. The provider translates between those two sides. Users don't need to understand that conversation. They interact with the resulting records through the Dynamics 365 application.

WHAT IS A DATA SOURCE?
If the provider knows how to communicate, the Data Source identifies where to communicate. The Data Source contains connection information for the external service. This can include the service address, authentication information, and connection-related settings. Think of the Data Provider as knowing the language and the Data Source as containing the address and connection details required to reach the correct system.

ODATA V4
Dataverse includes support for an OData Version 4 provider. OData provides a standardized approach for exposing and requesting data over the web. An external service might expose products containing fields such as product number, description, unit price, and available quantity. The provider can request those records and return them in a structure Dataverse understands. This provides a common integration approach when the external application already supports OData V4.

CUSTOM DATA PROVIDERS
Not every external business application supports OData. Organizations can use custom Data Providers when another integration method is required. A developer might create a provider connecting Dataverse with a REST API, database, or proprietary company service. The custom provider still performs the same fundamental job: Receive the Dataverse request → communicate with the external system → translate the response → return records to Dataverse.

MAPPING EXTERNAL COLUMNS
The Virtual Table defines how external fields should appear inside Dataverse. The warehouse application might call a field Available Quantity, while Dynamics 365 users see Stock on Hand. The mapping tells Dataverse that these fields represent the same information. This allows organizations to provide user-friendly terminology inside Dynamics 365 without requiring the external system to rename its own fields.

UNIQUE RECORD IDS
Dataverse needs to distinguish one external record from another. Virtual Table records therefore require dependable unique identifiers that Dataverse can recognize. Without a reliable ID, Dataverse can't confidently determine which exact product, invoice, customer, or other external record the user selected. Record identity is therefore an important technical requirement when evaluating whether an external data source can work effectively through Virtual Tables.

FOLLOWING A VIRTUAL TABLE REQUEST
Imagine a salesperson opens a product list and filters for available items. Dataverse recognizes that the request targets a Virtual Table. The Data Provider receives the request. The Data Source provides the information required to contact the external service. The provider translates the filter into something the external service understands. The source system returns matching records. The provider converts those results into Dataverse rows. Dynamics 365 displays them in the familiar interface. The user sees a normal-looking product list while the data remains in the external system.

WHERE VIRTUAL TABLES FIT BEST
Virtual Tables work particularly well when another system clearly owns the information but Dynamics 365 users need that information during their normal work. Examples include live inventory, product information, purchase status, invoice status, finance information, supplier catalogs, and selected marketing information. The external application remains responsible for managing the lifecycle of the reco

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Dynamics 365 Product Information Management - Simply Explained

Fri, 21 Aug 2026 21:55:02 +0000

What happens when sales, purchasing, warehouse teams, and your online store all have different information about the same product? A supplier changes a specification, one spreadsheet gets updated, another system doesn't, and suddenly customers receive outdated information or employees order the wrong item. In https://www.m365.fm/dynamics-365-product-information-management-simply-explained/ of M365 FM, Mirko Peters explains how https://www.m365.fm/categories/power-platform-talk/ Product Information Management (PIM) creates a shared product definition across the business and manages products, product masters, variants, dimensions, configurations, categories, attributes, legal entities, and integrations.

WHAT IS DYNAMICS 365 PRODUCT INFORMATION MANAGEMENT?
Dynamics 365 Product Information Management provides a central place for defining and maintaining product information. Purchasing needs supplier information and units. Warehouse teams need accurate information for receiving, storing, and picking. Sales needs understandable product names. Finance needs the correct product setup, while commerce channels need descriptions, images, and specifications. Without a shared product definition, each department can create its own version of the same information. PIM provides the common product record those different business processes can use.

ONE PRODUCT RECORD ACROSS THE BUSINESS
Consider an insulated water bottle originally sold as a 500-milliliter product. The supplier changes it to 750 milliliters. Purchasing receives the new specification, but the online store still shows 500 milliliters. Sales sends customers an outdated specification sheet, while warehouse employees see labels that don't match their orders. Nobody intentionally created incorrect information. The problem is that different departments were working from different copies. Product Information Management creates one central product definition where agreed product information can be maintained and reused.

WHAT INFORMATION DOES A PRODUCT RECORD CONTAIN?
The product number provides a consistent identifier even when different teams use different terminology. The record can also contain names, descriptions, units, images, attachments, categories, attributes, and translations. Units are particularly important because organizations might buy, sell, store, or count products as pieces, boxes, kilograms, liters, or pallets. Attachments can provide supplier documents or specifications, while images help employees and customers recognize products. Translations allow the same underlying product to have appropriate names and descriptions for different languages and markets.

SIMPLE PRODUCTS VS PRODUCT MASTERS
Dynamics 365 distinguishes between a simple product and a product master. A simple product represents one fixed item without choices that create separate variants. A product master represents an entire family of related products. A pair of jeans provides a useful example. Customers might consider it one product, but a warehouse needs to distinguish blue medium jeans from black large jeans. The product master contains the shared information for the jeans range. Individual variants represent the exact products employees purchase, stock, sell, and ship.

PRODUCT VARIANTS EXPLAINED
A variant is a specific sellable or manageable version of a product master. Blue medium jeans can represent one variant. Black large jeans can represent another. Although both belong to the same product family, they're not interchangeable. Each variant can have different inventory availability, labels, barcodes, and operational requirements. The product master therefore acts as the parent definition while variants represent the individual members of that family.

PRODUCT DIMENSIONS
https://www.m365.fm/dynamics-365-supply-chain-management/ includes five product dimensions discussed in the episode: Color, Size, Style, Configuration, and Version. Color and size are straightforward examples for clothing. Style can distinguish variations such as regular fit and slim fit. Configuration can identify a particular build or setup, such as different equipment specifications. Version can distinguish engineering changes to a product over time. Organizations choose the dimensions appropriate for each product family rather than applying every dimension to every product.

PRODUCT DIMENSIONS VS PHYSICAL DIMENSIONS
Product dimensions shouldn't be confused with physical dimensions. Weight, height, width, length, and volume describe the physical characteristics of a product. They don't necessarily create another sellable variant. Product dimensions identify which specific variant somebody wants. Physical dimensions describe what that product is physically like. For warehouse operations, physical dimensions can help determine how much space something requires. For a customer ordering black jeans in size large, product dimensions identify the correct variant.

THREE WAYS TO CONFIGURE PRODUCT VARIANTS
Dynamics 365 Supply Chain Management supports three approaches covered in the episode: Predefined variants, dimension-based configuration, and constraint-based configuration. The appropriate method depends on whether the organization already knows every valid product combination or whether the final product is configured according to customer choices and business rules. Choosing the appropriate configuration model early is important because it shapes how the product family is managed afterward.

PREDEFINED VARIANTS
Predefined variants work well when the organization already knows which combinations it will sell. A retailer might sell jeans in several colors and sizes but not offer every mathematically possible combination. Instead of generating unnecessary variants, the business creates only the combinations that actually exist. This keeps the catalog cleaner and prevents somebody from ordering a combination the organization doesn't sell.

DIMENSION-BASED CONFIGURATION
Dimension-based configuration can be useful in manufacturing. Imagine a company producing industrial pumps where different configurations require different components. The organization can use a shared Bill of Materials while associating particular components with specific configurations. A pump requiring one voltage might need one motor, while another configuration requires a different motor. The configuration determines which relevant component lines should be used for the resulting product.

CONSTRAINT-BASED CONFIGURATION
Constraint-based configuration becomes useful when customers can select many options but not every combination is technically possible. A custom machine might provide choices for its housing, motor, voltage, safety equipment, and control panel. Some combinations work together. Others don't. A product configuration model defines available choices and the rules controlling them. The system can therefore prevent an impossible product configuration before the order reaches manufacturing.

CHOOSING THE RIGHT CONFIGURATION MODEL ㅤ The key question is: Does the business know every valid product combination before an order arrives, or does the customer create a valid product through a controlled set of choices? A retailer with a fixed clothing range probably doesn't require a sophisticated configurable-product model. A manufacturer producing made-to-order equipment might. The product configuration approach should follow the real purchasing, sales, and production process rather than simply choosing the most flexible technology available.

PRODUCT CATEGORIES
Categories provide structure around product information. Think of them like aisles inside a well-organized store. A company might organize products into clothing, tools, office supplies, or more specialized categories. One product can also participate in multiple categories when those categories serve different business requirements. Categories make products easier to find, organize, and manage while providing structure for related product information.

PRODUCT ATTRIBUTES
Attributes provide additional details describing a product. For a water bottle, attributes might include material, capacity, lid type, insulation, brand, and care instructions. For industrial equipment, attributes might describe physical dimensions, power requirements, temperature ranges, or technical standards. Categories can carry attributes appropriate for the products they contain. This gives organizations a structured way to capture useful product information rather than inventing unrelated fields for individual products.

IMAGES, ATTACHMENTS AND TRANSLATIONS
Product information isn't limited to structured fields. Images can help warehouse employees, salespeople, and customers recognize an item. Attachments can contain supplier documentation, specifications, and other supporting information. Translations allow product names and descriptions to be presented appropriately across different languages while retaining the same underlying product definition. Together, these capabilities make the product record a richer source of information than a simple item number and description.

CONTROLLING ACCESS TO PRODUCT DATA
Not every employee should be allowed to modify every product record. Changes to product names, specifications, categories, or other information can affect multiple downstream teams and systems. Dynamics 365 can apply product-data access rules at category or individual-product level. Different teams can therefore manage the product areas for which they're responsible while sensitive or restricted products can receive tighter controls.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Dynamics 365 Master Planning - Simply Explained

Fri, 21 Aug 2026 20:55:02 +0000

A customer wants 100 bicycles next month. You already have some finished bicycles in stock, wheels are arriving from a supplier, frames are stored somewhere else, and your production line is booked for the next two weeks. What should you buy, what should you build, what should you move—and when does each action need to happen? In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Master Planning connects customer demand, inventory, purchasing, production, bills of materials, lead times, capacity, forecasts, and planned orders to create one connected supply plan.

WHAT IS DYNAMICS 365 MASTER PLANNING?
Dynamics 365 Master Planning is the part of Supply Chain Management that determines how future demand should be covered. Think of your business as an office building with a stockroom attached. Customer orders enter through one door. Inventory sits on shelves. Suppliers deliver materials. Production converts components into finished products. Master Planning looks across all of these activities instead of allowing each team to maintain its own disconnected plan. It combines current demand and available or expected supply, identifies shortages, and suggests actions for planners to review.

WHY A STOCK COUNT ISN'T ENOUGH
Imagine a customer orders 100 bicycles and your warehouse currently contains 30. You still need 70. But those 70 bicycles require frames, wheels, chains, seats, bolts, packaging, employees, machines, and enough production time. A simple inventory report tells you what exists now. It doesn't tell you whether the missing components can arrive before production needs them or whether the factory has enough time to complete the order. Master Planning connects quantity with time.

FROM SPREADSHEETS TO CONNECTED PLANNING
Without connected planning, sales might maintain customer orders in one system while warehouse employees check inventory somewhere else. Purchasing tracks supplier dates in spreadsheets and emails. Production maintains another schedule describing what the factory can build. Each individual list might be correct, but somebody still needs to connect everything to answer one question: Can we deliver what the customer ordered by the promised date? Dynamics 365 Master Planning brings these demand and supply signals together.

MASTER PLANNING VS A SPREADSHEET
Think of a spreadsheet as a photograph. It can provide a useful snapshot of inventory at a particular moment. Master Planning is closer to a forward-looking schedule. It considers quantities alongside dates, future demand, incoming supply, production requirements, and existing inventory. When one of those elements changes, the planning picture can change as well.

THE THREE PLANNING MODES
Dynamics 365 doesn't provide only one way to plan. The episode explains three different planning scenarios: Master Planning focuses on day-to-day and shorter-term requirements. Forecast Planning looks at expected future demand. Intercompany Master Planning connects demand and supply requirements between legal entities. Each starts with demand but answers a different planning question.

MASTER PLANNING AND NET REQUIREMENTS
Master Planning calculates net requirements. The basic concept is straightforward: Demand – Available or Expected Supply = Remaining Requirement Suppose a customer orders 100 units and the warehouse has 30 available. The remaining requirement is 70. If another 20 units are already scheduled to arrive from a supplier before the customer's required date, the uncovered requirement becomes smaller again. Dynamics 365 therefore doesn't simply suggest purchasing or producing the complete customer quantity. It considers supply that already exists or is expected to arrive.

WHY DATES CHANGE THE ANSWER
Having enough inventory eventually isn't the same as having enough inventory when it's required. Suppose 20 additional bicycles arrive from a supplier. If they arrive before the customer needs them, they can help satisfy the demand. If they arrive afterward, they don't solve this particular shortage. Master Planning therefore considers quantity and timing together. A total inventory number without dates can provide a misleading picture of whether customer demand can actually be fulfilled.

THE PLANNING HORIZON
The appropriate planning horizon depends on the business. A company purchasing simple products locally might only need to look several weeks ahead. A manufacturer using components with long supplier lead times may need to plan months ahead. The important principle is that planning needs to look far enough forward to identify shortages while there is still time to respond. Discovering a shortage after the required purchasing or production date has already passed provides very little value.

FORECAST PLANNING
Forecast Planning begins with expected demand rather than confirmed customer orders. A bicycle manufacturer might expect demand to increase during summer. A retailer might anticipate significantly higher sales during a promotion. Waiting until every customer order arrives could leave insufficient time to purchase materials or reserve production capacity. Forecast Planning gives organizations an earlier view of the workload they expect to face.

GROSS REQUIREMENTS
Forecast Planning calculates gross requirements based on expected demand. If the forecast predicts demand for 500 bicycles in July, planning begins with that expected requirement. The organization can then consider the materials, supplier capacity, warehouse space, and production resources potentially required to support that volume. Forecasts aren't guaranteed customer orders. They provide a planning signal allowing the business to prepare before confirmed demand arrives.

INTERCOMPANY MASTER PLANNING
Large organizations may operate several legal entities. One company might manufacture a product while another sells that product in another country. The selling company sees customer demand. The manufacturing company needs visibility into the supply requirements created by that demand. Intercompany Master Planning carries planning signals across company boundaries so each legal entity doesn't plan as though it operates completely independently.

FROM ONE ORDER TO A CHAIN OF SUPPLY
A finished product can create demand for many lower-level components. Suppose a customer orders 70 bicycles. Dynamics 365 can examine the structure of the finished bicycle and determine which components are required to produce those 70 units. That might create requirements for 70 frames, 140 wheels, 70 chains, 70 seats, and hundreds of smaller components. This is where the Bill of Materials becomes critical.

BILL OF MATERIALS EXPLAINED
A Bill of Materials, commonly called a BOM, is essentially the recipe for a manufactured product. For a bicycle, it identifies the frames, wheels, chains, seats, handlebars, brakes, bolts, and other components required for production. Master Planning can expand demand for the finished product into requirements for the components underneath it. Planners therefore don't need to manually calculate every component requirement whenever customer demand changes.

PRODUCTION ROUTES
Having every component available still doesn't automatically create a finished product. Production requires work. A route describes the steps required to manufacture the item. For a bicycle, those steps might include assembling the frame, installing wheels, checking brakes, and packing the finished product. Each operation can require resources such as employees, assembly lines, workbenches, machines, or specialized equipment.

PLANNING BACKWARD FROM THE CUSTOMER DATE
Suppose the customer needs the bicycles on Friday. Production might need to finish Thursday so the warehouse has time to prepare the shipment. Assembly might therefore need to begin Tuesday. Components might need to be available Monday. If a supplier requires ten days to deliver wheels, the purchase order must be placed considerably earlier. The customer delivery date therefore creates a chain of dependent dates stretching backward through production and purchasing.

LEAD TIMES
A lead time represents how long an activity takes. A supplier might require ten days to deliver components. A warehouse transfer could require two days. A production process might require three days. Master Planning uses these lead times when calculating when supply needs to become available. Incorrect lead times can therefore produce incorrect planning suggestions even when the planning calculation itself works perfectly.

PLANNED ORDERS
When existing supply can't cover demand, Dynamics 365 can create a planned order. A planned purchase order suggests buying something from a supplier. A planned production order suggests manufacturing something internally. A planned transfer order suggests moving inventory from another site or warehouse. These planned orders contain suggested quantities and dates based on the information available to the planning engine.

PLANNED ORDERS ARE SUGGESTIONS
A planned order isn't automatically a commitment. Dynamics 365 doesn't need to silently send a purchase order to the supplier or begin production simply because the planning calculation identified a shortage. The planner reviews the suggestion. Is the proposed supplier appropriate? Is the delivery date realistic? Does the quantity make sense? Can production actually handle the work? Master Planning provides the recommendation while the planner remains responsible for the decision.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Dynamics 365 Intelligent Order Management - Simply Explained

Fri, 21 Aug 2026 19:45:02 +0000

Orders arrive from websites, stores, marketplaces and call centers, while stock sits in many places, and manual handoffs lead to overselling and vague delivery promises. This episode explains for business and IT teams how Dynamics 365 Intelligent Order Management coordinates that journey with orchestration flows, inventory visibility, fulfillment optimization and providers. You will see how one order travels from checkout to billing.

In this episode

00:00 – Why orders become messy
02:50 – The plain English definition
05:17 – The order journey and orchestration flows
10:00 – Inventory visibility
12:21 – Fulfillment optimization
15:17 – Providers and connections
17:03 – Insights and the bigger picture

Key takeaways

Dynamics 365 Intelligent Order Management is a Dataverse-based coordinator that directs orders across existing sales, warehouse, shipping and billing systems instead of replacing them.
Orchestration flows with validation, conditions, splitters and custom actions define the route, while inventory visibility and fulfillment optimization decide where an order ships from.
First-party and third-party providers built on Power Automate connectors move order and fulfillment data both ways, and Power BI dashboards show where orders get stuck.

Worth quoting

“Intelligent Order Management doesn't take over every job. It doesn't suddenly become the warehouse workers picking screen, the carriers delivery network, or the finance team's billing system.” – Mirko Peters (04:58)

“If it goes straight to a warehouse and then to a carrier, someone might only spot the problem after a package can't be delivered. A validation step catches the issue earlier, while there's still time to contact the customer or hold the order.” – Mirko Peters (06:09)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on order orchestration
Dynamics 365 – the app family Intelligent Order Management belongs to and connects with through first-party providers
Dataverse – the shared data foundation Microsoft built Intelligent Order Management on
Power Platform – shares Dataverse with Dynamics 365 and supplies the pre-built connectors behind providers
Related episode: Dynamics 365 Dataverse Integration - Simply Explained

Dynamics 365 Business Central Extensions - Simply Explained

Fri, 21 Aug 2026 18:20:02 +0000

Business Central covers most core processes, but every company has gaps such as special shipping, local reports or bank integrations. This Simply Explained episode is for Business Central users, finance teams and admins who decide which add-ons to install. It explains the types of extensions and what to check on security, data and support before an app becomes part of daily work.

In this episode

00:00 – Why Business Central needs add-ons
00:37 – What an extension actually is
03:58 – The main types of extensions
07:29 – How extensions change your daily work
11:40 – Finding and installing apps
15:05 – Security, data and update questions
18:15 – Conclusion: choose the right add-on

Key takeaways

Business Central extensions add fields, pages, reports, permissions and integrations in their own package, so the standard application stays intact and updates cause less repair work.
Use Microsoft or ISV apps from AppSource for common needs and per-tenant extensions only for processes unique to your company, with a clear owner for support and testing.
Before installing, check publisher, supported versions, pricing, documentation, data flows and permissions, test real cases in a sandbox, and keep a record of every installed extension.

Worth quoting

“standard Business Central already handles a huge amount of normal business work, so extensions should fill a real gap, not become an excuse to rebuild every screen just because the old system looked different.” – Mirko Peters (03:33)

“But custom doesn't always mean better. A per tenant extension gives you a close fit, but someone has to own it. That means keeping notes, testing changes, and arranging support when your company changes the process” – Mirko Peters (06:38)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on choosing extensions
Dynamics 365 Business Central – the standard application that extensions add fields, pages, reports and integrations to without changing its code
Microsoft AppSource – the marketplace to search for Microsoft and ISV apps and check publisher, pricing and reviews
Related episode: Dynamics 365 Business Central AL Development

Dynamics 365 Procurement and Sourcing - Simply Explained

Fri, 21 Aug 2026 17:15:02 +0000

Purchasing often runs through emails, spreadsheets and paper delivery notes, so nobody can say who approved a purchase or whether an invoice is right. This episode explains for beginners how Dynamics 365 Procurement and Sourcing connects requests, vendors, purchase orders, receipts, invoice matching and payment into one traceable process.

In this episode

00:00 – Introduction
00:35 – What procurement and sourcing covers
03:15 – From internal request to the right vendor
06:59 – The purchase order
11:00 – Receiving goods and checking the invoice
15:05 – Controls, visibility and better vendor decisions
18:25 – Conclusion: one connected record

Key takeaways

Sourcing chooses the right vendor, while procurement manages the request, approval, purchase order, receipt, invoice and payment in one source-to-pay process.
In Dynamics 365 Supply Chain Management a purchase starts as a requisition, can go through an RFQ and becomes a purchase order backed by vendor records, agreements and approval workflows.
Product receipts and three-way matching against the purchase order and invoice catch differences before payment, and the connected record enables spend analysis, vendor evaluation and a full audit trail.

Worth quoting

“Procurement and sourcing might sound like a long name for buying things, and it is about buying, but the two words describe different jobs. Sourcing is the work of finding and choosing the right vendor.” – Mirko Peters (00:37)

“A purchase requisition is an internal request to buy something. It tells the company what a person needs, how much, and often where it should go. Notice that this request doesn't promise anything to a vendor yet.” – Mirko Peters (03:34)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on source to pay
Dynamics 365 – the platform where procurement and sourcing lives in Supply Chain Management, linked to accounts payable
Mirko Peters – hosts this episode and follows one safety equipment purchase from request to payment
Related episode: Dynamics 365 Product Information Management - Simply Explained
Related episode: Dynamics 365 Knowledge Management - Simply Explained

Dynamics 365 Accounts Receivable - Simply Explained

Fri, 21 Aug 2026 16:45:02 +0000

You made the sale and sent the invoice, but when does the money actually arrive, and what happens if it doesn't? This plain-English episode is for finance teams, consultants and business users who want to understand Dynamics 365 Accounts Receivable. Follow one customer balance from invoice to payment, credit checks and collections.

In this episode

00:00 – What accounts receivable is
00:35 – The customer account: payment terms, credit limits and posting profiles
03:31 – Creating the invoice: sales orders, free text invoices and subscription billing
06:58 – Receiving and matching payments: settlement and reconciliation
10:33 – Credit management: deciding when to keep selling
12:58 – Collections and disputes
15:54 – One invoice, one connected process
17:20 – Conclusion: keeping money inside under control

Key takeaways

Accounts receivable in Dynamics 365 Finance tracks what customers owe from the first invoice until the balance closes, using the rules stored on the customer account.
A payment only closes an invoice once it is settled against it; partial payments, payment reconciliation journals and centralized payments keep the open balance accurate.
Credit holds, collection lists, promises to pay, disputes and aging reports help finance and sales act on risk early without treating customers as case numbers.

Worth quoting

“Accounts receivable tracks the money customers owe you along with the payments that come back. Think of it as a filing cabinet for the money inside of your business.” – Mirko Peters (00:24)

“A contact list helps you call someone. A customer account records the financial relationship, including the rules that control what happens when the company sells to them.” – Mirko Peters (03:19)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on accounts receivable
Dynamics 365 Finance and Operations – the application behind the customer accounts, invoices, settlement and collections described here
Dynamics 365 – the platform that keeps sales orders, invoices, payments and collection work tied to one customer
Mirko Peters – hosts this Microsoft Knowledge Nuggets episode and walks through the Northwind Equipment example
Related episode: Dynamics 365 Virtual Entities - Simply Explained

Dynamics 365 Warehouse Management - Simply Explained

Fri, 21 Aug 2026 15:35:02 +0000

A spreadsheet can tell you that 50 units exist somewhere, but it cannot guide a worker to the right shelf. This episode explains Dynamics 365 Warehouse Management in plain English for operations teams, consultants and business users. Learn how receiving, put-away, picking, counting and shipping connect to the rest of the business.

In this episode

00:00 – Introduction: the digital guide on the warehouse floor
00:35 – Why warehouse management exists
02:53 – The warehouse map: sites, warehouses, locations and stock details
05:46 – Inbound work: from delivery truck to the right shelf
09:14 – Outbound work: waves, picking, packing and shipping
12:41 – Daily control: moving, counting, returns and labels
15:34 – One connected platform
17:52 – Conclusion

Key takeaways

Inventory management records how much stock the business owns, while Warehouse Management in Dynamics 365 knows exactly where it sits and what workers should do with it next.
Location directives, work templates and waves turn warehouse rules into step-by-step tasks that workers confirm with scans on mobile devices.
Because warehouse work runs inside Dynamics 365 Supply Chain Management, purchasing, sales, production, quality and finance all see the same stock picture.

Worth quoting

“So think of inventory management as the stock record. Warehouse management turns that record into guided physical work.” – Mirko Peters (02:44)

“Quarantine means the goods remain physically in the building, but workers can't use or ship them as normal stock.” – Mirko Peters (06:52)

Explore more on M365.FM

Episode page: the full episode with chapters, plain-English definitions and a short FAQ
Dynamics 365 – the platform where Warehouse Management runs inside Supply Chain Management, sharing one stock record
Power BI – mentioned briefly as the reporting tool that can use the connected warehouse data
Related episode: Dynamics 365 Case Management - Simply Explained
Related episode: Dynamics 365 Dataverse Integration - Simply Explained

Dynamics 365 Transportation Management - Simply Explained

Fri, 21 Aug 2026 14:15:00 +0000

Orders, warehouse work, carriers and freight bills often live in separate spreadsheets, emails and phone calls, and that is where delays and surprise charges start. This episode is for supply chain, logistics and Dynamics 365 teams who want to understand Transportation Management from the ground up. You will learn how loads, routes, rates and freight reconciliation connect one planned movement of goods from order to invoice.

In this episode

00:00 – Why goods, orders and freight bills drift apart
00:50 – Inbound, outbound and transfer order transportation
03:50 – Planning loads with load templates
07:50 – Carriers, routes, rates and the rate route workbench
11:20 – From warehouse door to customer door
14:50 – Freight costs and reconciliation
17:00 – Where Transportation Management fits and what it does not do

Key takeaways

Dynamics 365 Transportation Management is the transportation desk inside Dynamics 365 Supply Chain Management, turning sales, purchase and transfer orders into planned movements of goods.
Loads, load templates, routes and rate tables let planners group compatible shipments, respect vehicle limits and compare carrier services against delivery promises and cost.
Freight reconciliation compares carrier invoices with the expected charge before payment, while live multi-carrier rate shopping or Business Central scenarios need a third-party transportation management system.

Worth quoting

“A load is the digital record for a planned movement of goods. You can picture it as one truck, one trailer, one container, or one collection of shipments that travel together.” – Mirko Peters (04:39)

Explore more on M365.FM

Episode page: the full episode with chapters, key definitions and a short FAQ on transport planning
Dynamics 365 – the platform whose Supply Chain Management app contains the Transportation Management module
Dynamics 365 Business Central – does not include the built-in module, so transport planning there needs a third-party TMS
Dynamics 365 Finance and Operations – the finance and operations apps that Supply Chain Management and Transportation Management run on
Related episode: Dynamics 365 Copilot - Simply Explained

Extending Microsoft 365 Copilot: Agents, MCP & Production-Grade AI with Yves Habersaat [MVP]

Fri, 21 Aug 2026 10:00:27 +0000

Once organizations use Copilot seriously, the question shifts from writing better prompts to connecting Copilot with business data, APIs and processes. In this conversation, Microsoft MVP Yves Habersaat explains Copilot extensibility, agent architecture, MCP, RAG and permissions for architects, developers and IT decision-makers. Learn when to use Copilot Studio, Microsoft Foundry or custom code and how to build production-grade agents securely.

In this episode

00:00 – Introduction: beyond prompt engineering
01:30 – Yves' journey and why prompt engineering is not enough
08:26 – Where Copilot ends and extensibility begins: agents and multi-agent design
17:48 – Copilot Studio, Microsoft Foundry and custom development
24:22 – Model Context Protocol (MCP) versus APIs
34:40 – Data, governance and user versus application permissions
40:17 – RAG, knowledge sources and the semantic index
48:43 – Agent lifecycle, AI readiness, trust and rapid-fire round

Key takeaways

Prompt engineering alone is not enough: organizations still need architects and specialists who understand the customer, the data and the underlying technologies.
Yves recommends a multi-agent approach with clearly scoped agents, Copilot Studio for low-code needs and custom development when the orchestration or models must be customized.
MCP servers sit in front of existing APIs, while delegated user permissions, clean and classified data, and transparent logging keep enterprise agents secure and trustworthy.

Worth quoting

“But nowadays, it's better to have a multi-agent approach where each agent has a scope and is responsibility” – Yves Habersaat (11:35)

Explore more on M365.FM

Episode page: the full conversation with chapters, guest quotes and an FAQ on Copilot extensibility
Yves Habersaat – Microsoft MVP and AI architect in Switzerland who explains agent architecture, MCP and permissions
Model Context Protocol (MCP) – the protocol Yves recommends for agent tools, sitting in front of existing APIs, not replacing them
AI agent – the core subject: scoped agents in a multi-agent design with a front agent routing requests
Related episode: Microsoft Foundry Agent Service - Simply Explained

GitHub Copilot, Clean Context, Automated Testing & AI Coding Agents with Lars Gyrup Brink Nielsen [MVP]

Thu, 20 Aug 2026 15:20:02 +0000

Related M365.FM resources: For more on AI coding agents and clean repository context, see https://www.m365.fm/blog/copilot-not-responding-troubleshooting-guide-for-microsoft-users/ and https://www.m365.fm/the-monorepo-myth-why-your-architecture-is-fragmented/. For Microsoft AI agent architecture and https://www.m365.fm/categories/copilot-talk/ extensibility, see https://www.m365.fm/understanding-microsoft-copilot-enterprise-architecture/ and https://www.m365.fm/copilot-studio-vs-azure-ai-foundry-pick-your-poison/.

AI-assisted development is moving beyond autocomplete and chat. Modern AI coding agents can inspect repositories, modify files, run tests, analyze failures, create pull requests, and execute increasingly complex development tasks. In https://www.m365.fm/lars-gyrup-brink-nielsen/ of the M365 FM Podcast, Mirko Peters talks with Microsoft MVP Lars Gyrup Brink Nielsen about https://www.m365.fm/github-copilot-simply-explained/, AI coding agents, developer experience, automated testing, TypeScript, JavaScript, Nx, monorepos, Polygraph, https://www.m365.fm/github-actions-simply-explained/, Playwright, and the architectural foundations required to make agentic software engineering work at enterprise scale.

FROM AI ASSISTANCE TO AI CODING AGENTS
For the last few years, AI development tools have primarily helped developers generate code, autocomplete functions, answer technical questions, and accelerate individual programming tasks. Agentic engineering changes that model. AI coding agents can potentially inspect an existing repository, understand an issue, modify multiple files, run automated tests, analyze failures, make corrections, and prepare a pull request. That changes the central question from "Can AI generate code?" to "Can AI safely perform engineering work inside a real software architecture?"

MEET LARS GYRUP BRINK NIELSEN
Lars Gyrup Brink Nielsen is a Microsoft MVP in Developer Technologies, author, international speaker, tech writer, open-source maintainer, community organizer, and former GitHub Star. His experience spans frontend development, cloud-native systems, developer experience, automated testing, continuous delivery, deployment, and open-source software. He has also worked with GitHub Copilot since its early days and has spent more than a year experimenting with AI coding agents in open-source development.

WHY DEVELOPER EXPERIENCE MATTERS
Developer experience is fundamentally about removing friction from software development. That includes choosing and integrating development frameworks, testing tools, build systems, CI pipelines, documentation, reusable packages, development environments, architectural standards, and automation. Lars contrasts modern developer tooling with earlier workflows involving FTP deployments, directly editing production systems, shared ZIP files, and environments without proper source control. Modern developer experience replaces these fragile processes with repeatable, automated, and verifiable workflows.

ARCHITECTURE SHOULD BE ENFORCED
Documentation alone isn't enough for large software architectures. Lars explains how tooling such as Nx can attach metadata to projects and enforce architectural boundaries. Organizations can define which types of projects may depend on other projects and use linting rules to automatically detect violations. Generators can also scaffold components, services, projects, tests, and configurations according to organizational standards. This becomes particularly important with AI coding agents. Instead of expecting an agent to remember every architectural rule, organizations can make those rules automatically enforceable.

MONOREPOS EXPLAINED
A monorepo stores multiple projects or systems inside a shared source-control repository. Microservices and micro-frontends don't necessarily require separate repositories. They can exist within one monorepo while still being independently built and deployed. The advantage is that dependencies between projects become easier to understand and changes spanning multiple systems can be tested together. However, Lars also explains that moving hundreds or thousands of developers from established repositories into one monorepo can be extremely difficult organizationally.

MONOREPO VS MULTIPLE REPOSITORIES
Separate repositories don't eliminate dependencies between teams. They simply manage those dependencies differently. When two teams maintain dependent systems in different repositories, changes can require coordination, separate environments, cross-repository testing, and synchronized deployments. A monorepo can make those dependencies more visible because the relevant source code exists within the same repository. The larger challenge is often organizational rather than technical: teams still need to communicate, coordinate ownership, and manage dependencies regardless of repository strategy.

WHAT IS NX?
Nx is a development toolchain that helps teams manage complex codebases, project dependencies, tasks, testing, builds, linting, generators, and development workflows. Lars explains how Nx has evolved beyond its earlier JavaScript-focused roots. It can integrate development tools, automate migrations, understand project relationships, orchestrate tasks, and support multiple technologies. It can also determine which projects are actually affected by a change rather than unnecessarily rebuilding or retesting an entire large codebase.

CACHING CAN DRAMATICALLY ACCELERATE DEVELOPMENT
Large codebases can contain hundreds of projects and enormous test suites. Repeatedly running every build, test, linting operation, and compilation task wastes significant developer and CI time. Nx can cache task results. If the relevant source files and dependencies haven't changed, developers can reuse previous results instead of executing the same work again. Remote caching can also allow teams and CI systems to share those results. For https://www.m365.fm/ai-agents-simply-explained/, faster verification becomes especially valuable because an agent may repeatedly modify, test, inspect, and correct code during a single task.

POLYGRAPH AND MULTI-REPOSITORY AI AGENTS

Not every enterprise can move hundreds of existing repositories into a monorepo. Lars discusses Polygraph as a newer approach for helping AI coding agents operate across multiple related repositories. Instead of an AI coding session being isolated to one repository, Polygraph can provide a harness around multiple repositories and their dependencies. This can allow an agent to work across frontend, backend, microservice, and other repositories during the same development task and potentially prepare coordinated pull requests across those systems.

GITHUB ACTIONS AND CONTINUOUS INTEGRATION
Automation is a major part of the development environment discussed throughout the episode. GitHub Actions can provide the CI foundation for building, testing, validating, and deploying changes. Nx can work alongside CI workflows and delegate tasks through its own cloud capabilities. During the rapid-fire round, Lars gives GitHub Actions a particularly strong endorsement, calling it the best CI system.

PLAYWRIGHT FOR AUTOMATED TESTING
Automated verification becomes more important as AI writes a larger percentage of software. When asked to choose between Playwright and Cypress during the rapid-fire round, Lars chooses Playwright. The broader point is significant for agentic development: organizations need reliable automated feedback loops. If an agent changes code, it needs tools capable of determining whether those changes still satisfy the expected behavior.ㅤ

GITHUB COPILOT AND THE AGENTIC SHIFT
Lars was an early GitHub Copilot user through his involvement with the GitHub Stars program and provided feedback during Copilot's earlier development. His development workflow has now moved significantly beyond traditional Copilot autocomplete. He explains that he rarely writes code manually anymore and instead instructs coding agents to perform much of the implementation work. The challenge increasingly becomes reviewing and ensuring the quality of the code produced by those agents.

CONTEXT IS THE NEW ENGINEERING PROBLEM
An AI model may understand TypeScript, JavaScript, Angular, React, .NET, testing frameworks, and popular development tools from its training. What it doesn't automatically understand is your organization. Every large software environment contains internal naming conventions, architectural decisions, team standards, project-specific rules, historical constraints, and unique development practices. Those rules need to become accessible to AI agents through mechanisms such as agent instructions, skills, automated checks, architectural boundaries, and repository-specific context.

CLEAN CONTEXT FOR AI CODING AGENTS
Giving an AI agent more information isn't automatically better. Large repositories can contain enormous amounts of source code, documentation, configuration, legacy decisions, and irrelevant files. The challenge is providing the agent with the information required for its current task without overwhelming its working context. Development tooling, dependency graphs, repository structures, project metadata, agent instructions, and automated validation can help narrow that context. The objective is to give agents enough information to make architecturally correct decisions rather than merely locally correct code changes.

CODIFY YOUR TEAM STANDARDS FOR AI
Organizations don't necessarily need to fine-tune an AI model on their complete private codebase. Lars points instead toward codifying te

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Dynamics 365 Asset Management - Simply Explained

Thu, 20 Aug 2026 14:19:51 +0000

Related M365.FM resources: To explore connected https://www.m365.fm/categories/dynamics-talk/ capabilities, see https://www.m365.fm/dynamics-365-supply-chain-management-simply-explained/, https://www.m365.fm/dynamics-365-inventory-management-simply-explained/, and https://www.m365.fm/dynamics-365-finance-simply-explained/.

A conveyor stops in the middle of a shift, a forklift won't start, or a pump suddenly begins leaking. Before anyone can repair the equipment, the business needs answers: Who is responsible? When was it last serviced? Which parts are required? What happened during the previous repair? Dynamics 365 Asset Management provides one central place for this information. In https://www.m365.fm/dynamics-365-asset-management-simply-explained/ of M365 FM, Mirko Peters explains how Dynamics 365 Asset Management helps organizations track physical equipment, preventive maintenance, work orders, spare parts, costs, service history, functional locations, condition-based maintenance, and connected maintenance processes.

WHAT IS DYNAMICS 365 ASSET MANAGEMENT?
Dynamics 365 Asset Management is part of https://www.m365.fm/dynamics-365-supply-chain-management/ and focuses on the physical equipment businesses rely on every day. That could include production machines, conveyor belts, motors, pumps, forklifts, trucks, generators, heating and cooling systems, and other equipment requiring regular inspection, servicing, or repair. Instead of maintenance information being distributed across spreadsheets, folders, emails, invoices, and individual employees' knowledge, Asset Management creates a shared record around the equipment and its maintenance history.

WHY PHYSICAL ASSETS BECOME A BUSINESS PROBLEM
A machine doesn't only affect the maintenance department. When equipment fails, operations can lose production capacity, maintenance teams need to diagnose the fault, purchasing may need to urgently source replacement parts, and finance eventually receives the resulting costs. Emergency maintenance can become particularly expensive because organizations may need expedited shipping, urgent purchasing, overtime, or temporary workarounds. Dynamics 365 Asset Management connects these different parts of the maintenance story so teams can understand what happened and why money was spent. ㅤ

THE ASSET RECORD
Every piece of equipment can have its own digital asset record. The record can contain information such as the asset name, product or model number, serial number, description, technical details, and warranty information. This becomes particularly useful when several machines look almost identical but use different components, have different warranty periods, or require different maintenance procedures. Instead of relying on somebody remembering which machine is which, the asset record provides a consistent reference point.

FUNCTIONAL LOCATIONS EXPLAINED
Dynamics 365 Asset Management uses functional locations to describe where equipment performs its job. A functional location can represent a site, building, warehouse, workshop, production line, or another operational location. These locations can also form hierarchies. For example, an organization might have a plant containing a packing area, which contains a conveyor line, which contains individual motors, sensors, and rollers. When a motor fails, technicians therefore don't simply see a serial number. They can understand exactly where that motor operates and which wider process could be affected.

PARENT AND CHILD ASSET STRUCTURES
Complex equipment frequently consists of smaller components that need their own maintenance history. Dynamics 365 can represent parent-and-child relationships between equipment and components. A conveyor can contain a motor, while the motor itself might contain another component requiring individual maintenance attention. This structure helps maintenance teams understand how individual assets relate to larger equipment and operational systems. ㅤ

TRACKING EQUIPMENT AS IT MOVES
Physical equipment doesn't necessarily remain in the same location forever. Forklifts can move between warehouses. Pumps can move from storage into buildings. Machines can be reassigned between production lines. Asset Management can track these movements through functional locations. This also matters financially because maintenance costs can follow the equipment to the location currently using it. Managers can therefore understand which plant, department, or operational area is responsible for the costs associated with an asset.

BUILDING A COMPLETE SERVICE HISTORY
The real value of an asset record grows over time. Inspections, repairs, replaced parts, technician notes, labor time, faults, downtime, and other maintenance information can become part of the equipment's history. A technician investigating a recurring problem can review previous repairs instead of starting from zero. The history might reveal that the same motor has been repaired several times, that a particular component repeatedly fails, or that an earlier technician identified something that needs additional monitoring.

ASSET MANAGEMENT VS IT ASSET MANAGEMENT
Dynamics 365 Asset Management focuses on physical operational equipment requiring maintenance, inspections, servicing, and repair. It isn't primarily designed for tracking office laptops, smartphones, or software licenses. Production machinery, vehicles, pumps, motors, building equipment, and similar physical assets create a different maintenance requirement because downtime, replacement parts, labor, inspections, and equipment condition all need to be managed over time.

REACTIVE VS PREVENTIVE MAINTENANCE
Reactive maintenance begins after something fails. The equipment stops, operations are affected, and the maintenance team needs to restore service as quickly as possible. Preventive maintenance attempts to perform appropriate maintenance before a small problem becomes an unexpected failure. Dynamics 365 Asset Management helps organizations plan recurring inspections, cleaning, lubrication, safety checks, testing, and replacement of components that wear out over time.

MAINTENANCE PLANS
Maintenance plans help organizations turn preventive maintenance into repeatable work. A forklift might require regular inspections of its brakes, tires, fluid levels, lights, and battery condition. A production line might require weekly sensor cleaning, monthly belt inspections, and component replacement after a particular amount of use. These tasks aren't dramatic individually, but performing them consistently can reduce the likelihood of equipment failing during critical operations.

MAINTENANCE BASED ON EQUIPMENT USAGE
Calendar schedules aren't always enough. Two identical machines might have very different workloads. One could operate for a single shift every day while another operates continuously. Technical readings such as running hours, distance traveled, temperature, pressure, or other measurements can provide additional information about when maintenance should occur. This allows organizations to combine scheduled maintenance with the actual usage and condition of equipment.

MAINTENANCE ROUNDS
Maintenance rounds provide technicians with planned routes or groups of inspections across multiple assets. Instead of treating every inspection as a separate activity, a technician can inspect related equipment during one routine visit. For example, someone could walk through a packing area checking several conveyor motors, listening for unusual sounds, inspecting fittings, and recording relevant technical readings. This creates a more consistent inspection process even when different technicians perform the work.

CONDITION-BASED MAINTENANCE
Condition-based maintenance uses equipment measurements to identify when something may require attention. Imagine vibration readings from a conveyor motor gradually increasing over several weeks. The motor still operates, but the changing measurement indicates that something may be developing. When a reading crosses a threshold established by the organization, the maintenance team can investigate before the equipment necessarily fails. The objective isn't to perfectly predict every breakdown. It is to provide earlier warning and give maintenance teams more time to respond.

FROM MAINTENANCE NEED TO WORK ORDER
When maintenance becomes actual work, Dynamics 365 uses a work order. The work order acts as the job ticket connecting the problem, required activities, responsible workers, schedule, parts, safety instructions, labor, costs, and final outcome. Work orders can originate from scheduled maintenance, inspections, equipment breakdowns, or follow-up work identified by technicians. Regardless of the source, the work order turns a maintenance requirement into something that can be assigned, scheduled, tracked, completed, and reviewed.

PLANNING THE MAINTENANCE JOB
A work order can describe the job and the tasks required to complete it. For a conveyor motor showing unusual vibration, technicians might need to isolate the equipment, inspect the mounting, check bearings, complete the repair, test the machine, and return it to service. Checklists can help technicians perform required activities in the correct sequence. Safety instructions can also be associated with the work so requirements such as power isolation, protective equipment, or stopping moving equipment are visible during the job.

SPARE PARTS AND INVENTORY
Maintenance work frequently depends on replacement parts. A work order can identify required items such as bearings, filters, bolts, grease, or replacement motors.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Dynamics 365 Dataverse Integration - Simply Explained

Thu, 20 Aug 2026 09:30:03 +0000

When the same customer lives in five spreadsheets and tools, nobody knows which copy to trust. This episode is for business users, makers and Dynamics 365 teams who want to understand what Dataverse is and how Dynamics 365 actually uses it. You will learn how tables, security and rules form one shared foundation that Power Apps, Power Automate and Power BI can build on without extra copies.

In this episode

00:00 – What Dataverse is
00:36 – One shared place instead of separate copies
04:00 – Tables, rows, columns and relationships
08:17 – Identity, security roles and business rules
11:52 – What Dynamics 365 integration with Dataverse really means
16:40 – Power Automate, Power BI, Power Apps and Power Query on the same data
20:10 – When Dataverse fits and what it does not replace

Key takeaways

Dynamics 365 Sales and Customer Service already store their data in Dataverse, so integration is mostly about shared tables and access rather than syncing two systems.
Dataverse organizes business data in standard and custom tables with rows, columns and relationships, protected by Entra ID identity, security roles, column-level security, business units and business rules.
Power Apps, Power Automate and Power BI can work on the same Dataverse rows, while Excel, SharePoint lists and SQL remain better fits for personal analysis, simple tracking or deep developer control.

Worth quoting

“In plain English, dataverse is Microsoft's cloud data platform for business information. It stores that information, in structured tables. So the data has a clear shape, instead of living as random notes, loose files, and disconnected spreadsheet tabs.” – Mirko Peters (01:58)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Dataverse basics
Dataverse – the shared data foundation whose tables, security and business rules this episode explains
Dynamics 365 – its apps already store and secure their data in Dataverse, so no separate sync is needed
Dynamics 365 Sales – the example app where a salesperson creates a customer that support then sees
Related episode: Dynamics 365 Copilot - Simply Explained

Dynamics 365 Inventory Management - Simply Explained

Thu, 20 Aug 2026 06:10:02 +0000

When purchasing, warehouse, sales and finance each keep their own stock numbers, nobody can say how much inventory the business really has. In this Knowledge Nugget, Mirko Peters walks operations and finance teams through how Dynamics 365 Inventory Management tracks every item from supplier receipt to customer shipment, including the money attached to it.

In this episode

00:00 – Intro: the stock you can't see can cost you
00:40 – Why inventory management exists
02:56 – The digital record behind every item
06:48 – From supplier delivery to customer order
10:33 – The money attached to stock
13:51 – Visibility, reordering and daily control
17:16 – Inventory vs. warehouse management
18:19 – Conclusion: one shared stock story

Key takeaways

Dynamics 365 Inventory Management keeps one shared record of quantity, location, status, ownership and cost for every item, replacing separate team spreadsheets.
Inventory dimensions, item transactions, item groups and costing methods connect each physical stock movement to the general ledger.
Inventory management holds the company-wide stock story, while warehouse management guides the physical work of receiving, put-away, picking and shipping.

Worth quoting

“The goal isn't to make warehouses feel more technical, it's to give people a current shared answer when they need one.” – Mirko Peters (02:38)

“These actions shouldn't become a quiet way to erase mistakes. They create a trail that tells people what changed when it changed and why.” – Mirko Peters (10:04)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on stock tracking
Dynamics 365 – the platform whose Inventory Management module keeps the shared stock record discussed here
Mirko Peters – hosts this Knowledge Nugget and follows one item from supplier to customer
Related episode: Dynamics 365 Product Information Management - Simply Explained
Related episode: Dynamics 365 Procurement and Sourcing - Simply Explained

Dynamics 365 Financial Reporting - Simply Explained

Thu, 20 Aug 2026 03:55:02 +0000

Dynamics 365 Financial Reporting turns the financial data already posted in Dynamics 365 Finance into structured reports that finance teams, managers, auditors, and executives can actually use. Instead of rebuilding financial statements in multiple spreadsheets every month, organizations can use the general ledger, main accounts, financial dimensions, reporting categories, and predefined report structures to create consistent income statements, balance sheets, cash flow reports, trial balances, and budget-versus-actual reports. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Financial Reporting works and how organizations can move from financial transactions to reports people can trust.ㅤ

WHAT IS DYNAMICS 365 FINANCIAL REPORTING?
Financial Reporting is the Dynamics 365 Finance capability used to create, maintain, generate, and view financial statements based on general ledger information.It isn't another accounting ledger. Transactions such as invoices, payments, journals, payroll entries, and inventory adjustments are posted in Dynamics 365 Finance first. Financial Reporting then reads those financial results and organizes them into meaningful statements.Think of the general ledger as the financial filing cabinet and Financial Reporting as the report room that organizes those records into something people can understand.ㅤ

THE GENERAL LEDGER IS THE FOUNDATION
Every useful financial report starts with correctly structured accounting data.The general ledger contains the financial impact of customer invoices, supplier bills, payroll, bank payments, inventory adjustments, and other business transactions. Each amount is assigned to a main account representing what happened financially.Cash, sales revenue, rent expense, wages, accounts receivable, accounts payable, loans, and taxes can each have their own main accounts.Financial statements don't create these numbers. They organize and summarize balances that already exist in the ledger.ㅤ

MAIN ACCOUNT TYPES AND CATEGORIES
Main account types provide broad accounting classifications. Profit and loss accounts represent revenue and expenses for a period, while balance sheet accounts represent assets, liabilities, and equity.Main account categories provide another reporting layer.Several individual bank accounts, petty cash accounts, and clearing accounts might all belong to a broader cash category. A financial report can therefore show one clean cash line while finance retains the detailed accounts underneath it.Correct account types and categories make financial statements significantly easier to build and maintain.ㅤ

FINANCIAL DIMENSIONS ADD BUSINESS CONTEXT
Main accounts explain what happened financially. Financial dimensions explain where, who, or which part of the organization was responsible.Dimensions might represent departments, cost centers, business units, regions, locations, or projects.For example, three transactions could all post to the same rent expense account while their dimensions identify Head Office, Warehouse, and Retail North.Finance can see total rent expense while individual managers can analyze the portion associated with their area of responsibility.ㅤ

FINANCIAL DIMENSIONS VS FINANCIAL TAGS
Not every piece of transaction information should become a financial dimension.Dimensions are most useful for reusable values organizations expect to report against repeatedly, such as department, cost center, region, or business unit.Financial tags are better suited to flexible transaction references such as invoice numbers, purchase order numbers, payment references, or external system IDs.Creating dimensions for thousands of unique transaction references can make the financial structure unnecessarily complicated.ㅤ

DEFAULT FINANCIAL REPORTS
Dynamics 365 Finance includes 22 default financial reports that organizations can use as starting points.These include common reports such as income statements, balance sheets, cash flow reports, detailed and summary trial balances, rolling expense reports, budget-versus-actual reports, and other financial views.Organizations don't necessarily need to design every statement from scratch. A default report can be opened, compared against actual ledger balances, and adjusted to match the company's account structure and reporting requirements.ㅤ

FINANCIAL REPORTING VS POWER BI, EXCEL AND OTHER TOOLS
Dynamics 365 Finance provides several reporting technologies, and each serves a different purpose.Financial Reporting is designed for structured general-ledger-based financial statements. Power BI is better suited to interactive dashboards, visual analysis, filters, trends, and management questions.Excel remains useful for additional analysis, calculations, checks, and familiar data exploration.SSRS is generally suited to fixed-format operational documents and detailed reports, while Electronic Reporting focuses on structured files such as tax submissions, bank files, XML, and CSV outputs.Using the appropriate tool reduces the need to force every reporting requirement into Excel.ㅤ

HOW ROW DEFINITIONS WORK
A row definition controls what appears down the left side of a financial statement.For an income statement, rows might include Revenue, Cost of Sales, Gross Margin, Operating Expenses, and Net Result.Rows can reference individual main accounts, ranges of accounts, account categories, dimension combinations, or calculated totals.Gross margin, for example, doesn't necessarily point directly to an account. It can be calculated by subtracting cost of sales from revenue.Row definitions therefore determine what the report is actually reporting.ㅤ

HOW COLUMN DEFINITIONS WORK
Column definitions determine how financial information is displayed across the report.Columns might show the current month, year-to-date results, previous-year results, budget, actuals, forecast figures, or variance between actual and budget.A management income statement could therefore contain Current Month, Year to Date, Budget, and Variance columns without requiring someone to export the report into Excel and manually create comparison formulas.ㅤ

REPORT DEFINITIONS
A report definition connects the row and column structures into a report users can generate.For example, finance might create an Income Statement Rows definition and combine it with a Monthly Actual, Budget and Variance column definition.The resulting report definition could become the Monthly Management Income Statement.This modular approach means organizations can reuse the same financial statement structure with different periods, comparisons, and reporting views rather than rebuilding reports repeatedly.ㅤ

REPORTING TREES
Reporting trees allow organizations to structure financial reports around different reporting units.These units might represent legal entities, regions, departments, business units, or other organizational structures.A company with subsidiaries could generate results for each individual subsidiary and then provide a combined group view. A regional organization might show North, South, and West individually while also producing a company-wide total.This allows the same reporting framework to serve both local managers and centralized finance teams.ㅤ

SUMMARY, DETAIL AND DRILL-DOWN
Financial reports don't need to remain static pages.Users can begin with a summary showing figures such as total revenue, costs, and net result and then move into additional detail when a number requires investigation.If operating expenses are significantly above budget, finance can drill into the amount and inspect the transactions behind it, including journal entries, dates, vouchers, and related details.This turns a financial statement into a starting point for analysis instead of simply a document distributed at month-end.ㅤ

FILTERING FINANCIAL REPORTS
The same report can answer different questions by changing parameters and filters.Users can change report dates, currencies, detail levels, financial dimensions, and other attributes.A finance manager might begin with a company-wide income statement and then filter the same structure to a specific business unit or another reporting period.This reduces the need to maintain separate spreadsheet versions for every department or management question.ㅤ

SCHEDULING AND MULTI-ENTITY REPORTING
Financial reports can be generated on recurring schedules such as daily, weekly, monthly, or annually.This can support regular management packs, budget reviews, period-close processes, and group reporting.Organizations operating several legal entities can also use Financial Reporting to create views spanning multiple companies and support reporting currency requirements while individual entities continue maintaining their own accounting records.ㅤ

REPORT RETENTION AND AUDIT COPIES
Generated financial reports have retention considerations. The script notes that newly generated reports receive a 90-day expiration date by default, which appropriately authorized users can modify.It also highlights an important consideration for historical reporting: when saved reports are rerun or users drill into their details, current transaction data can be used.Organizations requiring an immutable audit copy of a finalized reporting period should therefore export the finalized report to Excel or PDF and retain it according to their normal records-management process.ㅤ

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Dynamics 365 General Ledger - Simply Explained

Thu, 20 Aug 2026 00:35:02 +0000

Dynamics 365 General Ledger provides the central financial record behind Dynamics 365 Finance. Customer payments, supplier invoices, inventory movements, payroll, bank transactions, taxes, accruals, and other financial events ultimately affect the company's financial position, and the general ledger brings those accounting entries together in a structured and traceable way. In this episode of M365 FM, Mirko Peters explains the Dynamics 365 General Ledger in plain English, including the chart of accounts, financial dimensions, subledgers, posting profiles, vouchers, journals, allocations, tax, period close, and consolidation.ㅤ

WHAT IS THE GENERAL LEDGER IN DYNAMICS 365?
The general ledger is the company's master financial record. Instead of finance teams piecing together numbers from separate spreadsheets and systems, financial transactions come together in one consistent accounting structure.The ledger contains debit and credit entries organized into accounts such as cash, sales revenue, inventory, rent expense, and accounts payable. Every financial event has two sides, and total debits and credits must remain balanced.Dynamics 365 Finance maintains a ledger for each legal entity, allowing individual companies within a larger organization to maintain their own financial records, reporting responsibilities, currencies, and accounting periods.ㅤ

CHART OF ACCOUNTS EXPLAINED
The chart of accounts provides the structure used to organize financial transactions. Think of it as a financial filing cabinet where each main account represents a specific category.Cash, inventory, accounts payable, sales revenue, and rent expense are examples of main accounts. These accounts are grouped into categories used for financial statements.Assets, liabilities, and equity appear on the balance sheet, while revenue and expenses contribute to the income statement. Correct account structures therefore form the foundation for reliable financial reporting.ㅤ

FINANCIAL DIMENSIONS
A main account tells finance what happened, but organizations often need additional information about where or why it happened.Financial dimensions provide those additional labels. An organization might use dimensions for department, cost center, business unit, or location.A travel expense can therefore remain in one travel expense account while dimensions identify whether the cost belongs to Sales, Support, Finance, London, Berlin, or another organizational unit.This allows companies to analyze financial performance without creating hundreds of unnecessary main accounts.ㅤ

ACCOUNT STRUCTURES AND FINANCIAL CONTROLS
Dynamics 365 Finance can use account structures to control which combinations of main accounts and financial dimensions are permitted.For example, a travel expense might require both a department and cost center, while another account may require fewer dimensions.These rules help prevent incomplete or inconsistent financial information from reaching the ledger and improve the quality of reporting across the organization.ㅤ

GENERAL LEDGER VS SUBLEDGERS
The general ledger provides the overall accounting record, while subledgers maintain the detailed operational information behind specific types of transactions.Accounts Payable tracks vendor invoices and payments. Accounts Receivable tracks customer invoices and incoming payments. Inventory tracks stock movements and value, while Fixed Assets tracks long-term assets such as equipment, vehicles, and buildings.Tax and production processes can also maintain specialized details.These subledgers feed accounting entries into the general ledger, allowing operational teams to retain the detail they need while finance receives the accounting impact required for reporting.ㅤ

HOW POSTING PROFILES WORK
Employees processing normal business transactions shouldn't have to manually determine every debit and credit account.Dynamics 365 Finance uses posting profiles and related accounting rules to determine which main accounts should receive particular transactions.When Accounts Payable processes a vendor invoice, for example, posting rules can automatically direct the liability to the appropriate accounts payable account while the other side of the transaction is posted according to the underlying purchase or expense.This creates more consistent accounting than asking individual users to determine postings manually.ㅤ

VOUCHERS AND FINANCIAL TRACEABILITY
A voucher provides an important connection between source documents, subledger transactions, and the accounting entries appearing in the general ledger.If a finance manager sees an amount in an account and wants to understand where it came from, the voucher can help trace the financial posting back to the corresponding vendor invoice, product receipt, customer invoice, or other business event.This traceability works in both directions. Finance can move from the ledger toward the source document or from the original transaction toward its accounting impact.ㅤ

HOW A PURCHASE REACHES THE GENERAL LEDGER
The episode follows a practical example involving a company purchasing 100 office chairs.The process begins with a purchase order. When the chairs arrive, a product receipt confirms that the company has received them. If the chairs are worth $10,000, inventory can receive a $10,000 debit while purchase accrual receives the corresponding $10,000 credit.The purchase accrual acts as a temporary accounting position because the goods have arrived but the vendor invoice hasn't yet been processed.When the invoice arrives, Dynamics 365 can clear the temporary purchase accrual and record the $10,000 obligation in accounts payable.One purchase therefore creates connected operational and accounting records without repeatedly entering the same financial information.ㅤ

DOUBLE-ENTRY ACCOUNTING
Dynamics 365 Finance follows double-entry bookkeeping. Every financial posting needs balanced debit and credit entries.If $10,000 is debited to one side of a transaction, an equal $10,000 must be credited somewhere else.The accounts involved depend on the business event, but the fundamental principle remains the same: total debits and total credits must balance.This provides the accounting structure that keeps the company's financial records internally consistent.ㅤ

JOURNAL ENTRIES
Not every accounting transaction begins with a purchase order, customer invoice, or inventory movement. Finance teams sometimes need to create journal entries directly.Journals can be used for adjustments, accruals, corrections, or other financial events that originate within the finance function.For example, if electricity was consumed during March but the corresponding invoice won't arrive until April, finance can create an accrual so the expense is represented in the appropriate accounting period.ㅤ

FINANCIAL ALLOCATIONS
Allocations allow organizations to distribute costs across accounts, departments, cost centers, or other dimensions according to defined rules.A fixed allocation might distribute head-office rent 50% to Sales, 30% to Support, and 20% to Finance.Variable allocations can distribute costs according to changing measures. Warehouse expenses, for example, could be distributed according to how much each business unit actually used the warehouse.This helps organizations represent shared costs more accurately in management reporting.ㅤ

TAX MANAGEMENT
Dynamics 365 Finance uses sales tax codes to define how taxes should be calculated and posted.Tax requirements can differ between countries, regions, states, counties, and cities, so tax configuration provides structured rules instead of requiring users to manually calculate taxes for individual transactions.When tax requirements change, organizations can update the appropriate configuration rather than relying on individual employees to remember new calculations.ㅤ

FISCAL CALENDARS AND ACCOUNTING PERIODS
The fiscal calendar determines how an organization's financial year is divided into accounting periods.These periods are commonly months and provide the structure used for month-end, quarter-end, and year-end financial activities.Transactions need to be recorded in the correct period so finance teams can accurately understand what happened during a particular part of the financial year.ㅤ

YEAR-END CLOSING
At year-end, Dynamics 365 Finance supports the process of preparing financial accounts for the next fiscal year.Revenue and expense accounts represent activity during a particular year, so their completed result moves through the closing process into equity.Balance-sheet accounts behave differently. Cash, inventory, accounts payable, and similar balances carry forward because those assets and obligations continue to exist when the calendar moves into a new financial year.ㅤ

CONSOLIDATION ACROSS LEGAL ENTITIES
Larger organizations may operate multiple legal entities while still requiring a combined view of overall financial performance.Consolidation combines financial information from multiple companies into an organizational view while each underlying legal entity continues maintaining its own financial records.Organizations can therefore preserve separate company accounting while still producing consolidated financial information for the wider group.ㅤ

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Dynamics 365 Autonomous Agents - Simply Explained

Wed, 19 Aug 2026 21:20:02 +0000

Repetitive work such as sorting leads, updating cases, matching transactions and chasing suppliers eats up time across every business team. In this Simply Explained episode, Mirko Peters shows Dynamics 365 users and decision makers what autonomous agents actually do, where Microsoft applies them, and how guardrails and human oversight keep people in charge.

In this episode

00:00 – Intro: copilot vs. autonomous agent
00:46 – A digital team member with a narrow job
03:31 – Dynamics 365 as the business office
06:21 – Service agents: intent, cases and knowledge
10:27 – Sales, finance, supply chain and field service agents
14:53 – Control, trust and the human team
17:21 – Conclusion: one job, clear rules, human oversight

Key takeaways

Dynamics 365 autonomous agents react to business events and carry out narrow, defined jobs, unlike a copilot that waits for someone to ask.
Microsoft applies agents across Customer Service, Sales, Business Central, Finance, Supply Chain Management and Field Service, each grounded in the related Dynamics 365 records.
The organization sets instructions, data access, permissions and approval points, and people remain accountable for outcomes.

Worth quoting

“Don't ask whether an agent can act, ask who decided what it can do. Every action comes from choices the organization made before it ever touched a customer record and order or a financial transaction.” – Mirko Peters (14:57)

“It's an AI worker with a narrow job, a set of rules and real business data to work from.” – Mirko Peters (03:21)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Dynamics 365 agents
AI agent – an AI worker with a narrow job that reacts to business events within set rules
Dynamics 365 – the business office whose customer, case, order and finance records give agents their context
Human in the loop – people set the guardrails, approve sensitive steps and stay accountable for every outcome
Dynamics 365 Customer Service – home of the customer intent, case management and customer knowledge management agents
Related episode: Dynamics 365 Copilot - Simply Explained

Dynamics 365 Case Management - Simply Explained

Wed, 19 Aug 2026 17:45:02 +0000

Dynamics 365 Case Management gives customer service teams one central place to manage customer issues from the first contact through resolution. Instead of information being scattered across emails, calls, chats, notes, and separate systems, each customer problem becomes a structured case containing the issue, customer context, activities, ownership, priority, service commitments, and final resolution. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Customer Service uses cases, queues, routing, SLAs, knowledge articles, Copilot, entitlements, and automation to create a more consistent support experience. ㅤ

WHAT IS A CASE IN DYNAMICS 365?
A case represents one customer issue that requires an answer or resolution. It could be a damaged product, billing question, login problem, technical issue, or request for help. Customers can have multiple cases simultaneously because each problem is managed separately. Cases can be connected to contacts and accounts while recording information such as the subject, product, priority, case type, description, and responsible owner. This creates a single working record for the entire support issue rather than forcing agents to reconstruct the customer story from multiple systems. ㅤ

KEEPING THE COMPLETE CUSTOMER HISTORY TOGETHER
Emails, calls, notes, appointments, tasks, chats, and other activities can remain connected to the same case. When ownership changes, the next agent can understand what happened without asking the customer to explain everything again. This customer context becomes particularly important for complex cases involving several agents or previous troubleshooting attempts. The case shows the immediate problem while the broader customer record provides information about previous interactions, products, and support history. ㅤ

ENTITLEMENTS AND CUSTOMER SUPPORT AGREEMENTS
Not every customer receives the same level of support. Dynamics 365 can use entitlements to represent the support terms associated with a customer. An entitlement might define warranty coverage, available support hours, permitted numbers of cases, or premium service conditions. Agents can therefore understand what support applies before committing resources or making promises to customers. ㅤ

KNOWLEDGE MANAGEMENT FOR FASTER RESOLUTION
Customer service teams frequently solve the same problems repeatedly. Dynamics 365 Knowledge Management allows organizations to maintain approved articles containing troubleshooting instructions, explanations, screenshots, standard answers, and other reusable support information. Agents can search these articles while working on cases instead of recreating solutions from memory. This can improve consistency and make organizational knowledge more accessible to less experienced support agents. ㅤ

COPILOT CASE SUMMARIES
Long-running cases can contain substantial amounts of information. Copilot can help agents understand that history by generating concise case summaries from information such as the customer, subject, product, priority, description, case type, and recent activities. The summary provides a faster starting point, particularly when a case changes ownership. Agents still review the underlying information and apply their own judgment before deciding what to do next. ㅤ

AUTOMATIC CASE CREATION
Customers can contact support through channels such as email, phone, chat, social media, and self-service portals. Dynamics 365 can use record creation rules to turn supported incoming communications into structured cases. For example, an email sent to a shared support address can automatically create a case rather than remaining unnoticed in a mailbox. Existing conversations can remain associated with their original cases while genuinely new problems receive separate records. ㅤ

QUEUES AND ROUTING
Once a case exists, it needs to reach the appropriate team. Dynamics 365 queues provide shared work areas where teams can manage incoming cases. Organizations might create separate queues for billing, technical support, returns, products, languages, regions, or different levels of urgency. Routing rules can evaluate information contained within a case and automatically direct it toward the appropriate queue or agent. Cases can also be manually reassigned when human judgment determines that a particular specialist is better suited to handle the problem. ㅤ

PARENT CASES, CHILD CASES AND DUPLICATES
Sometimes many customers report problems caused by the same underlying issue. Dynamics 365 can use parent and child cases to connect those individual customer reports to a larger problem. This allows teams to investigate the underlying issue centrally while maintaining individual customer records and communications. Duplicate cases can also be merged so multiple agents don't unknowingly work on the same problem. ㅤ

SERVICE LEVEL AGREEMENTS AND RESPONSE TIMES
Getting a case to the correct person isn't enough. Customers also expect organizations to meet agreed response and resolution times. Dynamics 365 Service Level Agreements, or SLAs, can attach time-based targets to cases. First-response targets measure how quickly the organization acknowledges the customer, while resolution targets measure how long the organization has to completely address the issue. Different support agreements, priorities, and case types can have different targets. Agents can see which cases are approaching deadlines, while alerts and escalation processes can help teams respond before service commitments are missed. ㅤ

BUSINESS PROCESS FLOWS FOR CONSISTENT SUPPORT
Business Process Flows provide agents with structured stages for handling cases. A process might move through intake, investigation, diagnosis, and resolution while requiring important information at each stage. This helps newer agents understand what information they need while providing experienced teams with a consistent process. Managers can also identify stages where cases frequently become delayed. ㅤ

RESOLVING AND REOPENING CASES
Sending an email doesn't automatically mean the customer's problem has been solved. Teams should record how the issue was resolved and then formally close the case. Resolution information creates useful history for future interactions. If the original solution doesn't work, the case can be reopened so the team continues with the existing history instead of creating another disconnected record. ㅤ

USING CASE DATA TO IMPROVE CUSTOMER SERVICE
Individual cases also become valuable operational data. Managers can analyze time to resolution, time spent in different stages, first-contact resolution, queue workloads, reopened cases, and recurring issue categories. Patterns can reveal broader problems. Increasing case volumes around one product could indicate a product issue, while repeated questions may indicate that documentation or knowledge articles need improvement. Case management therefore supports both individual customer service and continuous improvement across the support organization. ㅤ

CUSTOMER SELF-SERVICE
Some customers don't need direct assistance from an agent. Self-service experiences can allow customers to create requests, check case status, provide additional information, and access approved knowledge content themselves. This can reduce routine support demand while allowing customer service agents to concentrate on problems requiring investigation, explanation, or human judgment. ㅤ

MICROSOFT 365 AND POWER PLATFORM INTEGRATION
Dynamics 365 Case Management can work alongside familiar Microsoft technologies. Outlook can support email communication, Teams can help employees collaborate on difficult cases, SharePoint can manage related documents, Power BI can provide reporting and dashboards, and Power Platform can extend processes with additional forms and automation. The tools surrounding the process may change, but the Dynamics 365 case remains the central record connecting the customer problem, activities, ownership, service commitments, and resolution. ㅤ

THE KEY TAKEAWAY
Dynamics 365 Case Management isn't simply a ticketing system. It provides a structured lifecycle for customer issues from initial contact through routing, investigation, service commitments, knowledge, collaboration, resolution, and reporting. By keeping the customer, problem, communication history, support agreement, ownership, deadlines, and final answer connected to one record, customer service teams can reduce lost context, avoid duplicated work, and provide customers with a more consistent support experience. Subscribe to M365 FM for more Microsoft Knowledge Nuggets and Simply Explained episodes covering Dynamics 365, Microsoft 365, Power Platform, Copilot, AI, Azure, security, governance, and the Microsoft ecosystem.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Licensing, Security & Management: Making Microsoft 365 Defender and Intune Work Together with Videsh Chavan

Wed, 19 Aug 2026 15:20:02 +0000

Microsoft 365 licensing is often treated as a procurement problem: choose E3, E5, E7 or a collection of add-ons, assign the licenses, and move on. But licensing decisions directly influence security architecture, endpoint management, identity protection, and operational costs. In this episode of M365 FM, Mirko Peters talks with Videsh Chavan about building a unified Microsoft 365 strategy where licensing, Microsoft Intune, Microsoft Defender, identity, and endpoint security work together instead of operating as separate silos. ㅤ

MICROSOFT 365 LICENSING IS AN ARCHITECTURE DECISION
One of the central ideas of the conversation is that Microsoft 365 licensing shouldn't be treated purely as procurement. Organizations frequently purchase licenses without mapping the capabilities those licenses actually unlock. The result can be expensive features that nobody uses, duplicated security products, and security gaps that only become visible after an incident. Videsh recommends looking at licensing, Intune, Defender, and identity as parts of one connected architecture. Organizations should understand which capabilities they own, which capabilities they actually use, and where third-party products duplicate functionality already included in Microsoft licensing. ㅤ

A FIVE-STEP MICROSOFT 365 SECURITY FRAMEWORK
The discussion introduces a practical five-step approach for moving from disconnected Microsoft 365 tools toward a unified strategy. It starts with a licensing audit and capability mapping, followed by establishing an identity-first security baseline. Intune then becomes the enforcement layer, while Defender serves as the detection and response layer. The final component is continuous cost and coverage review, ensuring that licensing, security controls, and actual organizational requirements remain aligned. ㅤ

IDENTITY AS THE FOUNDATION OF MODERN SECURITY
As employees work from offices, homes, personal devices, mobile platforms, and Cloud PCs, the traditional corporate network becomes less useful as the primary security boundary. Identity therefore becomes a critical foundation. Users, groups, applications, connectors, access controls, and other resources depend heavily on identity. The conversation explores why organizations need strong identity controls, Conditional Access, MFA, and appropriate security guardrails as part of their Microsoft 365 architecture. ㅤ

AUDIT WHAT YOU ACTUALLY OWN
Before purchasing additional Microsoft security products, organizations should understand their existing entitlements. Videsh recommends inventorying assigned versus actively used licenses and mapping license tiers such as E3 and E5 against the Intune, Defender, identity, and security capabilities they unlock. This can expose features the organization already pays for but doesn't use. Regular reviews can also identify unused add-ons, capability gaps, and situations where upgrading or downgrading particular users makes more sense than applying the same licensing tier to everybody. ㅤ

WHY INTUNE IS MORE THAN MDM
Microsoft Intune has evolved far beyond traditional mobile device management. In the architecture discussed in this episode, Intune acts as an enforcement layer covering device configuration, application management, security policies, patching, provisioning, and endpoint security. Rather than maintaining large numbers of disconnected policies, organizations should consider structured security baselines and manageable policy architectures. The objective is to make endpoint management easier to understand, maintain, and continuously improve. ㅤ

WINDOWS AUTOPILOT AND ZERO-TOUCH PROVISIONING
Windows Autopilot fundamentally changes traditional corporate device provisioning. Instead of IT departments manually building and imaging every laptop before handing it to an employee, devices can be shipped directly from suppliers to users. The employee can unpack the device, connect it to the internet, authenticate, and allow organizational policies and configurations to provision the endpoint. This approach became particularly valuable as remote and hybrid work increased and organizations needed to onboard employees without requiring them to physically visit an office. ㅤ

INTUNE AS A SECURITY ENFORCEMENT LAYER
Intune increasingly sits at the intersection of endpoint management and cybersecurity. Security baselines, antivirus configurations, application policies, device configurations, and other endpoint controls can be centrally managed and enforced. This makes Intune an important part of the broader Microsoft security architecture rather than simply a tool for configuring laptops and smartphones. ㅤ

MICROSOFT DEFENDER AS DETECTION AND RESPONSE
Microsoft Defender represents a broader family of security capabilities rather than a single antivirus product. Organizations need to understand which Defender capabilities their licenses provide and how those capabilities fit into the wider endpoint security architecture. The episode discusses a practical security loop: detect suspicious activity, evaluate what happened, restrict the affected device or access when necessary, and restore normal operations after the problem has been addressed. Security teams remain responsible for investigating alerts and determining whether activity represents a genuine threat or a false positive. ㅤ

ZERO TRUST IS A STRATEGY, NOT A PRODUCT
Zero Trust isn't another Microsoft product organizations can simply purchase and enable. It is a cybersecurity strategy built around continuously verifying access instead of automatically trusting users, devices, or connections. Identity verification, application context, security controls, and least-privilege access all contribute to this model. Zero Trust therefore needs to influence architectural decisions across the organization rather than becoming another isolated security project. ㅤ

AI AND THE FUTURE OF ENDPOINT MANAGEMENT
AI introduces another layer to modern endpoint operations. Instead of waiting until users report that their device has a problem, telemetry and AI-assisted analysis can potentially identify deteriorating device health, recurring crashes, or other problems earlier. This creates an opportunity for more predictive and proactive IT operations. Videsh doesn't suggest handing endpoint management entirely to AI, but sees opportunities to shift some repetitive Level 1 activities toward AI-assisted operations while people remain responsible for more complex decisions. ㅤ

MODERNIZING A LARGE ENTERPRISE
For an enterprise operating Windows, macOS, iOS, Android, Windows 365, Active Directory, existing SCCM infrastructure, thousands of applications, BYOD, multiple Microsoft licensing tiers, and third-party security products, modernization should begin with discovery. Organizations need to understand their users, business requirements, existing technologies, licensing, regional restrictions, security requirements, and future use cases before redesigning the architecture. Modernization should then be controlled through documentation, peer review, architecture standards, and carefully managed implementation to minimize disruption. ㅤ

THE KEY TAKEAWAY
Microsoft 365 licensing, Intune, Defender, identity, Conditional Access, device health, and security policies shouldn't be managed as unrelated technologies. Together, they form a connected architecture in which identity and device signals influence access while Intune enforces policies and Defender provides detection and response. The starting point is understanding what the organization already owns and how those capabilities are being used. From there, organizations can identify security gaps, eliminate unnecessary licensing duplication, modernize endpoint management, and build a more coherent Microsoft 365 security strategy. As Mirko summarizes at the end of the conversation: licensing isn't simply procurement, Intune isn't simply device management, Defender isn't simply antivirus, and identity isn't simply a username and password.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Dynamics 365 Agents - Simply Explained

Wed, 19 Aug 2026 12:35:02 +0000

Dynamics 365 Agents take AI beyond answering questions and generating drafts. Instead of waiting for someone to ask https://www.m365.fm/categories/copilot-talk/ for help, agents can respond to defined business events, work with approved Dynamics 365 data, follow predefined rules, take permitted actions, and hand work to people when human judgment is required. In https://www.m365.fm/dynamics-365-agents-simply-explained/ of M365 FM, Mirko Peters explains how Dynamics 365 Agents work across sales, customer service, finance, supply chain, Business Central, Field Service, and Project Operations — and why permissions, guardrails, data quality, and human oversight are critical.
ㅤ
WHAT ARE DYNAMICS 365 AGENTS?
ㅤ
A Dynamics 365 Agent is AI configured to watch for a business event, understand approved information, follow defined rules, perform permitted actions, and report what happened.
The important difference is that an agent doesn't simply wait for a user to ask a question. A trigger such as a new lead, customer email, supplier response, order request, or financial mismatch can start the process automatically.
ㅤ
COPILOT VS DYNAMICS 365 AGENTS
ㅤ
Copilot typically works beside the user. You open a customer case and ask for a summary, request information, or generate a draft. The interaction begins because you asked Copilot to help.
An agent can continue working in the background according to its defined job. It can monitor an approved process, identify an event, collect relevant information, perform allowed actions, and escalate the work when necessary.
Think of Copilot as an assistant sitting beside you, while an agent is a specialized team member with a narrow job description, specific permissions, and clear rules.
ㅤ
HOW THE AI AGENT LOOP WORKS
ㅤ
The basic agent process can be understood as: notice, understand, act, check, and hand over.
The agent notices a defined event such as a new message or lead. It understands the situation using information and rules it has permission to access. It performs allowed actions, checks whether the result remains within its boundaries, and hands the work to a person when judgment or approval is required.
This creates supervised automation rather than unrestricted AI autonomy.
ㅤ
GUARDRAILS, PERMISSIONS AND HUMAN CONTROL
ㅤ
Guardrails define what an agent can see, change, create, or send. An organization might allow an agent to create a draft email but prevent it from sending that message automatically. An agent could categorize a customer case but be prevented from issuing a refund.
The same principle applies to supplier communication, financial transactions, customer promises, contracts, and other sensitive activities. The agent can prepare and route the work while people retain responsibility for higher-risk decisions.
ㅤ
DATAVERSE AND COPILOT STUDIO
ㅤ
Many Dynamics 365 applications use Microsoft Dataverse as the connected data foundation for customers, contacts, leads, cases, activities, products, and other business information.
For custom agents, Copilot Studio provides a place where organizations can define instructions, connect approved knowledge sources, configure actions, and determine how an agent should respond.
The quality of these agents depends heavily on the quality of the underlying data and processes.
ㅤ
SALES QUALIFICATION AGENTS
ㅤ
Sales agents can help close the gap between incoming interest and seller follow-up. A Sales Qualification Agent can research incoming leads, compare them against criteria established by the sales organization, prioritize potential opportunities, and prepare personalized outreach.
Instead of sellers spending significant time performing the first round of research for every new lead, the agent can prepare information while the salesperson decides whether the prospect deserves further attention.
ㅤ
SALES RESEARCH AND OPPORTUNITY AGENTS
ㅤ
Sales Research Agents can gather approved information before customer conversations, helping sellers understand companies, previous interactions, existing opportunities, and relevant account context.
Opportunity Agents operate later in the sales process. They can research active opportunities, surface deal context, identify potential risks, and highlight opportunities requiring attention.
Sales Close Agents can support the final stages through follow-ups, customer engagement, product suggestions, and handling common objections within defined business rules.
ㅤ
CUSTOMER SERVICE AGENTS
ㅤ
https://www.m365.fm/dynamics-365-customer-service-simply-explained/ Agents can reduce repetitive administrative work around customer cases. A Case Management Agent can interpret incoming customer communications, create cases, extract useful details, associate customers, and route cases appropriately.
Customer Intent Agents can identify why customers are contacting the organization and help direct requests toward appropriate queues, answers, or service representatives.
This can reduce the time agents spend manually creating and categorizing cases before they can begin solving the customer's actual problem.
ㅤ
KNOWLEDGE MANAGEMENT AND QUALITY AGENTS
ㅤ
A Customer Knowledge Management Agent can analyze completed cases to identify gaps in an organization's knowledge base and help prepare draft knowledge articles for human review.
Quality Evaluation Agents can evaluate larger numbers of customer interactions against standards established by service supervisors. This can help managers identify patterns and coaching opportunities without depending entirely on manually selected samples.
ㅤ
BUSINESS CENTRAL SALES ORDER AGENTS
ㅤ
In Dynamics 365 Business Central, a Sales Order Agent can process incoming customer order requests. It can read an order request received through email, identify the customer, extract requested products and quantities, and prepare order information for review.
People remain responsible for exceptions such as unusual pricing, missing products, incorrect customer information, or orders that don't match established patterns.
ㅤ
SUPPLY CHAIN AND SUPPLIER AGENTS
ㅤ
The Supplier Communications Agent in https://www.m365.fm/dynamics-365-supply-chain-management/ can support repetitive supplier follow-up activities.
It can request purchase order confirmations, ask suppliers for delivery updates, process incoming supplier communications, and associate responses with relevant orders. If a supplier reports a significant delay or another situation requiring a business decision, the agent can escalate the issue to a buyer or planner.
ㅤ
FINANCE AND RECONCILIATION AGENTS
ㅤ
Finance agents can support repetitive reconciliation work. An Account Reconciliation Agent can compare transactions and identify records that should match but don't, helping finance teams discover discrepancies earlier.
Financial Reconciliation Agents can support preparation and cleanup of information required for reconciliation and financial reporting. Accountants still determine what discrepancies mean and approve the appropriate resolution.
ㅤ
FIELD SERVICE AND PROJECT OPERATIONS AGENTS
ㅤ
https://www.m365.fm/dynamics-365-field-service/ can use scheduling-focused agents to help optimize technician schedules when appointments, availability, priorities, or other conditions change.
Project Operations can use agents to support administrative activities such as preparing time entries, processing expense information, and reviewing time, expense, and material records against organizational policies.
These capabilities target repetitive administrative work while keeping people responsible for exceptions and consequential decisions.
ㅤ
WHY DATA QUALITY MATTERS
ㅤ
An AI agent can only work with the information available to it. Duplicate customers, incomplete product records, outdated supplier contacts, and inconsistent business data can quickly reduce the reliability of automated processes.
Automation doesn't transform poor data into good decisions. Organizations need clean and consistent records before expecting agents to reliably connect incoming information with the correct customers, orders, cases, or suppliers.
ㅤ
HOW TO START WITH DYNAMICS 365 AGENTS
ㅤ
Start with one repetitive process that has clear steps, clear ownership, and a measurable result. Define what triggers the process, which records the agent can access, which actions it can perform, which actions require approval, and exactly when the agent must stop and involve a person.
Testing should include normal situations as well as difficult exceptions. Organizations should inspect what the agent reads, prepares, changes, and escalates before expanding its permissions or applying the approach to additional processes.
ㅤ
THE KEY TAKEAWAY
ㅤ
Dynamics 365 Agents turn repetitive business processes into supervised AI-powered actions. They can respond to events, understand approved business information, execute defined tasks, and escalate exceptions across sales, customer service, finance, operations, supply chain, and project workflows.
The objective isn't to give AI control of an entire department. Start with one clearly defined queue or process, establish permissions and guardrails, measure the result, and expand only after the process proves reliable.
An agent can only perform as well as the process, data, rules, and boundaries you give it.
Subscribe to M365 FM for more Microsoft Knowledge Nuggets and Simply E

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Dynamics 365 Copilot - Simply Explained

Wed, 19 Aug 2026 10:25:02 +0000

Sales calls, service cases, invoices and orders bury the facts people need under notes, emails and menus. This Simply Explained episode shows business users and decision makers how Copilot in Dynamics 365 summarizes records, answers questions and prepares drafts across Sales, Customer Service, Finance and Business Central, and why human approval stays essential.

In this episode

00:00 – Intro: what Dynamics 365 Copilot is
00:30 – Dynamics 365 as the foundation: CRM and ERP
03:26 – What Copilot actually does: summarize, answer, draft
07:40 – Sales: preparing for the next customer conversation
10:47 – Customer service: from long case histories to next steps
13:39 – Finance, operations and Business Central
16:37 – Data, security and human approval
18:34 – Conclusion: the helper inside each business room

Key takeaways

Copilot in Dynamics 365 works inside the business records people already use, summarizing histories, answering questions about permitted data and preparing first drafts.
Each Dynamics 365 app (Sales, Customer Service, Finance and Operations, Business Central) has its own Copilot features and task-focused agents, distinct from Microsoft 365 Copilot.
Copilot follows the signed-in user's access rules, and people must review drafts and stay accountable for refunds, payments, promises and approvals.

Worth quoting

“Treat a copilot response like work prepared by a junior colleague. It may save you time, but your name still goes on the email, the case update, or the approval.” – Mirko Peters (05:53)

“A copilot helps you ask, understand, draft, and decide. An agent focuses on a defined piece of work that it can carry out on the rules set by the business.” – Mirko Peters (07:01)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Copilot in Dynamics 365
Dynamics 365 – the CRM and ERP platform whose records Copilot summarizes, answers questions about and drafts from
Human in the loop – why every Copilot draft, payment match and agent output still needs a person's review
AI agent – task-focused agents in Sales, Customer Service and Business Central that carry out defined work
Related episode: Dynamics 365 Autonomous Agents - Simply Explained

Dynamics 365 Opportunity Management - Simply Explained

Wed, 19 Aug 2026 07:15:02 +0000

Many sales teams track deals in scattered notes and spreadsheets, so nobody knows what will really close. This episode walks sellers and sales managers through opportunity management in Dynamics 365 Sales, from lead qualification through the four pipeline stages to closing as won or lost. You will learn how to keep a deal record your team and your forecast can trust.

In this episode

00:00 – Lead vs. opportunity
00:26 – What an opportunity actually is
03:10 – How opportunities enter Dynamics 365 Sales
06:14 – The four-stage sales pipeline
11:01 – Building a deal record you can trust
14:37 – Winning, losing and learning
17:54 – Conclusion: keep the deal folder current

Key takeaways

An opportunity is one potential sale linked to an account or contact, created by qualifying a lead or directly for existing customers.
The qualify, develop, propose and close stages make sure budget, decision maker, stakeholders and internal review are covered before a deal is ready to close.
Keeping revenue, close dates and probability current and closing deals promptly as won or lost keeps the forecast honest.

Worth quoting

“A lead is early interest, but an opportunity is a sales conversation with enough shape to track as a possible deal” – Mirko Peters (00:07)

“If those dates are old or the amounts are guesses, the forecast becomes a neat looking screen full of bad information” – Mirko Peters (02:45)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a FAQ on the sales pipeline
Dynamics 365 Sales – where opportunities are created from qualified leads and moved through qualify, develop, propose and close
Dynamics 365 – keeps the customer account, contacts and each opportunity record together as one shared deal folder
Mirko Peters – follows one possible deal from first serious conversation to closing it as won or lost
Related episode: Dynamics 365 Forecasting - Simply Explained

Dynamics 365 Knowledge Management - Simply Explained

Wed, 19 Aug 2026 03:25:02 +0000

Support agents waste time hunting through old emails and spreadsheets while customers wait, and different agents give different answers. This episode shows customer service teams how Dynamics 365 Knowledge Management turns scattered know-how into approved, searchable articles inside daily case work. You will learn how articles are created, reviewed, found and kept current.

In this episode

00:00 – The problem: answers in people's heads
00:33 – Why teams need a shared knowledge base
03:24 – What Dynamics 365 Knowledge Management is
06:26 – The life of a knowledge article
10:03 – Finding knowledge while helping a customer
13:27 – Keeping knowledge accurate, safe and useful
16:10 – An end-to-end example
17:48 – Conclusion: one shared answer

Key takeaways

A shared knowledge base in Dynamics 365 Customer Service gives every support agent the same approved answers, so customers get consistent responses on every channel.
Knowledge articles move through a lifecycle of drafting, labelling, expert review, approval, publishing to the right audience and regular updates.
Clear titles, an owner per article, permissions and feedback from agents and search misses keep the knowledge base useful.

Worth quoting

“If one agent explains a return policy one way, and another gives a different version, the customer doesn't see an internal knowledge problem. They see a company that can't agree with itself.” – Mirko Peters (01:46)

“A knowledge base becomes the company's working memory, keeping useful know how available when someone takes leave, changes jobs, joins the team, or simply forgets a detail during a busy afternoon.” – Mirko Peters (02:48)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on knowledge articles
Dynamics 365 – the platform whose Knowledge Management feature gives support teams one approved place for answers
Dynamics 365 Customer Service – where agents open cases and search or get suggested knowledge articles without leaving their work
Mirko Peters – hosts this Microsoft Knowledge Nugget and walks through a knowledge article from gap to update
Related episode: Dynamics 365 Omnichannel - Simply Explained

Dynamics 365 Omnichannel - Simply Explained

Wed, 19 Aug 2026 00:50:02 +0000

Customers repeat their story on every channel because chat, email, phone and social messages live in separate tools. This episode explains for customer service teams and supervisors how Dynamics 365 Omnichannel connects those conversations in one workspace. You will learn how routing, agent tools, customer history and real-time dashboards fit together.

In this episode

00:00 – The broken support journey
00:43 – Why separate channels create bad support
03:27 – The unified agent desktop
07:39 – Routing behind the scenes
11:50 – Tools that help agents respond
15:38 – One customer record
17:38 – What supervisors can see
19:21 – Conclusion: the connected service desk

Key takeaways

Dynamics 365 Omnichannel brings chat, voice, SMS and social conversations into one agent workspace with the customer's history beside them.
Routing uses queues, rules, skills, presence and capacity to send each request to the right available person, and consults avoid needless transfers.
Context only follows the customer when channels are set up correctly and conversations are linked to the right contact or case.

Worth quoting

“Each channel feels like walking into a different branch of the same company where no one has seen the notes from the branch you just left.” – Mirko Peters (01:27)

“This doesn't mean every conversation connects by magic. The company still has to set up channels correctly, link records, and decide what information to collect.” – Mirko Peters (03:12)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Omnichannel
Dynamics 365 – the platform whose Omnichannel features pull chat, voice, SMS and social conversations into one workspace
Dynamics 365 Customer Service – named briefly as the home of Omnichannel when the episode turns to supervisor dashboards
Mirko Peters – hosts the episode and closes it with an invitation to more Dynamics 365 explainers
Related episode: Dynamics 365 Knowledge Management - Simply Explained

Dynamics 365 Relationship Intelligence - Simply Explained

Tue, 18 Aug 2026 21:55:02 +0000

A Dynamics 365 Sales opportunity can look busy while the customer has quietly stopped replying. This episode explains relationship intelligence for sellers, sales managers and CRM admins: relationship analytics, relationship health and who knows whom, and how to turn those signals into the next useful customer conversation.

In this episode

00:00 – A hidden problem in Dynamics 365 Sales
00:40 – Why sales teams need relationship intelligence
03:01 – What relationship intelligence actually is
06:17 – Relationship analytics: reading the conversation
10:52 – Relationship health: a warning light, not a crystal ball
14:14 – Who knows whom: finding the warm introduction
17:15 – A simple sales day example

Key takeaways

Relationship intelligence in Dynamics 365 Sales turns emails, meetings and calls tied to sales records into signals that show whether a customer is still engaged.
Basic insights update close to real time from Dynamics 365 activities, while enhanced insights add Exchange data via server-side synchronization and refresh every 24 hours.
Relationship health and who knows whom point sellers to the relationships that need attention and to colleagues for warm introductions, but the seller still has to judge the context and have the conversation.

Worth quoting

“Relationship intelligence is like someone opening that file and asking, are we still talking to these people?” – Mirko Peters (01:50)

“The tool can organize communication signals, but it cannot fill in conversations that were never captured. That's just how it works.” – Mirko Peters (04:38)

Explore more on M365.FM

Episode page: the full Knowledge Nugget with chapters, quotes and FAQ
Dynamics 365 Sales – the app where relationship health and who knows whom appear on sales records
Dynamics 365 – source of the emails, calls and appointments behind basic relationship insights
Exchange Online – adds email and meeting data to enhanced insights through server-side synchronization
Related episode: Dynamics 365 Sales Insights - Simply Explained

Dynamics 365 Customer Service Workspace - Simply Explained

Tue, 18 Aug 2026 19:10:02 +0000

Customer service agents lose time jumping between inboxes, tabs and notes while customers repeat their story. This Simply Explained episode is for Dynamics 365 users, service leads and admins who want to understand how Copilot Service workspace organizes sessions, channels, knowledge, Copilot help and unified routing in one service desk.

In this episode

00:00 – Why the workspace exists
03:06 – Sessions and tabs: the desk drawer analogy
07:04 – One workspace for every channel
10:17 – The productivity pane, Smart Assist and knowledge
11:48 – Scripts, macros, quick replies and Copilot
13:37 – Routing, presence and capacity
16:44 – SLAs, self-service and dashboards
18:50 – Conclusion: one organized service desk

Key takeaways

Copilot Service workspace, formerly Customer Service workspace, keeps each customer issue in its own session with up to ten tabs, so agents stop rebuilding context.
Omnichannel channels, cases, timelines, the productivity pane, scripts, macros and Copilot help agents find answers fast, but people still review everything before it is sent.
Behind the scenes unified routing uses queues, skills, presence and capacity, while SLA timers, escalation rules and dashboards help teams keep promises and spot patterns.

Worth quoting

“A session is how the workspace keeps one customer issue together. Think of it like a labeled desk draw.” – Mirko Peters (03:13)

“That is what OmniChannel means in plain English. The company lets customers choose how to get in touch, while service agents work from the same place.” – Mirko Peters (07:21)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on the service workspace
Dynamics 365 Customer Service – the service app behind Copilot Service workspace, its cases, channels and routing
Dynamics 365 – the platform where the older Customer Service Hub and the newer agent workspace live
Microsoft Teams – a channel for customer conversations and a way for agents to ask product specialists
Related episode: Dynamics 365 Autonomous Agents - Simply Explained

Dynamics 365 Forecasting - Simply Explained

Tue, 18 Aug 2026 18:57:50 +0000

Sales forecasts often live in scattered spreadsheets and hopeful guesses. This episode shows sellers, sales managers and leaders how Dynamics 365 Sales forecasting turns opportunity data into one shared view of expected revenue, confidence and risk. You will learn how forecast categories, role-based views and AI signals work, and why honest updates matter most.

In this episode

00:00 – Will we hit the number?
00:35 – What a sales forecast actually is
03:20 – From spreadsheets to a shared forecast board
06:33 – Forecast categories: the confidence ladder
10:53 – Different views for every sales role
13:50 – AI, data quality and human judgment
17:25 – A simple forecasting rhythm
18:03 – Conclusion

Key takeaways

Dynamics 365 Sales builds the forecast from opportunity records, so amount, close date, owner and forecast category must stay current.
Forecast categories (pipeline, best case, committed, omitted) give the team a shared confidence language, while won and lost are set automatically on closing.
AI scores and rollups support the forecast, but human context and honest weekly reviews decide whether the number can be trusted.

Worth quoting

“Think of the target, often called quota, as the line your sales team aims to cross. The forecast shows the path toward that line based on what the team knows right now.” – Mirko Peters (00:48)

“That doesn't mean the score knows the customer better than you do. It just gives you and your manager another signal to consider before you spend time on the next call or forecast review.” – Mirko Peters (14:40)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a FAQ on sales forecasting
Dynamics 365 Sales – builds the forecast grid from the opportunity records sellers already update in daily work
Dynamics 365 – the connected platform where amount, owner, close date and deal details live in one place
Mirko Peters – explains sales forecasting in plain English, from quota and forecast categories to AI scores
Related episode: Dynamics 365 Opportunity Management - Simply Explained

AI Turns Integration into an Organism as a Service — How Azure Logic Apps Are Changing Enterprise Integration with Sonny Gillissen [MVP]

Tue, 18 Aug 2026 14:55:02 +0000

Enterprise integration is usually invisible until it breaks, and deterministic workflows struggle with the unexpected. This episode is for architects and integration developers who want to understand Azure Logic Apps, connectors, identity and observability, and how agent loops can make integrations adaptive and self-healing.

In this episode

00:00 – Intro: integration as a commodity
02:05 – Sonny's path into integration and why enterprise integration gets complex
07:29 – What Azure Integration Services include
11:29 – Logic Apps, CI/CD, infrastructure as code, consumption vs. standard
20:38 – The connector ecosystem and its security trade-offs
27:11 – Authentication, managed identities and least privilege
30:59 – Observability, tracked properties and business-driven logging
49:37 – Organism as a Service: agent loops and self-healing integrations

Key takeaways

Azure Integration Services combine Logic Apps, API Management, Azure Functions, Service Bus and Event Grid, and the right mix depends on whether a team prefers low code or pro code.
Secure integrations rely on built-in connectors where possible, managed identities, Key Vault and least-privilege permissions so that one breached connection cannot take down every integration.
With agent loops in Logic Apps, integrations can interpret errors and intent and react to unexpected situations, turning integration as a service into what Sonny Gillissen calls Organism as a Service.

Worth quoting

“And in an Azure logic app, it's just a canvas. So as soon as you run your first logic app, you can see what it did, why it did it, what's the result?” – Sonny Gillissen (12:34)

“Our main objective is to always use built-in connectors when you can, because the built-in connectors are running within the logic app runtime.” – Sonny Gillissen (26:17)

Explore more on M365.FM

Episode page: the full conversation with chapters, quotes and FAQ on Azure Logic Apps
Sonny Gillissen – Microsoft MVP for Azure Integration Services who explains Logic Apps and Organism as a Service
Azure Logic Apps – the main product of the episode, from consumption vs. standard to agent loops
Connector – built-in, managed and custom connectors and the security trade-offs of each
Related episode: Azure Bicep - Simply Explained

Dynamics 365 Remote Assist - Simply Explained

Tue, 18 Aug 2026 13:05:02 +0000

When a machine stops, the expert who knows it best is often far away, and photos, chats and phone calls leave too much to guesswork. This episode explains Dynamics 365 Remote Assist for maintenance, field service and operations teams. You learn how live shared video and on-screen guidance speed up fixes while people on site stay in control.

In this episode

00:00 – A machine stops mid-shift
00:33 – Remote help without shared context
03:16 – What Remote Assist actually is
06:41 – A call from problem to guided fix
10:03 – The building blocks behind the call
13:41 – Where teams use it
16:34 – What Remote Assist is not
17:49 – Conclusion

Key takeaways

Part of Dynamics 365, Remote Assist lets a frontline worker share live video with a remote expert, who can mark the exact part or switch in the shared view.
Teams provides the calling and contacts, Field Service adds work order context, and Microsoft 365 with Entra ID controls who can join and access information.
Remote Assist fits visual, hands-on work where an expert's view prevents delays or trips, but it never replaces on-site safety rules or physical work.

Worth quoting

“Remote Assist isn't a repair manual that hands you every answer. It's not a robot that diagnoses a machine on its own, and it definitely doesn't replace the trained person who has to do the work safely on site.” – Mirko Peters (03:51)

“Each building block has a simple job. Teams connects people. Remote assist connects that conversation to physical work. Field service connects it to a planned service job and its history.” – Mirko Peters (13:15)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on Remote Assist
Dynamics 365 – the product family that includes Remote Assist and, in some setups, Field Service work orders
Microsoft Teams – provides the calls, chat and contacts that Remote Assist uses to connect workers and experts
Microsoft 365 – handles identity and security behind the scenes so only the right people join and see information
Related episode: Microsoft AppSource - Simply Explained

Dynamics 365 Unified Routing - Simply Explained

Tue, 18 Aug 2026 11:20:02 +0000

Growing service teams quickly find that one shared queue sends urgent cases to the wrong people or leaves them waiting. This episode explains Dynamics 365 unified routing for customer service leads and admins. You learn how workstreams, queues, skills and capacity work together so every request reaches the right agent the first time.

In this episode

00:00 – Requests stuck in a shared queue
00:33 – Why basic queues stop working
03:00 – Classification and assignment
06:50 – Workstreams, queues, skills and capacity
11:23 – One request from message to agent
14:49 – Planning a routing model
17:37 – Conclusion

Key takeaways

Unified routing first classifies incoming work with skills, language and priority, then assigns it to an available agent who has the right skills and free capacity.
Workstreams define the path for each kind of work, queues set team ownership, skills describe fit, and capacity profiles plus presence show who can take work now.
Build queues, people, skills and capacity before routing rules, keep rules minimal, and give the fallback queue an owner who watches it.

Worth quoting

“A queue only answers part of the question, it can tell you where a request should wait, but it doesn't always decide which available person has the right knowledge, who already handles several chats, or whether a more urgent request should come first.” – Mirko Peters (01:34)

“Your service leaders still decide which customers need faster help, what skills matter, how many chats an agent can manage, and where work should go when nobody matches. Unified routing takes those decisions and applies them the same way each time.” – Mirko Peters (02:36)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on unified routing
Dynamics 365 – the platform where workstreams, queues, skills and capacity profiles for unified routing are configured
Mirko Peters – hosts the episode and follows one Spanish-language email from intake to the right agent
Related episode: Dynamics 365 Product Information Management - Simply Explained
Related episode: Dynamics 365 Knowledge Management - Simply Explained
Related episode: Dynamics 365 Copilot - Simply Explained

Dynamics 365 Guides - Simply Explained

Tue, 18 Aug 2026 06:35:02 +0000

Frontline technicians often juggle manuals, laptops and memory while doing careful physical work. In this Simply Explained episode, Mirko Peters explains how Dynamics 365 Guides used mixed reality on HoloLens, Teams and Copilot to bring instructions to the job, and what operations teams must do before the end-of-availability date.

In this episode

00:00 – Intro: instructions right beside the machine
00:41 – The work problem: instructions far from the job
03:28 – Mixed reality in plain English
06:50 – From expert knowledge to a guide
10:53 – Remote experts with Microsoft Teams
13:07 – Copilot, Dataverse and connected apps
16:17 – The end date and preserving guide knowledge

Key takeaways

Dynamics 365 Guides placed step-by-step holographic instructions, photos, videos and 3D models directly in the worker's view on Microsoft HoloLens, keeping hands free.
Experts authored guides in the PC app and anchored them in the real workspace with HoloLens, while Microsoft Teams calls brought in remote experts for unexpected problems.
Microsoft has set December 31, 2026 as the end of availability for Guides and Remote Assist, so organisations should inventory and preserve the task knowledge stored in their guides.

Worth quoting

“Instead of flipping between a picture and the real object, they compare them in the same view. Fewer switches in focus means fewer missed steps.” – Mirko Peters (02:53)

“With Dynamics 365 Guides, you wear a Microsoft HoloLens headset. You can still see the real machine, the tools and the people around you, but digital instruction cards and 3D objects appear within that view.” – Mirko Peters (03:44)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on Guides
Microsoft Teams – built into Guides for calls where remote experts see the worker's view and annotate it
Dynamics 365 – the app family whose Field Service and Supply Chain Management can connect to Guides
Dataverse – the shared data storage where Dynamics 365 Guides keeps its records
Related episode: Dynamics 365 Dataverse Integration - Simply Explained

Dynamics 365 Sales Insights - Simply Explained

Tue, 18 Aug 2026 00:45:02 +0000

Sales teams rarely lack data, but they struggle to see which follow-up or deal matters most right now. In this Simply Explained episode, Mirko Peters walks sellers and sales managers through Dynamics 365 Sales Insights, from the assistant and auto capture to predictive scoring, relationship intelligence, conversation intelligence and forecasting.

In this episode

00:00 – Intro: lost follow-ups and the sales coach
00:50 – Why sales teams need insights, not more data
03:07 – Assistant, auto capture and email engagement
06:15 – Predictive lead and opportunity scoring
10:28 – Relationship intelligence and Who knows whom
14:07 – Conversation intelligence and notes analysis
17:58 – Forecasting and the connected sales picture

Key takeaways

Dynamics 365 Sales Insights sits on top of the CRM records in Dynamics 365 Sales and turns activity into prompts, scores and relationship signals.
Predictive lead and opportunity scoring helps sellers prioritise, but the scores are only as reliable as consistent historical sales data and never replace judgment.
Conversation intelligence, relationship analytics and forecasting improve coaching and planning when organisations set clear rules for recording, privacy and licensing.

Worth quoting

“Sales Insights is a group of AI-powered tools inside Dynamics 365 Sales that turns sales activity into guidance by surfacing prompts, scoring leads or opportunities and showing signals about customer relationships.” – Mirko Peters (02:04)

“A high score isn't a promise though. No score can tell you that a buyer has approved a budget, chosen your company, or signed a contract.” – Mirko Peters (08:16)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on Sales Insights
Dynamics 365 Sales – the filing cabinet of accounts, contacts, leads and deals that Sales Insights builds on
Dynamics 365 – the business app family whose sales app hosts the assistant, scoring and forecasting tools
Microsoft 365 – supplies the emails and meetings that relationship analytics and auto capture draw on
Related episode: Dynamics 365 Relationship Intelligence - Simply Explained

Dynamics 365 Sales Accelerator - Simply Explained

Mon, 17 Aug 2026 21:30:02 +0000

Sellers juggle inboxes, calendars, CRM records and reminders and still miss the leads that matter most. This Simply Explained episode shows sales teams and managers how Dynamics 365 Sales Accelerator, with its Up next work list, sequences and customer context, brings focus and repeatable follow-up to the daily sales routine.

In this episode

00:00 – Intro: deciding what to do next in sales
00:29 – Why sales work gets fragmented
03:07 – What Sales Accelerator actually is
05:57 – Up next: deciding who deserves attention
09:15 – Sequences: a repeatable plan for follow-up
12:44 – Customer context, insights and connected work
15:56 – A day with Sales Accelerator and who it fits

Key takeaways

Sales Accelerator is a guided workspace inside Dynamics 365 Sales that turns a large pool of CRM records into a practical daily work list.
The Up next work list uses predictive scoring, company rules and recent activity to surface priorities, while sequences provide repeatable follow-up steps.
Customer context and AI summaries support preparation, but sellers still own the conversation, and sequence capacity depends on the Sales Enterprise or Premium license.

Worth quoting

“Think of sales accelerator as a guide beside your desk, not a robot taking your chair. It helps you spend less effort finding the work, leaving you more room to do the part only a person can do, listen, respond and build trust.” – Mirko Peters (05:41)

“Predictive scoring sounds technical, but the idea is simple. It gives each lead a signal based on patterns in the sales data.” – Mirko Peters (06:36)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Sales Accelerator
Dynamics 365 Sales – the CRM that holds customer records and opportunities, with Sales Accelerator built inside it
Dynamics 365 – the platform behind Dynamics 365 Sales, where Sales Accelerator's guided work list lives
Microsoft Outlook – one of the scattered places where customer emails and follow-ups pile up for sellers
Microsoft Teams – mentioned as a channel where leads come up and as a connected tool for outreach
Related episode: Dynamics 365 Relationship Intelligence - Simply Explained

Dynamics 365 Human Resources - Simply Explained

Mon, 17 Aug 2026 19:05:02 +0000

HR information often lives in spreadsheets, inboxes and separate tools, so every change creates another outdated copy. This Knowledge Nugget explains Dynamics 365 Human Resources for HR teams, managers and IT, covering employee records, self-service, leave, benefits, workflows and integrations in plain English.

In this episode

00:00 – A typical HR day across too many tools
00:45 – The problem it solves: fragmented people work
03:07 – The employee record and organization
06:20 – Employee and manager self-service
09:37 – Benefits, compensation, learning and development
13:37 – Workflows, automation and reporting
17:20 – Connections across Microsoft and beyond
18:51 – Where Dynamics 365 Human Resources fits

Key takeaways

Dynamics 365 Human Resources gives each employee one controlled record with job details, skills, certifications and reporting lines, protected by roles and permissions.
Self-service and Microsoft Teams integration let employees check leave balances and submit requests while managers approve them through defined workflows, reducing email chains.
The product connects with payroll, recruiting, learning tools and Power BI rather than replacing them, so companies should define their HR processes first and configure the software around them.

Worth quoting

“Still, self-service doesn't replace HR. HR professionals still answer difficult questions, apply policy, handle sensitive cases, and help people through changes that don't fit a standard form.” – Mirko Peters (09:19)

“Records tell you what happened. Workflows help decide what happens next. A workflow is simply a set route for a task.” – Mirko Peters (13:42)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Dynamics 365 Human Resources
Dynamics 365 – the product family that Dynamics 365 Human Resources belongs to, alongside finance and payroll connections
Microsoft Teams – where employees check time off balances and submit leave requests without a separate HR site
Business events (Dynamics 365) – used together with Power Automate templates to connect HR activity to other processes
Related episode: Dynamics 365 Dataverse Integration - Simply Explained

When Azure SQL Becomes an Application Platform- APIs, Automation and AI with Dirceu Resende

Mon, 17 Aug 2026 15:05:02 +0000

Most teams still treat Azure SQL as passive storage behind the application. In this interview, Dirceu Resende shows data engineers and architects how Azure SQL Database can call REST APIs, automate workflows and support AI with vector search. You learn where this simplifies your architecture and how to keep it secure and performant.

In this episode

00:00 – Intro: Azure SQL as an application platform
02:55 – Dirceu's path into data and Power BI
09:20 – Azure SQL Database vs. Managed Instance
16:42 – Beyond traditional data storage
27:46 – REST integrations and automation examples
41:12 – Security, authentication and error handling
48:33 – Performance, AI and vector search
57:03 – BI, governance and rapid fire

Key takeaways

Azure SQL Database can call external REST APIs directly, so the database can trigger alerts, enrich data with AI and integrate with services without extra application code.
Secure these integrations with firewalls, least privilege, dedicated users, masking and encryption, and store API secrets in database credential objects instead of in procedures.
In the cloud, performance tuning directly lowers cost, and Fabric mirroring offers a near real-time path to BI without hand-built ETL pipelines.

Worth quoting

“Also, the database needs a special attention on it, because you can version code, but you cannot version data. So data is pretty critical and pretty important.” – Dirceu Resende (20:20)

“I understand this concern is really real. But if you can hack into the database, you already have access to all the data anyway.” – Dirceu Resende (41:56)

Explore more on M365.FM

Episode page: the full interview with chapters, key quotes and a short FAQ
Dirceu Resende – explains how Azure SQL Database calls REST APIs, automates jobs and supports vector search
Microsoft Fabric – its mirroring feature replicates Azure SQL data near real time for BI without ETL pipelines
Microsoft Azure – the cloud where Azure SQL Database runs, alongside services like Logic Apps and Data Factory
Power BI – Dirceu previously worked on it at Microsoft as a senior program manager
Mirko Peters – hosts the interview and asks about integrations, security, performance and governance
Related episode: Everyone Wants Copilot—but Is Your Data Ready: Microsoft Fabric Architecture with Walter Calcagno [MVP-MCT]

Dynamics 365 Customer Insights Data - Simply Explained

Mon, 17 Aug 2026 12:35:02 +0000

When sales, service and marketing each see a different version of the same customer, people get the wrong offers and repeat themselves. This episode explains Dynamics 365 Customer Insights - Data for CRM, marketing and data teams. You learn how one unified customer profile, measures and segments lead to better-informed customer conversations.

In this episode

00:00 – One customer, three stories
00:33 – Why scattered customer data creates bad decisions
03:30 – What Customer Insights - Data actually is
06:47 – Building the unified customer profile
11:26 – Measures, enrichment and predictions
14:43 – Segments and activation
17:35 – Privacy, security and the CDP difference
19:30 – Conclusion

Key takeaways

Dynamics 365 Customer Insights - Data is a customer data platform that maps, matches and de-duplicates records from many systems into one unified customer profile.
Measures, enrichment and AI predictions such as churn turn profiles into answers, but predictions are signals that still need human review.
Segments and destinations put the shared profile to work across sales, service and marketing, while consent, privacy and access control must be designed in from the start.

Worth quoting

“Each team still needs tools built for its job. What they need is one shared customer file that can connect the separate records.” – Mirko Peters (03:17)

“If sales calls someone a high value customer while marketing uses a different calculation, the customer experience splits again. A shared measure gives everyone one agreed way to look at the question.” – Mirko Peters (12:15)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ
Dynamics 365 Customer Insights – the episode's subject: Customer Insights - Data as the CDP, Journeys for communications
Dynamics 365 – the app family whose sales and service records feed the unified customer profile
Dynamics 365 Sales – the CRM for deals and leads that Customer Insights - Data extends rather than replaces
Dataverse – often supplies sales and service records as a data source for Customer Insights - Data
Related episode: Dynamics 365 Customer Insights - Simply Explained

Dynamics 365 Commerce - Simply Explained

Mon, 17 Aug 2026 10:40:02 +0000

A customer buys online, picks up in one store and returns in another, and suddenly four disconnected systems have to agree. This knowledge nugget explains Dynamics 365 Commerce in plain English for retail, IT and business leaders, covering the customer journey, Store Commerce, the headless Commerce Scale Unit and the data behind it, and what the platform still leaves to people.

In this episode

00:00 – Intro: one jacket, many systems
00:39 – What Dynamics 365 Commerce actually is
02:45 – One customer journey across every channel
05:59 – The physical store: Store Commerce and point of sale
08:42 – The engine behind the storefronts: Commerce Scale Unit and headless commerce
13:05 – Data, loyalty, reviews and fraud protection
16:19 – Who uses Commerce and what it does not replace
18:15 – Conclusion: the connected retail building

Key takeaways

Dynamics 365 Commerce connects websites, stores, call centers and back office around one shared view of products, prices, stock, orders and customers.
The Commerce Scale Unit is the headless engine behind every channel, so a new app or storefront reuses the same pricing, stock and order rules through APIs.
Commerce connects people and processes but does not replace them: clean product data, clear business rules and staff who pick, pack and serve remain essential.

Worth quoting

“Headless simply means the selling engine lives apart from the screen a person looks at. The engine doesn't care if a customer uses a website, a phone app, a self-service kiosk, or a store worker's tablet.” – Mirko Peters (09:18)

“Customers don't care which technical system answered their question. They care that the price on their phone matches the price in the store, and that an item shown as available can actually be ordered.” – Mirko Peters (10:11)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on Dynamics 365 Commerce
Dataverse – described as the shared business filing cabinet that Commerce uses to share customer data
Dynamics 365 – the app family Commerce connects to, including Supply Chain Management and Finance
Mirko Peters – hosts this Knowledge Nugget and follows one jacket purchase across stores and the website
Related episode: Dynamics 365 Dataverse Integration - Simply Explained

Dynamics 365 Project Operations - Simply Explained

Mon, 17 Aug 2026 06:05:02 +0000

Customer projects can become complicated quickly. Sales has the customer relationship and quote. Project managers have schedules and tasks. Resource managers need to know who is available. Consultants record hours and expenses. Finance needs to understand costs, revenue, and what can actually be invoiced.In this episode of Microsoft Knowledge Nuggets on M365 FM, Mirko Peters explains Microsoft Dynamics 365 Project Operations and how Microsoft connects project sales, project management, resource planning, time tracking, expenses, billing, and financial processes within one project-focused platform.The episode follows the complete lifecycle of a customer project—from the first sales conversation and project quote through planning, staffing, delivery, time and expense management, financial tracking, and finally customer invoicing.

WHAT IS DYNAMICS 365 PROJECT OPERATIONS?
Microsoft Dynamics 365 Project Operations is designed for organizations that sell project-based services. These businesses are not simply selling products. They are selling expertise, professional services, consulting hours, engineering work, implementation projects, design services, development work, or other customer engagements where people, time, costs, contracts, and billing need to remain connected.Without a connected system, different departments often create their own version of a project. Sales knows what was promised. Delivery creates another project plan. Employees record hours somewhere else. Finance receives approved hours and expenses later and then tries to determine what should appear on the customer's invoice.Dynamics 365 Project Operations connects these areas around shared project information.The objective is not to make every department use exactly the same interface. Salespeople, consultants, project managers, resource managers, and finance professionals have different responsibilities. What matters is that the underlying project information remains connected.

FROM SALES OPPORTUNITY TO PROJECT DELIVERY
A customer project begins before the first task is created.During the sales process, someone needs to determine what the customer actually needs, which roles will be required, how many hours may be necessary, when work could start, what the project should cost, and how the customer will be charged.Dynamics 365 Project Operations helps organizations capture this information while the opportunity is still being developed.This creates an important connection between what sales promises and what the delivery organization eventually needs to provide.Instead of project managers receiving an email saying that sales has apparently sold several weeks of consulting, the approved scope, roles, estimated effort, pricing, dates, and billing conditions can become part of the connected project record.

PROJECT QUOTES AND CONTRACTS
Quotes and project contracts establish the commercial foundation of a customer engagement.A quote represents what the organization proposes to sell. It can include planned work, estimated effort, project roles, pricing, expected dates, and billing conditions.Once the customer accepts the proposal, the project contract records what the customer actually agreed to purchase.This distinction is important because delivery teams should work against the accepted customer commitment rather than an earlier version of the proposal that may have changed during negotiations.Contracts can also establish whether customers are charged according to time worked, a fixed project price, milestones, or other agreed billing arrangements.

PROJECT PLANNING AND WORK BREAKDOWN STRUCTURES
After the customer accepts the project, the promise needs to become an executable plan.Project managers break large outcomes into smaller pieces of work. This structure is commonly called a Work Breakdown Structure, or WBS.For example, a cloud migration project might contain discovery, design, implementation, testing, customer review, deployment, and closure phases.Each part can then contain individual tasks with planned dates, expected effort, responsibilities, and dependencies.Dependencies are particularly important because project activities rarely happen completely independently. Design may depend on discovery. Testing depends on implementation. Customer approval may depend on testing.When one activity changes, project managers need visibility into what that change could mean for the rest of the schedule.

PROJECT MILESTONES
Milestones provide recognizable checkpoints during a project.A milestone might represent design approval, completion of testing, delivery of a major project component, customer acceptance, or another significant event.Unlike normal tasks, milestones typically represent a point in the project rather than a block of working hours.They are useful for communicating progress and can also have commercial importance. In milestone-based engagements, reaching an agreed milestone may trigger part of the customer's billing schedule.This connects project delivery directly with the commercial agreement.

PROJECT TIME TRACKING
Time entries are more than administrative timesheets.When employees record time against specific projects and tasks, the organization gains information about how much effort the work actually requires.Project managers can compare planned effort with actual effort. If discovery was expected to require 40 hours but has already consumed 60 hours, that difference becomes visible while the project is still active.That does not automatically mean the project is failing. The customer environment may simply have been more complicated than expected.The important point is that the organization now has information it can act on rather than discovering the problem after the project has finished.Approved time can also become an important input into project costs and customer billing.

PROJECT EXPENSE MANAGEMENT
Customer projects frequently involve costs beyond employee time.Consultants may travel to customer locations, purchase approved services, or incur other project-related expenses.Dynamics 365 Project Operations can associate these expenses with the relevant customer project instead of allowing them to disappear into disconnected receipts, emails, or financial records.This creates better visibility for project managers and provides finance with clearer information when reviewing project profitability and customer billing.

RESOURCE MANAGEMENT AND STAFFING
A perfect project plan is useless if the required people are unavailable.Resource management connects project requirements with employees and contractors who have the appropriate skills and availability.A project manager may know that a security specialist is required for two weeks without initially knowing which individual will perform the work.Resource management allows organizations to consider both requirements.Someone may have exactly the right technical skills but already be assigned to another customer. Another person might have the necessary expertise and sufficient capacity during the required period.This helps organizations reduce overbooking and make project commitments based on actual resource availability.

RESOURCE BOOKINGS AND CAPACITY
A resource booking reserves part of someone's working capacity for project work.Employees do not necessarily need to be assigned full-time. A consultant might spend three days each week on one customer project while using the remaining capacity for another engagement, training, internal work, or leave.Connecting resource bookings with availability gives organizations a clearer picture of their delivery capacity.This is particularly valuable for consulting organizations and professional services firms where people represent both the primary delivery resource and a significant part of project cost.

SKILLS, ROLES AND PROJECT COSTS
Staffing is not simply about finding someone with an empty calendar.Projects often require specific roles and competencies such as project managers, business analysts, developers, architects, engineers, consultants, or security specialists.The financial impact also matters.A senior specialist may have a different internal cost than a junior consultant. The organization therefore needs to balance skills, availability, delivery quality, and financial performance when staffing projects.Dynamics 365 Project Operations connects these staffing decisions more closely with the overall project plan and financial picture.

PROJECT COSTS AND PROFITABILITY
A project can finish on time and still lose money.Customer revenue represents only one side of the financial equation. Organizations also need to consider employee costs, contractors, travel, software, materials, and other expenses required to deliver the engagement.Dynamics 365 Project Operations helps connect planned and actual project costs with customer pricing.This makes it easier to understand whether the project is consuming more expensive resources or more working hours than originally anticipated.A project can therefore appear successful operationally while becoming less profitable financially.Connecting project delivery and project financial information helps organizations identify this situation earlier.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Dynamics 365 Supply Chain Management - Simply Explained

Mon, 17 Aug 2026 01:35:02 +0000

A single late shipment can empty a shelf and break a customer promise when every team works from its own spreadsheet. This episode explains Dynamics 365 Supply Chain Management for operations, planning and IT teams in manufacturing, retail and distribution. You learn how one connected record from purchasing to delivery leads to more reliable delivery dates.

In this episode

00:00 – When a late shipment breaks the chain
00:53 – What Supply Chain Management actually is
03:51 – From product idea to purchase order
07:51 – Inventory and warehouse management
12:23 – Manufacturing and equipment
15:41 – Transportation, fulfillment and promises
17:58 – Data, AI and Microsoft connections
19:51 – Conclusion

Key takeaways

Dynamics 365 Supply Chain Management is an ERP system that connects product records, planning, purchasing, inventory, production, maintenance and transport in one shared record.
Inventory numbers only become useful with location and status, and barcode scanning on mobile devices keeps the digital record in step with physical movements.
Power BI, AI and Copilot help planners spot shortages and risks, but people still review suggestions and make the decisions.

Worth quoting

“A forecast isn't a promise. It's a planned estimate that gives the business a reason to check whether it has enough materials, enough supplier deliveries, and enough time to meet expected demand.” – Mirko Peters (05:35)

“The system brings attention to these exceptions, but a person still decides whether to change the plan, buy from another supplier or speak with the customer.” – Mirko Peters (06:56)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ
Dynamics 365 – the Microsoft business application family that Supply Chain Management and Finance belong to
Power BI – turns supply chain records into dashboards for warehouse, planning, production and logistics teams
AI agent – described as helpers for routine tasks, such as a procurement agent for supplier communication
Dynamics 365 Finance and Operations – Dynamics 365 Finance links the movement of goods to the financial side
Related episode: Dynamics 365 Copilot - Simply Explained

Dynamics 365 Finance - Simply Explained

Sun, 16 Aug 2026 21:05:02 +0000

Finance teams lose time when budgets, invoices and bank data live in different spreadsheets and systems. This Knowledge Nugget explains Dynamics 365 Finance in plain English for business users, managers and newcomers to ERP, from the first purchase request to the general ledger, budgeting, reporting and controls.

In this episode

00:00 – One question, many spreadsheets
00:35 – What Dynamics 365 Finance actually is
03:15 – The daily money flow from purchase to financial record
06:59 – The general ledger, chart of accounts and financial dimensions
10:52 – Planning ahead: budgets, forecasts and cash
13:43 – Reports and decisions
16:43 – Controls, security and the connected Microsoft platform

Key takeaways

Dynamics 365 Finance keeps the official financial record in one place, linking purchase requests, purchase orders, receipts, supplier invoices and payments so nobody retypes data between tools.
The general ledger, chart of accounts and financial dimensions give every transaction a category and extra context such as department, location or project, so totals can be traced back to their source.
Budgets, forecasts and cash views answer different questions, and controls such as separated approvals, closed periods and a full audit trail protect the records behind every decision.

Worth quoting

“Now, Excel still has a job. You can use Excel to explore numbers, build a quick model, or answer a one-off question. But Excel usually holds a copy of the numbers.” – Mirko Peters (01:35)

“If a correction is needed later, finance handles it through a controlled process. They don't quietly change history.” – Mirko Peters (10:31)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a plain-English FAQ
Dynamics 365 Finance and Operations – the finance system followed here from purchase request to general ledger, budgets and reports
Microsoft Excel – still useful for quick models and one-off questions, but holds only a copy of the numbers
Power BI – turns finance data into charts and dashboards that should trace back to the original transactions
Related episode: Dynamics 365 Accounts Receivable - Simply Explained

From Garage Band to Symphony Orchestra- How Microsoft 365 Governance Creates Harmony at Scale — with Heiko Brenn

Sun, 16 Aug 2026 14:30:02 +0000

As Microsoft 365 grows, Teams, SharePoint sites and guest accounts multiply until collaboration turns into noise. In this interview, Heiko Brenn of BCC uses music metaphors to show IT leaders and governance owners how ownership, lifecycle management, monitoring and automation turn that sprawl into a well-coordinated orchestra.

In this episode

00:00 – From garage band to orchestra: the governance challenge
02:28 – Heiko Brenn's journey from Exchange 5.5 to BCC
05:18 – What Microsoft 365 governance means
10:16 – Governance is a team sport
14:26 – Music metaphors: bands, conductors and jam sessions
28:58 – AI as conductor, workload rules and the sound check
35:54 – Governance maturity and detecting drift
45:43 – Sprawl, BCC's role and rapid-fire round

Key takeaways

Microsoft 365 governance is the balance between creativity, freedom and structure, and it works best in the background so people can collaborate without bureaucracy getting in the way.
Governance is a team sport that needs a leadership sponsor, IT and security, and line-of-business owners, with different rules for areas such as HR and legal than for sales or marketing.
Start early with basic policies such as naming conventions, ownership and lifecycle rules for Teams and guests, then monitor for drift and automate so sprawl stays under control as the organization grows.

Worth quoting

“So from my perspective, I would say governance in general is a team sport. So it's really about involving all the different, I would say even everything that you mentioned is part of the process.” – Heiko Brenn (10:33)

“So I would definitely start at an early stage with some maybe more simplified rules, but have something in place already.” – Heiko Brenn (22:19)

Explore more on M365.FM

Episode page: the full interview with chapters, quotes and a governance FAQ
Heiko Brenn – BCC's Director of Product Marketing, explaining Microsoft 365 governance through bands, conductors and jam sessions
Governance – described as the balance between creativity, freedom and structure, run as a team sport
Microsoft Teams – named alongside guests as the top source of sprawl without naming and lifecycle rules
Related episode: Data Loss Prevention in Microsoft 365: Policies That Actually Work
Related episode: Beyond the Microsoft Adoption Framework: The Reality of M365 Success

Dynamics 365 Contact Center - Simply Explained

Sun, 16 Aug 2026 13:20:02 +0000

Customers hate repeating their story every time they switch from chat to phone or get transferred. This episode explains in plain English how Dynamics 365 Contact Center connects channels, routing, agent context and AI help for service leaders and agents. You will learn what the product does, how it fits next to your CRM, and where human judgment still matters.

In this episode

00:00 – The repeat-yourself problem
00:38 – What Dynamics 365 Contact Center is
03:51 – From first question to human help
07:10 – Unified routing and queues
10:29 – The agent workspace
13:57 – Copilot and AI agents
17:28 – Integration with Microsoft and existing CRMs
18:30 – Who it fits and conclusion

Key takeaways

Dynamics 365 Contact Center brings voice and digital customer conversations into one workspace with shared context, without forcing a company to replace its existing CRM.
Unified routing sends each conversation to a queue and an agent with the right skills and capacity, and transfers or consultations keep the collected context.
Copilot and AI agents reduce routine work such as self-service, summaries and case notes, but humans must review suggestions and remain responsible for decisions.

Worth quoting

“Think of the CRM as the customer filing cabinet. It stores the customer story over time. The Contact Center is the service desk in front of that filing cabinet where calls and messages arrive and people work through issues as they happen.” – Mirko Peters (01:53)

“That doesn't magically fix a bad service process. A confused policy is still a confused policy. Poor customer information is still poor customer information.” – Mirko Peters (03:26)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on Contact Center
AI agent – handles simple self-service and gathers details before handing customers to a human agent
Dynamics 365 – the product family Contact Center belongs to, even though it is not another CRM
Microsoft Teams – lets an agent pull in an expert while keeping the customer engagement open
Mirko Peters – host who follows one missing-order case to explain Dynamics 365 Contact Center
Dynamics 365 Customer Service – the CRM whose cases and knowledge articles Contact Center works alongside; Premium bundles both
Related episode: Dynamics 365 Copilot - Simply Explained

Dynamics 365 Customer Insights Journeys - Simply Explained

Sun, 16 Aug 2026 10:05:02 +0000

Scattered email lists, sales notes and form entries lead to late, repeated or irrelevant customer messages. This episode explains Dynamics 365 Customer Insights - Journeys in plain English for marketing, sales and business teams. You will learn how journeys, segments, channels and triggers work together to send the next sensible message.

In this episode

00:00 – More than a marketing email tool
00:41 – Why businesses need it
03:35 – The journey builder
07:01 – Customer data and segments
10:39 – Channels and content
13:30 – Planned journeys and real-time triggers
16:22 – Copilot, sales connections and analytics
18:50 – Conclusion

Key takeaways

Customer Insights - Journeys plans customer communication as visual journeys that decide who enters, what each person receives and when, based on their actions.
Segments and connected customer profiles only work with clean data and respected consent, channel preferences and contact limits.
Segment-based journeys suit shared schedules, trigger-based journeys respond to customer actions, and Copilot drafts still need human review.

Worth quoting

“A segment is a set of people who meet rules you define. It isn't a spreadsheet someone exported six months ago and forgot to update.” – Mirko Peters (08:30)

“Before you build anything, answer three simple questions. Who should enter? What should they receive? When should each message arrive?” – Mirko Peters (04:19)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on Customer Insights - Journeys
Dynamics 365 Customer Insights – the product whose Journeys part is explained here, fed by profiles from Customer Insights - Data
Dynamics 365 – pictured as an office building with Customer Insights - Journeys as its communications floor
Dynamics 365 Sales – where salespeople see demo requests and sent messages, and where stage changes can trigger journeys
Microsoft 365 Copilot – Copilot built into Customer Insights - Journeys drafts emails, describes audiences and suggests journey ideas
Related episode: Dynamics 365 Customer Insights - Simply Explained

Dynamics 365 Customer Insights - Simply Explained

Sun, 16 Aug 2026 06:21:41 +0000

Sales, service and marketing often each hold a different page of the same customer's story. This episode explains Dynamics 365 Customer Insights, its Data and Journeys parts and the confusing name change, for anyone working with Dynamics 365. You will learn how unified profiles, segments and triggered journeys help teams respond with the right message at the right time.

In this episode

00:00 – One customer, scattered records
00:41 – Definition and the name change
03:12 – Customer Insights - Data: one customer record
07:11 – Customer Insights - Journeys: turning knowledge into action
10:46 – How a customer journey works
14:45 – Measuring results
17:09 – Where Customer Insights fits in Dynamics 365

Key takeaways

Dynamics 365 Customer Insights has two parts: Data builds unified customer profiles and segments, and Journeys turns that picture into planned communication.
Journeys can be segment-led or trigger-led, with branches, waits and handoffs to sellers, while consent and frequency caps protect the customer relationship.
Clear goals, journey analytics and A/B tests show what works, but clean data and respected preferences matter more than complex branches.

Worth quoting

“Customer insights data uses matching rules that the business sets up so it doesn't just guess that every similar record belongs to the same person. Good matching rules help reduce duplicates without joining the wrong people together.” – Mirko Peters (04:47)

“Now a journey shouldn't become an endless machine that sends messages just because it can. It needs choices inside it.” – Mirko Peters (10:23)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on Customer Insights
Dynamics 365 Customer Insights – the episode's subject, covering its Data and Journeys parts and the 2023 rename
Dynamics 365 – the wider business app family where Customer Insights sits next to Sales and Customer Service
Dataverse – the shared data store where form submissions create or update customer records
Related episode: Dynamics 365 Customer Insights Journeys - Simply Explained

Dynamics 365 Field Service - Simply Explained

Sun, 16 Aug 2026 03:10:02 +0000

Field service jobs often fall apart because of phone calls, paper notes and a technician who arrives without the right part. This episode explains Dynamics 365 Field Service in plain English for service managers, dispatchers and anyone planning on-site work. Follow one job from request to invoice and see how work orders, scheduling, the mobile app and assets fit together.

In this episode

00:00 – A broken heating system
00:45 – Why businesses need Field Service
02:47 – The work order
06:19 – Scheduling and dispatch
09:54 – The Field Service mobile app
13:12 – Parts, assets, maintenance and billing
16:28 – Copilot and the wider Microsoft connection
17:52 – Conclusion

Key takeaways

Field Service, part of Dynamics 365, manages on-site work from the first request through scheduling, the technician visit and parts to the final invoice.
The work order is the single source of facts for a visit, and the schedule board matches it to a resource with the right skills, availability and location.
The mobile app, customer assets and preventive or predictive maintenance improve first-visit fixes, while Copilot helps summarize but people stay responsible.

Worth quoting

“A first visit fix usually needs three things, the right person, clear instructions, and the correct part, and missing one can turn a simple repair into a second visit.” – Mirko Peters (01:25)

“Customer service can receive the call, but Field Service manages the trip, the work, the parts, and the result.” – Mirko Peters (02:39)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on Field Service
Dynamics 365 – the wider business app family whose customer, case, sales and billing records Field Service shares
Microsoft 365 – supports communication and documents around Field Service work
Mirko Peters – hosts this knowledge nugget and follows one service job from request to invoice
Dynamics 365 Customer Service – handles the incoming call, while Field Service takes over once a site visit is needed
Power Platform – mentioned briefly as support for reports, automations and custom processes around Field Service
Related episode: Dynamics 365 Contact Center - Simply Explained

Microsoft Purview Data Map - Simply Explained

Sun, 16 Aug 2026 00:10:02 +0000

Data rarely stays in one app: it is copied, exported, renamed and forgotten across Outlook, Teams, SharePoint and Fabric. This episode is for Microsoft 365 admins, data owners and compliance teams who need a plain-English map of Microsoft Purview. You learn how its data map, catalog, labels, DLP and investigation tools fit together to make data findable, trustworthy and protected.

In this episode

00:00 – Why data sprawl turns into business risk
04:39 – What Microsoft Purview actually is
08:44 – Find, name and trust data: data map, catalog and lineage
12:13 – Classify and protect: sensitivity labels and DLP
16:18 – Manage risk, records and investigations
19:47 – How the pieces work together

Key takeaways

Microsoft Purview does not store your data; it adds rules, context and visibility around data that stays in Microsoft 365, Azure, Fabric and supported external sources.
The data map, unified catalog, glossary, lineage and data quality checks help people find data, know who owns it and judge whether it can be trusted.
Sensitivity labels, DLP, audit, retention, eDiscovery and communication compliance protect information as it moves and give responsible teams records and context when something goes wrong.

Worth quoting

“An accessible report is not always a trusted report. That difference can save a team from building a decision around incomplete or outdated information.” – Mirko Peters (12:09)

“A sensitivity label and DLP work together, but they do different jobs. The label identifies information and describes how it should be handled. DLP checks an action as it happens and can warn the person, block the action or record it for review.” – Mirko Peters (14:43)

Explore more on M365.FM

Episode page: the full knowledge nugget with chapters, quotes and FAQ
Microsoft Purview – the main topic, adding governance, protection and risk tools around data it does not store
Sensitivity labels – handling instructions that can add watermarks, encrypt files or limit forwarding and printing
Data loss prevention (DLP) – checks risky actions like personal cloud uploads and can warn, block or record them
Related episode: Microsoft Purview Audit - Simply Explained

Microsoft Entra Connect - Simply Explained

Sat, 15 Aug 2026 21:55:02 +0000

Duplicate accounts, separate passwords and leavers who keep cloud access are classic hybrid identity problems. This episode explains Microsoft Entra Connect in plain English for IT admins and anyone running Active Directory alongside Microsoft 365. You will learn how sync, authentication and health monitoring work together and where the tool's limits are.

In this episode

00:00 – Two identity systems, one person
01:06 – Active Directory and Entra ID
04:41 – Building block one: Sync
08:48 – Building block two: Authentication
13:38 – Building block three: Health
15:44 – What Entra Connect does not do
18:25 – One employee, one connected identity
19:20 – Put it to work

Key takeaways

Microsoft Entra Connect is the controlled bridge that syncs selected users, groups and details from on-premises Active Directory to Microsoft Entra ID, with Active Directory remaining the source of authority.
Password hash synchronization fits most organizations, pass-through authentication keeps the local directory in every password check, and federation suits existing sign-in systems.
Entra Connect Health warns when sync stops, which matters most when disabled accounts must also lose cloud access, and Entra Connect is neither a backup nor a replacement for MFA or conditional access.

Worth quoting

“Editing the same synced detail directly in EntraID can either fail or get replaced later by the local value. That sounds strict, but it prevents two filing cabinets from arguing over which record is correct.” – Mirko Peters (04:14)

“But sync has a clear limit. Entra Connect doesn't assign a Microsoft 365 license, just because it creates Alex's cloud account. It also doesn't create a mailbox by itself.” – Mirko Peters (07:28)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on hybrid identity
Microsoft Entra Connect – the bridge this episode explains, covering sync, sign-in methods, health monitoring and its limits
Active Directory – the on-premises staff directory that stays the source of authority for synced users
Microsoft Entra ID – the cloud directory that receives synced identities and handles Microsoft 365 sign-ins and access
Microsoft 365 – the cloud services employees reach once their synced identity and license are in place
Related episode: Microsoft Entra Cloud Sync - Simply Explained

Microsoft Entra Cloud Sync - Simply Explained

Sat, 15 Aug 2026 20:19:50 +0000

Many organizations still keep identities in on-premises Active Directory while their people work in Microsoft 365. This knowledge nugget helps identity admins understand Microsoft Entra Cloud Sync, how it differs from Entra Connect, what changed in 2026, and how to run a safe, small pilot before deciding.

In this episode

00:00 – Intro: two places where identity matters
00:52 – Why identity sync exists
03:55 – What Microsoft Entra Cloud Sync actually is
07:57 – High availability and multiple forests
11:00 – Scoping, mappings, provision on demand and safeguards
14:39 – Cloud Sync versus Entra Connect and the 2026 shift
18:22 – A safe first move for your company

Key takeaways

Microsoft Entra Cloud Sync moves most identity sync processing into Microsoft Entra, leaving only lightweight provisioning agents in the local network that connect outbound to the cloud.
Multiple agents provide built-in failover and can connect separate Active Directory forests to one tenant, while scoping by OU or security group and provision on demand keep pilots controlled.
Entra Connect still fits setups with pass-through authentication, federation, advanced custom rules or specific Exchange hybrid needs, so compare requirements before migrating and never let both tools manage the same objects.

Worth quoting

“No, Cloud sync is newer but newer does not automatically mean it fits your setup. The right choice depends on what your identity system needs to do today, not on which product sounds more modern.” – Mirko Peters (14:45)

“An outbound connection means the agent starts the conversation with the cloud. You don't need to open your network and wait for an unknown connection to come in.” – Mirko Peters (04:30)

Explore more on M365.FM

Episode page: the full knowledge nugget with chapters, quotes and FAQ
Microsoft Entra Cloud Sync – the main topic, covering lightweight agents, cloud-managed configuration, scoping and the 2026 additions
Microsoft Entra Connect – the server-based sync tool compared with Cloud Sync, still the better fit for some setups
Active Directory – the on-premises source of user records that Cloud Sync reads and keeps authoritative
Related episode: Microsoft Entra Domain Services - Simply Explained

Everyone Wants Copilot—but Is Your Data Ready: Microsoft Fabric Architecture with Walter Calcagno [MVP-MCT]

Sat, 15 Aug 2026 16:30:41 +0000

Everyone wants Copilot and agents, but fragmented data and weak governance undermine trustworthy answers. Mirko Peters talks with Walter Calcagno about Microsoft Fabric, semantic models, ontology layers, metadata and his AI readiness approach. Data architects, BI teams and decision makers learn what must exist between the lakehouse and a reliable AI experience.

In this episode

00:00 – Intro: is your data ready for Copilot?
02:47 – Walter's path from accounting to data and Spanish content
09:34 – Power BI and asking the right business questions
19:09 – Microsoft Fabric, OneLake and Delta Lake
24:25 – Semantic models, ontology and AI access
30:20 – Medallion layers and data ready for AI
37:39 – AI readiness assessment and the seven-layer model
48:07 – Governance, Fabric Apps and rapid fire

Key takeaways

AI on enterprise data starts with business questions, clear KPI definitions and governance, not with a chat prompt or a specific tool.
In Microsoft Fabric, semantic models and an ontology layer above them give LLMs a governed, cost-efficient path to the right data, guided by good metadata.
Medallion architecture is flexible: use as many layers as needed, at least two, and prepare specific data for AI to keep token costs under control.

Worth quoting

“So companies don't need to make more dashboard. They need to answer more business question because the real business is on the street” – Walter Calcagno (16:55)

“You need to define what is your definition of the KPI. If you have sales in your perspective, you need to prompt that into the LLM.” – Walter Calcagno (36:40)

Explore more on M365.FM

Episode page: the full interview with chapters, quotes and FAQ
Walter Calcagno – data architect and Microsoft MVP explaining semantic models, ontology layers and AI readiness
Microsoft Fabric – Walter's main platform, with OneLake built on Delta Lake and Fabric Apps in client projects
Semantic model – where Fabric data lives for AI access, linked across models by an ontology layer
Related episode: From Financial Data to AI-Ready Decisions: Power BI, Microsoft Fabric, Semantic Models & AI Agents with Rishi Sapra [MVP]

Microsoft Entra Domain Services - Simply Explained

Fri, 14 Aug 2026 19:02:51 +0000

Moving an old Windows app to an Azure VM does not remove its need for a classic domain with LDAP, Kerberos and Group Policy. This Knowledge Nugget shows IT admins and cloud architects where Microsoft Entra Domain Services fits next to Entra ID and Active Directory, and which limits to check before choosing it.

In this episode

00:00 – The cloud app that still expects a Windows domain
00:45 – Why Entra ID alone cannot run every legacy app
03:28 – What Microsoft Entra Domain Services actually is
07:20 – Entra ID, Active Directory and Domain Services: different jobs
10:40 – When Domain Services fits and when it does not
13:53 – The managed-service trade-offs
15:35 – A simple Azure migration story

Key takeaways

Microsoft Entra Domain Services provides a managed Windows domain inside an Azure virtual network for legacy apps that still need LDAP, Kerberos, NTLM, domain join or Group Policy, without you running domain controllers.
Identity data flows one way, from on-premises Active Directory or Entra ID into the managed domain, so users and groups must be managed in the source directory, and cloud-only users may need a password change before they can use it.
New cloud apps should sign in directly through Entra ID; Domain Services does not fit apps that need LDAP write access, schema changes or full domain admin control.

Worth quoting

“The main identity record stays in Entra ID. Users and groups from Entra ID copy into the managed domain so the older app can see and use them in the form it understands.” – Mirko Peters (05:16)

“For cloud-only users, that often means the user needs to change their password after domain services is enabled. That password change creates the protected form needed for the managed domain.” – Mirko Peters (06:18)

Explore more on M365.FM

Episode page: the full Knowledge Nugget with chapters, key quotes and FAQ
Microsoft Entra Domain Services – the managed Windows domain in an Azure virtual network for apps that need LDAP or Kerberos
Microsoft Entra ID – the source of cloud identities, which copy one way into the managed domain
Active Directory – the self-run domain for hybrid companies and the better choice when full domain control is needed
Related episode: Group Policy - Simply Explained
Related episode: Microsoft Entra Cloud Sync - Simply Explained

The Future of AI Software Factories- OpenCLAW, Agent Orchestration & The Intelligence Age with Mark Smith [MVP]

Fri, 14 Aug 2026 15:00:05 +0000

What happens when AI agents become the whole software team? Mirko Peters talks with Mark Smith (NZ365Guy) about his OpenClaw-based AI software factory, Ralph loops, governance and why context engineering matters more than prompts. A practical look ahead for developers, consultants and IT leaders preparing for AI-first software engineering.

In this episode

00:00 – Welcome and introducing Mark Smith
01:44 – From IT training to Dynamics CRM and Power Platform
08:45 – Low code superseded by AI
13:44 – Microsoft's AI strategy and Copilot adoption
21:31 – Building a nine-agent AI software factory
41:10 – OpenClaw, harnesses and Copilot Studio
44:08 – Governance, email agents and AI at the edge
50:19 – Preparing for an AI-first career and rapid fire

Key takeaways

Mark Smith runs a nine-agent AI software factory in which each agent fills one gated role in the DevOps loop, from requirements and architecture to coding, security, release and documentation.
Owning the agent harness with OpenClaw keeps context and data in his own Azure environment, so models from different providers can be swapped without rebuilding the system.
For an AI-first career, Mark recommends moving from prompt engineering to context and outcomes engineering, learning about harnesses and avoiding lock-in to a single vendor.

Worth quoting

“The day of low code has been superseded by AI. And that, I can do a lot more with a lot deeper technical functionality and technical ability.” – Mark Smith (08:45)

“And so what I loved about open claw is that I own the harness, right? I can plug, as I said, I've got nine different API connections, not even including open router.” – Mark Smith (41:10)

Explore more on M365.FM

Episode page: the full conversation with Mark Smith, including chapters, key quotes and FAQ
Mark Smith – the NZ365Guy, who explains the nine-agent AI software factory he built on OpenClaw
AI agent – nine gated agents cover roles from requirements and architecture to verification, release and documentation
Microsoft 365 Copilot – Mark's critique of Copilot adoption and his advice to learn Copilot and Work IQ properly
Related episode: Power Platform Copilot Integration - Simply Explained

Why Your Business Central Won't Scale to Finance & Operations

Thu, 13 Aug 2026 19:00:02 +0000

Many IT leaders assume a growing company can simply upgrade from Business Central to Dynamics 365 Finance and Operations later. This episode explains why that bridge does not exist, why acquisitions hit the wall hardest, and how finance and IT teams can plan a realistic phased path before a deal forces their hand.

In this episode

00:00 – The Business Central to F&O trap
02:53 – Upgrade vs. re-implementation
05:45 – Two systems, two design philosophies
13:25 – Why M&A is the real trigger
16:10 – Dataverse, dual-write and the patchwork
21:36 – Break-even: patchwork vs. migration
26:49 – Process redesign and data cleanup
41:47 – The phased path and common mistakes

Key takeaways

Business Central and Finance and Operations come from different lineages (NAV and AX), so moving between them is a full re-implementation rather than an upgrade.
Acquisitions and multi-entity consolidation are what expose the gap, and Dataverse sync, dual-write and batch GL transfers only form a lagging patchwork.
Plan early by designing the chart of accounts and master data for consolidation, documenting customizations and following a phased path with a parallel run.

Worth quoting

“Business central to finance and operations isn't that. It's not a newer version of the same thing, it's a full re-implementation, and those two words carry very different weight once you understand what's actually different underneath.” – Mirko Peters (03:36)

“growth in scale and growth in shape are two different things and only one of them runs you into this particular wall” – Mirko Peters (35:40)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on ERP migration
Dynamics 365 Business Central – the NAV-based ERP that fits smaller companies but hits a wall with multi-entity consolidation
Dynamics 365 Finance and Operations – the AX-based enterprise ERP that requires a full re-implementation rather than an upgrade
Dual-write – near real-time sync built for F&O and customer engagement apps, not for Business Central
Related episode: Dynamics 365 Dual-write - Simply Explained

PowerPoint Like a Pro- Hidden Features, Corporate Templates & Copilot with Fiona Walsh [MVP]

Thu, 13 Aug 2026 13:00:03 +0000

Most professionals use PowerPoint every day but miss features that have existed for years. In this interview, PowerPoint MVP Fiona Walsh shows presenters, template owners and Microsoft 365 users which fundamentals, template practices and Copilot techniques make presentations faster to build and clearer to deliver.

In this episode

00:00 – Intro: why PowerPoint is underestimated
01:00 – Fiona's path from chemistry to PowerPoint
04:38 – What professionals misunderstand about PowerPoint
08:30 – Fundamentals: alignment tools, grouping and the Selection Pane
18:20 – SmartArt, shortcuts and the Quick Access Toolbar
26:40 – Corporate templates that work
33:30 – Copilot in PowerPoint: strengths and limits
45:00 – Delivery tools, storytelling and quick-fire round

Key takeaways

Many PowerPoint problems come from using one deck for different purposes: a handout read as a PDF needs a different design from slides that support a live speaker.
Long-standing fundamentals such as the alignment tools, grouping, the Selection Pane, SmartArt conversion and the Quick Access Toolbar save time even for experienced users.
Copilot and Designer work best with a robust corporate template with many layouts and image placeholders, and Copilot is especially useful for structuring ideas, finding hooks and endings, and anticipating audience questions.

Worth quoting

“People don't tend to realize that one deck doesn't suit all different applications. And that's why PowerPoint gets the bad name.” – Fiona Walsh (03:32)

“If it's a slide that I haven't created, the first thing I'd want to do is click on the selection pane because then I can see how the slide's been put together.” – Fiona Walsh (11:33)

Explore more on M365.FM

Episode page: the full interview with Fiona Walsh, including chapters, key quotes and FAQ
Fiona Walsh – PowerPoint MVP and trainer sharing fundamentals, template advice and Copilot techniques from her sessions
Microsoft PowerPoint – the focus of the episode, from alignment tools and SmartArt to Presenter View features
Microsoft 365 Copilot – Copilot in PowerPoint for structuring ideas, finding hooks and endings, anticipating questions and creating images
Related episode: Microsoft 365 Copilot: What Actually Makes People More Productive with Adrian Espes [MVP]

Microsoft Cloud PKI - Simply Explained

Thu, 13 Aug 2026 09:04:23 +0000

Shared Wi-Fi passwords and repeated VPN logins are still common in small businesses, yet running a traditional certificate infrastructure is often too much work. This episode explains certificates and Microsoft Cloud PKI in plain language and shows IT admins how Intune can deliver, renew and revoke device certificates behind the scenes.

In this episode

00:00 – The device access problem
00:46 – Why certificates exist
03:31 – Traditional PKI as a burden
06:27 – What Microsoft Cloud PKI is
09:40 – How a device gets a certificate
13:09 – Where Cloud PKI fits
16:08 – Starting with a small pilot

Key takeaways

Device certificates let managed laptops and phones prove they belong without shared Wi-Fi or VPN passwords.
Microsoft Cloud PKI moves the root and issuing certificate authorities into Intune, removing on-premises servers, NDES connectors and HSM hardware from the plan.
Cloud PKI only covers Intune-managed devices, so start with one use case, make sure the Wi-Fi, VPN or app trusts the certificate chain, and test renewal and revocation.

Worth quoting

“A shared Wi-Fi password can travel. Someone can write it down forward it, reuse it on a personal device, or keep it after leaving the company. A device certificate gives each managed laptop or phone its own proof instead.” – Mirko Peters (01:56)

“Microsoft Cloud PKI keeps the certificate process, but shifts much of that machinery out of your server room and into the Microsoft Cloud.” – Mirko Peters (06:20)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and FAQ on Microsoft Cloud PKI
Microsoft Cloud PKI – the managed certificate authority service inside Intune that this episode explains end to end
Microsoft Intune – confirms devices are enrolled and managed, then delivers, renews and revokes their certificates
Zero Trust – the principle that device certificates support by checking each device's proof on every request
Microsoft Entra ID – cast as the reception desk handling sign-in identity, and a basic to check before a pilot
Related episode: Microsoft Intune - Simply Explained

Internal Developer Platforms (IDPs) - Simply Explained

Thu, 13 Aug 2026 06:50:13 +0000

Developers often spend more time on tickets, permissions and cloud setup than on the feature they were asked to build. This episode explains internal developer platforms in plain English for IT and engineering leaders, covering golden paths, service catalogs, guardrails and how Azure tools fit behind a single self-service request.

In this episode

00:00 – From tickets to self-service
00:46 – Why developers need a better way
03:37 – Golden paths
06:53 – The service catalog
09:29 – Guardrails and identity
13:05 – Automation behind Create Service
16:41 – IDP myths and where Azure fits

Key takeaways

An internal developer platform is a self-service front door to approved building blocks, run by a platform team that treats developers as customers.
Golden paths, a service catalog and guardrails built on Entra ID, Azure Policy and Key Vault let teams move fast without manual approvals or unsafe shortcuts.
An IDP is not a single portal product; start with one painful workflow and one golden path, then measure waiting time, tickets and developer feedback.

Worth quoting

“A golden path is an approved, repeatable route for a job that teams do often. It doesn't tell every developer how to write their code.” – Mirko Peters (03:42)

“If the platform says no without a route forward, people will build their own workarounds outside the platform. That creates the exact confusion the platform was meant to reduce.” – Mirko Peters (06:23)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and FAQ on internal developer platforms
Microsoft Azure – supplies the compute, storage, networking, monitoring, policy and security behind the platform's golden paths
Azure DevOps – one option for hosting code and running the build and release pipelines behind a service
Microsoft Entra ID – described as the reception desk that places developers in groups for least-privilege access
Azure Key Vault – the protected place for secrets so passwords stay out of code and pipeline files
Related episode: Azure Platform Engineering, Azure Landing Zones, Cloud Adoption Framework & Building Enterprise Cloud Platforms Jev Suchoi [MVP]

Why Power Platform Is Your Real Automation Layer — Not Custom Code

Wed, 12 Aug 2026 19:00:02 +0000

In many Dynamics 365 projects, every automation request ends up as custom code in a developer backlog, and the business pays for it every time a rule changes. This episode shows Dynamics and Power Platform teams where plug-ins still belong, how to make automation visible and owned, and how to migrate safely to Power Platform as the real automation layer.

In this episode

00:00 – Automation as a development backlog
04:25 – The hidden cost of custom code
08:40 – Where custom code still belongs
12:14 – Reasoning between event and action
16:46 – Sales approval without a plug-in
24:06 – Ownership, solutions and environments
35:20 – Governance, DLP and Dataverse security
51:09 – Inventory, migration and a 90-day reset

Key takeaways

Keep plug-ins narrow for transactional validation and performance-critical work, and move orchestration across people, systems and time into Power Platform.
Business-critical flows need organizational identities, solutions with environment variables and managed deployments instead of personal ownership and production edits.
Governance through environments, DLP policies and Dataverse security is an operating model that lets automation scale, starting with an inventory rather than a rewrite.

Worth quoting

“This isn't an argument against developers, it's an argument against using developers as the routing layer for every business process change.” – Mirko Peters (03:36)

“Then somebody asks why dynamics feels slow to change. Dynamics isn't slow, the automation model is.” – Mirko Peters (06:24)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Dynamics automation
Dynamics 365 – the application where every automation request turns into a developer backlog item and hidden custom code
Power Platform – proposed as the visible, owned automation layer for processes crossing people, systems and time
Dataverse – the event pipeline where transactional validation still belongs, plus security roles that bound automation
Automation – the episode's core subject: moving it from accumulated customization to an operating model with owners
Related episode: Power Apps - Simply Explained

Power Platform Governance Without Killing Innovation: Security, DLP, Environments & Citizen Development with Michael Roth [MVP]

Wed, 12 Aug 2026 13:00:02 +0000

Many organizations either leave Power Platform wide open or bury makers in approvals. In this interview, Microsoft MVP Michael Roth explains to admins and platform owners how inventory, environments, DLP policies and clearly explained boundaries make governance an enabler for citizen developers rather than a brake on innovation.

In this episode

00:00 – Introduction to Power Platform governance
02:25 – Michael's path into Power Platform
08:30 – Platform, not just a set of tools
15:23 – When harmless apps become critical
19:31 – Governance as traffic rules
30:04 – Clarity, confidence and boundaries
40:01 – Inventory as the foundation
47:55 – Environments, ALM and DLP

Key takeaways

Power Platform is an enterprise platform that happens to be accessible, so tenants need deliberate setup instead of open default settings.
Governance built on clarity, confidence and explained boundaries speeds up makers and reduces shadow IT, while overly bureaucratic processes drive people away.
Start with an inventory, structure environments, and use DLP policies, tenant settings, roles and ALM where solutions become business critical.

Worth quoting

“So it all depends on the context, what is critical or what is not, what is secure, what is insecure, it's never the app, almost never the app, it's almost always the behavior of the people.” – Michael Roth (18:37)

“If I know what will happen, if everything is clear to me, then I can choose my actions and do so. And clarity in Power Platform is exactly that.” – Michael Roth (30:50)

Explore more on M365.FM

Episode page: the full interview with chapters, quotes and FAQ on Power Platform governance
Michael Roth – the MVP guest who explains his governance approach built on clarity, confidence and boundaries
Simon Owen – named by Michael Roth at the end as a UK community colleague worth inviting next
Craig White – another UK community colleague Michael Roth suggests as a future guest
Power Platform – the platform whose tenant setup, environments and DLP policies the whole episode is about
Governance – reframed in this episode as clarity, confidence and explained boundaries instead of bureaucracy
Related episode: Power Platform Copilot Integration - Simply Explained

Git - Simply Explained

Wed, 12 Aug 2026 09:05:08 +0000

If your project folders are named final, final-final and use-this-one, Git is the fix. This episode explains Git in plain English for beginners, makers and Microsoft 365 builders: commits, the staging area, branches, merges, conflicts and how GitHub and pull requests fit into a team workflow.

In this episode

00:00 – Git is your project history
03:26 – The three local areas: working directory, staging area, repository
07:17 – Branches, merges and conflicts
10:46 – GitHub, the shared online repository
13:55 – A Git-based team workflow
15:55 – CI/CD, AI and the daily route

Key takeaways

Git is a local-first version control system that records deliberate, named checkpoints called commits, so you can see what changed and return to an earlier version.
Changes move from the working directory through the staging area into the local repository, while branches let you work safely without disturbing the trusted main version.
GitHub adds a shared remote repository and pull requests for review and automated checks, turning separate computers into one team workflow: work, stage, commit, push, review, merge.

Worth quoting

“So think of Git as your project's memory, not a magic undo button, and not a coding language. It's a system for creating deliberate, named checkpoints that you can inspect later” – Mirko Peters (03:10)

“Git is the tool that tracks your project history. GitHub is an online place where people can share that history.” – Mirko Peters (02:29)

Explore more on M365.FM

Episode page: the full knowledge nugget with chapters, key quotes and a short FAQ
GitHub – the shared remote repository where teams push branches and review pull requests
Azure DevOps – named briefly as one alternative to GitHub for hosting Git repositories
Mirko Peters – host of this knowledge nugget, explaining Git step by step in plain English
Related episode: Git Branching Strategies - Simply Explained

Azure Well-Architected Framework - Simply Explained

Wed, 12 Aug 2026 04:00:03 +0000

Unexpected Azure bills, over-permissive apps and late-night outages often come from the decisions around a service, not the service itself. This episode explains the Azure Well-Architected Framework and its five pillars for cloud architects, developers and IT teams. You learn how to weigh trade-offs and run a practical review on one workload.

In this episode

00:00 – Why Azure decisions go wrong
00:59 – WAF versus CAF
02:38 – Reliability
05:32 – Security
08:28 – Cost optimization
11:00 – Operational excellence
13:47 – Performance efficiency
16:05 – Trade-offs and the WAF review

Key takeaways

The Azure Well-Architected Framework is a decision framework for one workload at a time, while the Cloud Adoption Framework prepares the shared company-wide foundation.
Each of the five pillars forces trade-offs, so goals like cost reduction should always be phrased together with the agreed recovery and security targets.
Start small with one important workload, run the Azure Well-Architected review and turn its recommendations into an owned, prioritized backlog.

Worth quoting

“It isn't an Azure product you turn on. It isn't a compliance badge you earn. It's a decision framework for designing and running a workload that can hold up over time.” – Mirko Peters (00:30)

“So the question isn't how much reliability can we buy. It is what level of reliability does this workload need and what are we willing to support?” – Mirko Peters (05:18)

Explore more on M365.FM

Episode page: the full episode with chapters on all five pillars, quotes and FAQ
Microsoft Azure – the platform whose workloads, bills and outages the framework helps you design around
Microsoft Cloud Adoption Framework – the company-wide foundation that prepares the airport while WAF helps one plane fly
Zero Trust – the security thinking behind checking every identity and giving the smallest access needed
Related episode: Azure Platform Engineering, Azure Landing Zones, Cloud Adoption Framework & Building Enterprise Cloud Platforms Jev Suchoi [MVP]

The Copilot Assumption That's Holding You Back — Agentic RAG

Tue, 11 Aug 2026 19:00:02 +0000

Many teams still treat Copilot as a search box and blame the tool when answers come back incomplete. This episode explains agentic RAG, the orchestration loop behind modern Copilot, for IT decision makers and Microsoft 365 architects. You learn when agentic retrieval is worth its cost, when simple retrieval wins and how to govern agents that act on their own.

In this episode

00:00 – The Copilot-is-search assumption
02:57 – Where single-shot RAG breaks
05:21 – What agentic RAG is and the orchestration loop
13:29 – Performance data and trade-offs
18:13 – Hybrid RAG and Copilot Wave 3
22:33 – Agents as digital employees
30:43 – MCP and why grounding matters
35:38 – Adoption, production reality and ROI

Key takeaways

Agentic RAG turns the language model from a passive summarizer into a decision maker that plans, retrieves from multiple sources, evaluates results and queries again.
Agentic RAG improves accuracy on complex multi-source tasks but costs more and runs slower, so most enterprises route simple lookups to traditional retrieval in a hybrid design.
Autonomous agents need identity in Entra, oversight through Purview, audit trails and enforced grounding before they can be trusted in production.

Worth quoting

“A system that's 10 times more expensive isn't better. It's better for something specific at a cost that has to be worth paying. The real question isn't which is better. It's which task deserves which architecture.” – Mirko Peters (15:28)

“So the more freedom you give the system to reason on its own the more grounding has to be enforced not less” – Mirko Peters (34:40)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on agentic RAG in Copilot
Retrieval-augmented generation (RAG) – the single-shot retrieval architecture behind the Copilot-is-search assumption and its limits
Microsoft 365 Copilot – the product shifting from a question-answering tool to an orchestrator that plans, checks and acts
AI agent – framed as a digital employee that needs its own Entra identity, access controls and audit trail
Agent loop – the six-stage orchestration loop from query understanding to safety checks, walked through step by step
Related episode: Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It

From Demo to Production- Building Enterprise AI Agents That Actually Work with Microsoft Copilot Studio with Elliot Margot [MVP]

Tue, 11 Aug 2026 13:00:03 +0000

Many AI agents look impressive in a demo but fail in production because of governance gaps, poor data and runaway costs. This episode helps Copilot Studio makers, architects and IT leaders move from chatbot experiments to secure, governed enterprise agents with RAG, MCP and multi-agent designs.

In this episode

00:00 – Intro and Elliot's journey into generative AI
06:56 – Why enterprise AI is hard: governance and DLP
10:43 – Selling AI to executive sponsors: ROI and the wow effect
16:17 – Multi-agent systems and orchestration
21:06 – RAG, metadata, versioning and chunking
27:38 – MCP explained
31:05 – Governance, DLP and citizen development
47:46 – The future of agents, model choice and token costs

Key takeaways

Enterprises learn AI governance fastest by building small solutions while steadily improving DLP policies, sensitivity labels and monitoring rather than waiting for a perfect model.
Good RAG depends on good data: well-described metadata, a clean production knowledge base without outdated versions, and careful chunking keep answers accurate and token costs down.
Production agents need clearly communicated tasks, tightly scoped connectors, manual testing and the right model size, because small language models are often enough and endless agent loops can become expensive.

Worth quoting

“You can't see the results of the governance in place if you don't start. So you can have to start while building it.” – Elliot Margot (08:48)

“Maybe you want to remove a MailChimp, if it's not in your scope, really keep the scope small, so that you're not able to use things that you shouldn't be able to.” – Elliot Margot (33:05)

Explore more on M365.FM

Episode page: the full conversation with chapters, key quotes and a short FAQ
Elliot Margot – Microsoft MVP and Jumpstart team lead sharing lessons from enterprise Copilot Studio agents
Copilot Studio – the main build tool discussed, from knowledge metadata to DLP and model billing levels
AI agent – the core building block, from the RFP agent to multi-agent slide reviews
Related episode: Beyond Copilot: Building Enterprise AI Agents That Actually Work with Copilot Studio with Manpreet Singh [MVP-MCT]

Microsoft Cloud Adoption Framework - Simply Explained

Tue, 11 Aug 2026 08:00:04 +0000

Microsoft Cloud Adoption Framework, commonly called CAF, helps organizations avoid one of the most common cloud mistakes: moving into Azure before deciding how the environment should actually work. Creating an Azure subscription and deploying a virtual machine is easy. Building an environment where applications, security, networking, costs, governance, and operational responsibilities remain manageable as the organization grows is much harder. CAF provides Microsoft's structured guidance for that journey. It helps organizations decide why they're adopting Azure, plan what should move, prepare the Azure foundation, migrate or modernize workloads, establish governance, and operate the environment over time.
ㅤ
WHY THE CLOUD NEEDS A PLAN
Azure gives organizations enormous flexibility. Teams can create virtual machines, databases, storage, networks, applications, and many other services within minutes. But flexibility doesn't automatically produce good architecture. Without shared decisions, one team might expose services publicly because it's convenient. Another might create expensive resources without clear cost ownership. Another could deploy an application before the required network connectivity exists. Eventually nobody knows exactly who owns what, why resources exist, or who is responsible when something fails. CAF provides a framework for making those decisions before this becomes normal.
ㅤ
WHAT IS THE CLOUD ADOPTION FRAMEWORK?
The Microsoft Cloud Adoption Framework isn't an Azure product you install. It isn't a certification. And it isn't a button that automatically creates the perfect Azure environment. Instead, CAF provides guidance for organizing the decisions, responsibilities, architecture, governance, and operational processes required for cloud adoption. Its core journey can be understood through Strategy, Plan, Ready, Adopt, Govern, Secure, and Manage activities.
ㅤ
STRATEGY: WHY ARE YOU MOVING TO AZURE?
Cloud adoption shouldn't begin with the question, "Which Azure service should we buy?" Start with the business problem. An organization might need to leave an aging data center. Product teams may need to release software faster. Applications might need to serve users in multiple regions. The organization could require better disaster recovery or more transparent cloud spending. These objectives lead to different technical decisions. The strategy should therefore describe measurable outcomes rather than simply stating that the organization wants to "move to the cloud."
ㅤ
TURN BUSINESS GOALS INTO MEASURABLE OUTCOMES
Useful cloud goals are specific. "Move these ten servers before hardware support ends" gives teams a deadline and measurable result. "Reduce application release time from weeks to days" connects cloud adoption to development productivity. "Give every department a cloud budget with an identified owner" creates financial accountability. These objectives help technical, business, security, and finance teams understand what success actually means.
ㅤ
PLAN: UNDERSTAND WHAT YOU ACTUALLY HAVE
Once the objective is clear, planning turns strategy into practical work. Organizations need an inventory of applications, data, dependencies, owners, skills, risks, and timelines. Dependencies are particularly important. An apparently simple application might depend on a database, shared file location, authentication service, scheduled task, and another business application. Moving only the visible server without understanding those relationships can result in a migration that technically completed but left the application unable to operate.
ㅤ
CHOOSE THE RIGHT MIGRATION PATH
Not every workload should move to Azure in the same way. Some applications can be rehosted, commonly called lift and shift. The existing application moves to Azure with relatively few changes. Others can be replatformed by moving individual components to managed Azure services. Some applications benefit from refactoring or rebuilding. Others might be replaced with a SaaS product or remain outside Azure entirely. Cloud adoption doesn't mean everything must move. The correct approach depends on the workload, business objective, risk, cost, and available time.
ㅤ
DON'T START WITH YOUR WORST APPLICATION
Organizations sometimes choose their oldest and most problematic application as their first Azure migration because it feels urgent. That can create a difficult first experience. The application may be poorly documented, dependent on forgotten systems, and understood by very few people. A better first workload is important enough to provide meaningful lessons but simple enough that its architecture, ownership, data, and success criteria are understood. The first migration should help the organization learn how its cloud model works.
ㅤ
READY: PREPARE AZURE BEFORE WORKLOADS ARRIVE
The Ready phase prepares the Azure environment. One of the central concepts is the Azure landing zone. A landing zone is a prepared Azure environment where applications and data can operate within established identity, networking, security, governance, monitoring, and organizational boundaries. Instead of allowing every application team to independently invent these foundations, the organization creates an environment workloads can safely enter.
ㅤ
WHAT IS AN AZURE LANDING ZONE?
Think of an Azure landing zone like preparing an office before employees arrive. The building needs electricity, doors, network connectivity, security, shared facilities, and rules. You wouldn't move hundreds of employees into an empty building and tell every department to design its own electrical system and security model. Azure landing zones apply the same principle to cloud infrastructure. Common foundational decisions are prepared before workloads arrive.
ㅤ
IDENTITY WITH MICROSOFT ENTRA ID
Identity is one of those foundational components. Microsoft Entra ID controls digital identities and helps determine who or what can access Azure resources. Users should receive only the permissions required to perform their work. Applications and services should follow the same principle. Giving everyone broad permissions might initially appear easier, but it increases the impact of mistakes and compromised identities.
ㅤ
ORGANIZING AZURE RESOURCES
Azure provides several organizational layers. Management groups can apply shared governance across multiple subscriptions. Subscriptions provide boundaries for areas such as billing, access, and workloads. Resource groups organize related Azure resources inside subscriptions. Naming conventions and tags provide additional context such as workload owner, department, environment, or cost center. The objective is to make the Azure environment understandable rather than creating a complicated naming system that nobody can remember.
ㅤ
NETWORKING IS PART OF THE FOUNDATION
Azure networking determines how workloads communicate with each other, with the internet, and with systems that remain outside Azure. Some applications require private connectivity to databases. Others need public connectivity for customers. Certain systems should never communicate directly with one another. A landing zone establishes these connectivity patterns before every workload team independently creates its own approach.
ㅤ
PLATFORM AND APPLICATION LANDING ZONES
Organizations can separate shared platform capabilities from individual workload environments. A platform landing zone can provide shared services such as identity, networking, monitoring, backup, and security. Application landing zones provide spaces for individual workloads or teams. A customer website and an internal finance application might therefore operate in different application landing zones while still using the organization's shared identity, networking, monitoring, and governance approach.
ㅤ
AZURE POLICY
Azure Policy can enforce or evaluate organizational rules. Organizations might require specific tags so every resource has an owner. They might restrict deployments to approved Azure regions. Storage configurations allowing inappropriate public access could be blocked. The objective isn't to make Azure difficult to use. Policy should prevent predictable mistakes while still giving teams a clear path for deploying legitimate workloads.
ㅤ
DON'T BUILD EVERYTHING ON DAY ONE
Microsoft architecture diagrams can make cloud adoption appear enormous. A small organization doesn't need every possible enterprise component before deploying its first workload. The environment should match the organization's actual requirements. Start with the foundations you need, deploy representative workloads, learn from them, and improve the landing zone as real requirements emerge. A landing zone that looks perfect on a diagram can still encounter unexpected application requirements when real workloads arrive.
ㅤ
ADOPT: MOVE AND MODERNIZE WORKLOADS
The Adopt phase is where workloads begin moving into the prepared Azure environment. This can include migrating existing applications as well as modernizing them to take greater advantage of cloud services. A workload might be a website, database, business application, or collection of connected services. The important point is that deployment isn't complete simply because an application starts successfully.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure Image Builder - Simply Explained

Tue, 11 Aug 2026 04:00:04 +0000

Hand-built virtual machine images drift, depend on one admin's memory and break when steps are skipped. This episode explains Azure Image Builder and Azure Compute Gallery for Azure administrators and Azure Virtual Desktop teams. You learn how to build, validate, version and distribute the same approved image every time.

In this episode

00:00 – The problem with hand-built images
01:00 – What Azure Image Builder is
03:27 – The five building blocks of an image build
07:31 – What happens behind the scenes
12:08 – Azure Compute Gallery
15:30 – The parts that usually break
18:49 – A simple first plan

Key takeaways

Azure Image Builder turns hand-built golden images into a repeatable process driven by an image template with a source, customizations, validation, distribution and versioning.
Azure Compute Gallery organizes images into definitions and versions, replicates them to regions and enables rollback to a known good version.
Most build failures come from permissions, network access, policies and scripts, so use a least-access managed identity, silent scripts and the Packer logs to troubleshoot.

Worth quoting

“One person tests before capturing another skips a step because the deadline is tight. That's not a people problem. It's a process problem.” – Mirko Peters (00:38)

“You're not just saving time during setup. You're replacing memory and manual work with a process you can repeat.” – Mirko Peters (03:14)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on image builds
Microsoft Azure – the platform that runs image templates, temporary build resources and the finished images
Azure DevOps – suggested as the pipeline for running image builds regularly once a first template works
Azure Marketplace – the source of clean Windows or Linux starting images such as Windows 11 or Ubuntu
Azure Virtual Desktop – an example audience: an Azure Virtual Desktop team would likely start from Windows 11
Related episode: Azure Local and Landing Zones: How to Build Hybrid Cloud the Right Way with Christoffer Klarskov Jakobsen [MVP]

Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It

Mon, 10 Aug 2026 19:00:03 +0000

Copilot can answer a question perfectly today and fumble the same question tomorrow because it searches instead of remembering. This episode explains why RAG-based Copilot stays shallow and how the LLM Wiki pattern adds compiled, maintained knowledge, for IT leaders and Microsoft 365 architects. You learn how a hybrid Copilot with a wiki layer improves consistency, trust and governance.

In this episode

00:00 – Copilot searches, it doesn't remember
03:37 – What RAG actually does
05:59 – The stateless trap
10:55 – Enter the LLM Wiki
16:00 – Where Copilot's retrieval lives
26:36 – Trust and redundant knowledge
40:33 – Scale and hybrid Copilot
45:42 – Governance and getting started

Key takeaways

Copilot's Graph grounding is retrieval-augmented generation, which searches from zero on every query and therefore cannot build memory or consistency over time.
The LLM Wiki pattern compiles raw sources once into maintained, cross-linked pages governed by a schema and flags contradictions instead of silently averaging them.
Start with one recurring high-value knowledge domain, clean up its sources with retention, content types and ownership, and give a named owner responsibility for the schema.

Worth quoting

“Retrieval and memory are not the same thing. One finds information, the other builds on what it already knows.” – Mirko Peters (00:23)

“You can't prompt your way out of an architecture that has no place to store what it learns.” – Mirko Peters (09:54)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a FAQ on Copilot memory
Retrieval-augmented generation (RAG) – the retrieval method behind Copilot's Graph grounding that searches from zero on every query
Microsoft 365 Copilot – the assistant whose stateless retrieval the episode diagnoses and proposes extending with a wiki layer
Knowledge source – registering SharePoint sites as knowledge sources narrows the search but adds no memory
Related episode: The Copilot Assumption That's Holding You Back — Agentic RAG

Beyond Copilot: Building AI That Works in the Real World with Azure AI Foundry and Agentic AI for Frontline Workers with Fergus Kidd [MVP]

Mon, 10 Aug 2026 13:00:04 +0000

Most AI talk targets desk workers, yet the technicians, installers and inspectors in the field still drown in paperwork with little connectivity. Microsoft MVP Fergus Kidd, co-founder and CTO of FieldPal AI, shows builders and IT leaders how agentic AI on Azure AI Foundry, small language models and edge thinking can turn a short voice conversation into a complete, clean report.

In this episode

00:00 – From the ExoMars rover to AI at the edge
06:25 – Why frontline workers deserve more attention
09:20 – Connectivity, voice and wearable devices
13:08 – HoloLens, smart glasses and enterprise hardware
21:08 – Why FieldPal AI was founded
28:06 – Agentic AI on Azure AI Foundry
38:08 – Small language models, RAG and computer vision
53:08 – Rapid fire and advice: go and try it

Key takeaways

Frontline workers make up most of the workforce but are rarely the focus of AI, and they need voice-first, offline-capable tools that fit how they actually work.
Agentic AI on Azure AI Foundry lets one conversational interface orchestrate specialised agents for knowledge lookup, note taking and report filling, improving data quality at the point of entry.
Small language models grounded in curated data via Azure AI Search can be more reliable than large general models, provided the right information and good prompts go in.

Worth quoting

“if we've got the ability to do stuff at the edge, we kind of should, because it's quicker, faster, cheaper, and more resilient in terms of your closer to the person you're trying to help.” – Fergus Kidd (04:48)

“So the beautiful thing about small language models is that they don't always have this kind of inherent confidence that they know everything because their training sets are much smaller.” – Fergus Kidd (39:05)

Explore more on M365.FM

Episode page: the full interview with chapters, key quotes and a short FAQ
Fergus Kidd – Microsoft MVP and FieldPal AI co-founder, building voice-first agents for frontline workers
Azure AI Foundry – hosts all FieldPal AI models, its background agents and the speech capabilities
AI agent – specialised agents for lookup, note taking and reports behind one orchestrator
Related episode: How AI Changed Software Development Forever — Building the Agentic Future with Andre Baltieri [MVP]

Azure Compute Fleet – Simply Explained

Mon, 10 Aug 2026 09:01:28 +0000

Large batch jobs often stall because one exact VM size has no capacity when it is needed. This episode is for Azure architects and platform teams running simulations, rendering, testing or data processing at scale. You learn how Azure Compute Fleet, Spot VMs and a retry-safe workload design keep big jobs moving at a controlled cost.

In this episode

00:00 – Why one exact VM size blocks large deployments
00:34 – Compute Fleet in plain English
02:49 – Three choices that give Azure room to work
06:45 – Spot and on-demand VMs
10:07 – Compute Fleet versus virtual machine scale sets
14:03 – Example: an overnight risk calculation
17:26 – When to use it and what to decide first

Key takeaways

Azure Compute Fleet lets you request a large pool of capacity across several acceptable VM sizes, zones and pricing models instead of betting a deployment on one exact SKU.
Mixing on-demand VMs as a stable baseline with Spot VMs for extra throughput only works when progress lives outside the worker, in durable queues, checkpoints and retry-safe tasks.
Virtual machine scale sets fit steady application tiers that serve user traffic, while Compute Fleet fits batch, simulation, rendering and other work that splits across many independent workers.

Worth quoting

“With Compute Fleet, you list multiple acceptable VM sizes. Azure can then place some workers on one size and others on another as long as your workload runs on both.” – Mirko Peters (02:01)

“A Spot VM is not the place for the only copy of an important database, a single user facing server, or a job that loses hours of progress when one worker stops.” – Mirko Peters (07:43)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ
Microsoft Azure – the cloud where Compute Fleet searches VM sizes, zones and Spot or on-demand capacity
Mirko Peters – hosts this knowledge nugget and walks through Compute Fleet with an overnight risk example
Related episode: Building Azure That Survives the Real World — with Mike Martin [MVP]
Related episode: Azure Bicep - Simply Explained

Azure Update Manager - Simply Explained

Mon, 10 Aug 2026 04:00:07 +0000

https://www.m365.fm/categories/azure-talk/ Update Manager brings operating system patching into one central Azure-native service. Instead of managing updates through scattered tools, separate server lists, and disconnected reports, it gives IT teams a common place to assess missing updates, schedule maintenance, install patches, and verify what actually happened afterward. The important question isn't simply whether patching started. It's whether every required machine was successfully updated, which systems failed, which servers still require a restart, and where someone needs to take action.
ㅤ
WHAT IS AZURE UPDATE MANAGER?
Azure Update Manager is a service for checking, scheduling, installing, and tracking operating system updates across servers. Its primary focus is operating system updates for Windows and Linux rather than managing every application installed on every machine. The objective is to provide one place where administrators can understand the patching state of their server environment and manage the work required to keep those systems current.
ㅤ
MANAGING AZURE VIRTUAL MACHINES
Azure Update Manager can manage Windows and Linux Azure virtual machines. It also supports virtual machine scale sets, where multiple similar virtual machines can be created or removed automatically as demand changes. Instead of treating every VM as an isolated patching problem, administrators can establish a more consistent update process across groups of machines.
ㅤ
PATCHING SERVERS OUTSIDE AZURE
Not every enterprise server runs inside Azure. Organizations frequently have servers in their own data centers, branch offices, or other cloud environments. https://www.m365.fm/azure-arc-simply-explained/ provides the connection between these machines and Azure management. Once an external server is connected through Azure Arc, Azure Update Manager can include it alongside Azure virtual machines in the same patching environment. The server doesn't move into Azure. Azure Arc simply makes it manageable through Azure services.
ㅤ
ONE CENTRAL PATCHING VIEW
Combining Azure VMs and Azure Arc-enabled servers provides administrators with a more centralized view of patching. Teams can identify machines with missing updates, review patch status, investigate previous update runs, and see which machines comply with expected patching requirements. This doesn't remove ownership from individual infrastructure and application teams. Instead, it makes problems easier to identify and assign. When an update fails, teams have a common place to begin investigating.
ㅤ
ASSESSMENT: WHAT DOES EACH SERVER NEED?
Before installing updates, you need to understand what is actually missing. Azure Update Manager can assess machines and create a current picture of pending operating system updates. For most managed machines, automatic assessment occurs every 24 hours. This matters because patch status changes continuously. A server that was fully patched yesterday might have new updates available today, while another machine might have completed its updates and no longer require attention.
ㅤ
WINDOWS AND LINUX UPDATES
For Windows servers, assessment identifies applicable operating system updates. For Linux servers, Azure Update Manager checks available package updates from the configured update sources. The underlying operating systems handle updates differently, but the management question remains the same: which updates does this server still need?
ㅤ
SECURITY AND CRITICAL UPDATES
Not every update has the same priority. Security updates address known security weaknesses, while critical updates typically resolve serious system problems. Other updates may introduce broader functionality or changes to components that business applications depend on. This means patch management isn't simply about installing everything immediately. Organizations need processes that distinguish urgent security remediation from changes requiring additional testing.
ㅤ
UNDERSTANDING PATCH COMPLIANCE
Azure Update Manager provides a compliance view across managed machines. For example, an organization might have 100 servers, with 92 fully updated and eight still requiring attention. The important information isn't simply the 92 percent compliance figure. The real work is understanding why those eight servers remain noncompliant. One might have failed to reach its update source. Another could require a restart. Another might need additional investigation before the update can safely be installed. The dashboard identifies where to investigate. It doesn't eliminate the need for administrators to understand what happened.
ㅤ
MAINTENANCE WINDOWS
Knowing that an update exists doesn't tell you when it should be installed. A maintenance window defines when patching can safely take place. This is particularly important for production servers because some updates require restarts. Installing updates without considering business usage could interrupt applications, processes, databases, or users. Maintenance windows provide a controlled period for performing this work.
ㅤ
ONE-TIME AND RECURRING PATCHING
Azure Update Manager supports both urgent and recurring patching scenarios. A one-time update job can be used when an important security vulnerability needs to be addressed before the normal maintenance cycle. Recurring schedules can support regular patching operations, such as monthly maintenance after Microsoft's normal Windows update releases. Instead of rebuilding the same patching plan every month, teams can establish a repeatable schedule.
ㅤ
CONTROLLING WHICH UPDATES ARE INSTALLED
Within a patching schedule, administrators can determine which categories of updates should be included. Many organizations prioritize security and critical updates because they typically address the most immediate risks. Other update categories can be introduced according to the organization's testing and change-management processes. The objective isn't to install everything simply because an update exists. The objective is to decide what belongs in each patching cycle.
ㅤ
MANAGING REBOOTS
Some operating system updates don't become fully effective until the server restarts. For lower-risk systems, organizations might allow automatic restarts when required, provided they occur within the approved maintenance window. Critical business systems may require tighter control. A database, business application, or system with strict availability requirements might require the service owner to approve and coordinate the restart separately. Update installation and reboot strategy therefore need to be considered together.
ㅤ
AUTOMATIC VM GUEST PATCHING
Azure Update Manager supports automatic VM guest patching for supported Azure virtual machines. Azure can download and install operating system updates inside the VM according to the selected patching approach. This can reduce repetitive administrative work, but automation doesn't eliminate the need to understand and test the applications running on those servers.
ㅤ
HOTPATCHING
Hotpatching can reduce the number of required server restarts. On supported Windows versions and supported Azure virtual machines, certain security updates can be installed without rebooting the machine. This can be valuable for workloads where availability is particularly important. However, hotpatching doesn't eliminate maintenance windows. It only applies to supported systems and specific updates, and some changes will still require traditional restarts.
ㅤ
BUILD PATCH RINGS
A safer patching strategy moves updates through stages. Development and test systems can receive updates first. This gives teams an opportunity to identify application compatibility problems or unexpected behavior. After successful testing, updates can move to a small production pilot group. Only after those machines have been validated should the update reach the wider production environment. Separate maintenance windows for development, test, pilot, and production systems reduce the risk of one problematic update affecting the entire environment simultaneously.
ㅤ
UPDATE HISTORY AND VERIFICATION
A completed patch schedule doesn't necessarily mean every machine was successfully updated. One server might fail during installation. Another might require a restart. A third might never reach its configured update source. Azure Update Manager keeps update history so administrators can review what happened during individual update runs. This transforms patching from "we ran the job" into a more useful question: which servers still need attention?
ㅤ
https://www.m365.fm/azure-resource-graph/
Azure Update Manager uses Azure Resource Graph for compliance information. Azure Resource Graph provides a way to query information across managed Azure resources, allowing Update Manager to build centralized views of update and compliance status. For administrators, the important result is the ability to investigate patching status across many resources without manually checking every individual machine.
ㅤ
https://www.m365.fm/log-analytics-simply-explained/ IS NO LONGER REQUIRED
One important difference from the older patching architecture is that a Log Analytics workspace isn't required for the core Azure Update Manager service. https://www.m365.fm/azure-monitor-simply-explained/ and Log Analytics can still be valuable when organizations need alerts, deeper investigation, or additional histori

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure Elastic SAN — Simply Explained

Sun, 09 Aug 2026 20:00:02 +0000

As Azure environments grow, per-VM managed disks lead to paying for idle performance while busy workloads hit limits. This episode helps cloud architects and database teams understand Azure Elastic SAN, its building blocks and shared performance model, and decide when pooled block storage beats managed disks.

In this episode

00:00 – Why separate disks turn into a storage problem
04:23 – What Azure Elastic SAN actually is
07:15 – The three building blocks: SAN, volume groups and volumes
10:28 – How shared performance changes the design
13:51 – Where Elastic SAN fits and where it doesn't
17:14 – A simple way to decide

Key takeaways

Azure Elastic SAN pools high-performance block storage so that volumes share IOPS and throughput instead of each VM disk being sized for its own worst-case peak.
A SAN is organized into volume groups, which hold network and access rules, and volumes, which connect to workloads over iSCSI and whose performance scales with their size.
Elastic SAN fits groups of SQL Server databases, clustered workloads, Azure VMware Solution and supported Kubernetes designs whose peaks do not overlap, while small or isolation-sensitive workloads are often better on managed disks.

Worth quoting

“You might be paying for storage speed you aren't even using while another workload can't borrow that spare capacity.” – Mirko Peters (00:28)

“So you've moved the limit, not removed it, a shared pool doesn't create unlimited storage speed.” – Mirko Peters (11:53)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ
Azure Disk Storage – the per-VM managed disk model that Elastic SAN is compared against throughout
Azure Files – mentioned briefly as the shared-folder service, unlike Elastic SAN's block storage
Related episode: Azure Availability Zones - Simply Explained
Related episode: Azure Reservations and Savings Plans - Simply Explained
Related episode: Windows 365 or Azure Virtual Desktop: Choosing the Right Cloud PC Model

Beyond the Microsoft Adoption Framework: The Reality of M365 Success

Sun, 09 Aug 2026 16:00:06 +0000

Microsoft 365 transformation is often discussed as though success can be engineered by following the right framework closely enough. Define the strategy, prepare the environment, migrate workloads, establish governance, train users, measure adoption, and continue optimizing. On paper, the process appears logical and comprehensive. In practice, organizations can follow almost every recommended step, successfully deploy Microsoft Teams, SharePoint, OneDrive, Microsoft 365 Copilot, and the wider Microsoft cloud platform, and still discover that very little about the way the organization actually works has changed. That is the central problem explored in this episode. Microsoft 365 adoption rarely fails because the technology itself is incapable of supporting the organization. The more persistent failure occurs because deployment is treated as transformation, activity is interpreted as adoption, and a framework is expected to compensate for an operating model that was never redesigned. The result can be a technically successful Microsoft 365 implementation sitting on top of exactly the same organizational behaviors, unclear responsibilities, information silos, governance gaps, and inefficient processes that existed before the migration. The Microsoft Cloud Adoption Framework and Microsoft 365 adoption guidance remain useful, but they cannot answer the most important organizational questions on their own. They cannot decide who owns a Team after the project that created it has finished. They cannot determine where a business decision should be documented instead of remaining inside someone's inbox. They cannot force employees to stop recreating shared-drive structures inside SharePoint. They cannot determine which Copilot use cases matter to finance, legal, sales, operations, or HR. Most importantly, they cannot change the mental model employees and leaders have developed over years of working in a particular way.

THE FRAMEWORK IS A MAP, NOT THE TRANSFORMATION
Microsoft's adoption and cloud frameworks contain substantial experience accumulated across many implementations, but their usefulness depends on how organizations interpret them. A framework can provide direction, identify common failure points, describe architectural patterns, and force teams to consider questions they might otherwise overlook. What it cannot provide is a universal operating model suitable for every organization regardless of size, maturity, industry, risk profile, existing technology, and organizational culture. The source uses the analogy of replacing a policeman directing traffic at an intersection with a roundabout. The traditional environment is slower and more centralized because movement is controlled directly. The cloud introduces something closer to the roundabout: greater autonomy and speed combined with predefined lanes and guardrails. The infrastructure may be objectively better, but the infrastructure itself does not teach anyone how to behave inside it. Drivers still need to understand when to yield, how to enter, and how to leave safely. Microsoft 365 creates the same challenge. Teams, SharePoint, OneDrive, Copilot, identity services, security controls, retention capabilities, and governance tooling create an environment in which organizations can operate very differently from the traditional world of email, file servers, departmental applications, and manually controlled access. However, providing the environment does not automatically create the behavior required to use it effectively. The framework establishes the roads and guardrails, but the organization still needs to establish the traffic rules.

WHY TECHNICALLY SUCCESSFUL DEPLOYMENTS CAN STILL FAIL
A Microsoft 365 project can reach every conventional technical milestone and still fail as a transformation initiative. Mailboxes can be migrated successfully, identities synchronized, Teams enabled, SharePoint sites provisioned, policies configured, and Copilot licenses assigned without changing how employees think about collaboration or information. This happens partly because different groups define completion differently. IT naturally concentrates on technical readiness and may consider the project substantially complete once the environment is stable and users can access the required services. Employees experience the same event as a change in the tools available to perform their jobs. Leadership may interpret completion through budget, timeline, and project-status reporting. All three perspectives can be reasonable while still failing to describe whether adoption actually occurred. The critical gap exists between access to technology and changed behavior. License activation proves that an employee is technically capable of using a service. It does not prove that the employee understands why the service matters, which existing behavior it should replace, or how it should fit into a real business process. That distinction becomes increasingly important as Microsoft 365 expands beyond productivity applications into AI. Assigning a Copilot license can happen in minutes. Changing the way an employee prepares a report, analyzes information, documents a decision, evaluates AI-generated content, or collaborates with colleagues can take months.

WHY MORE MICROSOFT 365 ACTIVITY DOES NOT NECESSARILY MEAN MORE ADOPTION
Traditional adoption reporting tends to favor metrics that are easy for the platform to observe. Monthly active users, Teams messages, meetings, SharePoint edits, OneDrive activity, and Copilot prompts all provide useful information about what is happening inside the tenant, but none of these measurements independently establishes that the organization has improved. A rise in Teams messages could indicate that employees have successfully moved collaborative conversations into transparent team spaces. The same increase could indicate that communication has become fragmented across channels and employees are sending more messages simply to locate information. Increased SharePoint activity could represent successful co-authoring, or it could represent employees repeatedly moving and duplicating documents because nobody understands the information architecture. The source makes this distinction particularly important by arguing that confusion itself generates activity. A dashboard can therefore move upward while the quality of collaboration moves downward. Activity tells administrators that something is happening; it does not explain whether the behavior producing that activity represents the desired transformation. This is why Microsoft 365 success cannot be reduced to an adoption percentage derived exclusively from platform telemetry. Usage is evidence, but it requires context before it becomes evidence of success.

STRATEGY HAS TO EXIST BEFORE TECHNOLOGY BECOMES THE STRATEGY
One of the earliest problems appears when organizations begin with technology rather than with the business reason for change. A Microsoft 365 license agreement already exists, servers are approaching end of support, a merger creates pressure to consolidate environments, or executives decide that Copilot needs to be introduced quickly. Because the technology and deadline are already visible, the organization begins implementing before clearly defining what should become different as a result. The source distinguishes migration triggers from innovation triggers. Migration can be driven by cost, complexity, aging infrastructure, or operational risk, while innovation is driven by opportunities to create capabilities, enter new markets, increase scale, automate work, or introduce technologies such as AI. The distinction matters because the architecture, budget, timeline, and measurement model should change according to the objective. An organization trying to escape unsupported infrastructure may reasonably prioritize speed and risk reduction. An organization trying to redesign knowledge work around Copilot requires a very different program involving experimentation, process analysis, training, governance, and measurement. When these motivations are not explicit, organizations can become extremely efficient at implementing the wrong thing.

A DEADLINE CAN CREATE MOVEMENT WITHOUT CREATING DIRECTION
Urgency frequently disguises itself as strategy. Hardware reaches end of life, contracts expire, security requirements change, or executives commit publicly to an AI initiative, and suddenly the organization has a transformation program. The project has a deadline, a budget, and a list of deliverables, but it may still lack a destination. The source describes this effectively as a deadline wearing the clothes of strategy: the organization knows why it must leave the current state but has not clearly defined what the future state is supposed to achieve. This distinction becomes critical when costs begin increasing. Leadership can defend an investment when the expected business outcome is understood. It becomes considerably more difficult to defend additional spending when nobody can clearly explain whether the objective was cost reduction, improved collaboration, reduced risk, faster decision-making, AI-enabled productivity, or simply completing a migration before something stopped being supported. Strategy therefore needs to provide more than momentum. It needs to establish the criteria by which the organization will later decide whether the transformation was worthwhile.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Phi-4 is the Runtime. MAI-1 is the Reason.

Sun, 09 Aug 2026 09:01:29 +0000

Microsoft’s AI strategy becomes much easier to understand once we stop asking which model is better. The important question is no longer whether MAI-1 can beat Phi-4, whether Phi-4 is more efficient, or which model should become the enterprise standard. Those questions assume that both models are competing for the same job. They are not. Microsoft is building toward an architecture in which different forms of intelligence perform different roles. Phi-4 represents the fast, efficient Runtime layer. MAI-1 represents the deeper Reasoning layer. One executes close to the workload; the other handles problems that justify substantially more reasoning capability. This distinction matters because enterprise AI is moving beyond the era of connecting every application to one enormous general-purpose model. Organizations increasingly need to think about AI as an architecture consisting of models, routing, orchestration, governance, infrastructure, and specialized workloads. The competitive advantage may therefore come less from having access to the most powerful model and more from knowing when that power is actually necessary.

THE WRONG QUESTION: WHICH MODEL IS BETTER?
AI model launches are usually treated like sporting events. Benchmark scores are compared, parameter counts are examined, and eventually somebody declares a winner. That approach makes sense for consumers choosing between individual AI assistants, but enterprise architecture has never worked according to that principle. Companies don't use the same compute configuration for every application, the same storage tier for every file, or the same database architecture for every workload. There is little reason to assume intelligence should be different. The source describes this assumption as “The Model” thinking: the belief that one model ultimately needs to become the standard intelligence layer. Microsoft's emerging architecture points in another direction. Instead of selecting a winner, organizations need to understand the division of labor between models. Reasoning systems determine what should happen. Runtime systems execute work efficiently. Once intelligence is viewed this way, directly comparing Phi-4 and MAI-1 becomes much less useful. The meaningful comparison is between the requirements of a workload and the characteristics of the model handling it.

MICROSOFT IS BUILDING A DIVISION OF LABOR
The broader signal from Microsoft's model strategy is specialization. Instead of concentrating exclusively on one universal flagship model, Microsoft is developing multiple model families and capabilities spanning reasoning, coding, voice, images, transcription, multimodal processing, and efficient local execution. That suggests an architecture in which intelligence becomes distributed. Some models can live close to users and devices. Others can remain centralized because their workloads require substantially greater compute and context. Specialized models can handle specific modalities or business processes while deeper reasoning models become escalation points for problems requiring judgment and planning. The result begins to resemble a modern computing architecture more than a traditional chatbot. Different layers perform different jobs, and an orchestration mechanism connects those layers into what appears to the user to be one intelligent system.

DENSE AND SPARSE REPRESENT DIFFERENT DESIGN PHILOSOPHIES
Phi-4 and MAI-1 also demonstrate two different approaches to building intelligence. Phi-4 emphasizes density and efficiency. The objective is to produce substantial capability from a comparatively compact architecture. MAI-1 represents the opposite side of the equation, where substantially greater total capacity can be combined with selective activation through a Mixture-of-Experts architecture. A useful analogy is organizational structure. A small company may employ fewer specialists but expect almost everyone to participate whenever work arrives. A much larger organization can maintain hundreds of specialists while involving only the employees relevant to a particular problem. Both structures can work extremely well, but they optimize for different environments. That difference becomes crucial when AI reaches enterprise scale. Sending a simple classification request to a massive reasoning system can be unnecessary. Sending an extremely complicated planning problem to a small model can leave the system without enough reasoning capacity. Neither outcome means that the underlying model is bad. It means the workload was assigned to the wrong layer.

AI ARCHITECTURE IS ALSO AI ECONOMICS
Model architecture quickly becomes a financial issue once organizations move from experiments into production. During a proof of concept, the difference between a cheap inference request and an expensive one may appear insignificant. Multiply that difference across millions of requests and the architecture begins determining whether the use case is financially sustainable. The important metric therefore isn't simply cost per token. Organizations need to understand cost relative to workload complexity. A request that requires deep reasoning may justify substantially greater inference cost because the business problem itself is valuable. A routine classification request performed millions of times should be optimized very differently. This is why the Runtime-and-Reason distinction matters financially. The organization gains the ability to reserve expensive intelligence for workloads that actually benefit from it while moving repetitive execution into a significantly more efficient layer.

PHI-4 AS THE RUNTIME LAYER
A Runtime is responsible for execution. It sits close to the point where work happens and responds quickly enough that intelligence becomes part of the application experience rather than a remote service users are constantly waiting for. The source positions Phi-4's compact models naturally within this role. Phi-4-mini and Phi-4-multimodal are designed around relatively small footprints, while capabilities such as function calling allow the model to participate in agentic workflows rather than merely generate text. MIT licensing also creates considerably more flexibility for developers considering embedded and specialized deployments. Consider a local coding assistant examining a file, an endpoint agent classifying a request, an application deciding which internal function should execute, or an assistant performing routine processing against local information. These tasks require intelligence, but they do not necessarily require a frontier model with enormous context and deep planning capabilities. They need low latency, predictable execution, and an economic model that works at high volume. That is the Runtime role.

LOCAL AI CHANGES THE SOVEREIGNTY DISCUSSION
Local inference also changes the relationship between AI and data sovereignty. Traditionally, organizations have concentrated on securing the journey between corporate information and a remote AI service. If a workload can instead be processed directly on an endpoint or within a controlled local environment, some information may never need to make that journey. That doesn't eliminate governance. It changes where governance can be enforced. Data residency and sovereignty can potentially become characteristics of the architecture itself rather than controls applied after information has already been transmitted somewhere else. For highly regulated organizations, this distinction can be significant. Some workloads may be perfectly suitable for cloud reasoning while others should remain local by design. The question becomes workload-specific rather than forcing an organization into a binary choice between cloud AI and local AI.

MAI-1 AS THE REASONING LAYER
Reasoning serves a fundamentally different purpose. It is needed when a system must evaluate alternatives, maintain relationships across a large amount of information, understand dependencies, plan multiple steps ahead, or make sense of a problem where the correct next action is not immediately obvious. The source positions MAI-Thinking-1 within this deeper reasoning category and discusses its larger active reasoning capacity, substantial context capabilities, multi-step problem solving, training lineage, and software-engineering performance. Think about an architecture review involving multiple systems, a complicated root-cause investigation, a large codebase where changes have cascading consequences, or a strategic planning problem involving dozens of constraints. Those aren't primarily execution problems. They require the model to maintain the structure of the problem while evaluating what should happen next. That is where the Reason layer belongs.

PHI-4 EXECUTES WHILE MAI-1 DECIDES
The central idea of the architecture can therefore be reduced to a very simple distinction: Phi-4 executes. MAI-1 decides. The important part, however, is what connects those two layers. A Runtime without a reasoning layer eventually encounters problems beyond its capabilities. A reasoning layer without an efficient Runtime wastes expensive intelligence on routine execution. The architecture only becomes powerful when requests can move intelligently between them. That handoff may become considerably more important than the individual models themselves. If organizations can reliably determine when a problem requires escalation, they can create systems that feel fast for routine work while still providing sophisticated intelligence when complexity demands it.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Microsoft Defender Vulnerability Management - Simply Explained

Sun, 09 Aug 2026 04:00:05 +0000

Microsoft Defender Vulnerability Management goes far beyond running a vulnerability scan and installing patches. The real challenge isn't finding vulnerabilities. It's deciding which weaknesses create the most risk, what should be fixed first, who should fix it, and whether the remediation actually worked. A vulnerability scan might return hundreds or thousands of CVEs. Defender Vulnerability Management adds the device, threat, exposure, and business context needed to turn that enormous list into practical security work.
ㅤ
PATCH MANAGEMENT VS VULNERABILITY MANAGEMENT
Patch management focuses on applying fixes. You update Windows, install a newer browser version, remove outdated software, or change a configuration. Vulnerability management answers a broader set of questions: Which issue should be addressed first? How urgent is it? Which devices are affected? Who owns the remediation? And did the fix actually eliminate the vulnerability? A critical CVE on an isolated test system might represent less immediate risk than a lower-rated vulnerability on a finance laptop that handles sensitive information and is exposed to active threats. Severity matters, but context matters more.
ㅤ
DISCOVERY: KNOW WHAT YOU ACTUALLY HAVE
Before Defender can prioritize vulnerabilities, it needs visibility into your environment. Defender Vulnerability Management continuously tracks weaknesses across devices, including outdated software, missing updates, unsafe configurations, and other security gaps. Through Defender for Endpoint signals, Microsoft can understand operating systems, installed software, versions, and known vulnerabilities across onboarded devices. Unlike a traditional periodic scan, this information changes as your environment changes.
ㅤ
DEVICE DISCOVERY
Organizations frequently have devices that aren't included in their official inventory. Device discovery can use managed Defender for Endpoint devices to identify other systems visible around them on the network. That might uncover an old server, unmanaged workstation, printer, router, or another device that was never properly onboarded. Device inventory shows systems Defender already knows about. Device discovery helps expose the gaps outside that known inventory. You can't manage the vulnerability of a device you don't know exists.
ㅤ
SOFTWARE INVENTORY
Defender also builds an inventory of software across onboarded devices. Security teams can see applications, publishers, versions, affected devices, and vulnerabilities associated with installed software. Instead of manually checking hundreds of computers, teams can begin with a vulnerable application and identify every affected device, or begin with a particular device and investigate the software requiring attention. This makes it much easier to understand the actual scale of a vulnerability.
ㅤ
MORE THAN SOFTWARE PATCHES
Depending on licensing, configuration, platforms, and enabled capabilities, Defender Vulnerability Management can assess more than conventional desktop applications. This can include digital certificates, browser extensions, firmware, hardware security configurations, network shares, and other configuration weaknesses. The correct remediation isn't always installing a patch. Sometimes the appropriate response is changing a configuration, removing software, restricting access, or replacing outdated hardware.
ㅤ
PRIORITIZATION: WHAT SHOULD YOU FIX FIRST?
CVSS provides a useful general severity rating for vulnerabilities, but it doesn't understand your organization's individual environment. Defender Vulnerability Management adds additional context. Is a public exploit available? Is the vulnerability associated with active threat activity? Are there related alerts inside your environment? How many devices are affected? What roles do those devices perform? The important question changes from "Which CVE has the highest score?" to "Which vulnerability creates the most exposure for our organization?"
ㅤ
EXPOSURE SCORE AND SECURE SCORE FOR DEVICES
Exposure Score provides a broader indication of your organization's exposure. Lower is better, but it shouldn't be interpreted as a guarantee of security. Secure Score for Devices looks at security configurations and recommended protections across devices. These scores provide direction and allow teams to monitor whether security improvements are reducing exposure over time. They aren't substitutes for investigating individual vulnerabilities and recommendations.
ㅤ
SECURITY RECOMMENDATIONS
The practical work happens through recommendations. A recommendation can connect a vulnerability with the affected software, exposed devices, and an action that can reduce the risk. This allows teams to move from a general vulnerability warning to a specific remediation plan. The surrounding context can also significantly change priority. A vulnerable file sitting unused inside an archive represents a different situation from vulnerable software actively running and listening for network traffic.
ㅤ
THREAT ANALYTICS
Defender can connect vulnerability management with Microsoft's threat analytics. This helps teams understand emerging threats and active attack campaigns. Security teams can investigate whether their organization is affected, which devices are exposed, whether related alerts already exist, and what mitigations could reduce risk while a permanent solution is prepared. This is another reason vulnerability management shouldn't simply mean patching everything in severity order.
ㅤ
REMEDIATION: TURN FINDINGS INTO WORK
Defender Vulnerability Management isn't a universal patching engine. Its role is to identify vulnerabilities, prioritize them, create remediation work, track progress, and verify the result. The actual change might be performed through Microsoft Intune, ServiceNow, another ticketing platform, software deployment tools, or directly by an IT team. Security recommendations provide the context needed to turn a vulnerability into an actionable task with scope, priority, ownership, and a deadline.
ㅤ
DEFENDER AND INTUNE WORKING TOGETHER
With an Intune connection, Defender can turn remediation requirements into security tasks. Security teams identify and prioritize the risk. Device management teams determine how the necessary changes should be deployed without unnecessarily disrupting users or business applications. For example, a browser vulnerability might first be remediated across a small pilot group. Once compatibility is confirmed, the update can be deployed progressively to the remaining devices. This creates a controlled remediation workflow rather than immediately pushing every change to every endpoint.
ㅤ
EXCEPTIONS AND MITIGATIONS
Sometimes a vulnerability can't be fixed immediately. A legacy application may require an older browser version. A vendor may need additional time to release or validate an update. A production server might only be changed during an approved maintenance window. In these situations, exceptions should be documented with a clear reason and an end date. Temporary mitigations can also reduce exposure while teams prepare the permanent fix, such as restricting connectivity, blocking vulnerable applications, or implementing vendor-recommended controls.
ㅤ
VERIFICATION: DID THE FIX ACTUALLY WORK?
A closed ticket doesn't automatically mean a vulnerability has disappeared. An update might have been deployed through Intune while individual devices remained offline, failed the installation, or continued running the vulnerable version. Defender Vulnerability Management continues evaluating device signals. When affected devices stop reporting the weakness, the remediation can be considered completed. This provides evidence based on the actual state of the devices rather than relying only on a deployment report.
ㅤ
THE CONNECTED MICROSOFT SECURITY ECOSYSTEM
Vulnerability management becomes more powerful when combined with the wider Microsoft security ecosystem. Intune manages device configuration and compliance. Defender for Endpoint detects threats and calculates device risk. Entra ID can use those signals through Conditional Access. For example, a device with serious security problems could become noncompliant in Intune. Conditional Access could then restrict that device from accessing SharePoint, Teams, or Exchange Online until it returns to an acceptable state. This limits what a risky endpoint can access while remediation is still underway.
ㅤ
ADDING DATA SENSITIVITY TO THE RISK PICTURE
Microsoft Purview can add another layer of business context by helping identify sensitive information. A device regularly handling confidential finance or customer information may deserve higher priority than a general-purpose device carrying the same vulnerability. This is where vulnerability management becomes more than technical severity. Security teams can consider what a vulnerable device actually represents to the organization.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

The PCF Blueprint: Architecture Over UI

Sat, 08 Aug 2026 16:00:05 +0000

Many Power Platform tenants drown in undocumented apps, fragile web resources and duplicated grids. This episode is for architects and platform owners who want to see the Power Apps component framework as a governance layer, with solutions, ALM, catalogs and managed environments that let low code scale safely.

In this episode

00:00 – The lie we tell ourselves about low code
03:04 – What PCF actually is structurally
05:38 – The governance vacuum and enforcement by design
10:50 – Solutions, field controls and dataset controls
18:47 – Performance: gains, failure modes and the hybrid model
25:40 – The component catalog, ALM and environment strategy
33:07 – Citizen developers, federated governance and the architect's new job
42:45 – React, Fluent UI, trust and a realistic rollout

Key takeaways

PCF is not a UI skin but an enforcement layer: once a code component is packaged in a solution it becomes a versioned, traceable dependency that every app inherits.
Use standard controls first and PCF only for structural gaps, and back every component with a governed catalog, ALM pipeline, managed environments and a review process.
Citizen developers are not the risk; missing guardrails are, so a federated model with a central catalog lets business users build safely while leadership funds governance as platform infrastructure.

Worth quoting

“That is the reframe this whole episode is built around. PCF is not decoration. It is the enforcement layer.” – Mirko Peters (02:53)

“Citizen developers are not the risk. A business analyst dragging a field onto a form is not what causes a tenant to buckle. Ungoverned components are the risk.” – Mirko Peters (02:04)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes, takeaways and FAQ
Governance – the episode argues PCF is a governance and enforcement layer rather than a UI skin
Power Platform – the tenants whose app sprawl, environments and ALM practices this episode examines
Canvas app – one of three surfaces PCF runs in, and the source of duplicated gallery logic
Model-driven app – one of three surfaces where PCF code components run, already loading React
Related episode: Power Apps Component Framework - Simply Explained

The Architecture of Intelligence- Why the Chatbox is the Wrong Model for Enterprise AI

Sat, 08 Aug 2026 09:01:25 +0000

Artificial intelligence was supposed to transform how organizations access information, make decisions, and execute work. Microsoft Copilot, enterprise AI agents, and generative AI promised to remove the barriers between employees and organizational knowledge. But many companies are discovering a fundamental problem: employees can ask AI better questions and receive better answers, yet they still have to navigate SharePoint, Excel, business applications, approval systems, and other tools to actually complete the work. The intelligence improved, but the workflow often did not. This episode explores a much larger architectural shift happening across Microsoft 365, SharePoint, Copilot, SPFx, MCP, governance, security, and enterprise AI. The argument is simple: the chatbox may be the wrong primary interface for enterprise intelligence. The future is not simply better prompts or better conversational AI. It is an environment where AI becomes an orchestration layer capable of presenting the exact interface, data, action, or workflow a user needs at the moment they need it.

THE CHATBOX BOTTLENECK
Chat interfaces are extremely effective for asking questions, summarizing information, brainstorming, and discovering knowledge. But enterprise work rarely ends with an answer. Employees need to approve requests, update records, modify documents, change statuses, trigger workflows, review dashboards, and make auditable decisions. That creates the chatbox bottleneck. A user asks Copilot about a purchase order and receives an excellent summary, but then still needs to locate the procurement system, find the corresponding record, and execute the approval. AI accelerated information retrieval without necessarily accelerating task completion. Every additional application switch introduces navigation time, cognitive load, and another potential break in the audit trail. The more important enterprise AI metric therefore isn't simply how quickly an AI produces an answer. It is the distance between “I need something done” and “the task is complete.”

COPILOT DOESN'T CREATE BAD PERMISSIONS — IT EXPOSES THEM
One of the biggest enterprise concerns around Microsoft Copilot is security. But the episode challenges the assumption that Copilot itself creates an entirely new permission problem. Instead, AI dramatically increases the discoverability of information users could already access. A poorly governed SharePoint environment may contain years of permission drift, broadly shared sites, inherited permissions, old sharing links, and sensitive information that is technically accessible but historically difficult to discover. Natural-language AI removes much of that discovery friction. Information that once required knowing the correct SharePoint site, library, folder, filename, or search terminology can potentially become much easier to find. That means Copilot can function as a permission magnifier. The underlying governance weakness may already exist; AI simply makes the consequences visible much faster.

FROM CHAT TO ACTION
The alternative to the chat-first model isn't necessarily abandoning conversational AI. It is changing what happens after the conversation begins. Instead of asking Copilot a question, receiving text, and navigating elsewhere, imagine Copilot presenting an interactive form, approval interface, dashboard, list, or action directly inside the experience. The user receives both the intelligence required to make a decision and the interface required to execute it. This represents a shift from text as the interface toward actions as the interface. Interactive components can dramatically reduce the distance between decision and execution.

SHAREPOINT, SPFX AND THE NEW INTERACTION MODEL
This shift gives SharePoint Framework a potentially much larger role in enterprise AI architecture. SPFx has traditionally been associated with SharePoint customization: web parts, dashboards, intranet experiences, list interfaces, and specialized business applications. In the architecture described in this episode, those skills become relevant to something broader: building interactive experiences that can participate in AI-driven workflows. Instead of thinking only about where a component appears on a SharePoint page, developers increasingly need to think about how that component becomes part of an orchestration flow. The user expresses intent, the AI identifies the appropriate capability, an interface is surfaced, the user takes an action, and the result feeds back into the process. The component stops being merely a destination. It becomes an actionable building block of enterprise intelligence.

THE OLD MODEL VS. THE NEW MODEL
Traditional enterprise information architecture assumes that humans are the navigation layer. Employees are expected to know where information resides, understand organizational structures, navigate applications, search folders, interpret documents, and then locate another interface to execute an action. The emerging model reverses that relationship. AI increasingly becomes the navigation and orchestration layer. Instead of teaching employees where every system lives, the organization exposes governed capabilities that AI can surface when appropriate. The human concentrates on the decision while the architecture handles discovery and execution. That is a much more significant transformation than adding a chatbot to an existing application.

MCP VS. SPFX: TWO DIFFERENT ARCHITECTURAL PATHS
The episode also examines two important approaches to building interactive enterprise AI experiences: Model Context Protocol (MCP) and SharePoint Framework-based experiences. MCP provides a more open integration model. It can expose tools and capabilities to AI systems and can be valuable when enterprise information is distributed across Microsoft platforms, custom applications, ERP environments, CRM systems, data platforms, and external services. That flexibility introduces additional architectural responsibility. Identity propagation, authentication, external infrastructure, security controls, logging, credential management, API governance, and cross-system auditing all become important considerations. SPFx represents a more Microsoft 365-centric path. Where SharePoint already acts as a major system of record or operational platform, organizations can potentially build on existing Microsoft 365 identity, permissions, governance, and development investments. The decision therefore isn't simply MCP versus SPFx. It is a governance and architecture decision based on where the organization's data lives, how portable integrations need to be, and what security boundaries the organization is capable of managing.

THE AGENT FABRIC
At the center of the discussion is the idea of an Agent Fabric: an enterprise environment in which AI doesn't simply answer questions but can select and invoke governed capabilities. The basic cycle becomes: Intent → Reasoning → Tool → Interactive Experience → Human Action → Result An agent can determine that a particular capability is needed, invoke it, surface the relevant information or interface, receive the user's action, and continue the workflow. This changes Copilot from primarily a conversational layer into an orchestration layer. But that architecture only works safely when identity, authorization, permissions, auditability, data protection, and human approval are designed into the foundation.

GOVERNANCE BEFORE AI ARCHITECTURE
This leads to one of the most important arguments of the episode: governance must precede architecture. Buying Copilot licenses first and fixing governance later reverses the correct sequence. Organizations need to understand who has access to information, where sensitive data resides, whether permissions reflect actual business requirements, how data is classified, and whether actions can be audited before AI dramatically increases the speed at which that information can be discovered and used. The recommended sequence is therefore: Governance → Architecture → Implementation → Measurement → Expansion Weak permissions do not disappear when AI arrives. They become easier to exploit accidentally. Poor classification doesn't become less important. It becomes more important. Missing auditability becomes increasingly dangerous as AI moves from generating answers toward executing actions.

SHAREPOINT PERMISSION AUDITS BECOME CRITICAL
Organizations preparing for enterprise AI should examine SharePoint permissions as an architectural foundation rather than routine administration. Broad organizational access, old sharing links, unnecessary external sharing, broken inheritance, overshared libraries, and sensitive documents stored inside broadly accessible collaboration spaces all deserve renewed attention. The objective isn't to restrict information unnecessarily. It is to ensure that the permission model accurately represents the organization's real business and compliance requirements before AI makes discovery dramatically easier. Sensitivity labels, DLP policies, appropriate access boundaries, audit capabilities, and systematic permission reviews therefore become part of the AI architecture itself.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Microsoft Defender EASM - Simply Explained

Sat, 08 Aug 2026 07:00:03 +0000

Attackers start with what your company exposes publicly: old test sites, forgotten subdomains and services nobody remembers. This episode is for security teams and IT admins who need to see their organization from the outside. You learn how Microsoft Defender EASM discovers internet-facing assets, how to prioritize findings by ownership and risk, and how it fits into the wider Microsoft security stack.

In this episode

00:00 – What strangers can see about your company
00:56 – You can't lock what you can't see
03:29 – What Microsoft Defender EASM actually is
06:05 – How discovery works: from one seed to a map
09:34 – From inventory to action
13:28 – How EASM fits into Microsoft security
16:15 – A simple starting plan

Key takeaways

Part of the Microsoft Defender family, Defender EASM gives an outside-in view of everything your company exposes on the public internet, from forgotten subdomains to expiring certificates.
Discovery starts from trusted seeds such as domains, IP ranges and ASNs and follows public connections outward, but your team still has to confirm which assets are really yours.
Findings become useful when each asset gets an owner, a business reason and a decision, and when EASM data flows into tools like Log Analytics, Microsoft Sentinel and Exposure Management.

Worth quoting

“Most security tools start from inside your company and protect known devices, known users, and known files. An attacker starts outside, they don't need your company map or a login.” – Mirko Peters (00:28)

“Shadow IT means a tool, service, or system that operates outside the normal company list. It doesn't always come from bad choices. Often someone simply needed to get work done quickly.” – Mirko Peters (03:14)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ
Microsoft Defender – the security family EASM belongs to, alongside Defender for Endpoint, Office 365 and Cloud
Microsoft Entra ID – controls sign-in for exposed applications that EASM may find on the public internet
Mirko Peters – hosts this knowledge nugget and explains EASM from an attacker's outside view
Related episode: When Microsoft Messaging Looks Secure but Isn’t — Exchange Server, Hybrid and Microsoft 365 Security with Thomas Stensitzki [MVP]

Microsoft Defender for Cloud - Simply Explained

Sat, 08 Aug 2026 04:00:05 +0000

Microsoft Defender for Cloud can sound like another antivirus product because of the Defender name. In reality, its scope is much broader. Instead of focusing on a single laptop or server, Defender for Cloud helps organizations understand and improve the security of their entire cloud environment. It shows how securely resources are configured, identifies suspicious activity, and helps teams prioritize what should be fixed first.
ㅤ
ㅤ
WHY CLOUD SECURITY GETS COMPLICATED
Modern cloud environments change constantly. Virtual machines, databases, storage accounts, containers, and other services can be created within minutes, often by different teams. A temporary test server might remain online with RDP or SSH exposed to the internet. Storage could accidentally allow public access, or an old administrator account might retain permissions long after it is needed. The challenge becomes even larger when organizations operate across Azure, AWS, Google Cloud, and on-premises infrastructure. Defender for Cloud provides security context across these connected environments rather than forcing security teams to investigate every resource individually.
ㅤ
ㅤ
CLOUD SECURITY POSTURE MANAGEMENT
One of the main building blocks is Cloud Security Posture Management, or CSPM. Think of CSPM as a continuous security inspection of your cloud environment. Defender for Cloud evaluates configurations and looks for weaknesses such as excessive permissions, missing encryption, insecure network rules, and resources that don't comply with organizational policies. Because cloud infrastructure changes continuously, these assessments continue as resources are created and modified. A central concept is Secure Score. It provides an overview of how many recommended security controls have been implemented and where improvements remain. The objective isn't simply to achieve a perfect number. The recommendations behind the score identify specific resources and actions that can reduce risk.
ㅤ
ㅤ
ATTACK PATHS AND RISK PRIORITIZATION
Not every security finding represents the same level of risk. Defender for Cloud can identify attack paths: possible routes through which an attacker could move from an exposed resource toward sensitive systems or data. For example, a publicly accessible resource might connect to an identity with extensive permissions, which in turn could access a sensitive database. Individually, each configuration might appear manageable. Together, they can create a significant attack path. Defender for Cloud can also identify choke points, where fixing one weakness can eliminate several potential attack paths simultaneously.
ㅤ
ㅤ
WORKLOAD PROTECTION
Security posture focuses primarily on configuration. Workload protection focuses on what is actually running. Defender for Cloud provides different Defender plans depending on the workload, including protection for servers, storage, containers, and databases. Instead of applying one generic security mechanism everywhere, organizations can select protection according to the importance and exposure of each workload. For servers, Defender for Cloud can identify software vulnerabilities, missing updates, and other security weaknesses. Microsoft Defender for Endpoint can complement this by monitoring processes, files, and suspicious behavior inside the operating system. Together, the two products provide both workload-level and cloud-level security context.
ㅤ
ㅤ
JUST-IN-TIME SERVER ACCESS
Leaving RDP or SSH management ports permanently accessible creates unnecessary exposure. Just-in-time access provides another approach. Management access can remain closed until an administrator actually needs it. Access is temporarily enabled for an approved period before being closed again automatically. This reduces the amount of time that administrative interfaces are exposed.
ㅤ
ㅤ
PROTECTING STORAGE, CONTAINERS AND DATABASES
Different workloads require different security controls. Defender for Storage can scan uploaded files for malware and detect suspicious access patterns. Container protection focuses on container images, configurations, and runtime behavior, while database protection can identify suspicious queries, login behavior, and data-related threats. The goal isn't to run the same security scan against everything. It's to provide protection appropriate to each workload.
ㅤ
ㅤ
MULTICLOUD AND HYBRID SECURITY
Most enterprises no longer operate exclusively in one environment. Defender for Cloud can bring connected Azure, AWS, Google Cloud Platform, and on-premises resources into a common security view. Asset inventory becomes particularly important here. Organizations need to know what resources exist, where they are located, and whether the expected security coverage is actually enabled. A dashboard cannot protect resources that were never connected or onboarded. Coverage therefore needs to be verified rather than assumed. Forgotten Azure subscriptions, AWS accounts, GCP projects, or older on-premises servers can otherwise become security blind spots.
ㅤ
ㅤ
CONTINUOUS COMPLIANCE
Defender for Cloud can continuously evaluate resources against security and compliance standards. Examples include CIS, NIST, ISO 27001, HIPAA, PCI DSS, and the Microsoft Cloud Security Benchmark. Instead of relying entirely on screenshots and spreadsheets collected shortly before an audit, teams can review current control status and identify the resources responsible for failed checks. Compliance should not be confused with complete security. Passing defined controls doesn't eliminate vulnerabilities, stolen credentials, or new attack techniques. Compliance provides a structured way to measure requirements, identify gaps, and demonstrate progress.
ㅤ
ㅤ
HOW TO GET STARTED WITH DEFENDER FOR CLOUD
A practical implementation starts with understanding what you actually operate. Map your Azure subscriptions, servers, storage accounts, databases, containers, AWS and GCP workloads, and relevant on-premises systems. Then verify coverage before attempting to solve hundreds of recommendations. Start with posture management and review Secure Score and high-risk findings. Prioritize issues such as public exposure, weak identity controls, open management ports, and missing patches. After that, enable workload protection based on business importance and risk rather than simply switching everything on. Assign owners to findings and establish a recurring review process so recommendations turn into actual remediation work.
ㅤ
ㅤ
THE KEY TAKEAWAY
Microsoft Defender for Cloud combines cloud security posture management, workload protection, attack-path analysis, multicloud visibility, asset coverage, and compliance monitoring. The objective isn't to chase a perfect security score. It's to understand where your most important risks exist and systematically remove the easiest paths attackers could use. A good first step is simple: connect one Azure subscription, verify which resources appear in the coverage view, identify the most exposed resource, and assign someone to remediate it.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Microsoft Purview Records Management - Simply Explained

Fri, 07 Aug 2026 17:00:02 +0000

Contracts, policies and financial reports now live across SharePoint, OneDrive, Exchange Online and Teams, yet organizations must still prove how long they kept them and why they deleted them. This Simply Explained episode shows compliance teams and Microsoft 365 admins how Purview Records Management uses retention labels, record declaration, disposition review and audit history to build a defensible records lifecycle.

In this episode

00:00 – Intro: from filing cabinets to Microsoft 365
01:27 – What counts as an official record
04:16 – Retention labels are the rule book
07:53 – Record declaration locks the evidence
11:07 – Disposition review: the gate before deletion
14:17 – Audit history provides the proof
16:35 – Putting the pieces together

Key takeaways

Microsoft Purview Records Management keeps official records for the required time and disposes of them in a controlled, reviewable way.
Retention labels attach item-level rules (trigger, period, end action), record declaration locks official evidence, and retention policies cover broad locations.
Disposition review and Purview Audit provide the decision gate and the trail needed to prove why a record was kept or deleted.

Worth quoting

“A record is official evidence that your organization did something, decided something, approved something, or agreed to something.” – Mirko Peters (01:30)

“You can use both approaches in the same connected platform, but they solve different problems. Policies handle broad coverage, while labels handle the records that need individual treatment.” – Mirko Peters (06:39)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes, takeaways and FAQ
Microsoft Purview – Records Management is the part of Microsoft Purview this episode explains step by step
Audit logs – the unified audit log holds the trail that shows why a record was kept or deleted
Sensitivity labels – contrasted with record labels: they protect access and sharing, not how long evidence stays
Related episode: Microsoft Purview Audit - Simply Explained
Related episode: Data Loss Prevention in Microsoft 365: Policies That Actually Work

From Raw Data to Real Business Impact: Mastering Power BI and Microsoft Fabric with Thummalacherla Krishnakanth

Fri, 07 Aug 2026 13:00:05 +0000

Power BI projects often struggle not because of the visuals but because of weak data quality, modeling and performance foundations. In this interview, Fabric Super User and Senior Power BI Developer Thummalacherla Krishnakanth shares practical guidance for beginners and BI developers on star schemas, Power Query versus DAX, optimization, Microsoft Fabric and staying relevant in the AI era.

In this episode

00:00 – Welcome and guest introduction
02:06 – From electrical engineering to data
04:36 – Power BI in the age of AI and versus Excel
10:30 – Common Power BI mistakes: data quality and modeling
16:53 – Star versus snowflake schema, Power Query versus DAX
24:42 – Performance, governance and Microsoft Fabric
31:25 – AI in BI, enterprise projects and stakeholders
47:05 – Certifications, community and rapid-fire round

Key takeaways

Many Power BI problems start before the visuals: check data quality and data types in Power Query or at the source, and model clean relationships from dimension to fact tables.
A star schema with fewer, denormalized dimension tables connected directly to fact tables is the recommended default over a snowflake schema for performance.
AI can help analyze and explore data, but strong fundamentals, certifications such as PL-300 via Microsoft Learn and close stakeholder contact remain what keeps data professionals relevant.

Worth quoting

“So in the means we will be having a less number of dimension tables getting directly connected to the fact tables so I would suggest to go with the star schema as a best practice.” – Thummalacherla Krishnakanth (19:24)

Explore more on M365.FM

Episode page: the full interview with chapters, quotes and FAQ on Power BI fundamentals
Thummalacherla Krishnakanth – Fabric Super User and Power BI developer from Bangalore sharing modeling, performance and career advice
Power BI – the main topic: data quality, modeling, DAX, performance tuning and the guest's career path
Microsoft Fabric – discussed for Lakehouse, Dataflow Gen2 and warehouse reporting, and where organizations are heading
Related episode: Power BI Semantic Models - Simply Explained

Communication Compliance - Simply Explained

Fri, 07 Aug 2026 07:00:04 +0000

Business communication has evolved far beyond email. Employees collaborate through Microsoft Teams chats, Outlook emails, Viva Engage, Microsoft 365 Copilot, and other digital communication platforms every day. While these tools improve productivity, they also create new risks involving workplace misconduct, regulatory compliance, sensitive information, insider threats, and inappropriate communication. In this Microsoft Knowledge Nuggets episode, Mirko Peters explains Microsoft Purview Communication Compliance in plain English, showing how organizations can identify potentially risky workplace communications while balancing security, compliance, privacy, and fair human review. Whether you're an IT administrator, compliance officer, HR professional, security analyst, or Microsoft consultant, this episode explains how Communication Compliance helps organizations build safer and more compliant digital workplaces.

UNDERSTANDING MICROSOFT PURVIEW COMMUNICATION COMPLIANCE
Microsoft Purview Communication Compliance is designed to identify communications that may violate organizational policies, legal requirements, or regulatory obligations. Rather than monitoring every conversation indiscriminately, organizations create targeted compliance policies that define which users, communication channels, message directions, and risk scenarios require review. These policies can monitor Microsoft Teams conversations, Exchange Online email, Viva Engage discussions, Microsoft 365 Copilot prompts and responses, and supported third-party communication platforms connected through Microsoft Purview. The service detects potential policy matches while leaving the final decision to trained human reviewers who evaluate each situation within its full business context.

BUILDING TARGETED COMMUNICATION COMPLIANCE POLICIES
Communication Compliance policies form the foundation of every implementation. Organizations define specific business scenarios such as workplace harassment, inappropriate language, regulatory supervision, conflicts of interest, insider communications, customer interactions, or the exposure of sensitive information. Policies can target selected users, departments, security groups, external communications, internal conversations, or high-risk business units instead of monitoring the entire organization. Microsoft provides built-in templates that simplify deployment while allowing organizations to customize users, communication locations, reviewers, risk conditions, and compliance rules to match their own governance requirements and regulatory obligations.

HOW MICROSOFT PURVIEW IDENTIFIES RISKY COMMUNICATIONS
Microsoft Purview combines multiple detection technologies to identify communications that may require investigation. Sensitive Information Types detect structured information such as financial records, health data, personal identifiers, and confidential business information. Trainable Classifiers use machine learning to recognize communication patterns associated with harassment, threats, discrimination, and other behavioral risks beyond simple keyword matching. Organizations can further strengthen policies using custom keywords, phrase dictionaries, Optical Character Recognition (OCR) for text inside images, contextual conversation analysis, and configurable review sampling percentages. These technologies generate signals rather than conclusions, allowing reviewers to evaluate communications within their complete conversational context before determining whether any policy has actually been violated.

HUMAN REVIEW, PRIVACY, AND RESPONSIBLE GOVERNANCE
A fundamental principle of Microsoft Purview Communication Compliance is that technology supports human decision-making rather than replacing it. Messages that match compliance policies enter a secure review workflow where trained reviewers evaluate surrounding conversations, classify findings, document their decisions, and determine whether escalation is necessary. Potential issues may be dismissed, resolved through coaching, escalated to Human Resources, referred to compliance teams, or transferred into Microsoft Purview eDiscovery for formal legal investigations. Role-based access control, pseudonymization, reviewer accountability, privacy protections, and documented governance procedures help ensure investigations remain fair, proportionate, and aligned with applicable legal and organizational requirements.

HOW COMMUNICATION COMPLIANCE FITS INTO MICROSOFT PURVIEW
Microsoft Purview Communication Compliance operates alongside several complementary Microsoft Purview services. Microsoft Purview Audit records user activities and administrative actions across Microsoft 365. Content Search locates emails, documents, and messages relevant to investigations. Microsoft Purview eDiscovery manages legal cases, preserves evidence, and supports litigation workflows. Data Loss Prevention (DLP) helps prevent sensitive information from leaving the organization, while Communication Compliance focuses on reviewing communications that may indicate workplace misconduct, regulatory violations, or other organizational risks. Together, these services create a comprehensive Microsoft Purview compliance platform that helps organizations secure communications, protect sensitive information, maintain regulatory compliance, and strengthen enterprise governance across Microsoft 365.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Microsoft Purview Audit - Simply Explained

Thu, 06 Aug 2026 17:00:02 +0000

When a file is shared externally or a policy quietly changes, many Microsoft 365 teams cannot say who did it or when. This episode explains Microsoft Purview Audit for IT admins, compliance officers and security analysts, from the unified audit log to Audit Standard vs. Premium and a practical audit plan.

In this episode

00:00 – What Purview Audit records
00:45 – The problem audit solves
03:18 – How Purview Audit works behind the scenes
06:52 – Audit vs. Compliance Manager, eDiscovery and Insider Risk
10:30 – Audit (Standard) vs. Audit (Premium)
13:36 – A simple audit plan for your organization

Key takeaways

Microsoft Purview Audit collects activity records from Microsoft 365 services into one searchable unified audit log, capturing who did what and when, but not the full content of files or messages.
Audit answers what happened, while eDiscovery, Content Search, Insider Risk Management and Compliance Manager each cover different parts of an investigation or compliance programme.
Audit (Premium) adds longer retention and richer detail, but retention cannot recover events that were never recorded, so plan retention, roles and a tested investigation process before an incident.

Worth quoting

“It records actions, not the full contents of every file or message. That difference matters a lot.” – Mirko Peters (00:40)

“Audit tells you that a person opened a document at a certain time. E-discovery helps you find the document itself and manage it as evidence.” – Mirko Peters (08:13)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes, takeaways and FAQ
Microsoft Purview – the wider platform where Audit sits beside eDiscovery, Compliance Manager and Insider Risk Management
Audit logs – the unified audit log that gathers activity records from Microsoft 365 services into one search
eDiscovery – finds, holds and exports the actual content once Audit has shown what happened
Compliance – why compliance teams need recorded evidence of who did what and when
Related episode: Data Loss Prevention in Microsoft 365: Policies That Actually Work

AVD vs Windows 365: Which Virtual Desktop Strategy Wins: with Shabaz Darr [MVP]

Thu, 06 Aug 2026 13:00:03 +0000

Choosing the right virtual desktop platform has become one of the most important decisions for organizations modernizing their workplace. Although Azure Virtual Desktop (AVD) and Windows 365 are often compared, they solve different business challenges. In this episode of M365.FM, Microsoft MVP Shabaz Darr explains the architecture, licensing, deployment strategies, and real-world use cases for both platforms. The discussion provides practical guidance for IT leaders, cloud architects, Microsoft administrators, and consultants looking to build secure, scalable, and cost-effective end-user computing environments.

WHEN TO CHOOSE AZURE VIRTUAL DESKTOP OR WINDOWS 365
Every successful virtual desktop deployment begins with understanding user personas. Shabaz explains why organizations should evaluate how employees work before selecting a platform. Azure Virtual Desktop excels for multi-session environments where many users share cloud resources efficiently, making it ideal for general office workers, call centers, education, and enterprise-scale deployments. Windows 365, on the other hand, delivers dedicated Cloud PCs that are perfectly suited for developers, power users, engineers, and professionals requiring predictable performance, dedicated resources, and simplified management through Microsoft Intune.

BUILDING A SECURE AND SCALABLE VIRTUAL DESKTOP ARCHITECTURE
Successful Azure Virtual Desktop implementations rely on strong architectural foundations. The conversation explores Azure Landing Zones, Cloud Adoption Framework principles, identity, networking, storage, Azure Files, Azure NetApp Files, FSLogix profile containers, host pools, workspaces, autoscaling, monitoring, and performance optimization. Shabaz explains why proper planning, governance, and infrastructure design have a far greater impact on long-term success than simply deploying virtual machines. Organizations that invest in architecture from the beginning gain better security, lower operational costs, improved user experiences, and easier long-term maintenance.

OPTIMIZING COSTS, PERFORMANCE, AND USER EXPERIENCE
Managing cloud costs remains one of the biggest concerns for enterprise IT teams. This episode explains how Azure Virtual Desktop automatically scales resources based on demand, reducing unnecessary infrastructure costs while maintaining excellent performance for users. Shabaz also discusses monitoring strategies using Azure Monitor and Nerdio, workload optimization, storage performance, session host sizing, bandwidth considerations, and continuous tuning based on real usage data. Rather than guessing infrastructure requirements, organizations can use performance analytics to optimize environments over time while delivering consistent user experiences.

MODERN SECURITY FOR CLOUD DESKTOPS
Security is built into every layer of Microsoft's virtual desktop platforms. The discussion covers Conditional Access, Microsoft Entra ID, Zero Trust, Microsoft Defender, multifactor authentication, compliance policies, identity protection, and secure remote access. Shabaz explains why identity has become the new security perimeter in cloud computing and why organizations should balance strong security controls with user productivity. Instead of creating friction through excessive authentication prompts, modern security focuses on intelligent risk-based protection that safeguards users without interrupting their daily work.

THE FUTURE OF END-USER COMPUTING IN THE AI ERA
Artificial Intelligence is beginning to reshape virtual desktop environments through automation, intelligent management, and AI-powered administration. The conversation explores Windows 365 Frontline, Windows 365 Reserve, GPU-enabled Cloud PCs, AI workloads, automation, Infrastructure as Code, Nerdio management capabilities, and the future evolution of Azure Virtual Desktop and Windows 365. Listeners also gain insight into how organizations can prepare for next-generation cloud desktops while balancing performance, cost optimization, governance, and the growing role of AI in enterprise computing.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Global Secure Access - Simply Explained

Thu, 06 Aug 2026 07:00:03 +0000

VPNs were built for a world where everyone worked in one office and apps lived in one data center. This knowledge nugget helps IT and security teams understand Microsoft Entra Global Secure Access in plain English, showing how Private Access and Internet Access replace broad network tunnels with identity-driven, per-app routes and where to start with a focused pilot.

In this episode

00:00 – Intro: one app, a whole floor of keys
01:27 – Why traditional VPNs no longer fit
04:22 – Identity at the center: SSE, Zero Trust and Conditional Access
07:36 – Entra Private Access: the modern VPN replacement
11:16 – Entra Internet Access: the secure web gateway
14:46 – How the pieces work as one system
16:37 – Getting started with a focused pilot

Key takeaways

Traditional VPNs start with the network and often grant broader reach than a user needs, which increases the risk of lateral movement and adds routing and support overhead.
Microsoft Entra Global Secure Access puts identity at the center: Entra ID and Conditional Access decide, per request, whether a user on a given device may reach a specific private app or internet destination.
Entra Private Access replaces broad VPN tunnels with app-specific routes via connectors, while Entra Internet Access applies web, SaaS and AI traffic rules that follow the user anywhere.

Worth quoting

“Global Secure Access isn't one giant tunnel that takes all your traffic to one place. It's a set of guarded routes. Each route has a destination, a set of rules, and a decision about whether you should be allowed through.” – Mirko Peters (14:50)

“Zero trust doesn't mean trusting nobody forever. It means a connection doesn't earn broad permission, just because it comes from a familiar network, a company location, or an encrypted tunnel.” – Mirko Peters (05:44)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a Global Secure Access FAQ
Zero Trust – is the approach underneath Global Secure Access: no broad trust from the network
Conditional Access – applies the company's rules per request, such as MFA or a managed device
Microsoft Entra ID – checks who signed in and feeds identity into every access decision
Related episode: ENTRA PIM EXPLAINED: Securing Privileged Access with Mark Orr [MVP]

Entra Workload Identities - Simply Explained

Wed, 05 Aug 2026 17:00:02 +0000

Apps, pipelines and AI agents need access too, yet many still hide passwords in code and config files. In this Simply Explained episode, Mirko Peters gives Azure admins, developers and architects a plain-English map of Microsoft Entra workload identities, managed identities, service principals and federation, plus a practical checklist for securing them.

In this episode

00:00 – Intro: who signs in when software needs access?
00:53 – User identities and workload identities
03:19 – App registrations, service principals and managed identities
07:09 – What happens during a token request
10:30 – Security rules for workload identities
14:06 – Picking the right pattern and a workload identity check

Key takeaways

Workload identities give applications, automations and AI agents their own Entra identity instead of shared service accounts or passwords in code.
An application registration is the app's global design, a service principal is its local identity in each tenant, and a managed identity is a service principal that Azure manages for an Azure resource.
Prefer managed identities inside Azure and workload identity federation outside it, use certificates over client secrets, grant minimal permissions and give every workload identity an owner.

Worth quoting

“A workload identity is different. It's a digital badge for software. That software could be an app your team built an automation that runs on a schedule, a background service, or even an AI agent” – Mirko Peters (01:25)

“So when you hear these names keep this map in your head, the application registration is the app's master design. The service principle is its working identity inside your company.” – Mirko Peters (06:41)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a workload identity FAQ
Microsoft Entra ID – acts as the reception desk that authenticates workloads and issues short-lived tokens
Azure Key Vault – holds the secret a logic app reads using its managed identity
Azure Logic Apps – serves as the running example of a workload with a managed identity
Related episode: Entra ID Governance: Access Reviews, Entitlement Management and Lifecycle Workflows

Azure Platform Engineering, Azure Landing Zones, Cloud Adoption Framework & Building Enterprise Cloud Platforms Jev Suchoi [MVP]

Wed, 05 Aug 2026 13:00:03 +0000

Many organizations have moved workloads to Azure but still run it like a traditional data center. In this interview, Microsoft MVP Jev Suchoi explains to cloud architects, platform teams and IT leaders how Azure landing zones, the Cloud Adoption Framework, Azure Policy and infrastructure as code combine into a secure self-service platform developers want to use.

In this episode

00:00 – Intro: building Azure the right way
00:58 – Jev's path from GIS and .NET to infrastructure and DevOps
10:50 – What platform engineering means
12:40 – Azure is not a data center
18:10 – Azure landing zones explained
28:50 – Cloud Adoption Framework and Well-Architected Framework
37:35 – Azure Policy, Zero Trust and infrastructure as code
46:15 – Self-service platforms, DevOps, IDPs, AI and quick-fire round

Key takeaways

Azure should not be treated as a data center: cloud success is an adoption exercise across people, processes and technology, not only a technical migration.
An Azure landing zone separates the platform landing zone for shared security, management, networking and identity from application landing zones built from subscriptions with pre-provisioned utilities and policies.
Platform engineering builds standardized, self-service building blocks for developers, using Azure Policy remediation, infrastructure as code with Bicep or Terraform, Azure Verified Modules and Azure DevOps or GitHub as guardrails that help rather than block.

Worth quoting

“It's not a data center and you should not treat it as well. I think that's the most fundamental, the biggest mistake or anti-pattern that exists when we're talking about moving workloads, applications, anything to Azure.” – Jev Suchoi (13:40)

Explore more on M365.FM

Episode page: the full interview with chapters, quotes and FAQ on Azure platform engineering
Jev Suchoi – cloud architect and Microsoft MVP who explains how he builds Azure platforms developers want to use
Azure landing zone – explained as a neighborhood: the platform landing zone serves application landing zones built from subscriptions
Microsoft Azure – the platform discussed throughout, with the warning not to run it like a data center
Related episode: Terraform - Simply Explained

Microsoft Entra Verified ID - Simply Explained

Wed, 05 Aug 2026 07:00:02 +0000

Modern identity security extends far beyond passwords and multi-factor authentication. While Microsoft Entra ID, passkeys, and MFA help verify that someone controls a sign-in method, they cannot prove important real-world facts such as employment status, completed security training, professional certifications, contractor relationships, or verified identity during account recovery. In this Microsoft Knowledge Nuggets episode, Mirko Peters explains Microsoft Entra Verified ID in plain English, showing how organizations can replace manual document verification with secure, privacy-friendly digital credentials that improve trust while reducing administrative effort.

UNDERSTANDING MICROSOFT ENTRA VERIFIED ID
Microsoft Entra Verified ID enables organizations to issue, store, and verify digital credentials based on open standards for decentralized identity. Instead of emailing PDFs, screenshots, certificates, or identity documents, trusted organizations issue digitally signed credentials that individuals securely store inside the Microsoft Authenticator app. These credentials contain verified claims such as employee status, completed training, professional licenses, student enrollment, or supplier relationships. When another organization requests proof, users decide whether to share the required information while the verifier can validate the credential's authenticity, issuer, expiration date, and revocation status without relying on manual phone calls or email confirmations.

ISSUERS, HOLDERS, AND VERIFIERS: THE VERIFIED ID MODEL
Every Microsoft Entra Verified ID solution follows a simple three-party trust model. The issuer creates and digitally signs the credential after validating information from trusted business systems. The holder receives and securely stores the credential in their digital wallet within Microsoft Authenticator. The verifier requests specific claims to support a business decision such as granting access, approving onboarding, confirming qualifications, or validating identity during sensitive operations. This model significantly reduces document handling, minimizes unnecessary sharing of personal information, and creates a more secure verification process that scales across organizations.

FACE CHECK AND HIGH-ASSURANCE IDENTITY VERIFICATION
For higher-risk scenarios, Microsoft Entra Verified ID introduces Face Check to strengthen identity verification. Face Check compares a live selfie with the photo stored inside the verified credential, helping organizations confirm that the individual presenting the credential is the legitimate credential holder. The episode explores practical use cases including remote employee onboarding, privileged account recovery, contractor verification, privileged access requests, and high-security administrative operations. Combined with Microsoft Entra ID, Face Check provides stronger protection against impersonation attacks, deepfakes, stolen devices, and social engineering while supporting Zero Trust identity principles.

PRACTICAL MICROSOFT 365 USE CASES FOR VERIFIED ID
Microsoft Entra Verified ID integrates naturally with Microsoft 365 identity and governance scenarios. Organizations can automate remote onboarding, simplify secure account recovery, validate contractor relationships, confirm training completion before granting access to sensitive projects, and verify qualifications without exchanging physical documents. Combined with Microsoft Entra Access Packages, Microsoft Teams, SharePoint Online, enterprise applications, and Microsoft Entra role assignments, Verified ID enables organizations to make access decisions based on trusted business facts instead of manual document reviews. This reduces administrative overhead while improving both security and user privacy.

BUILDING A TRUSTED DIGITAL IDENTITY STRATEGY
Successfully implementing Microsoft Entra Verified ID requires careful planning around credential issuance, trusted issuers, claim definitions, expiration policies, revocation processes, governance, and user experience. Organizations should begin with a single business scenario that already involves manual identity verification, establish clear trust relationships, define credential lifecycles, and gradually expand their implementation. As digital identity continues evolving, Microsoft Entra Verified ID provides a scalable foundation for privacy-preserving verification that complements Microsoft Entra ID, MFA, passkeys, and Zero Trust architecture while helping organizations modernize identity proofing across employees, partners, contractors, students, and customers.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Windows 365 Link - Simply Explained

Tue, 04 Aug 2026 17:00:02 +0000

Windows 365 Link looks like a small PC but works very differently, and many teams misjudge where it fits. This episode helps IT administrators and decision-makers understand the device, Cloud PCs, Entra ID and Intune, and decide whether shared-desk and frontline scenarios justify a rollout.

In this episode

00:00 – What Windows 365 Link is
01:34 – The device and the Cloud PC
04:48 – Sign-in with Entra ID, Intune management and Teams
08:21 – Security by design: TPM, secure boot, BitLocker
11:54 – Who it fits and who should skip it
16:05 – How the parts connect and three questions before rollout

Key takeaways

Windows 365 Link is a purpose-built access device: the Windows desktop, apps and files run in a Windows 365 Cloud PC, while the box on the desk only connects the user to it.
Entra ID handles identity, Intune manages the device and the Cloud PC, and Windows 365 provides the workspace, with TPM, secure boot, BitLocker and no local admin keeping the device locked down.
The device fits shared desks, shift work and contact centers with reliable networks, but not offline, mobile or developer roles, and it does not work with Azure Virtual Desktop.

Worth quoting

“Windows 365 link is a physical device built for one job, connecting you to a Windows 365 cloud PC. That definition matters because the device and the cloud PC are not the same thing.” – Mirko Peters (01:37)

“Intune manages the small link device at the desk while Windows 365 and Intune manage the actual cloud PC where the user works. One is the access point, the other is the working desktop.” – Mirko Peters (06:53)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a rollout FAQ
Windows 365 – provides the Cloud PC where the desktop, apps and files actually run
Microsoft Intune – manages the Link device itself and, with Windows 365, the Cloud PC
Microsoft Entra ID – checks the user's identity and access rules before the Cloud PC session opens
Microsoft Teams – calls keep camera, microphone and headset media handled locally at the desk
Related episode: Windows 365 or Azure Virtual Desktop: Choosing the Right Cloud PC Model

Building Modern Microsoft 365 Solutions with SharePoint Framework, Microsoft Graph, PnPjs & Great User Experiences with Julie Turner [MVP]

Tue, 04 Aug 2026 13:00:03 +0000

Modern Microsoft 365 development is about far more than writing code. Organizations expect solutions that integrate seamlessly across SharePoint, Microsoft Teams, Microsoft Graph, Azure, and Microsoft 365 while remaining scalable, secure, maintainable, and ready for future innovation. In this episode of M365.FM, Microsoft MVP Julie Turner shares decades of real-world experience designing enterprise-grade Microsoft 365 solutions. From SharePoint Framework (SPFx) and Microsoft Graph to PnPjs, open-source development, UX design, and AI-assisted coding, this conversation provides practical guidance for developers, solution architects, consultants, and technical decision makers building on the Microsoft platform.

WHY MICROSOFT 365 EXTENSIBILITY MATTERS MORE THAN EVER
Microsoft 365 has evolved into a powerful business platform that goes far beyond email and collaboration. Julie explains how extensibility enables organizations to transform Microsoft 365 into a tailored business platform by integrating external systems, automating business processes, extending SharePoint and Teams, and creating custom user experiences. Rather than replacing standard Microsoft functionality, modern development focuses on extending it through supported APIs, frameworks, and services that remain compatible with Microsoft's continuous cloud updates.

SHAREPOINT FRAMEWORK AS THE FOUNDATION OF MODERN DEVELOPMENT
SharePoint Framework has become the standard for building supported client-side solutions across Microsoft 365. Julie explains why SPFx remains the preferred development model for SharePoint Online, Microsoft Teams, and Microsoft 365 experiences. The discussion covers hosted deployment, simplified maintenance, supported customization, reusable components, and how developers can build scalable enterprise applications without maintaining complex infrastructure. The episode also highlights the best learning resources, Microsoft Learn content, and the extensive Patterns and Practices (PnP) community for developers getting started with SharePoint Framework.

MICROSOFT GRAPH, PNPJS, AND THE FUTURE OF ENTERPRISE APIS
Microsoft Graph has become the central gateway into Microsoft 365, but understanding when to use Graph versus native SharePoint REST APIs remains critical. Julie discusses the strengths and current limitations of Microsoft Graph, endpoint maturity, authentication, permissions, performance considerations, and enterprise security. She also explains how PnPjs dramatically simplifies development by eliminating repetitive boilerplate code, providing fluent APIs, simplifying authentication, retry logic, error handling, and API consumption. Listeners also gain insight into the future roadmap of PnPjs Version 5 and the importance of semantic versioning in large open-source projects.

DESIGNING USER EXPERIENCES THAT PEOPLE ACTUALLY ENJOY USING
Technology alone does not create successful solutions. Great user experience often determines whether employees embrace or avoid enterprise software. Julie shares practical examples from real customer projects, explaining how thoughtful UX design improves productivity, reduces friction, and increases adoption. Whether building mobile applications for field workers, internal business applications, or Microsoft 365 solutions, developers should focus on simplicity, responsiveness, accessibility, and minimizing unnecessary user interaction. Small UX decisions can have enormous impacts on employee satisfaction and business efficiency.

OPEN SOURCE, AI, AND THE FUTURE OF MICROSOFT DEVELOPMENT
The conversation concludes with an honest discussion about open-source software, AI-assisted development, GitHub Copilot, Claude Code, Microsoft Copilot, and the future relationship between low-code and pro-code development. Julie explains why AI should enhance—not replace—developer expertise, how experienced developers can use AI as a collaborative assistant rather than an automated replacement, and why logical thinking and software architecture remain essential skills. The episode finishes with rapid-fire questions covering favorite developer tools, coding preferences, Microsoft events, future improvements for Microsoft Graph, and practical advice for developers who want to start building modern Microsoft 365 solutions today.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure Local - Simply Explained

Tue, 04 Aug 2026 07:00:05 +0000

Some workloads cannot leave the factory, hospital or store, yet running them on isolated local servers splits teams and tools. This Simply Explained episode helps IT pros and architects understand what Azure Local is, how it differs from Azure Arc, and when bringing Azure management to on-premises workloads really makes sense.

In this episode

00:00 – Two worlds: cloud and local servers
00:54 – Why some workloads must stay local
03:29 – What Azure Local actually is
06:29 – Building blocks: hardware, HCI cluster, Hyper-V
09:10 – Azure Arc and the Azure control plane
10:48 – One control plane for local workloads
13:37 – Where Azure Local fits and where it doesn't
16:22 – Start with the workload, not the hardware

Key takeaways

Azure Local runs virtual machines, containers and selected Azure services on validated hardware at your own site, while Azure provides management, monitoring, policy and security.
Azure Arc is the management layer that connects any outside infrastructure to Azure, whereas Azure Local is the hyperconverged platform where local workloads actually run.
Choose Azure Local when latency, data location rules, required offline operation or direct control demand it, and start every decision with the workload rather than the hardware.

Worth quoting

“Keeping data local isn't always about distrust of the cloud. Sometimes it's about law, sometimes about speed, and sometimes about keeping the business running when the network fails.” – Mirko Peters (02:41)

“Azure local doesn't copy all of public Azure into a rack of servers. You don't suddenly get every Azure service running locally just because you installed Azure local.” – Mirko Peters (04:19)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure Local
Azure Local – the platform explained here, running VMs and containers on validated hardware at your own site
Microsoft Azure – provides the control plane for Azure Local sites, while the full service range stays public
Microsoft Entra ID – decides who can view or manage the Azure Local environment instead of shared local admin passwords
Related episode: Microsoft Dev Box - Simply Explained

Microsoft AI Gateway - Simply Explained

Mon, 03 Aug 2026 21:00:03 +0000

When every team connects its own AI app straight to a model provider, keys leak, costs blur and nobody can say what an agent actually did. This episode is for platform, security and AI teams scaling beyond a single chatbot. You learn how Microsoft AI Gateway in Azure API Management centralizes routing, identity, safety checks and token limits for models, tools and agents.

In this episode

00:00 – From one chatbot to dozens of AI tools
00:56 – One front door for AI
03:27 – One endpoint, many models
06:53 – Governing agents and tools
10:08 – Token costs, limits and visibility
13:28 – A simple request journey
16:38 – Where to start

Key takeaways

Microsoft AI Gateway is a set of Azure API Management features that puts one managed control point in front of AI models, MCP tools, agents and business APIs.
Routing behind a stable endpoint lets platform teams change models, regions or providers and add backup paths without changing every application.
Per-agent identities, narrow approved tools, safety checks and token limits and quotas keep agents in bounds and make AI usage and cost traceable.

Worth quoting

“The AI Gateway is the reception desk and the security desk at the front. It checks who is coming in, applies the rules and records where requests go before they reach the rest of the building.” – Mirko Peters (01:21)

“A wrong answer from a model confuses someone, but an agent using the wrong tool can expose data, change a record, or trigger a process it should never touch.” – Mirko Peters (07:22)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Microsoft AI Gateway
Azure API Management – the service whose features make up Microsoft AI Gateway, extended from regular APIs to AI traffic
AI agent – the main risk case here, since agents call tools and each should get its own identity
Model Context Protocol (MCP) – the tool connection standard whose servers the gateway can put access and safety controls around
Microsoft Foundry – where teams build and manage AI projects, while the gateway governs the traffic they create
Related episode: Extending Microsoft 365 Copilot: Agents, MCP & Production-Grade AI with Yves Habersaat [MVP]

Microsoft Power Fx - Simply Explained

Mon, 03 Aug 2026 17:00:02 +0000

Many Excel users want to build apps but think they first need to learn a programming language. This Simply Explained episode shows beginners and citizen developers how Power Fx brings the familiar formula mindset into Power Apps, from properties and button actions to data, variables and reusable rules.

In this episode

00:00 – What Power Fx is
01:50 – From spreadsheet cells to app properties
04:52 – Properties turn formulas into app behavior
07:37 – Working with business data
11:03 – Variables, collections and reusable rules
14:46 – One formula system in an expense app
16:57 – Getting started and limits of low-code

Key takeaways

Power Fx is the Excel-like formula language of Power Platform, where formulas live in control properties instead of cells and update automatically.
Property formulas describe what a control should show, while OnSelect formulas run actions such as Notify or Navigate, and Filter, Sort and LookUp work with business data.
Variables and collections hold short-term context, reusable functions keep rules consistent, and lasting records belong in a proper data source such as SharePoint or Dataverse.

Worth quoting

“PowerFX is Microsoft's formula language for the Power Platform. It brings a familiar spreadsheet way of thinking into app building” – Mirko Peters (00:28)

“A text, visible, or color formula describes what something should be, while an on select formula runs because a person clicked or tapped.” – Mirko Peters (06:58)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on Power Fx
Power Fx – the formula language explained here, from property formulas and OnSelect actions to reusable functions
Power Apps – where Power Fx formulas sit in control properties such as Text, Visible and OnSelect
Microsoft Excel – the familiar starting point, since Power Fx carries the spreadsheet formula mindset into app building
Power Platform – the wider family of tools where Power Fx serves as the shared formula language
Related episode: Power Apps Component Framework - Simply Explained

Building Communities That Last: Copilot Adoption, Microsoft 365, and the Human Side of Technology with Heather Cook [Microsoft]

Mon, 03 Aug 2026 13:00:03 +0000

Heather Cook shares her remarkable journey from studying theater to becoming one of Microsoft's most influential community leaders. Her Microsoft story began more than 25 years ago when she joined the original SharePoint "Tahoe" project, helping write the very first customer case studies that introduced SharePoint to the world. From there, she built a career around customer advocacy, event production, marketing, and community engagement, eventually becoming a Microsoft MVP before joining Microsoft full-time. Heather explains how storytelling, creativity, and relationship-building have shaped every stage of her career and why communication skills remain just as valuable as technical expertise in today's AI-driven world.

WHY STRONG COMMUNITIES OUTLAST TECHNOLOGY
Technology constantly changes, but great communities continue to grow because they are built around people rather than products. Heather discusses how her theater background taught her the importance of collaboration, shared purpose, and creating memorable experiences. She reflects on witnessing the birth of the SharePoint community, where MVPs, consultants, Microsoft engineers, partners, and customers naturally came together to help one another. The conversation explores why becoming a Microsoft MVP is ultimately about giving back, why consistency matters more than perfection for content creators, and how podcasts, newsletters, blogs, and events all contribute to building trust over many years rather than overnight.

INSIDE MICROSOFT'S COMMUNITY, ADOPTION, AND EVENTS STRATEGY
Heather provides an inside look at Microsoft's SCALE organization and explains how teams responsible for Studio, Community, Adoption, Learning, and Events work together to help organizations successfully adopt Microsoft technologies. She introduces initiatives including Microsoft Tech Community, Adoption.microsoft.com, Microsoft 365 Champions, the Microsoft Global Community Initiative (MGCI), CommunityDays.org, and Microsoft's worldwide learning programs. The discussion covers how event organizers can work more closely with Microsoft, why CommunityDays.org is the central hub for Microsoft ecosystem events, how Microsoft supports community-led conferences around the world, and why adoption always requires much more than simply deploying new technology.

AI, CONTENT CREATION, AND THE HUMAN SIDE OF TECHNOLOGY
Artificial intelligence is changing the way creators work, but Heather believes AI should strengthen human creativity rather than replace it. She discusses using AI to accelerate newsletters, writing, research, and content production while emphasizing that authenticity remains the most valuable asset any creator has. The conversation also explores imposter syndrome, encouraging creators to publish their work confidently because every podcast, article, or presentation becomes part of a lasting knowledge archive. Heather also shares her passion for Women in Technology initiatives, inclusive communities, mentorship, and creating opportunities for future leaders throughout the Microsoft ecosystem.

RAPID FIRE INSIGHTS
During the quick-fire round, Heather recommends Facilitator as a Microsoft 365 feature everyone should explore, highlights custom Copilot agents as one of today's most exciting AI capabilities, and continues to praise SharePoint as one of Microsoft's most innovative platforms. She identifies maintaining a simple to-do list as one of the most underrated productivity habits, credits The Tipping Point by Malcolm Gladwell as an influential book in her career, and recognizes community leaders such as Caruana Gatimu and Donna Sarkar for their impact on the Microsoft ecosystem. She also encourages future community builders to listen first, understand people's needs, and only then begin creating solutions that genuinely serve their audiences.

BUILD RELATIONSHIPS THAT LAST
Heather closes with a message that reaches far beyond Microsoft technologies. Be curious, keep experimenting, continue learning, and never stop building meaningful relationships with other people. Products will evolve, AI will continue transforming the workplace, and new technologies will constantly emerge, but authentic human connections remain the foundation of every successful career and every thriving community. As Heather reminds listeners, the word "unity" exists inside the word "community"—a simple idea that perfectly captures why the human side of technology will always matter most.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Data Lifecycle Management - Simply Explained

Sun, 02 Aug 2026 21:01:55 +0000

Microsoft Purview Data Lifecycle Management helps organizations control how long information should be kept, when it should be reviewed, and when it should be securely deleted. Instead of allowing emails, Teams chats, SharePoint documents, OneDrive files, and other Microsoft 365 content to accumulate indefinitely, lifecycle management ensures every piece of information follows a defined business, legal, or regulatory process. This reduces storage costs, minimizes compliance risks, improves search efficiency, and ensures outdated or unnecessary information is removed in a controlled manner rather than remaining in the environment forever.

UNDERSTANDING THE DATA LIFECYCLE
Every piece of business information follows a natural lifecycle. It is created, actively used, retained for business or legal purposes, reviewed when necessary, and eventually disposed of once it no longer provides value. Microsoft Purview supports this complete journey through retention settings that prevent premature deletion while also ensuring content is not kept longer than necessary. Organizations can choose to retain content, delete content after a defined period, or combine both approaches by retaining information first and automatically deleting it later. A successful lifecycle strategy always begins by understanding why information exists before deciding how long it should remain.

RETENTION POLICIES VS. RETENTION LABELS
Retention Policies provide organization-wide rules that apply to entire Microsoft 365 locations such as Exchange Online mailboxes, SharePoint sites, OneDrive accounts, or Microsoft Teams chats. They are ideal when large amounts of similar content require identical retention behavior. Retention Labels, on the other hand, apply directly to individual emails or documents. This allows important business records, such as signed contracts or official agreements, to receive different retention periods than drafts or everyday working documents stored in the same location. Labels may be applied manually by users or automatically by Microsoft Purview based on predefined conditions, creating much more granular control over business-critical information.

SCOPES, CONFLICT RESOLUTION, AND RETENTION LOGIC
Microsoft Purview determines where retention rules apply by using either static scopes or adaptive scopes. Static scopes target specific users, mailboxes, or SharePoint sites, making them suitable for stable environments. Adaptive scopes automatically include users or locations based on Microsoft Entra ID attributes such as department or job title, significantly reducing administration in large organizations. When multiple retention rules overlap, Purview follows predictable conflict rules. Retention requirements always take priority over deletion, longer retention periods override shorter ones, and item-level retention labels can override broader location-based policies. This ensures organizations never delete information that must legally or operationally remain available.

HOW ALL THE COMPONENTS WORK TOGETHER
Data Lifecycle Management works by combining policies, labels, scopes, and automated retention into one consistent governance framework. A general retention policy can protect everyday content across Microsoft 365 while retention labels provide special treatment for important records. Adaptive scopes ensure policies automatically follow organizational changes, and retention continues to protect required content even if users accidentally delete files or emails. It is also important to understand that lifecycle management only controls how long information exists. It does not determine who can access content or how it is is shared. Those responsibilities belong to Microsoft Purview Sensitivity Labels and Data Loss Prevention (DLP), which complement lifecycle management as part of a complete Microsoft Purview governance strategy.

BEST PRACTICES FOR BUILDING A RETENTION STRATEGY
A successful Data Lifecycle Management implementation starts with understanding where information is stored across Exchange Online, SharePoint, OneDrive, Microsoft Teams, and AI-generated content. Business owners should define why each type of information exists, how long it must be retained, and what should happen when that retention period expires. Begin with broad, low-risk retention policies before introducing more granular retention labels for specialized records. Use adaptive scopes where organizational structures frequently change, clearly document every retention policy, carefully test automatic deletion before enabling it in production, and regularly review overlapping rules with compliance, legal, records management, and business stakeholders. By following this structured approach, organizations can reduce compliance risk while ensuring information remains available for exactly as long as it is needed—and no longer.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Microsoft Purview eDiscovery — Simply Explained

Sat, 01 Aug 2026 08:21:50 +0000

What happens when a regulator requests company records, HR launches an investigation, or legal teams need to preserve critical evidence? Searching through Outlook mailboxes, Teams chats, SharePoint sites, and OneDrive folders manually is slow, error-prone, and often impossible at enterprise scale. In this episode of Microsoft Knowledge Nuggets on M365.fm, Mirko Peters explains Microsoft Purview eDiscovery in plain English. You'll learn how organizations can securely discover, preserve, review, and export Microsoft 365 data using a structured, case-based process that supports legal investigations, compliance requests, internal audits, HR matters, and security incidents. Whether you're an IT administrator, Microsoft 365 consultant, compliance officer, security professional, or simply preparing for Microsoft certifications, this episode provides a practical introduction to one of the most important Microsoft Purview capabilities.

WHY eDISCOVERY MATTERS IN MICROSOFT 365
Modern work is scattered across multiple Microsoft services. Business conversations no longer live only in Outlook. Critical evidence may be spread across:

Exchange Online emails
Microsoft Teams chats and meetings
SharePoint Online document libraries
OneDrive for Business
Microsoft 365 Groups
Viva Engage conversations

During an investigation, missing even one location can result in incomplete evidence. Microsoft Purview eDiscovery provides a centralized process that helps organizations collect the right information while maintaining security, privacy, and governance. Instead of searching every mailbox and document library, organizations create structured cases that define exactly what should be searched and who may access the results.

HOW MICROSOFT PURVIEW eDISCOVERY WORKS
Rather than acting as a giant search engine, eDiscovery follows a carefully controlled workflow. The process begins by creating a case, which becomes the secure workspace for a specific investigation. Authorized users define the data sources, preserve evidence through Legal Hold when required, execute targeted searches, review the collected results, classify relevant documents, and finally export only the approved evidence. This structured workflow dramatically reduces risk compared to manually searching Microsoft 365 services while providing a clear audit trail for compliance and legal teams.

EXPLORE THE COMPLETE eDISCOVERY WORKFLOW
This episode explains every major component of Microsoft Purview eDiscovery, including:

Creating investigation cases
Selecting Exchange, Teams, SharePoint and OneDrive data sources
Understanding Legal Hold
Running targeted searches
Using Keyword Query Language (KQL)
Reviewing collected evidence
Working with Review Sets
Applying Tags
Exporting evidence securely
Managing permissions and access control
Understanding Standard vs Premium eDiscovery

Every topic is illustrated using practical business scenarios that demonstrate how investigations typically unfold inside Microsoft 365 environments

LEGAL HOLD EXPLAINED
One of the most misunderstood concepts in Microsoft Purview is Legal Hold. A Legal Hold ensures that potentially relevant information remains preserved even if users delete emails, edit documents, or leave the organization during an active investigation. Unlike traditional retention policies, which enforce normal business record retention, Legal Hold protects data because of a specific legal or compliance matter. This episode explains:

when Legal Hold should be used,
how it differs from Microsoft 365 retention,
why preservation must happen before searching,
and why only authorized business stakeholders should decide when a hold is applied or released.

SEARCH SMARTER — NOT WIDER
Many administrators assume that searching the entire Microsoft 365 tenant is the safest option. In reality, enterprise investigations work best when searches remain focused. You'll learn how to:

define relevant custodians,
limit searches using date ranges,
search by sender or recipient,
use keywords effectively,
understand Keyword Query Language (KQL),
analyze search statistics,
refine search queries iteratively,
and avoid collecting unnecessary personal or business information.

The episode demonstrates why successful investigations begin with focused questions instead of massive searches.

REVIEW, CLASSIFY AND EXPORT EVIDENCE
Finding information is only the beginning. Microsoft Purview eDiscovery enables reviewers to examine search results, determine relevance, classify documents using tags, and prepare evidence for legal or compliance teams. You'll discover:

what Review Sets are,
how reviewers organize findings,
when Premium review capabilities become valuable

<

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

ENTRA PIM EXPLAINED: Securing Privileged Access with Mark Orr [MVP]

Fri, 31 Jul 2026 13:00:02 +0000

Attackers rarely break in anymore, they sign in, and over-privileged admin accounts make that easy. In this episode Microsoft MVP Mark Orr shows Microsoft 365 and security admins how Entra Privileged Identity Management, phishing-resistant MFA, Intune device compliance and Conditional Access work together, and how PowerShell automation makes just-in-time access practical.

In this episode

00:00 – From Marine Corps satcom to Microsoft cloud
07:41 – Why identity is the new perimeter
13:13 – Common mistakes with privileged accounts and Zero Trust
18:05 – How Intune and Entra ID complement each other
21:19 – Entra PIM and just-in-time access
28:29 – Approvals, auditing, compliance and licensing
38:15 – PowerShell, automation and learning with AI
49:08 – Community tools and rapid-fire round

Key takeaways

Protect the identity plane first: move to passwordless, phishing-resistant authentication before investing in advanced device compliance or AI.
Entra PIM replaces standing admin rights with just-in-time, task-driven elevation, ideally with justifications, approvals and authentication context that forces MFA on every activation.
Combining Intune device compliance, device filtering and Conditional Access with cloud-only admin accounts creates defense in depth, and PowerShell keeps admins working when portals fail.

Worth quoting

“just in time elevation should be task driven and when the task is complete deactivate your role because you're opening yourself up to risk not only to yourself but to the organization” – Mark Orr (25:40)

“I feel like zero trust is a is a moving target and I see so many organizations get paralyzed trying to be perfect” – Mark Orr (17:19)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ
Mark Orr – the Marine Corps veteran and MVP who built a PowerShell module for bulk PIM activation
Conditional Access – the policy layer that ties device compliance, device filtering and authentication context to PIM elevation
Zero Trust – a moving target that Mark Orr says should not paralyze organizations chasing perfection
Related episode: Global Secure Access - Simply Explained

Microsoft Fabric Apps - Simply Explained

Thu, 30 Jul 2026 18:00:02 +0000

Microsoft Fabric Apps are a new way to build modern, data-driven web applications directly inside Microsoft Fabric. Rather than managing servers, APIs, databases, authentication, and hosting separately, Fabric provides these services automatically, allowing developers and data professionals to focus on creating business applications instead of infrastructure. A Fabric App can either connect to an existing Power BI semantic model or include its own managed SQL database, making it suitable for everything from interactive dashboards to operational business applications. This significantly lowers the barrier to building enterprise-grade solutions while keeping security, governance, and scalability within the Microsoft ecosystem.

HOW MICROSOFT FABRIC APPS WORK
Every Fabric App combines several managed services into a single application platform. When you create a new app, Microsoft Fabric automatically provisions a SQL database, GraphQL API, Microsoft Entra ID authentication, and static web hosting. Developers no longer need to configure backend infrastructure manually. Instead, they can concentrate on designing user experiences, building forms, creating dashboards, and implementing business logic. Fabric handles the underlying platform, making application development significantly faster than traditional full-stack approaches.

FABRIC APPS VS POWER BI
One of the biggest misconceptions is that Fabric Apps replace Power BI. They do not. Instead, both products solve different problems while sharing the same governed data foundation. Power BI remains Microsoft's leading business intelligence platform for analytics, reporting, dashboards, drill-through analysis, natural language queries, and executive reporting. Fabric Apps extend these capabilities by enabling custom web applications that can both display and write data. This makes them ideal for operational workflows such as inventory management, approval systems, CRM solutions, and internal business tools where users need to interact with data rather than simply analyze it.

REAL-WORLD USE CASES FOR FABRIC APPS
Fabric Apps are designed for business scenarios that require custom user experiences while still leveraging trusted enterprise data. Organizations can build inventory management systems with write-back capabilities, HR onboarding portals, expense approval applications, operational dashboards, customer feedback systems, and rapid business prototypes. Because Fabric Apps can connect directly to Power BI semantic models, organizations reuse existing DAX calculations, relationships, and governance policies without rebuilding business logic. This creates a single source of truth across both analytical reports and operational applications.

CURRENT LIMITATIONS OF MICROSOFT FABRIC APPS
Since Fabric Apps are currently in Public Preview, organizations should understand their current limitations before adopting them in production. Authentication currently supports only Microsoft Entra ID users, making the platform suitable for internal applications rather than customer-facing solutions. Applications also consume Microsoft Fabric Capacity Units (CUs), meaning performance and cost planning remain important considerations. In addition, advanced transactional scenarios, stored procedures, and highly complex business workflows may still require traditional development approaches. While AI-assisted development accelerates application creation, developers still benefit from understanding frontend technologies such as JavaScript and TypeScript.

SHOULD YOU START LEARNING FABRIC APPS?
If you're already working with Microsoft Fabric or Power BI, Fabric Apps represent one of the most important additions to the Microsoft data platform. They expand what organizations can build without replacing existing reporting investments, allowing the same semantic models and governed datasets to power both analytics and business applications. The best way to get started is by enabling the Fabric Apps preview, experimenting with both the Blank App and Data App templates, and exploring how custom applications can extend your existing Microsoft Fabric environment. Learning the platform today will prepare you for the broader capabilities expected as Fabric Apps move toward general availability.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Beyond the Prompt: Mastering Microsoft Copilot for Real Productivity with Jess Stratton [MVP]

Thu, 30 Jul 2026 13:00:03 +0000

Many companies buy Copilot licenses and still struggle to see real productivity gains. In this conversation, Microsoft MVP and LinkedIn Learning instructor Jess Stratton shares how business users and adoption leads can move beyond prompt engineering. Learn how personalization, better expectations, prompt galleries and departmental champions make Copilot work the way you work.

In this episode

00:00 – Welcome and guest introduction
01:24 – From Lotus Notes to LinkedIn Learning
06:13 – Why Copilot licenses fail to deliver value
09:56 – Misconceptions and the first coaching week
16:07 – Agents, skills and habits to unlearn
19:23 – Making Copilot sound like you
31:15 – Favorite prompts and best Copilot apps
46:56 – Rapid fire round

Key takeaways

Copilot value depends more on human behavior and showing people how it helps their own work than on features or governance.
Better results come from clear expectations in prompts, the right model choice and personalization settings such as custom instructions, meeting recap templates and Copilot memory.
Successful adoption uses excited champions per department and organization-specific prompt galleries to create quick, visible wins.

Worth quoting

“Human behavior, I think. I don't think it's quite the governance because I think that enough admins that are setting up co-pilot are pretty clear on what needs to happen and the risks.” – Jess Stratton (07:35)

“companies can put in your own prompts specific to your own organization. And I think that it's going to be a game changer because people have and companies have very specific workflows, very specific apps.” – Jess Stratton (09:20)

Explore more on M365.FM

Episode page: the full interview with chapters, quotes and FAQ on Copilot adoption
Jess Stratton – Microsoft MVP and LinkedIn Learning instructor sharing how she coaches people to get value from Copilot
Microsoft 365 Copilot – the assistant at the center, from personalization settings to PowerPoint tips and saved prompts
Prompt – why clear goals, context and especially expectations matter more than long prompt engineering
Related episode: Microsoft 365 Copilot: What Actually Makes People More Productive with Adrian Espes [MVP]

The Death of the Chatbot: Why Your Dataverse Strategy Is Broken

Wed, 29 Jul 2026 17:30:02 +0000

Many organizations celebrate early Copilot and chatbot wins, then discover agents borrowing human identities, calling models directly and running long after their projects ended. This episode is for architects, IT and governance leaders who want to scale AI agents safely, explaining how identity, ontologies, a governance hub with a model gateway, observability and Agent 365 form the landing zone that turns scattered chatbots into a managed platform.

In this episode

00:00 – Intro: chat isn't a platform
01:57 – The Copilot illusion and governance debt
06:04 – Identity and reasoning: agent IDs, RAG and ontologies
20:37 – What an AI landing zone actually is
25:13 – The model gateway and the ontology layer
40:26 – Agent 365 as the control plane and the governance hub
50:41 – Data residency, FinOps, multi-cloud and ghost agents
85:07 – Security, transition strategy and autonomous operations

Key takeaways

Copilot and chatbots are features, not a platform: scaling AI agents without identity, policy enforcement and logging creates governance debt that compounds with every new team.
An AI landing zone combines a traceable identity plane (agent IDs), a governance hub with a model gateway, and a shared ontology-based data plane so agents reason consistently over business relationships instead of text fragments.
Agent 365 as a control plane adds registry, policy enforcement, observability and lifecycle management across clouds, enabling cost control, preventive compliance and retirement of ghost agents.

Explore more on M365.FM

Episode page: the full episode with chapters, takeaways and a short FAQ on agent landing zones
AI agent – why isolated agents built by separate teams turn into governance debt as they multiply
Azure landing zone – reframed here as the operating model for AI: identity plane, governance hub and data plane
Governance – the episode's core theme: governance debt, shadow AI and why governance must come before migration
Related episode: Beyond Copilot: Building Enterprise AI Agents That Actually Work with Copilot Studio with Manpreet Singh [MVP-MCT]

The Future of IT Is Agentic: Inside Windows 365, Intune & Microsoft's AI Vision with Christiaan Brinkhoff

Wed, 29 Jul 2026 13:00:02 +0000

Cloud PCs, Intune and agentic AI are reshaping how enterprise IT manages endpoints. Christiaan Brinkhoff, who helped build Azure Virtual Desktop and Windows 365 at Microsoft, explains for IT pros and decision makers how these platforms fit together and where AI agents, MCP and Graph are taking endpoint management. Learn which decisions keep your foundation future-proof.

In this episode

00:00 – Welcome and guest introduction
01:41 – From FSLogix and Microsoft to Nerdio
07:19 – Azure Virtual Desktop vs. Windows 365
26:24 – Windows 365 Boot and the Windows App
31:31 – Agentic AI and the future admin role
53:52 – Intune, Graph and MCP
69:20 – AI hardware, NPUs and cost
77:39 – Rapid fire and closing advice

Key takeaways

Azure Virtual Desktop is the PaaS option with full control, while Windows 365 is the SaaS Cloud PC that democratizes VDI, and both can be combined.
Endpoint management is moving toward task-specific AI agents with tightly scoped permissions and agentic identities, with admins orchestrating rather than clicking.
MCP layered on top of Graph and a unified Copilot experience are seen as the path to more autonomous management, but training and change management are lagging behind.

Worth quoting

“I honestly believe that a product is the representation of the people and the culture who build it.” – Christiaan Brinkhoff (05:24)

“So imagine you have an agent that does like security, policy management for you, but you still in control of what that agent is doing. I think that's the important part.” – Christiaan Brinkhoff (44:00)

Explore more on M365.FM

Episode page: the full conversation with chapters, quotes and FAQ on agentic endpoint management
Christiaan Brinkhoff – guest who joined Microsoft via FSLogix, helped build Windows 365 and now builds at Nerdio
Windows 365 – the SaaS Cloud PC Christiaan helped build, compared with AVD and Windows 365 Boot
Azure Virtual Desktop – the PaaS VDI service with full control, its RDMI origins and the new hybrid option
Related episode: Windows 365 or Azure Virtual Desktop: Choosing the Right Cloud PC Model

How Do You Successfully Deploy Microsoft 365 Copilot Across an Enterprise?

Wed, 29 Jul 2026 09:16:16 +0000

A successful Microsoft 365 Copilot deployment begins long before licenses are assigned. Organizations should first define measurable business outcomes, identify high-value use cases, and secure executive sponsorship across IT, security, finance, and business leadership. Rather than treating Copilot as another software rollout, enterprises need an AI operating model that aligns governance, adoption, security, and ROI with real business processes. Starting with targeted scenarios creates faster wins while reducing risk and establishing a repeatable framework for future AI initiatives.

ASSESS MICROSOFT 365 READINESS BEFORE ENABLING COPILOT
One of the biggest mistakes organizations make is assuming their Microsoft 365 tenant is AI-ready simply because they own the licenses. Before deployment, businesses should assess identity management, SharePoint permissions, Teams collaboration spaces, OneDrive sharing, Microsoft Entra ID, Conditional Access, and overall information architecture. Existing oversharing, outdated permissions, unmanaged guest accounts, and poor data ownership become significantly more visible once Copilot can surface enterprise knowledge through natural language. A structured readiness assessment identifies critical risks before they become security incidents during rollout.

SECURE YOUR DATA WITH GOVERNANCE, PERMISSIONS, AND MICROSOFT PURVIEW
Microsoft 365 Copilot never creates new permissions—it simply works with the permissions users already have. That makes governance, Microsoft Purview, sensitivity labels, Data Loss Prevention, lifecycle management, and permission cleanup essential parts of every deployment. Organizations should prioritize high-risk content, establish clear ownership of SharePoint sites and Teams, implement strong information protection policies, and continuously review access rights. AI success depends as much on data quality and governance as it does on the underlying technology.

RUN A CONTROLLED COPILOT PILOT BEFORE SCALING ACROSS THE ENTERPRISE
Enterprise AI should expand through carefully planned pilot programs instead of company-wide deployments. Successful pilots focus on repeatable business workflows, measurable productivity improvements, and clearly defined success criteria. Business owners, IT, security, and finance should jointly evaluate business outcomes, adoption rates, governance findings, and user feedback before approving additional rollout phases. Every pilot should generate practical lessons that improve future deployments rather than simply proving that Copilot can generate content.

DRIVE MICROSOFT 365 COPILOT ADOPTION WITH CHANGE MANAGEMENT
Technology alone does not transform an organization—people do. Successful Copilot adoption requires executive communication, role-based enablement, workflow-specific training, AI champions, ongoing coaching, and continuous learning. Employees need practical guidance on when to trust Copilot, when human review remains mandatory, and how AI supports rather than replaces professional judgment. Measuring adoption should focus on changed business behavior and improved workflows instead of simple prompt counts or login statistics.

MEASURE COPILOT ROI AND BUILD A SCALABLE ENTERPRISE AI PLATFORM
The true return on Microsoft 365 Copilot comes from measurable business improvements rather than AI usage alone. Organizations should track workflow efficiency, quality improvements, reduced rework, employee productivity, governance maturity, and financial outcomes across every deployment phase. A successful rollout creates more than a productive workforce—it establishes the governance, architecture, operating model, and organizational experience required to scale future AI capabilities such as Copilot Studio, AI agents, Microsoft Graph integrations, and enterprise automation.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

From Pilot to Production: Building Enterprise AI That Actually Delivers with Leon Gordon [MVP]

Tue, 28 Jul 2026 13:00:02 +0000

Why do so many enterprise AI projects never leave the pilot stage? Five-time Microsoft MVP Leon Gordon explains for data leaders and Fabric teams how value-first proofs, governance by design and strong semantic models turn AI demos into production systems.

In this episode

00:00 – Introduction and Leon's background
05:11 – Why enterprise AI pilots fail
12:48 – Why Microsoft Fabric matters
25:18 – Fabric in an AI-first world and metadata
29:39 – Semantic models and governance by design
33:01 – Good governance, FabOps and data quality
46:24 – Copilot, Foundry and AI harnesses
50:23 – Business value, future roles and quickfire

Key takeaways

Most generative AI pilots fail because they do not start from measurable business value and a governed, AI-ready data foundation.
Microsoft Fabric unifies pipelines, notebooks, semantic models, real-time intelligence and apps on one platform, with the semantic model becoming the key context layer for agents.
Governance should be baked into the development life cycle from day one, including data quality rules, quarantining anomalies and cost attribution per domain.

Worth quoting

“The vast majority of it comes down to actually not leading with value first, understanding what the return investment is and what the outcome you're trying to deliver is” – Leon Gordon (06:36)

“how we do this is to bake in governance as part of the whole development life cycle so how do we get to an end working goal in the quickest possible way” – Leon Gordon (32:20)

Explore more on M365.FM

Episode page: the full interview with chapters, key quotes and an FAQ on Fabric and AI
Leon Gordon – five-time Microsoft MVP and Fabric consultant explaining value-first proofs and governance by design
Microsoft Fabric – the unified platform Leon sees becoming AI first, with semantic models as agent context
Governance – should be baked into the development life cycle from day one, not fixed later
Related episode: Everyone Wants Copilot—but Is Your Data Ready: Microsoft Fabric Architecture with Walter Calcagno [MVP-MCT]

Microsoft Purview is a Trap: The Hard Truth About Data Governance

Tue, 28 Jul 2026 08:27:15 +0000

Microsoft Purview is already in your tenant, and that ease is exactly why so many data governance rollouts end in permission sprawl and an unused catalog. This episode shows data governance and platform teams how to roll out Purview use case first, with a four-layer permission blueprint, role groups, data products and PIM-protected admins.

In this episode

00:00 – Why Purview's ease becomes a trap
03:10 – Big bang versus use case first
06:28 – The four-layer permission blueprint
20:52 – Five role groups and business-aligned collections
32:37 – Data products: where structure becomes value
36:09 – The medallion accountability chain
39:38 – Caging the Purview administrator with PIM
42:41 – Rollout sequence and failure modes

Key takeaways

Start a Microsoft Purview rollout with one concrete business question instead of scanning and cataloging everything.
Purview access spans four layers (tenant, data map, unified catalog, governance domain), so bundle each persona's permissions into about five role groups assigned to Entra groups.
Protect the Purview administrator role with just-in-time PIM activation and make ownership explicit for every data product and medallion layer.

Worth quoting

“governance isn't technology, governance is structure. It's the deliberate choices you make about ownership, accountability and how information flows. Those choices have to come first. The tool is the byproduct.” – Mirko Peters (02:30)

“The moment you decide to catalog everything you've already failed, not because you didn't work hard enough, but because of your intent you chose to build for completeness, instead of building for a person” – Mirko Peters (03:36)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on rolling out Microsoft Purview
Microsoft Purview – already in your tenant, so rollouts skip planning and end in sprawl and an unused catalog
Data governance – framed as structure first: ownership, accountability and one business question before any scanning
Governance – the core argument that governance is deliberate structure and the tool is only the byproduct
Related episode: From Pilot to Production: Building Enterprise AI That Actually Delivers with Leon Gordon [MVP]

From Excel Expert to Microsoft MVP: Empowering Millions with Data, Dashboards & AI with Karen Abecia [Microsoft MVP]

Mon, 27 Jul 2026 13:00:02 +0000

Many professionals use Excel every day without realizing how far it can take their careers. In this interview, Microsoft MVP Karen Abecia tells Excel users, data enthusiasts and educators how spreadsheets, dashboards and AI tools like Copilot shaped her journey and what makes data presentation truly stand out.

In this episode

00:00 – Welcome: Karen Abecia, Excel educator and Microsoft MVP
02:29 – How Excel changed her life, and the two Excel tattoos
09:44 – Is Excel dead? Answering the critics
11:36 – Good dashboards, the wow effect and data storytelling
22:11 – Copilot, AI and the end of coding barriers
26:47 – Excel and Power BI as partners
35:25 – Teaching, community and becoming an MVP
53:03 – Quick-fire round and wrap-up

Key takeaways

Karen Abecia built a global career as an Excel educator without a university degree, driven by continuous learning and a focus on visual, well-presented spreadsheets.
In her view, great dashboards come from small details such as alignment, consistent colors and correct text, not just numbers and charts, and Excel and Power BI complement each other.
She is still building her working relationship with Copilot in Excel, and she sees the Microsoft MVP award as recognition for years of helping people with data.

Worth quoting

“Excel don't have a lot of things that Power BI have. So they are complementary things.” – Karen Abecia (28:56)

“So I'm creating my relationship with co-pilot to say, do it, but in my way, and co-pilot is surprising me with good things.” – Karen Abecia (24:47)

Explore more on M365.FM

Episode page: the full interview with chapters, quotes and FAQ
Karen Abecia – the Brazilian Excel educator and Microsoft MVP interviewed about her career, teaching and community
Microsoft Excel – the tool at the center of her career, her dashboards and her two tattoos
Power BI – the tool she sees as a complementary partner to Excel rather than a rival
Related episode: What Happens When Sales Promises an Urgent Order

The Copilot Credit Trap- Why Your AI Economy is Already Broken

Sun, 26 Jul 2026 17:00:02 +0000

Copilot Credits and autonomous agents replace predictable license costs with variable consumption, while most tenants lack visibility, identity controls and audit trails. This episode helps IT leaders, architects and finance teams understand the credit economy, EU AI Act obligations and the governance, FinOps and procurement steps needed to deploy agents without runaway costs or compliance exposure.

In this episode

00:00 – Intro: from seats to credits
00:51 – The death of predictable AI budgeting
06:17 – Visibility, permission amplification and autonomy
15:03 – The August 2026 EU AI Act deadline and high-risk agents
20:45 – Identity, tool access and audit trails
33:13 – AI FinOps, ROI and the governance operating model
58:16 – The consumption trap and building a cost model
68:37 – The 90-day implementation timeline to August 2026

Key takeaways

Copilot Credits turn AI from a predictable per-seat license into variable consumption, so budgets must be forecast from usage patterns, task complexity and business value rather than head count.
Agents inherit user permissions, act autonomously and can be redirected by prompt injection, which makes distinct agent identities (Agent 365 and Entra ID), scoped tools, approval gates, kill switches and dedicated audit logging essential.
With EU AI Act high-risk obligations applying from August 2026, organizations need an agent inventory, risk classification, meaningful human oversight and AI FinOps practices such as showback and chargeback before scaling.

Explore more on M365.FM

Episode page: the full episode with chapters, cost examples and FAQ
Copilot Credits – the consumption currency that replaces predictable per-seat budgets with variable, per-task costs
AI agent – autonomous actors that inherit user permissions, act without approval per step and often run unseen
Copilot Cowork – the agent experience whose tasks consume 70 to 1,500 or more credits depending on complexity
Related episode: Power Platform Copilot Integration - Simply Explained

The End of AI Bloat: Why Modern Agents Need Skills

Sun, 26 Jul 2026 13:00:03 +0000

AI agents that start fast often become slow, costly and unreliable as their prompts grow into huge instruction blobs. This episode shows architects and Copilot Studio makers how modular skills, progressive disclosure and solid governance keep enterprise agents lean, accurate and manageable at scale.

In this episode

00:00 – Intro: agent bloat and the context tax
00:46 – Why agents degrade
03:46 – The skill as a reasoning boundary
07:00 – Progressive disclosure and manageability
16:48 – Skills in Copilot Studio and the Dataverse MCP bridge
23:42 – Routing, instructions vs. skills and cost economics
44:13 – Governance: supply chain risk and zoned environments
53:36 – Skill catalogs, measurement and common mistakes

Key takeaways

Monolithic system prompts make agents slower, more expensive and less accurate over time, while modular skills loaded through progressive disclosure keep the baseline context lean.
A skill's name and description are routing signals for the orchestrator, so they must be precise; universal rules belong in instructions, situational guidance in skills, and each skill should follow one archetype.
Skills that bundle scripts are a supply chain risk and need zoned governance, DLP, review, sandboxing and measurement, with Copilot Studio, Dataverse and MCP enabling managed, reusable skill libraries.

Explore more on M365.FM

Episode page: the full episode with chapters, skill design patterns, governance zones and FAQ
Agent skill – the modular, on-demand instruction packages proposed as the fix for bloated agent prompts
AI agent – agents that become slow, costly and error-prone when every turn reads a monolithic prompt
Copilot Studio – where makers create, upload and bundle skills and debug routing in the reasoning view
Dataverse – a central, versioned and access-controlled store for business skills shared across many agents
Related episode: From Financial Data to AI-Ready Decisions: Power BI, Microsoft Fabric, Semantic Models & AI Agents with Rishi Sapra [MVP]

THE DEATH OF THE PROXY: Architecting Dataverse for the Agent Fabric

Sun, 26 Jul 2026 07:00:03 +0000

Still wiring a local proxy to connect AI tools to Dataverse? This episode shows Power Platform architects and developers why the remote Dataverse MCP endpoint, secured with PKCE and Entra ID, turns Dataverse into a governed, multi-LLM backbone for Claude, GitHub Copilot and custom agents.

In this episode

00:00 – Why the local STDIO proxy is dead
02:39 – The latency lie and the scaling problem
08:10 – Streamable HTTP: the remote endpoint
11:27 – PKCE and registering the Entra ID app
19:44 – Connecting Claude Desktop, Claude Code and GitHub Copilot
27:12 – The 15-tool contract and safe mutation
33:27 – Governance layers and observability
40:00 – The fabric model, multi-LLM and the 2027 trajectory

Key takeaways

The remote streamable HTTP endpoint of the Dataverse MCP server replaces local STDIO proxies and scales to many agents and LLM clients through one governed endpoint.
PKCE with an Entra ID app registration, an environment allow list and correct redirect URIs lets Claude and GitHub Copilot authenticate without any client secret.
Existing Dataverse roles, row and field level security, business rules, confirmation flags and audit trails keep agent actions governed and traceable.

Worth quoting

“enterprises figured out that if you're serious about AI, you can't afford one-off integrations for every LLM. You need a contract, a single endpoint, a model that scales.” – Mirko Peters (00:37)

“Dataverse stops being the database under power apps and becomes the agentic backbone of your entire platform. One endpoint, any LLM, same governance, same security, same audit trail” – Mirko Peters (00:55)

Explore more on M365.FM

Episode page: the full episode with chapters, setup steps, quotes and an FAQ
Dataverse – exposes a remote MCP endpoint and becomes the governed data backbone for many agents
Model Context Protocol (MCP) – the protocol contract that lets any compliant client reach Dataverse through one endpoint
Dataverse MCP server – the streamable HTTP endpoint with 15 bounded tools, secured by PKCE and Entra ID
Related episode: The Architecture of Intelligence- Why the Chatbox is the Wrong Model for Enterprise AI

The Death of the Pipeline: Why AI Agents are Replacing Traditional

Sat, 25 Jul 2026 17:00:02 +0000

CI/CD pipelines were designed for human-speed decisions and are becoming the bottleneck in modern software delivery. This episode is for architects and DevOps leaders who want to understand how AI agents replace linear pipelines with an adaptive fabric, why full autonomy is a myth, and how to build governance, skills and a realistic business case for agentic DevOps.

In this episode

00:00 – The pipeline was built for humans
03:36 – Why linear automation hits a wall
06:52 – Enter the agent: reasoning instead of scripts
10:10 – From pipeline to fabric and the supervisor-worker pattern
16:29 – The autonomy ceiling and governance as architecture
25:18 – Real-world impact, skills gap and cost
34:26 – Use cases: incidents, reviews, tests and deployments
46:07 – Governance fabric, roadmap, risks and the five-year vision

Key takeaways

Traditional CI/CD pipelines are built around human approval gates and brittle scripts, which makes humans the bottleneck once infrastructure moves faster than people can reason about it.
Agents operate under policy rather than procedure, coordinated through patterns such as supervisor-worker and multi-agent committees, with tiered autonomy instead of full autonomy.
Governance must be built into the architecture through scoped agent identities, policy engines, audit logs and decision-level observability, rolled out in staged low-risk pilots with change management.

Explore more on M365.FM

Episode page: the full episode with chapters, architecture patterns, roadmap and FAQ
AI agent – reasoning actors that work under policy and replace brittle pipeline scripts across delivery
Governance – built into the architecture through scoped permissions, policy engines and audit logs, not documents
Automation – the scripts and runbooks the episode shows breaking whenever infrastructure changes
Agent observability – decision traces, decision quality metrics and policy dashboards that reveal agent drift early
Related episode: The Death of the Chatbot: Why Your Dataverse Strategy Is Broken

The Productivity Illusion: Why AI is Breaking Your Engineering KPIs

Sat, 25 Jul 2026 13:00:03 +0000

Engineering dashboards look greener than ever in the age of AI-generated code, yet incidents, review queues and developer burnout keep rising. This episode helps engineering leaders and IT decision makers see through the productivity illusion and shows which flow, quality, cognitive load and value metrics reveal what is really happening.

In this episode

00:00 – The hallucination of speed
09:18 – Activity versus systemic flow
13:21 – The cognitive load crisis
17:06 – The toxic KPI trap
20:13 – From DORA 4 to DORA 5: rework rate
34:28 – The governance bottleneck and the burnout signal
47:44 – The diagnostic dashboard
55:48 – The organizational shift and the roadmap

Key takeaways

AI has moved the engineering bottleneck from writing code to reviewing, testing and governing it, so activity metrics like deployment frequency look better while stability, incidents and rework get worse.
Rework rate, decomposed lead time, flow efficiency and cognitive load reveal system health far better than the classic four DORA metrics alone.
Metrics should be diagnostic questions owned by teams and never used for individual performance, with changes introduced as measured experiments through a phased roadmap.

Explore more on M365.FM

Episode page: the full episode with chapters, the metric breakdown and FAQ
Governance – the new AI code review gates that lengthen lead time and must be made explicit
Human in the loop – a dashboard metric checking whether human review really catches the problems AI code creates
Compliance – one of the extra checks AI-generated code passes before production, adding waiting time
Related episode: Beyond Copilot: Building Enterprise AI Agents That Actually Work with Copilot Studio with Manpreet Singh [MVP-MCT]

The DevOps Tax: Why Your Platform is Failing

Sat, 25 Jul 2026 07:00:02 +0000

Developers are drowning in Kubernetes, pipelines and compliance checklists instead of shipping features. This episode is for engineering leaders and platform teams who want to understand the DevOps tax and replace it with platform engineering, from golden paths and policy as code to Team Topologies, measurement and AI-ready governance.

In this episode

00:00 – The DevOps tax defined
03:19 – How DevOps broke at scale
06:42 – The cognitive load crisis and shadow IT
16:25 – DevOps versus platform engineering
20:18 – Golden paths, infrastructure as code and policy as code
31:12 – Team Topologies and the platform product mindset
41:16 – Measurement, developer experience and AI governance
64:31 – Migration path, ROI and objections

Key takeaways

The DevOps tax is the hidden cost of making every team run its own infrastructure at scale, paid in cognitive load, tool sprawl, shadow IT and burnout.
Platform engineering inverts the model: a platform team treats infrastructure as a product and offers golden paths built on infrastructure as code and policy as code.
Success is measured by voluntary adoption, developer experience, DORA metrics and reduced cognitive load, and the same embedded governance lets AI agents such as Copilot operate safely.

Worth quoting

“The DevOps promise didn't fail because the idea was wrong. It failed because it scaled wrong.” – Mirko Peters (00:44)

“A golden path is an opinionated pre-built workflow that handles the 80% of use cases that are actually common, not all use cases, not every possible variation.” – Mirko Peters (20:33)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on platform engineering
Infrastructure as code – the foundation that makes golden paths reproducible, auditable and enforceable at scale
Governance – shifting from ignored policy documents and code review to automated checks at deployment
Bicep – recommended for pure Azure organizations for native support and Azure Policy integration
Terraform – the multi-cloud option, with provider plugins that can lag behind new Azure services
Related episode: Azure Bicep - Simply Explained

Microsoft Purview Insider Risk Management - Simply Explained

Fri, 24 Jul 2026 18:00:02 +0000

Your biggest data risk may already be logged in: departing employees, careless sharing and unapproved apps all look like normal work to traditional security. This episode explains for compliance and IT teams how Microsoft Purview Insider Risk Management detects risky patterns, supports privacy-preserving investigations and can be rolled out step by step.

In this episode

00:00 – The insider blind spot
01:11 – Why traditional security misses insider threats
02:28 – What Insider Risk Management is
03:59 – How risk is defined and scored
05:27 – Indicators, policies and templates
07:12 – Investigating an alert
08:46 – Privacy guardrails and compliance
10:19 – Real-world scenarios and getting started

Key takeaways

Insider threats come from authorized users, so perimeter tools like firewalls and MFA cannot detect them on their own.
Microsoft Purview Insider Risk Management scores patterns of behavior over time using templates, indicators and optional HR or physical security signals.
Start small with one or two templates and a pilot group, tune thresholds for about 30 days and train investigators on privacy controls like anonymized user names.

Worth quoting

“Insider threats are hard to detect because they come from authorized users. They're not breaking in. They're logging in. And logging in looks exactly like normal work.” – Mirko Peters (00:44)

“Traditional security tools keep bad actors out, but they're not designed to spot a trusted employee who suddenly starts acting differently.” – Mirko Peters (00:52)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on insider risk
Microsoft Purview – the compliance platform that Insider Risk Management runs inside as a module
Compliance – the team that should start the rollout and own the privacy and legal guardrails
Microsoft 365 – the signal source, and many companies already licensed for it just need to turn it on
SharePoint – one of the signal sources, tracking file access and downloads that feed risk scores
Related episode: Microsoft Purview Audit - Simply Explained

Microsoft Purview Information Protection - Simply Explained

Fri, 24 Jul 2026 17:00:02 +0000

Welcome to another episode of Knowledge Nuggets with Mirko Peters. Today we're exploring Microsoft Purview Information Protection, the foundation of Microsoft's data classification and protection strategy across Microsoft 365. Every day, organizations create thousands of documents, spreadsheets, emails, presentations, and Teams conversations. Some of that information is completely public, while other files contain financial records, customer information, legal contracts, intellectual property, or confidential business plans. The challenge isn't simply storing this data—it's ensuring every piece of information is handled appropriately wherever it travels. Microsoft Purview Information Protection solves this challenge by allowing organizations to classify sensitive information, apply persistent sensitivity labels, and automatically enforce protection policies across Microsoft 365. Instead of waiting until data is about to leave the organization, protection begins the moment the content is created. In this episode, we'll explore how Microsoft Purview Information Protection works, how sensitivity labels travel with your data, how automatic classification operates behind the scenes, and how it integrates with Data Loss Prevention, Microsoft Teams, and Microsoft 365 Copilot.

WHY INFORMATION PROTECTION MATTERS
Many organizations assume their information is secure simply because it resides in Microsoft 365. However, protecting data from hackers is only one part of the challenge. The larger risk often comes from accidental sharing, misclassification, or users unknowingly exposing confidential information. Traditional security approaches attempted to inspect files only when they were leaving the organization. Every outgoing email or shared document had to be scanned before determining whether it contained sensitive information. While effective, this approach introduces delays and only reacts after data has already begun moving. Microsoft Purview Information Protection changes the model entirely. Instead of waiting until information leaves the organization, content is classified and labeled immediately. Once protected, every Microsoft 365 service instantly understands how that information should be handled without repeatedly scanning the content. Protection becomes proactive rather than reactive.

WHAT IS MICROSOFT PURVIEW INFORMATION PROTECTION?
Microsoft Purview Information Protection provides a centralized framework for classifying, labeling, and protecting sensitive information. The core concept is remarkably simple. Every document or email receives a sensitivity label that communicates its security requirements. Common examples include:

Public
Internal
Confidential
Highly Confidential

These labels aren't merely visual indicators. Each label contains metadata that permanently travels with the file wherever it goes. That metadata can automatically trigger:

Encryption
Access restrictions
Watermarks
Headers and footers
Printing restrictions
Sharing controls
Copy protection

Rather than relying on users to remember every security setting manually, one sensitivity label applies the correct protections automatically. Because Information Protection is built directly into Microsoft 365, users often interact with it through the Sensitivity dropdown available in Word, Excel, PowerPoint, Outlook, and other Office applications.

CLASSIFICATION: FINDING SENSITIVE INFORMATION
Before information can be protected, Microsoft Purview must first identify sensitive content. Microsoft uses two primary detection methods. The first is Sensitive Information Types (SITs). These recognize structured information such as:

Credit card numbers
Passport numbers
National identification numbers
Healthcare identifiers
Banking information

Microsoft provides hundreds of built-in detection patterns that organizations can immediately begin using without additional configuration. The second approach uses Trainable Classifiers. Unlike simple pattern matching, trainable classifiers use artificial intelligence to recognize unstructured documents such as:

Contracts
Legal documents
Resumes
Financial reports
Project documentation

Organizations can also create custom classifiers and custom Sensitive Information Types for proprietary business information including employee IDs, customer numbers, project codes, or invoice formats. Classification identifies sensitive information. Protection comes later through sensitivity labels.

SENSITIVITY LABELS: THE FOUNDATION OF PROTECTION
Once content has been classified, sensitivity labels determine how Microsoft 365 should handle it. Each label becomes much more than a simple category. A single label can automatically apply multiple protections simultaneously. For example, a Highly Confidential label might:

Encrypt the document
Prevent external sharing
Disable printing
Restrict copy and paste
Apply visible watermarks
Limit editing permissions

Most importantly, these protections remain attached to the file itself. If the document leaves SharePoint, is emailed externally, or stored elsewhere, the label and its protections travel with it. This persistence ensures organizations maintain control over sensitive information regardless of where the file moves. Every Microsoft 365 workload—including SharePoint, OneDrive, Teams, Exchange Online, and Microsoft 365 Copilot—recognizes and respects these labels automatically.

MANUAL VS AUTOMATIC LABELING
Organizations can apply sensitivity labels in two different ways. Manual labeling allows users to choose the appropriate label directly within Microsoft Office applications. This works well when users understand the business context surrounding a document. However, relying entirely on users creates inconsistency. Microsoft therefore provides automatic labeling. Client-side automatic labeling operates inside Office applications while users create documents. If sensitive information such as payment card data appears, Office can recommend or automatically apply the correct label before the document is saved. Service-side automatic labeling works across Microsoft 365 itself. Existing documents stored in SharePoint, OneDrive, or Exchange Online are scanned and labeled automatically without requiring user interaction. Microsoft recommends combining both approaches. Automatic labeling provides consistent baseline protection across large environments, while manual labeling allows users to apply additional context when appropriate. Simulation mode allows organizations to evaluate automatic labeling policies before enforcing them in production.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Microsoft Purview Data Loss Prevention (DLP) - Simply Explained

Fri, 24 Jul 2026 16:00:03 +0000

Most data leaks are not attacks but honest mistakes by your own people. This episode explains to IT and security teams how Microsoft Purview Data Loss Prevention protects sensitive data across email, files, Teams chats, devices and Copilot, and how to roll it out without breaking legitimate workflows.

In this episode

00:00 – Intro: an accidental leak of 27.7 million records
00:36 – The data leak problem: why DLP exists
02:06 – The office building analogy
03:16 – Exchange Online: protecting email
04:50 – SharePoint, OneDrive and Teams DLP
08:10 – Endpoint DLP: protecting devices
10:48 – Copilot and AI DLP
12:46 – Avoiding common mistakes and a 90-day plan

Key takeaways

Most data leaks are accidental, so Microsoft Purview DLP focuses on catching honest mistakes by watching what the data is, who handles it and where it goes.
DLP covers Exchange Online, SharePoint, OneDrive, Teams, endpoints and Copilot, and each channel is a separate door that needs its own policy coverage.
Treat DLP as a governance program: keep sensitivity labels simple, start in simulation mode, use policy tips and only then turn enforcement on.

Worth quoting

“It's not built to stop hackers, it's designed to stop your own people from accidentally leaking sensitive data.” – Mirko Peters (00:22)

“Instead of blocking everything, it watches three things, what the data is, who's handling it and where it's going. Then it enforces rules automatically.” – Mirko Peters (01:30)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short DLP FAQ
Data loss prevention (DLP) – the episode's core topic, built to catch accidental leaks rather than outside attackers
Microsoft Purview – the Microsoft product behind the DLP covering email, files, chats, devices and AI tools
Microsoft 365 Copilot – the AI assistant DLP now watches, blocking responses built from sensitive, labeled content
Related episode: Data Loss Prevention in Microsoft 365: Policies That Actually Work

Microsoft Entra Private Access - Simply Explained

Fri, 24 Jul 2026 15:00:03 +0000

VPNs give remote users far too much access and create constant help desk friction. This Simply Explained episode is for IT admins and security teams who want to understand how Microsoft Entra Internet Access and Global Secure Access replace network trust with identity-driven Zero Trust, how Conditional Access stops token theft and how to get started with licensing.

In this episode

00:00 – Why traditional VPNs are broken
01:37 – From network trust to identity trust
03:10 – What Entra Internet Access is
04:54 – The three traffic forwarding profiles
06:45 – Conditional Access integration
08:45 – Web filtering and threat protection
11:11 – Licensing and getting started

Key takeaways

Traditional VPNs trust the network and grant broad access, while Microsoft Entra Internet Access verifies identity, device and risk for every request.
Global Secure Access routes traffic through Microsoft, internet and private access profiles, and Conditional Access can require the client to block stolen-token attacks.
Web content filtering, TLS inspection, tenant restrictions and shadow AI discovery run at the network level, and the Microsoft traffic profile is already included with Entra ID P1.

Worth quoting

“VPNs trust the network, not the user. They check your credentials at the door, and then assume everything is fine for the rest of the session. That's the opposite of what modern security needs.” – Mirko Peters (01:21)

“Instead of protecting a network, you're protecting identities. Instead of building walls, you're building policies. And instead of trusting a connection, you're verifying every request.” – Mirko Peters (02:58)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on Global Secure Access
Conditional Access – the policy engine that can require the Global Secure Access client and block stolen tokens
Zero Trust – the never trust, always verify model that replaces network trust with identity trust
Microsoft Entra ID – the central identity plane that makes real-time access decisions for every request
Related episode: ENTRA PIM EXPLAINED: Securing Privileged Access with Mark Orr [MVP]

Microsoft Graph Delta Queries - Simply Explained

Fri, 24 Jul 2026 14:00:02 +0000

Many apps that sync Microsoft 365 data still download everything every few minutes, wasting bandwidth and hitting rate limits. This episode explains for developers how Microsoft Graph delta queries and delta links work, which limitations to plan for, and how to combine them with change notifications for reliable, efficient sync.

In this episode

00:00 – Why full syncs waste data
01:22 – What is a delta query?
02:50 – How the token system works
04:38 – Limitations you can't ignore
07:25 – Delta query vs. change notifications
09:45 – The hybrid approach
11:42 – Practical rules for production
13:31 – Example: syncing calendar events

Key takeaways

A delta query returns only the items added, updated or deleted since your last call, using a saved delta link instead of a full resync.
Plan for token expiry after seven days, HTTP 410 resets, processing delays, untracked properties and duplicate changes.
Combining change notifications as a trigger with delta queries for the details gives near real-time sync without wasteful polling.

Worth quoting

“A Delta query asks Microsoft Graph for only the changes since your last check. Not everything, just a new, updated, or deleted items.” – Mirko Peters (01:26)

“You don't have to store timestamps or version numbers yourself. You don't have to figure out what changed and what didn't. Microsoft handles all that tracking.” – Mirko Peters (04:27)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Graph delta queries
Change notifications and webhooks – the push trigger paired with delta queries in the recommended hybrid sync pattern
Microsoft Graph – the API that tracks changes and returns delta links so apps fetch only what changed
Microsoft Entra ID – the directory whose user and group delta tokens expire after seven days
Microsoft 365 – the source of users, mail, calendar events and files that delta queries keep in sync
Related episode: Microsoft Graph Change Notifications - Simply Explained

Responsible AI Is Good Business — Featuring Wiebke Apitzsch

Fri, 24 Jul 2026 13:00:03 +0000

Many companies rush into AI because of market pressure and then stall when results disappoint or the gut feeling says something is wrong. In this conversation, AI strategy advisor Wiebke Apitzsch shows business leaders why responsible AI is good business: start from strategy, protect what must stay human, and design processes that keep hallucinations, bias and data risks under control.

In this episode

00:00 – Welcome and Wiebke's path into technology
03:35 – Lessons from strategy consulting
08:10 – Why AI adoption is still difficult
12:00 – Kant: dignity, price and what to automate
17:16 – AI and philosophy
26:51 – How autonomous should AI be?
35:42 – Culture, process and a practical example
39:40 – Hallucinations, bias, security and responsibility

Key takeaways

Before choosing tools, organizations should decide who they want to be with AI and which activities must stay human, especially relationships with clients and employees.
AI adoption is mostly a culture and process problem: start from business strategy, and design workflows where a knowledgeable human must check AI results, which also keeps hallucinations in check.
Responsibility and trust cannot be delegated to a chatbot provider; the company using AI stays accountable, and confidential data needs security measures matched to its sensitivity.

Worth quoting

“So the best thing that companies can do is to say, hey, let me review my strategy and my numbers as always and find out where my problems are and where my opportunities are as always.” – Wiebke Apitzsch (33:49)

“So if you set up the process in a way that a knowledgeable human has a look at the final result in a way that it cannot skip it, yeah? You have to avoid that people can become lazy and just say yes, yes, yes.” – Wiebke Apitzsch (40:39)

Explore more on M365.FM

Episode page: the full conversation with chapters, key quotes and an FAQ on responsible AI
Wiebke Apitzsch – the guest, co-founder of AI Impact, who connects philosophy, strategy and technology in AI adoption
Human in the loop – her design principle: a knowledgeable person must check AI results and cannot skip that step
AI agent – discussed through the host's agent with its own money and the limits of autonomy
Related episode: Beyond Copilot: Building Enterprise AI Agents That Actually Work with Copilot Studio with Manpreet Singh [MVP-MCT]
Related episode: Microsoft Agent Framework - Simply Explained

Microsoft Graph Webhooks - Simply Explained

Fri, 24 Jul 2026 12:00:03 +0000

Is your app still asking Microsoft Graph every few minutes whether anything has changed? This episode explains to Microsoft 365 developers how Graph webhooks replace polling with change notifications, how subscriptions and validation work, and why combining them with Delta query gives you integrations that are both fast and reliable.

In this episode

00:00 – Intro: the mailbox analogy
00:43 – The polling problem and Graph throttling
02:23 – What are webhooks?
04:10 – How Microsoft Graph webhooks work
06:10 – Creating a subscription
08:40 – The validation handshake
10:32 – Handling notifications, security and lifecycle
16:17 – Real-world example and next steps

Key takeaways

Polling Microsoft Graph wastes thousands of requests, still misses real-time changes and can push your app into throttling.
A Graph webhook needs a subscription with notification URL, resource, change type and expiration, plus a validation handshake that echoes the token as plain text.
Acknowledge notifications within seconds, process them asynchronously, renew subscriptions before they expire and use Delta query as a safety net for missed changes.

Worth quoting

“A web hook is an HTTP request sent automatically when something happens. You don't ask for it. The server just pushes it to you.” – Mirko Peters (02:30)

“Acknowledge immediately and process asynchronously. Your endpoint should validate the client state, accept the notification, and return it 200 or 202 responses as fast as possible.” – Mirko Peters (12:22)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on Graph webhooks
Change notifications and webhooks – the episode's subject: Graph's name for webhooks, plus Delta query as the safety net
Microsoft Graph – the API that sends change notifications instead of being polled and throttles apps that over-poll
SharePoint – an example source of change notifications, such as receipts uploaded to a document library
Related episode: Stop Reinventing SPFx- Building Better SharePoint Solutions with PnP React Controls with Siddharth Vaghasia [MVP]

Microsoft Graph Change Notifications - Simply Explained

Fri, 24 Jul 2026 11:00:03 +0000

Polling Microsoft Graph every few minutes wastes requests, misses changes and can get your app throttled. This episode explains for Microsoft 365 developers how change notifications, subscriptions, validation and renewal work, and how to build reliable real-time apps with delta queries as a safety net.

In this episode

00:00 – The problem with polling
01:04 – What are change notifications?
02:34 – Creating a subscription
04:16 – The validation handshake
05:16 – Subscription renewal
06:26 – Reliability and safety nets
08:08 – Real-world use cases
09:26 – Choosing the delivery channel

Key takeaways

Microsoft Graph change notifications push events to your app through subscriptions, replacing wasteful polling that risks throttling.
Every subscription needs a validation handshake within 10 seconds and must be renewed before its resource-specific expiration.
Acknowledge notifications fast, use delta queries as a safety net, and choose webhooks, Event Hubs or Event Grid based on volume.

Worth quoting

“Change, notifications, let your app react instantly to events in Microsoft 365 without constant checking.” – Mirko Peters (01:08)

“It's a security check. It proves your endpoint is alive, listening, and under your control. It stops someone from pointing a subscription at a URL they don't own, hoping to intercept notifications meant for someone else.” – Mirko Peters (04:52)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Graph change notifications
Change notifications and webhooks – the push model that replaces polling, from subscription and validation to renewal
Microsoft Graph – the API that stores subscriptions and posts notifications to your HTTPS endpoint
SharePoint – an example resource, with file subscriptions lasting about 30 days and invoice processing
Related episode: Microsoft Graph Webhooks - Simply Explained

Microsoft Cloud for Sustainability - Simply Explained

Fri, 24 Jul 2026 10:00:04 +0000

Asked to report your company's carbon footprint but buried in utility bills, spreadsheets and supplier data? This episode explains to business leaders and ESG teams how Microsoft Cloud for Sustainability collects that data, calculates emissions with built-in factors and produces reports for frameworks like CSRD.

In this episode

00:00 – Intro: why most companies can't state their carbon footprint
01:03 – The messy reality of sustainability data
02:35 – What Microsoft Cloud for Sustainability actually is
04:15 – Building block one: getting the data in
06:45 – Building block two: calculating your real impact
08:15 – Reporting frameworks, data trail and Copilot
10:05 – Companies using it today
11:52 – The bottom line

Key takeaways

Most companies cannot state their carbon footprint because sustainability data is scattered across systems, formats and units.
Microsoft Cloud for Sustainability brings data in via Excel templates, Power Query, partner connectors or manual requests and applies built-in emissions factors across scopes 1, 2 and 3.
Ready-made templates for frameworks such as CSRD, an auditable data trail and AI-drafted disclosures turn months of manual reporting into a far faster process.

Worth quoting

“Right now, most companies cannot tell you their carbon footprint. Not because they don't want to or don't care, but because the data is a complete mess.” – Mirko Peters (00:16)

“The platform has three main jobs, record your emissions, report on them accurately, and reduce your impact over time. Record, report, reduce. That's the cycle.” – Mirko Peters (03:15)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on sustainability reporting
Power Query – the import option that pulls data from other systems on a schedule via over 40 connectors
Power Platform – one of the two foundations Microsoft Cloud for Sustainability is built on
Dynamics 365 – together with Power Platform, the foundation Microsoft Cloud for Sustainability is built on
Microsoft Excel – where scattered utility and supplier data often sits, and the format of the simplest import templates
Related episode: Power Query - Simply Explained

Microsoft Partner Center - Simply Explained

Fri, 24 Jul 2026 09:00:45 +0000

Many partners think Partner Center is only a portal for big resellers and leave benefits, credits and incentives unused. This episode explains Microsoft Partner Center for consultants, managed service providers and software companies: who it is for, what the Launch, Core and Expanded tiers include, how to set it up safely and which upcoming API and MFA changes to prepare for.

In this episode

00:00 – Why Partner Center matters
00:44 – What Partner Center actually is
02:09 – The old way versus the new way
03:39 – Who Partner Center is for
05:28 – The FY26 benefit tiers and what you get
09:25 – How to get started
11:28 – Common pitfalls and how to avoid them
13:49 – The future of Partner Center

Key takeaways

Microsoft Partner Center is the single hub where any Microsoft partner, from a one-person consultancy to a large reseller, manages benefits, incentives, customers and certifications.
The FY26 benefits refresh groups partners into Launch, Core and Expanded tiers, with internal-use licenses, Azure credits, security tools and, through designations, Microsoft 365 Copilot licenses.
Avoid common pitfalls by setting up under your primary Entra ID tenant, using role-based access and a break-glass account, checking earnings reports and making API automation MFA-ready.

Worth quoting

“Partner Center isn't just a reseller portal. It's the central hub for your entire Microsoft partnership.” – Mirko Peters (15:49)

“Use the role-based access control to give each person exactly what they need and nothing more. That prevents security headaches down the road.” – Mirko Peters (10:33)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on Partner Center
Microsoft 365 Copilot – internal-use Microsoft 365 Copilot licenses come with the Expanded tier and specific designations
Microsoft Entra ID – set up Partner Center under your primary Entra ID tenant and keep a break-glass account
Multifactor authentication (MFA) – by April 2026 every app plus user Partner Center API call needs an MFA token
Related episode: ENTRA PIM EXPLAINED: Securing Privileged Access with Mark Orr [MVP]

Agent Governance Explained- How IT Can Enable the AI Agent Revolution with Thomas Zou [Microsoft]

Thu, 23 Jul 2026 13:00:13 +0000

As organizations create hundreds or thousands of AI agents, IT faces the question of who owns, secures and governs them. In this interview, Thomas Zou from the Microsoft Copilot Studio team explains for IT leaders and admins how zoned governance, lifecycle management, Entra and Purview help scale agents safely without slowing innovation.

In this episode

00:00 – Intro and Thomas Zou's journey
05:06 – What is agent governance?
07:46 – Where governance begins and readiness
12:09 – Zone governance: innovation vs. control
16:15 – Copilot Studio controls and agent ownership
21:37 – Lifecycle management and monitoring
30:16 – Entra, Purview and securing sensitive data
41:27 – Compliance, adoption and what's next

Key takeaways

Agent governance should enable makers to innovate safely rather than block them, with IT acting as an enabling function.
Zoned governance with Power Platform environments, Agent 365, Entra and Purview lets organizations match controls to each agent's risk.
Successful agent adoption combines an AI center of excellence, executive sponsorship, champions and automated, self-service guidance.

Worth quoting

“It's no longer a realistic expectation for IT to be the gatekeeper to manually approve or deny everything. They cannot have one-on-one meetings with every innovator every day to walk them through the best practices.” – Thomas Zou (26:34)

“The one big best practice is never allow sensitive data to be accessed through agent that is unauthenticated, right? If you want to make sure that you expose sensitive data to specific people, then authentication needs to come in place with a lot of scrutiny.” – Thomas Zou (38:10)

Explore more on M365.FM

Episode page: the full interview with chapters, quotes and FAQ on governing AI agents
Thomas Zou – product marketing manager for Copilot Studio governance who explains how IT can scale agents safely
AI governance – framed here as enabling makers to innovate safely rather than policing or blocking them
AI agent – the growing number of agents that IT has to own, secure and monitor
Related episode: The Copilot Credit Trap- Why Your AI Economy is Already Broken

Microsoft AppSource - Simply Explained

Thu, 23 Jul 2026 12:00:03 +0000

Finding the right business solution for your Microsoft stack used to mean googling vendors and chasing trials. This episode explains Microsoft AppSource for IT pros, business owners, consultants and ISVs: what you can find there, how it plugs into Dynamics 365, Power Platform, Azure and Microsoft 365, and how trials, transactable offers and co-sell work.

In this episode

00:00 – What AppSource actually is
02:04 – The three kinds of offerings
03:40 – How it connects to Dynamics 365
04:55 – Power Platform and Azure
06:24 – Microsoft 365 and Teams
07:41 – Marketplace mechanics: trial, buy, co-sell
09:44 – Common myths and mistakes
11:21 – The big picture and next steps

Key takeaways

Microsoft AppSource is a marketplace for business solutions, offering apps and extensions, consulting services, and templates and data services that work with Microsoft products.
It connects Dynamics 365, Power Platform, Azure and Microsoft 365 in one search, and since September 2025 it is unified with Azure Marketplace as Microsoft Marketplace.
Free trials, transactable offers on existing Microsoft billing, private offers and co-sell make it a low-risk buying channel for customers and a go-to-market channel for partners and ISVs.

Worth quoting

“AppSource is Microsoft's online marketplace for business solutions. Think of it like a mall. But instead of selling clothes or electronics, every store sells software, services, and templates that work with Microsoft products.” – Mirko Peters (00:59)

“Then there's co-sell. This is probably the most powerful feature that most people don't know about. If an offering is co-sell eligible, Microsoft's own sales team can recommend it to their customers.” – Mirko Peters (08:49)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on AppSource
Microsoft AppSource – the episode's subject, a marketplace for business apps, consulting services and templates
Dynamics 365 – the biggest AppSource connection, with extensions like address verification and lead enrichment
Microsoft Marketplace – the unified platform formed in September 2025 from AppSource and Azure Marketplace
Related episode: Power Platform Copilot Integration - Simply Explained

Agent Feed - Simply Explained

Thu, 23 Jul 2026 11:00:03 +0000

Welcome to another episode of Knowledge Nuggets with Mirko Peters. Today we're exploring Agent Feed, Microsoft's new supervision experience for https://www.m365.fm/ai-agents-simply-explained/ inside https://www.m365.fm/power-apps-simply-explained/. As AI agents become capable of processing emails, reviewing documents, creating records, and automating entire business processes, a new challenge emerges. How do you actually supervise them? If an AI agent processes hundreds of insurance claims, procurement requests, or customer service cases every day, how do you know it made the right decisions? More importantly, what happens when the agent encounters something it doesn't understand? Blind automation may increase speed, but without oversight it also increases risk. Microsoft created Agent Feed to solve exactly this problem. Instead of hiding AI agents behind the scenes, Agent Feed brings their work directly into the business applications people already use every day. It allows business users—not just IT administrators—to monitor agents, review their actions, and step in whenever human judgment is required. In https://www.m365.fm/agent-feed-simply-explained/, we'll explain how Agent Feed works, how it connects to Power Apps and https://www.m365.fm/categories/copilot-talk/ Studio, and why human supervision remains one of the most important parts of enterprise AI.

WHY AI AGENTS NEED SUPERVISION
An AI agent is very different from a chatbot. A chatbot waits for instructions, answers questions, and ends the conversation. An AI agent receives a goal and begins working independently. It can read emails, create records, update databases, process documents, and complete entire business workflows without requiring constant user interaction. That autonomy is incredibly powerful. However, real business processes are rarely perfect. Documents arrive with missing information. Policies contain exceptions. Customers provide incomplete details. Regulations sometimes conflict with business rules. An agent cannot simply guess. Without supervision, it may create incorrect records, approve requests that should be rejected, or become stuck without anyone realizing there's a problem. Traditionally, IT departments were expected to monitor these systems, but IT teams rarely possess the business expertise necessary to make policy decisions or resolve complex exceptions. Microsoft's solution is straightforward: allow business users—the people who understand the process best—to supervise AI agents directly inside the applications where they already work.

WHAT IS AGENT FEED?
Agent Feed is Microsoft's supervision hub for AI agents running inside model-driven Power Apps. Instead of opening a separate administration portal or AI dashboard, business users see agent activity directly alongside the applications they already use throughout the day. The interface typically contains three important areas. One section displays the AI agents currently working within the application. Another presents tasks generated by those agents, while an insights panel provides visibility into completed work, pending reviews, and overall agent activity. The most important concept is that users don't need to search for agents. The agents bring work directly to them. Whenever an AI agent completes a task, encounters an exception, or requires a business decision, the activity automatically appears inside Agent Feed. This transforms Power Apps into much more than a business application. It becomes the central command center where humans and AI agents collaborate throughout the workday.

THE THREE SUPERVISION TOOLS
Agent Feed provides three primary supervision patterns that balance automation with human oversight. The first is Log for Review. This is the most passive supervision model. The agent completes its work independently and simply records what happened for later inspection. Users can review the activity whenever convenient without interrupting the automated workflow. The second is Request Assistance. Here the agent recognizes that it has encountered a situation beyond its capabilities. Instead of guessing, it pauses execution and creates a task requesting human input. The workflow resumes only after the user provides guidance, ensuring complex business decisions always remain under human control. The third tool is Invoke Data Entry. Rather than automatically creating business records, the agent extracts information from emails, documents, or attachments, pre-populates fields inside Dataverse, and presents the proposed values for approval. Users simply review the suggestions, make corrections if necessary, and approve the final record before it becomes official. Together, these three approaches provide varying levels of supervision depending on the sensitivity of the business process.

HOW THE POWER APPS MCP SERVER MAKES IT WORK
Behind Agent Feed sits the Power Apps MCP Server, where MCP stands for Model Context Protocol. Rather than requiring every AI agent to implement custom integrations with every application, MCP provides a standardized communication protocol that allows agents and business applications to work together consistently. You can think of MCP as a universal adapter. Agents send standardized requests through the protocol, while the Power Apps MCP Server handles communication with Dataverse and the model-driven application. This standardization dramatically reduces integration complexity while allowing developers to build agents that work consistently across different business systems. Instead of creating custom connectors for every new application, agents simply communicate through MCP using a shared language understood throughout Microsoft's AI ecosystem.

A REAL-WORLD INSURANCE CLAIMS EXAMPLE
One of the clearest demonstrations of Agent Feed involves insurance claims processing. Imagine a Claim Intake Agent monitoring a shared mailbox. Whenever a customer submits a new insurance claim, the agent reads the email, extracts customer details, identifies policy numbers, determines the reported incident, and prepares a new Dataverse record. Rather than immediately creating the claim, the agent uses Invoke Data Entry to present its suggested values inside Agent Feed. The claims adjuster compares the extracted information with the original email and simply approves the proposed record if everything looks correct. Next, a Coverage Determination Agent analyzes the customer's insurance policy. Most claims can be processed automatically. However, suppose water entered a customer's basement, and the available information doesn't clearly indicate whether the source was groundwater or a broken window. The policy treats those situations differently. Recognizing the ambiguity, the agent doesn't make an assumption. Instead, it creates a Request Assistance task asking the adjuster to investigate. Once the human decision has been made, the agent immediately continues processing the claim and finally records its completed work using Log for Review. Throughout the entire process, automation handled repetitive work while human expertise remained responsible for policy interpretation and judgment.

WHY HUMAN-IN-THE-LOOP MATTERS
Microsoft designed Agent Feed around an important principle known as human-in-the-loop AI. The goal isn't to replace people. The goal is to allow AI agents to perform repetitive, predictable work while humans focus exclusively on situations requiring experience, judgment, empathy, or business expertise. Agents process documents faster than people. They can review thousands of records, classify emails, and perform routine validation almost instantly. Humans, however, remain responsible for interpreting ambiguous situations, making exceptions, approving sensitive decisions, and ensuring organizational policies are followed correctly. Agent Feed creates a practical collaboration model where automation handles volume while people maintain responsibility for business outcomes. Instead of competing with each other, humans and AI become complementary members of the same operational workflow.

HOW AGENT FEED FITS INTO THE MICROSOFT AI ECOSYSTEM
Agent Feed represents only one component of Microsoft's broader vision for enterprise AI. Agents themselves are typically created using Microsoft Copilot Studio, where organizations build AI-powered business assistants using low-code or code-first approaches. https://www.m365.fm/power-automate-simply-explained/ enables those agents to trigger workflows across hundreds of connected business systems, while Dataverse stores the business information agents read and update throughout their work. Microsoft has also announced broader governance capabilities that will eventually provide centralized administration, policy management, monitoring, and activity tracking for enterprise AI agents across entire organizations. Within this ecosystem, Agent Feed serves as the daily operational interface where business users collaborate with the AI agents supporting their work. Rather than introducing yet another application, Microsoft embeds AI supervision directly into Power Apps, allowing organizations to adopt intelligent automation without disrupting existing business workflows.

WHY THIS MATTERS FOR BUSINESS USERS
One of the most important aspects of Agent Feed is that it isn't designed primarily for developers. It's designed for business experts. Claims adjusters understand insurance policies. Procurement managers understand purchasing rules. HR professionals understand employment policies. Customer service teams understand their customers. These are the people best positioned to supervise AI agents. Instead of spend

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Microsoft Agent Framework - Simply Explained

Thu, 23 Jul 2026 10:00:02 +0000

AI agents are everywhere in headlines, yet few people can explain what they are or which framework to build them with. This episode is for developers, IT leaders and business decision makers exploring agents in Microsoft environments. You learn what Microsoft Agent Framework is, how its building blocks work and where it fits next to Foundry, Copilot Studio and Microsoft 365 Copilot.

In this episode

00:00 – Why agents are more than chatbots
02:46 – Before the framework: a fragmented landscape
04:25 – What Microsoft Agent Framework is
06:22 – Building blocks: agents, tools, memory, workflows
08:40 – Practical value for business and IT
10:37 – How it fits with Foundry, Copilot Studio and Copilot
12:42 – Getting started

Key takeaways

An AI agent combines reasoning, tools and memory so it can plan and act toward a goal instead of only answering questions like a chatbot.
Microsoft Agent Framework unifies Semantic Kernel and AutoGen into one open-source SDK for Python and .NET with agents, workflows, MCP tools, memory and human-in-the-loop approvals.
Developers build with the framework and deploy to Foundry, while Copilot Studio offers a low-code path, and both let organizations replace shadow AI with governed agents in Teams and Copilot.

Worth quoting

“So think about the difference, a chatbot is reactive, it waits for your next question. An agent is proactive, you give it a goal and it goes off and works on it.” – Mirko Peters (01:47)

“What makes something an agent is the combination of three things. Reasoning, the ability to think through a problem. Tools, the ability to act on the world. And memory, the ability to remember what happened before” – Mirko Peters (02:31)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on agents
AI agent – defined here as reasoning, tools and memory working toward a goal, unlike a chatbot
Copilot Studio – the low-code path for non-developers, complementing the framework's code-first approach
Microsoft Foundry – where agents built with the framework are deployed, run and monitored in production
Related episode: Microsoft Foundry Agent Service - Simply Explained

Microsoft Fabric Real-Time Intelligence - Simply Explained

Thu, 23 Jul 2026 09:00:35 +0000

Many teams confuse real-time intelligence with faster Power BI refreshes and either overbuild or miss critical signals. This episode explains for data and analytics professionals what Microsoft Fabric Real-Time Intelligence really is, how its four building blocks work, and when streaming is actually worth it.

In this episode

00:00 – Real-time is not just faster dashboards
00:50 – The shift from batch to streaming
03:01 – What is Real-Time Intelligence?
04:57 – Eventstreams: getting data in
07:40 – Eventhouse: storing and querying
10:01 – Real-time dashboards
11:58 – Activator: action without code
14:22 – When you need it and how it connects

Key takeaways

Real-time intelligence is about shortening the time between signal and action, not about refreshing reports faster.
Its four building blocks are eventstreams for ingestion, Eventhouse for storage and KQL queries, real-time dashboards for live views and Activator for automated action.
Use real-time only when action must happen within seconds and combine it with OneLake and batch analytics for historical, cost-efficient analysis.

Worth quoting

“The difference between fast and real-time is about the relationship between data and action, not speed.” – Mirko Peters (02:07)

“Instead of data flowing into a database and waiting for someone to ask a question, data flows into a system that's already listening, watching and ready to respond.” – Mirko Peters (02:49)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on Real-Time Intelligence
Microsoft Fabric – the platform that hosts Real-Time Intelligence alongside OneLake, shared security and Power BI
Fabric Data Activator – the building block that watches streaming data and triggers alerts, flows or pipelines without code
Kusto Query Language (KQL) – the query language of Eventhouse, also used to build real-time dashboard tiles
Related episode: Your Machine Data Never Becomes a Decision. Here's the Missing Pipeline.

Microsoft Fabric Data Warehouse - Simply Explained

Thu, 23 Jul 2026 08:00:03 +0000

Many people treat Microsoft Fabric's data warehouse as just another SQL database and miss what makes it different. This episode explains for beginners and data professionals how Fabric Warehouse works on OneLake, which features like time travel, cloning and Direct Lake it unlocks, and when to choose it over a lakehouse or Eventhouse.

In this episode

00:00 – Why Fabric Warehouse is not just SQL
00:47 – What is a data warehouse? The old way
02:23 – How Fabric Warehouse works under the hood
04:09 – Building blocks and loading data
07:49 – Querying with T-SQL and cross-database queries
09:31 – Time travel and table cloning
11:54 – Performance: GPU acceleration and Direct Lake
13:45 – Warehouse vs. lakehouse vs. Eventhouse

Key takeaways

Fabric Warehouse feels like SQL Server but stores every table as Delta Parquet in OneLake, separating compute from shared storage.
Delta storage enables cross-database queries, 30-day time travel and zero-copy table cloning out of the box.
Use the lakehouse for raw exploration, the warehouse for clean, structured reporting data with full DML, and Eventhouse for time-based streams.

Worth quoting

“Traditional databases are islands, but fabric warehouse is a room in a connected building. The walls are still there.” – Mirko Peters (03:56)

“With time travel, you just adjust your query. See the data as it was, copy it back and keep moving. No backup restore needed.” – Mirko Peters (10:21)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a beginner FAQ on Fabric Warehouse
Microsoft Fabric – the unified analytics platform whose warehouse stores every table as Delta files in OneLake
Power BI – reads warehouse data through Direct Lake mode, without imports or live queries
Fabric workspace – where GPU acceleration is switched on and the SQL endpoint lists all databases
Fabric notebooks – Spark notebooks load and process the same Delta tables the warehouse queries with T-SQL
Related episode: Microsoft Fabric End-to-End: From Raw Data to Business Decisions with Amit Chandak [MVP]

Microsoft Fabric Data Factory - Simply Explained

Thu, 23 Jul 2026 00:00:03 +0000

Is Fabric Data Factory just Azure Data Factory with a new name? This episode explains the four building blocks - pipelines, Dataflow Gen2, copy jobs and mirroring - and how they work together through OneLake. Data engineers and analysts get a clear rule of thumb for when switching from ADF pays off.

In this episode

00:00 – What Fabric Data Factory is
01:22 – How it differs from Azure Data Factory
03:05 – Data pipelines
04:56 – Dataflow Gen2
06:57 – Copy jobs
08:41 – Mirroring
10:18 – How the pieces work together
11:49 – Practical guidance and cost

Key takeaways

Fabric Data Factory is the built-in data integration engine of Microsoft Fabric, with capacity-based pricing and OneLake as automatic storage instead of linked services and storage accounts.
Pipelines orchestrate, Dataflow Gen2 transforms with Power Query, copy jobs handle continuous incremental ingestion and mirroring replicates operational databases in near real time.
If your ADF bill is low and you are not on Fabric, staying with ADF can make sense; if you already have Fabric capacity, pipelines cost very little extra.

Worth quoting

“ADF charges per activity run, so every copy activity stored procedure and pipeline execution adds to your bill. Fabric Data Factory uses capacity-based pricing instead.” – Mirko Peters (01:32)

“If pipelines are the assembly line that moves boxes around, data flow, Gen 2 is the kitchen where you actually chop, season, and cook the raw ingredients.” – Mirko Peters (05:20)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on Fabric Data Factory
Microsoft Fabric – the platform Data Factory is built into, sharing one capacity and OneLake with other workloads
Power Query – the familiar interface and engine behind the transformations in Dataflow Gen2
Fabric notebooks – called from pipelines to enrich data and used with Spark for very heavy transformations
Related episode: Microsoft Fabric End-to-End: From Raw Data to Business Decisions with Amit Chandak [MVP]

Microsoft Fabric - Simply Explained

Wed, 22 Jul 2026 23:00:02 +0000

Everyone talks about Microsoft Fabric, but few can explain what it actually is. This episode walks business and IT folks through OneLake, lakehouses, warehouses, data integration, real-time intelligence and Power BI in plain English. You will understand how the pieces fit together and why one copy of data changes everything.

In this episode

00:00 – What is Microsoft Fabric?
00:33 – Why data was broken
01:40 – What Fabric actually is
02:45 – OneLake and shortcuts
04:26 – Lakehouses and warehouses
07:41 – Getting data in
09:35 – Real-time intelligence and AI
11:21 – Power BI, governance and value

Key takeaways

Microsoft Fabric is a unified SaaS data and analytics platform that brings data engineering, integration, warehousing, real-time analytics and BI together under one login.
OneLake is the single data lake per tenant in open Delta Parquet format, and shortcuts let you reference external data without copying it.
Power BI in Fabric reads OneLake data directly via Direct Lake, while Purview sensitivity labels, DLP and domains provide governance from the start.

Worth quoting

“More time was spent moving data between systems, than actually analyzing it. Data integration became a full-time job for entire teams.” – Mirko Peters (01:13)

“The easiest way to think about one lake is like one drive for your data.” – Mirko Peters (02:52)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Fabric's building blocks
Microsoft Fabric – the unified SaaS data platform this episode explains piece by piece
Power BI – Fabric's reporting front door, reading OneLake data directly through Direct Lake mode
Semantic model – sits beneath every Power BI report and can now be built in a web browser
Fabric notebooks – how lakehouses let data engineers run Spark and Python code cell by cell
Power Query – powers the no-code data transformations in Dataflow Gen2 inside Data Factory
Related episode: Copilot for Microsoft Fabric - Simply Explained

Microsoft Defender for Identity - Simply Explained

Wed, 22 Jul 2026 22:00:03 +0000

Attackers no longer break in - they log in with stolen credentials, and traditional security tools never notice. This episode explains how Microsoft Defender for Identity watches your on-premises Active Directory with sensors and behavioral analytics. Security and IT admins learn which attacks it catches and how honeytokens and Defender XDR make it even stronger.

In this episode

00:00 – Stolen passwords, not broken firewalls
00:35 – The identity security problem
02:14 – What Defender for Identity is
04:01 – Sensors and behavioral analytics
06:37 – The attack lifecycle it catches
08:22 – Alerts, incidents and actions
10:53 – Honeytokens, tagging and exclusions
12:44 – Place in the Defender XDR ecosystem

Key takeaways

Defender for Identity detects identity-based attacks on on-premises Active Directory by learning normal user behavior and flagging deviations rather than scanning for malware.
Lightweight sensors on domain controllers feed a cloud service that detects reconnaissance, pass-the-hash, Kerberoasting, golden tickets, DCSync and lateral movement mapped to MITRE ATT&CK.
Combined with Defender for Endpoint, Defender for Office 365, Sentinel and Entra ID Protection inside Defender XDR, its alerts become complete attack stories.

Worth quoting

“Attackers don't break in, they just log in, they scoop up a legitimate password through phishing, a data breach, or a simple guess, and then stroll right through the front door.” – Mirko Peters (00:59)

“Microsoft Defender for Identity is a cloud-based security tool that watches your on-premises active directory for identity-based attacks.” – Mirko Peters (02:17)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on identity threat detection
Microsoft Defender for Identity – the episode's subject, combining domain controller sensors with behavioral analytics in the cloud
Active Directory – the on-premises directory that Defender for Identity monitors for identity-based attacks
Microsoft Defender – Defender XDR correlates Defender for Identity alerts with endpoint and email signals into incidents
Related episode: Microsoft Entra Connect - Simply Explained

Microsoft Defender for Office 365 - Simply Explained

Wed, 22 Jul 2026 21:00:02 +0000

Modern phishing emails copy real branding and writing styles, so a basic spam filter no longer keeps a business safe. This episode is for Microsoft 365 admins, security teams and business owners. You learn how the five protection layers of Microsoft Defender for Office 365 work together to stop malware, phishing, malicious links and spoofed senders.

In this episode

00:00 – Why email is still the number one threat
01:16 – What Defender for Office 365 is and anti-spam
03:02 – Anti-malware and Safe Attachments
04:42 – Anti-phishing and impersonation protection
06:22 – Safe Links and time-of-click protection
08:12 – Anti-spoofing with SPF, DKIM and DMARC
09:47 – How the five layers work together
11:05 – Common myths and misconceptions

Key takeaways

Microsoft Defender for Office 365 is not just antivirus for email but a cloud service with five layers: anti-spam, anti-malware with Safe Attachments, anti-phishing, Safe Links and anti-spoofing.
Safe Attachments opens files in a sandbox to judge behavior, and Safe Links rewrites URLs and checks them at the moment of the click, across email, Teams and Office documents.
Authentication checks such as SPF, DKIM and DMARC plus impersonation protection stop spoofed and look-alike senders, so check whether your Microsoft 365 plan already includes Defender.

Worth quoting

“Safe attachments watch its behavior, not just signatures. It doesn't matter if the malware is brand new. If it acts suspicious Defender catches it” – Mirko Peters (03:56)

“The attacker doesn't need to break into your system. They just need you to hand over the keys.” – Mirko Peters (04:48)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Defender for Office 365
Microsoft 365 – the platform Defender for Office 365 runs inside, with many features already in standard plans
Microsoft Teams – one of the places where Safe Links checks URLs at the moment of the click
Exchange Online – named in the myths section as one of the services Defender integrates with deeply
Related episode: Microsoft Fabric for Microsoft 365 Admins: What You Need to Know

Microsoft Defender for Endpoint - Simply Explained

Wed, 22 Jul 2026 20:00:02 +0000

Traditional antivirus can no longer keep up with ransomware, phishing and attackers who move quietly between devices. This plain-English episode is for IT admins and business owners who want to understand Microsoft Defender for Endpoint, from EDR and attack disruption to licensing and the first steps to turn it on.

In this episode

00:00 – Why antivirus is no longer enough
00:37 – What endpoint security means
02:30 – Defender for Endpoint: prevention, detection, response
04:56 – Endpoint detection and response (EDR)
06:34 – Vulnerability management and threat analytics
07:52 – Automated investigation and attack disruption
10:09 – How it fits into Microsoft Defender XDR
11:49 – How to get started

Key takeaways

Signature-based antivirus only catches known threats, so modern endpoint security has to watch behavior across every device, not just scan files.
Microsoft Defender for Endpoint combines next-generation protection, EDR, vulnerability management and automated investigation, and Plan 2 is already included in Microsoft 365 E5.
Integrated with Defender XDR, Intune and Sentinel, it correlates alerts into single incidents, but small teams still need people or an MDR service to watch and respond.

Worth quoting

“Signature-based detection only catches what's already been seen. Modern attacks are adaptive, targeted, and often use brand new or custom malware.” – Mirko Peters (01:48)

“Prevention is the lock on your front door. And EDR is the motion sensor in your hallway that alerts you when someone's already inside.” – Mirko Peters (05:08)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Defender for Endpoint
Microsoft Defender – the Defender XDR platform that correlates endpoint, identity and email alerts into one incident
Microsoft Intune – connected to Defender in the setup steps so security policies are enforced through device management
Microsoft Defender for Identity – appears in the XDR example, watching for credential theft after a phishing click
Related episode: Licensing, Security & Management: Making Microsoft 365 Defender and Intune Work Together with Videsh Chavan

Exchange Online Protection (EOP) - Simply Explained

Wed, 22 Jul 2026 19:00:02 +0000

Every Microsoft 365 tenant already has email protection, but few admins know where it stops. This episode breaks down Exchange Online Protection's three filtering layers, the zero-hour auto purge safety net and the gaps attackers exploit. Small and mid-sized businesses learn when EOP is enough and when Defender for Office 365 is worth the upgrade.

In this episode

00:00 – Why the inbox matters
00:40 – What EOP is
01:32 – Layer one: anti-spam
02:59 – Layer two: anti-malware
04:41 – Layer three: anti-phishing
06:56 – Zero-hour auto purge
09:18 – Limits and Defender for Office 365
14:27 – How it all fits together

Key takeaways

Exchange Online Protection is included in every Microsoft 365 plan and filters spam, known malware and basic phishing through connection filtering, content filtering, signatures and authentication checks.
Zero-hour auto purge retroactively removes messages whose verdict changes after delivery, now also in Teams chats and the Deleted Items folder.
EOP has no sandboxing, click-time link scanning or impersonation protection, so organizations with visible executives should add Defender for Office 365 and publish a strict DMARC record.

Worth quoting

“EOP is always on, even if you never touch a single setting. You could buy a Microsoft 365 license, never open the admin center. And EOP would still be filtering your email” – Mirko Peters (01:14)

“EOP does not sandbox unknown files. They can only catch threats that have already been identified.” – Mirko Peters (03:34)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on EOP's filtering layers
Exchange Online – the mailbox service EOP protects, with ZAP enabled by default for every mailbox
Microsoft 365 – every plan includes Exchange Online Protection at no extra cost
Microsoft Teams – Teams chat messages are now also covered by zero-hour auto purge
Related episode: Microsoft Purview eDiscovery — Simply Explained

OneDrive Sync — Simply Explained

Wed, 22 Jul 2026 18:00:02 +0000

Most people think OneDrive is just a cloud folder - until files vanish or sync gets stuck with a red X. This episode explains in plain English how the sync engine, Files On-Demand and selective sync really work and why sync breaks. Everyday Microsoft 365 users learn simple habits to keep sync healthy and see how Copilot is turning OneDrive into a smart assistant.

In this episode

00:00 – Sync is not upload
00:59 – The two-way mirror
02:23 – Files On-Demand
04:06 – How the sync engine works
06:09 – Why sync breaks
08:20 – Selective sync vs. Files On-Demand
10:24 – Moving OneDrive and Copilot
13:51 – Tips for a healthy sync

Key takeaways

OneDrive sync is a continuous two-way mirror between devices and the cloud, backed by version history, not a one-time upload.
Files On-Demand keeps all files visible as online-only placeholders, while selective sync decides which folders appear on a device at all.
Most sync problems come from long paths, full storage, locked files or unsupported characters, and pausing and resuming sync fixes many temporary glitches.

Worth quoting

“Think of it as a two-way mirror, a live connection between your device and Microsoft servers, where any change on one side automatically shows up on the other” – Mirko Peters (00:21)

“If you delete an online only file from your device, it deletes it from OneDrive everywhere. It's gone from the cloud, too.” – Mirko Peters (03:37)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes, FAQ and eight habits for healthy sync
OneDrive – the service whose sync engine, Files On-Demand and selective sync this episode explains
Microsoft 365 Copilot – turns OneDrive into an assistant that summarizes, compares and answers questions about files
Microsoft Word – used as the example of a file you double-click, which is locked while open
Microsoft Excel – an open Excel file is locked by the app, so OneDrive cannot sync it
Related episode: Data Loss Prevention in Microsoft 365: Policies That Actually Work

What Is SharePoint Premium - Simply Explained

Wed, 22 Jul 2026 17:00:02 +0000

Your Microsoft 365 tenant is full of untagged, overshared files, and Copilot will happily surface that mess. This episode explains in plain English what SharePoint Premium adds to regular SharePoint for admins and IT decision makers. You learn its three pillars, how it prepares content for Copilot, what it costs and where to start.

In this episode

00:00 – Intro: two billion messy documents
00:27 – The problem SharePoint Premium solves
01:56 – Pillar 1: Content experiences
03:25 – Pillar 2: Content processing
05:00 – Pillar 3: Content governance
08:29 – Why Copilot demands SharePoint Premium
10:16 – Licensing, costs and what's free
11:54 – Your first steps

Key takeaways

SharePoint Premium is an AI add-on on top of SharePoint Online that adds content experiences, content processing and content governance rather than replacing anything.
Copilot is only as good as your content, so clean metadata, classified documents and governed access are the foundation for useful AI answers.
Start small with one high-volume document type such as invoices on one site, use pay-as-you-go with a budget, and run a data access governance report to find oversharing.

Worth quoting

“Co-pilot is not a cleanup crew. It's an amplifier. If your content is organized and governed, co-pilot makes you faster and smarter. If your content is a disaster, co-pilot just surfaces that disaster more efficiently.” – Mirko Peters (09:46)

“Why is governance so important here? Because AI automation can multiply your mistakes. If you're processing thousands of files automatically and your permissions are a mess, you're just speeding up the spread of bad access.” – Mirko Peters (06:23)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes, FAQ and first steps for admins
SharePoint Premium – the AI add-on this episode breaks down into three pillars, costs and first steps
Microsoft 365 Copilot – needs the clean metadata and governed access that SharePoint Premium provides to give useful answers
SharePoint – the existing SharePoint Online base that Premium sits on top of rather than replacing
Related episode: Copilot Inherits Your Mess: Modernizing Microsoft 365 for AI with Richard Harbridge [MVP]

Microsoft Viva Learning - Simply Explained

Wed, 22 Jul 2026 16:00:02 +0000

Training is scattered across SharePoint folders, old portals and email links, so employees never find it and managers cannot track it. This episode explains Viva Learning for HR, L&D and Microsoft 365 admins. You learn where its content comes from, how managers assign courses and five steps to switch it on today.

In this episode

00:00 – Intro: where does training live?
00:37 – The learning problem
01:52 – What Viva Learning actually is
03:52 – Content source 1: Microsoft's own library
05:09 – Content source 2: LinkedIn Learning
06:34 – Content source 3: Your own SharePoint content
08:10 – Manager view: assignments and tracking
11:29 – Your next steps

Key takeaways

Viva Learning is a learning hub inside Microsoft Teams that is included in most Microsoft 365 E3, E5 and Business Premium plans and only needs to be turned on.
It combines Microsoft's own library, LinkedIn Learning and your own SharePoint training content into one catalog, with up to 1,000 SharePoint files without extra licensing.
Managers can assign and track courses directly in Teams, which removes friction and drives much higher completion rates.

Worth quoting

“This fragmentation is the real reason learning programs fail. Not the quality of the courses, not the relevance of the topics, but the sheer friction of getting to them.” – Mirko Peters (01:32)

“The key insight is simple. When learning is easy to find and easy to assign, completion rates go up. Not because the content is better, but because the system stops getting in the way.” – Mirko Peters (09:25)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes, FAQ and five setup steps
Viva Learning – the learning hub in Teams that this whole episode explains and recommends turning on
Microsoft Teams – the app where Viva Learning lives, so courses sit next to chats and meetings
SharePoint – where internal training files live, with up to 1,000 files usable in Viva Learning
Related episode: Copilot Inherits Your Mess: Modernizing Microsoft 365 for AI with Richard Harbridge [MVP]

Viva Engage - Simply Explained

Wed, 22 Jul 2026 15:00:03 +0000

Many organizations still confuse Viva Engage with Yammer or Microsoft Teams and miss its value for culture and knowledge sharing. This episode helps IT pros, communicators and leaders understand what Engage is, how communities, storylines and campaigns work, and how to start with the licenses they already have.

In this episode

00:00 – Intro: what Viva Engage is and why it matters
00:48 – From Yammer to Viva Engage
02:14 – Viva Engage vs. Microsoft Teams
04:03 – Core features: communities and storylines
07:58 – Campaigns, events and analytics
09:48 – Where Engage fits in the Viva suite
12:21 – The business case for engagement
15:10 – Licensing and getting started

Key takeaways

Viva Engage is the evolution of Yammer into the Microsoft Viva family, adding deeper integration with Teams and other Viva apps such as Viva Connections, Viva Insights and Viva Learning.
Teams is for real-time work in small groups, while Engage is a company-wide, asynchronous space for communities, storylines, campaigns and events.
Basic Engage features come with most Microsoft 365 business plans, while premium features such as advanced analytics, campaigns and leadership corner need an additional Viva license.

Worth quoting

“Teams is a collaboration hub for real-time work. You use it for chat, meetings, file sharing and project management. It's built for small groups doing daily tasks.” – Mirko Peters (02:25)

“They're not competing tools. They complement each other. You use teams to get work done and you use engage to build culture, share knowledge and connect across departments.” – Mirko Peters (03:31)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Viva Engage
Viva Engage – the subject of the episode, from its Yammer roots to communities, storylines and campaigns
Microsoft Viva – the employee experience suite where Engage is the community and conversation app
Microsoft Teams – contrasted with Engage as the hub for real-time work in small groups
Viva Insights – briefly covered as the Viva app that tracks work patterns like meeting overload and focus time
Related episode: Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It

Viva Connections - Simply Explained

Wed, 22 Jul 2026 14:00:02 +0000

Static intranets are a ghost town, and many employees never find the news, tools and policies they need. This episode explains Viva Connections and its 2026 rename to SharePoint for intranet owners, internal communicators and Microsoft 365 admins. You learn its three components, the engagement stats that matter and the first steps to make it work.

In this episode

00:00 – Intro: a renamed employee tool
00:24 – The old intranet problem
01:50 – What Viva Connections is
03:12 – The 2026 rebrand to SharePoint
05:03 – Component 1: The news reader
06:54 – Components 2 and 3: Dashboard and resources
10:41 – The engagement stats that matter
12:45 – Who needs it and first steps

Key takeaways

Viva Connections is an employee experience front door inside Teams, built on a SharePoint home site, with a news reader, a dashboard of cards and curated resources.
In 2026 Microsoft renamed the Viva Connections app in Teams to the SharePoint app, while functionality and admin tools stayed the same and the basic version remains included in Microsoft 365.
Adoption depends on pinning the app globally in Teams, keeping news fresh with multiple posts per week and offering a rich dashboard, especially for mobile and frontline workers.

Worth quoting

“Viva connections is an employee experience app that lives inside Microsoft Teams. And you can think of it as a digital front door. One place where employees go for company news, tools, and resources.” – Mirko Peters (01:54)

“Viva Connections was always powered by SharePoint. The news, the dashboard, the resources, all of it came from a SharePoint home site behind the scenes” – Mirko Peters (03:31)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Viva Connections
SharePoint – the home site behind Viva Connections and, since 2026, the app's new name in Teams
Microsoft Teams – where the app lives, and pinning it globally there drives most weekly usage
Microsoft Viva – the brand customers confused with an extra license, plus the premium Viva Suite version
Related episode: Viva Engage - Simply Explained

Beyond Copilot- How to Make AI Transformation Actually Stick with Femke Cornelissen [MVP]

Wed, 22 Jul 2026 13:00:03 +0000

Many organizations roll out Copilot and agents but see little business value because everyone builds their own way of working. In this conversation, Femke Cornelissen, Chief Transformation Officer at Wortell, shares with leaders and adoption teams how strategy, policy, trust and culture make AI transformation stick. You get practical ideas for agent ownership, experimentation and continuous adoption.

In this episode

00:00 – Intro: transformation starts with people
01:38 – Femke's journey and role
09:56 – Why transformation projects fail
17:18 – Change management and culture
20:39 – Building trust and experimenting
25:30 – The future of work and knowledge work
44:07 – How Femke uses Copilot daily
52:26 – Quickfire round and closing

Key takeaways

AI transformation needs a strategy from the top, an AI team or council and a transformation team, otherwise everyone builds their own isolated solutions without business value.
Trust grows when leaders share where the organization is heading, involve employees in solving problems and give a clear framework for which AI tools and data may be used.
Adoption is a continuous effort: agents need owners and up-to-date data, and champions help colleagues keep up with constant change.

Worth quoting

“So why you don't have business value is because everyone is creating their own way. You don't have any synergy in your organization in your way of working.” – Femke Cornelissen (10:50)

“Today's conversation was a great reminder that successful AI adoption isn't measured by how many licenses are assigned or how many prompts are written. It's measured by how people collaborate, make decisions and create value together.” – Mirko Peters (55:16)

Explore more on M365.FM

Episode page: the full conversation with chapters, quotes and FAQ on AI transformation
Femke Cornelissen – Chief Transformation Officer at Wortell who leads her own company's AI transformation
Copilot adoption – the core theme: strategy, policy, champions and continuous adoption instead of button training
AI agent – agents need owners and current data; her company has about 1,200 agents for 500 people
Related episode: Microsoft 365 Copilot Without the Hype: Adoption, Governance & Getting Your Tenant Ready with Paul Keijzers [MVP]

Microsoft Places - Simply Explained

Wed, 22 Jul 2026 12:00:04 +0000

Hybrid work often means driving to the office only to find your team stayed home. This episode explains Microsoft Places for employees, IT admins and facilities teams: how work plans, desk and room booking, check-in and analytics inside Outlook and Teams take the guesswork out of office days.

In this episode

00:00 – Why hybrid office days go wrong
00:36 – The hybrid work coordination problem
01:35 – What Microsoft Places actually is
02:37 – Setting your work plan
03:38 – Desk booking
05:07 – Room booking with photos and Copilot
06:32 – Check-in and Nearby
07:51 – Analytics, admin and the AI-powered workplace

Key takeaways

Microsoft Places lives inside Outlook and Teams and connects your calendar with the physical office, so people know who is coming in and where to sit.
Work plans, map-based desk booking, room booking with photos, automatic check-in and Nearby turn office days from guesswork into coordination, with presence sharing always opt-in.
Utilization analytics, auto-release policies and a web admin portal help facilities teams, and Places data feeds Copilot and Microsoft Graph for smarter in-office decisions.

Worth quoting

“First, it's not a separate app you install. You don't go to a website, create an account, or learn a new interface. Places lives inside Outlook in Teams, showing up in your calendar and your chat.” – Mirko Peters (01:40)

“The problem isn't the office itself. It's not that offices are bad. It's that you have no information about who's coming in and when.” – Mirko Peters (01:09)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on Places
Microsoft Places – the subject of the episode, covering work plans, desk and room booking, check-in and analytics
Microsoft Teams – one of the two apps Places lives in, showing in-office presence and the Nearby feature
Microsoft 365 Copilot – books rooms on request and suggests office days based on Places data
Microsoft Outlook – hosts Places in the calendar, where work plans and room booking with photos appear
Related episode: Data Loss Prevention in Microsoft 365: Policies That Actually Work

Microsoft Mesh - Simply Explained

Wed, 22 Jul 2026 11:00:03 +0000

Microsoft Mesh is surrounded by metaverse buzzwords, yet few people can explain what it does today. This Simply Explained episode is for Teams users and IT decision makers who want to know how Mesh became immersive spaces in Teams, how avatars and spatial audio work, and when a 3D meeting actually beats a video call.

In this episode

00:00 – What Microsoft Mesh does today
00:54 – What exactly is Microsoft Mesh
02:12 – The big pivot from metaverse to Teams feature
03:50 – How to join an immersive space
06:22 – Spatial audio
08:00 – Avatars
09:14 – Custom environments and real use cases
12:10 – The verdict and what's coming

Key takeaways

Microsoft Mesh is no longer a standalone metaverse platform; it lives on as immersive 3D spaces inside Microsoft Teams meetings.
Avatars and spatial audio create a sense of presence and make side conversations possible, which reduces meeting fatigue.
Immersive spaces are capped at 16 people with no custom worlds, so they fit interactive team meetings, onboarding and training rather than webinars.

Worth quoting

“Mesh is not a virtual world you live in. It's a meeting space you enter for specific sessions. No persistent universe, no digital real estate to buy” – Mirko Peters (01:43)

“Companies didn't want another platform to manage, since they already have Teams and Microsoft 365. They didn't want to learn a whole new tool just for a 3D meeting.” – Mirko Peters (02:48)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on Mesh
Microsoft Mesh – the subject of the episode, from metaverse platform to 3D meetings in Teams
Microsoft Teams – where immersive spaces now live, opened through the View menu of a meeting
Microsoft 365 – named as the existing toolset companies did not want to add another platform to
Mirko Peters – hosts this Knowledge Nuggets episode and explains what Mesh does in Teams today
Related episode: Microsoft Teams Premium - Simply Explained

Microsoft Loop Workspaces - Simply Explained

Wed, 22 Jul 2026 10:00:03 +0000

Welcome to another episode of Knowledge Nuggets with Mirko Peters. Today we're taking a closer look at Microsoft Loop Workspaces, one of the newest collaboration experiences in Microsoft 365 that's changing how teams organize projects and work together. If you've ever found yourself jumping between Microsoft Teams, Outlook, OneNote, SharePoint, Planner, and Microsoft To Do just to keep a single project moving, you're not alone. Modern work is more connected than ever, yet the information we need is often scattered across multiple applications. Notes live in OneNote, conversations happen in Teams, documents are stored in SharePoint, and tasks are managed somewhere else entirely. Every application does its job well, but switching between them interrupts focus and makes collaboration harder than it needs to be. Microsoft Loop Workspaces were created to solve exactly this problem. Instead of treating documents, conversations, and tasks as separate pieces, Loop brings them together into one flexible collaborative workspace where teams can plan, brainstorm, assign work, and make decisions in real time. In this episode we'll explore how Loop Workspaces are structured, how they integrate with the rest of Microsoft 365, and when they're the right tool for your next project.

WHAT IS A MICROSOFT LOOP WORKSPACE?
The easiest way to understand a Loop Workspace is to imagine a dedicated project room inside your office. Every project has its own whiteboards, notes, action lists, meeting minutes, reference documents, and ideas pinned to the walls. Anyone working on that project knows exactly where to go to see the latest information. A Microsoft Loop Workspace brings that same concept into the digital world. It acts as a shared space where everything related to a project lives together. Instead of searching through Teams conversations, Outlook emails, Planner boards, and SharePoint folders, your team opens one workspace and immediately sees the latest notes, tasks, documents, and decisions. Unlike Microsoft Teams, which primarily focuses on conversations, or SharePoint, which concentrates on document management, Loop Workspaces provide a flexible canvas for collaboration. Teams continue chatting, brainstorming, updating tasks, embedding files, and documenting decisions inside the same workspace without constantly changing applications. Every workspace belongs to a specific team or initiative and includes its own members, cover image, pages, and collaborative content, making it easy to separate different projects while keeping everyone aligned.

UNDERSTANDING THE BUILDING BLOCKS OF LOOP
Microsoft Loop is built around three core concepts that work together to organize information naturally. At the highest level sits the Workspace. This represents an entire project, department, or business initiative and acts as the container for everything related to that work. Inside each workspace are Pages. These are where the actual collaboration happens. A page might contain meeting notes, project timelines, brainstorming sessions, documentation, checklists, or planning information. As projects grow, additional subpages can be created to organize more detailed topics without making the main workspace feel cluttered. Perhaps the most innovative feature of Loop is its Components. Components are portable pieces of content that remain synchronized wherever they appear. A task list created inside a Loop page can be copied into a Microsoft Teams chat or an Outlook email while remaining connected to its original source. When someone updates the task list in Teams, those changes automatically appear inside the Loop Workspace. Likewise, edits made in Loop immediately appear wherever that component has been shared. This synchronization removes one of the biggest frustrations in modern collaboration: maintaining multiple versions of the same information across different applications.

CREATING A LOOP WORKSPACE
Getting started with Microsoft Loop is surprisingly straightforward, especially for organizations already using Microsoft Teams. A Loop Workspace can be created directly inside a Teams channel by adding a new Loop tab. Once the workspace receives a name and optional cover image, it immediately becomes available to everyone who already has access to that Teams channel. There is no need to manually invite every team member or configure separate permissions because membership automatically follows the existing Teams channel. While basic collaboration can happen directly inside Microsoft Teams, opening the workspace in the dedicated Loop application unlocks additional capabilities including richer navigation, page management, version history, and enhanced meeting experiences. The result is a living collaboration hub where project information remains organized and continuously updated instead of being scattered across several disconnected Microsoft 365 services.

REAL-TIME COLLABORATION ACROSS MICROSOFT 365
One of Loop's greatest strengths is how naturally it supports teamwork. Just like Microsoft Teams and Outlook, Loop supports @mentions, allowing team members to notify colleagues directly within a page. When someone is mentioned, they receive notifications together with the relevant collaborative content, making it easy to understand the context before responding. Comments remain attached directly to specific blocks of content rather than existing as separate email conversations. Team members can discuss ideas exactly where the work is happening instead of creating disconnected chat threads or forwarding long email chains. Multiple people can edit the same page simultaneously while seeing each other's cursors in real time. Changes appear instantly for everyone, creating an experience that feels much closer to working together around the same whiteboard than editing traditional documents. By keeping conversations, edits, and project content together, Loop significantly reduces context switching and helps teams stay focused on the work itself.

TASK MANAGEMENT THAT SYNCS AUTOMATICALLY
Another area where Loop stands out is task management. Task lists created inside a Loop Workspace are not isolated within the application. Instead, they integrate directly with Microsoft Planner and Microsoft To Do, allowing assignments to follow users wherever they already manage their work. When a task is assigned inside Loop, it automatically appears in the assigned person's Microsoft To Do list. At the same time, project managers can monitor those same tasks inside Microsoft Planner using familiar board, timeline, or calendar views. Marking a task complete in one application immediately updates it everywhere else. This synchronization eliminates duplicate data entry while ensuring everyone sees the same information regardless of whether they prefer working inside Loop, Planner, or Microsoft To Do. For many smaller projects, this also means Loop can provide lightweight project management capabilities without introducing another dedicated project management platform.

BETTER MEETINGS WITH LOOP
Loop also improves one of the most common business activities: meetings. Meeting agendas can be created directly inside Microsoft Teams using Loop components before the meeting even begins. Team members contribute agenda items, assign presenters, and prepare discussion topics collaboratively instead of relying on one organizer to distribute updates. During the meeting, everyone contributes notes to the same shared workspace in real time. Decisions, action items, and meeting summaries remain visible to every participant as they're created. After the meeting finishes, assigned tasks already exist inside Planner and Microsoft To Do without anyone manually copying notes or rewriting action lists. Because recurring meetings reuse the same collaborative structure, teams build a continuous knowledge base instead of starting from scratch every week. This integrated workflow dramatically reduces administrative work while ensuring that decisions and responsibilities are immediately visible to everyone involved.

WHEN SHOULD YOU USE LOOP?
Although Microsoft Loop is incredibly flexible, it isn't designed to replace every Microsoft 365 application. Loop performs best when teams need fast-moving collaboration, brainstorming sessions, project planning, meeting notes, lightweight task management, or shared working documents that evolve continuously throughout a project. OneNote remains the better choice for personal notebooks, handwritten notes, and long-term personal knowledge management. SharePoint continues to excel at document libraries, formal records management, compliance, and structured file storage. Microsoft Word and Excel are still the preferred tools for formal reports, contracts, financial models, and documents requiring advanced formatting. Rather than replacing these applications, Loop acts as the collaborative layer that connects them. It becomes the central workspace where ideas are captured, tasks are coordinated, and projects move forward while the specialized Microsoft applications continue handling the work they were designed for. Thinking of Loop as the glue between Microsoft 365 applications is often the easiest way to understand its role within the broader ecosystem.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Microsoft Cloud Solution Provider (CSP) - Simply Explained

Wed, 22 Jul 2026 09:00:33 +0000

Most businesses buying Microsoft 365 or Azure through a partner are already using CSP without knowing how it works. This episode explains the Cloud Solution Provider program for IT buyers and Microsoft partners: direct versus indirect resellers, how partners earn money, what the new commerce experience changed, and when CSP beats an Enterprise Agreement.

In this episode

00:00 – What CSP is: partners as wholesalers
01:40 – Direct bill versus indirect reseller
03:09 – How partners add value
04:36 – The new commerce experience and term commitments
06:43 – Why customers choose a CSP partner
08:43 – CSP versus Enterprise Agreement
10:24 – Partner requirements and support
12:20 – The big picture

Key takeaways

The Cloud Solution Provider program lets partners resell Microsoft cloud services and own billing, support and provisioning for their customers.
Under the new commerce experience, monthly, annual and triennial terms carry different prices, and seats can be added but not reduced after the short cancellation window.
CSP is a service delivery program rather than a discount program: it suits small and mid-sized businesses, while large, stable organizations should compare it with an Enterprise Agreement.

Worth quoting

“When you buy through a CSP partner, Microsoft is not your billing contact. The partner handles billing, support, and provisioning.” – Mirko Peters (00:57)

“The partner earns the margin on the service layer, not the software. That's the model. The license gets you in the door. The services keep you there.” – Mirko Peters (04:24)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on CSP
Microsoft 365 – one of the cloud services partners resell through CSP, used in the episode's pricing examples
Related episode: How Microsoft 365 & Copilot Are Redesigning the Way We Work with Tracy van der Schyff [MVP]
Related episode: Subnetting and CIDR - Simply Explained
Related episode: Microsoft Fabric for Microsoft 365 Admins: What You Need to Know
Related episode: Microsoft Teams Premium - Simply Explained

Microsoft Marketplace - Simply Explained

Wed, 22 Jul 2026 08:00:03 +0000

Welcome to another episode of Knowledge Nuggets with Mirko Peters. Today we're exploring https://www.m365.fm/categories/simply-explained/ Marketplace, one of the most important platforms in the Microsoft ecosystem—and one that's often misunderstood. When most people hear the word Marketplace, they imagine something similar to an app store where you browse a few applications, click Buy, and you're done. While that's certainly part of the story, Microsoft Marketplace has evolved into something much bigger. Today it's a global commerce platform that connects customers, software vendors, consultants, AI solutions, and cloud services through a single purchasing experience. Whether you're an IT administrator looking for infrastructure, a business leader searching for a https://www.m365.fm/power-platform-simply-explained/ solution, or a software vendor trying to reach millions of Microsoft customers, Marketplace plays a central role. By the end of https://www.m365.fm/microsoft-marketplace-simply-explained/, you'll understand what Microsoft Marketplace actually is, why it exists, how it simplifies software procurement, and why it's becoming one of Microsoft's most important growth platforms.

WHY MICROSOFT CREATED MARKETPLACE
Before cloud marketplaces existed, buying enterprise software was surprisingly complicated. Every vendor had its own website, its own pricing model, its own contract, and its own billing process. If an organization wanted a security platform from one company, a reporting solution from another, and an AI tool from a third, procurement quickly became a project of its own. IT departments spent weeks evaluating vendors, finance teams had to process multiple invoices every month, and legal departments reviewed countless contracts that often covered very similar services. Even after the software had been purchased, deployment could still involve manual licensing, configuration, and user provisioning. Microsoft recognized that the buying experience itself had become a problem. Organizations didn't necessarily need fewer software vendors—they needed a simpler way to discover, evaluate, purchase, and manage them. That's exactly what Microsoft Marketplace delivers. Instead of maintaining dozens of independent vendor relationships, organizations can purchase solutions through the same Microsoft relationship they already use for Azure and Microsoft 365. The result is a procurement process that's dramatically simpler, faster, and easier to manage.

WHAT IS MICROSOFT MARKETPLACE?
At its core, Microsoft Marketplace is Microsoft's unified commercial platform for cloud solutions. Rather than being limited to applications, Marketplace offers an enormous range of commercial products including SaaS solutions, Azure infrastructure, virtual machines, managed applications, https://www.m365.fm/ai-agents-simply-explained/, consulting services, business applications, and Power Platform extensions. Every solution published on the platform has gone through Microsoft's validation process before becoming available to customers. A useful way to think about Marketplace is as a digital shopping mall. Instead of every software company building its own storefront, Microsoft provides the building. Customers enter through a single front door, compare products, read documentation, start free trials, purchase subscriptions, and deploy solutions without ever leaving the Microsoft ecosystem. Because everything integrates with Microsoft accounts, Azure subscriptions, and Microsoft 365 tenants, customers spend less time managing vendors and more time deploying technology that actually solves business problems.

TWO STOREFRONTS, ONE PLATFORM
One area that often causes confusion is the relationship between Azure Marketplace and AppSource. Although Microsoft now presents one unified Marketplace experience, the platform still serves two different audiences. Azure Marketplace is primarily designed for technical buyers. Cloud architects, developers, infrastructure engineers, and Azure administrators typically visit Azure Marketplace when searching for virtual machines, managed applications, containers, security appliances, databases, or cloud-native SaaS services that integrate directly with Azure. AppSource, on the other hand, focuses on business users. Marketing departments, HR teams, finance professionals, sales organizations, and operations managers generally discover business applications, Microsoft Teams extensions, Dynamics 365 solutions, and Power Platform applications through AppSource. The important point is that customers don't need to understand this distinction. A software vendor can publish a single solution, and Microsoft automatically presents it through the most appropriate storefront depending on who is searching and what they're looking for. This unified experience removes unnecessary complexity while ensuring both technical and business audiences discover relevant solutions.

BUYING SOFTWARE HAS NEVER BEEN EASIER
One of Marketplace's biggest strengths is how dramatically it simplifies procurement. Instead of contacting vendors individually, customers search Marketplace, compare available products, review documentation, examine customer ratings, and often start a free trial within minutes. If the solution meets their requirements, purchasing becomes equally straightforward. Marketplace supports several commercial models, including subscription licensing, pay-as-you-go services, bring-your-own-license scenarios, and private offers for enterprise agreements. Perhaps even more valuable is the integration with Microsoft's existing billing infrastructure. Organizations don't receive another vendor invoice or need another purchasing workflow. Instead, Marketplace purchases are added to their existing Microsoft agreement, allowing Azure services, Microsoft 365 subscriptions, and Marketplace solutions to appear together on consolidated billing. For procurement and finance teams, this eliminates significant administrative overhead while giving IT departments much faster access to new technology.

WHY SOFTWARE VENDORS LOVE MARKETPLACE
Marketplace doesn't only benefit customers—it has become one of the most important sales channels for Microsoft partners. Publishing a solution on Marketplace immediately exposes it to millions of organizations already working inside Microsoft's cloud ecosystem. Instead of convincing customers to visit another website, partners appear directly where purchasing decisions are already being made. Their applications can be discovered through Azure, Microsoft Teams, Microsoft 365, Copilot, and Microsoft's administration portals. This dramatically increases visibility while reducing customer acquisition costs. Marketplace also enables participation in Microsoft's co-sell programs, where Microsoft sales teams actively recommend partner solutions during customer engagements. For many software companies, Marketplace has evolved from an optional distribution channel into a fundamental part of their overall go-to-market strategy. As Microsoft continues investing in partner incentives and Marketplace Rewards, the platform is becoming increasingly important for software vendors building on Azure and Microsoft 365.

AI IS CHANGING THE MARKETPLACE EXPERIENCE
Like many Microsoft products, Marketplace is rapidly being transformed by artificial intelligence. Instead of requiring customers to search using exact product names, Marketplace increasingly supports natural language queries. Rather than typing "project management software," a customer might simply ask for "an AI agent that helps coordinate projects inside Microsoft Teams." Marketplace understands the request, recommends relevant solutions, highlights important differences, and even generates side-by-side comparisons that explain which product best matches the customer's requirements. Product pages are also becoming more interactive through AI-powered assistants capable of answering licensing, deployment, integration, and compatibility questions. At the same time, Marketplace has introduced dedicated sections for Microsoft 365 Copilot agents and AI-powered business applications, making it much easier for organizations to discover intelligent solutions that integrate directly into their existing Microsoft environment. Instead of simply becoming a larger software catalog, Marketplace is evolving into an intelligent advisor that actively helps customers make better purchasing decisions.

EVERYTHING CONNECTS THROUGH THE MICROSOFT ECOSYSTEM
Perhaps the greatest strength of Microsoft Marketplace isn't the number of available products—it's how seamlessly everything integrates. When a customer purchases a solution through Marketplace, they're not simply buying software. They're extending their existing Microsoft environment. Authentication works through Microsoft Entra ID. Existing https://www.m365.fm/conditional-access-simply-explained/ policies continue protecting users. Billing flows through established Microsoft agreements. Azure subscriptions provision resources automatically, while Microsoft Teams, Copilot, Dynamics 365, and Microsoft 365 can immediately surface newly purchased applications. This level of integration dramatically reduces deployment complexity while maintaining the governance, identity management, and security controls organizations have already invested in. Rather than introducing another isolated platform, Marketplace strengthens the Microsoft ecosystem by allowing customers to extend it safely with trusted third-party solutions.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Microsoft Secure Score - Simply Explained

Wed, 22 Jul 2026 07:00:03 +0000

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're exploring Microsoft Secure Score—one of the simplest yet most misunderstood security features in Microsoft 365. Many administrators log into the Microsoft Defender portal, see a percentage like 35% or 50%, and immediately wonder whether their organization is at risk. Others spend months trying to reach a perfect score of 100%, believing that's the ultimate goal. The reality is very different. Secure Score isn't a cybersecurity grade or a guarantee against attacks. Instead, it's a practical roadmap that helps organizations understand how many of Microsoft's recommended security controls have been implemented and where improvements can have the biggest impact.

WHAT IS MICROSOFT SECURE SCORE?
Microsoft Secure Score measures how many recommended security controls are enabled within your Microsoft 365 tenant. It evaluates configuration rather than real-world security effectiveness. Think of it as a checklist rather than a vulnerability scanner. The score answers questions such as:

Is Multi-Factor Authentication enabled?
Are security policies configured?
Are recommended protections implemented?
Have important security settings been activated?

Secure Score lives inside the Microsoft Defender portal under Exposure Management and provides organizations with a continuously updated view of their Microsoft security configuration.

HOW SECURE SCORE IS CALCULATED
Secure Score follows a simple formula: Points Earned ÷ Total Available Points = Secure Score Organizations earn points in two ways. Binary Controls Some recommendations are either enabled or disabled. For example:

Multi-Factor Authentication
Legacy Authentication blocking
Security Defaults

If the control is enabled, full points are awarded. If not, no points are earned. Proportional Controls Other recommendations award partial credit. For example, if BitLocker encryption is enabled on 80% of managed devices, Secure Score awards approximately 80% of the available points. This allows organizations to receive recognition while gradually expanding security across their environment.

WHAT IS A GOOD SECURE SCORE?
One of the biggest misconceptions is that every organization should achieve 100%. In reality, Microsoft itself recognizes that this isn't always practical. Reasons include:

Different licensing levels
Features not relevant to every organization
Business requirements
Legacy systems
Accepted business risks

Many Microsoft 365 environments begin between 30% and 45%, while organizations with mature security programs often maintain scores between 70% and 85%. Rather than chasing perfection, Secure Score should help organizations prioritize meaningful security improvements without negatively affecting productivity.

THE FOUR PILLARS OF SECURE SCORE
Secure Score organizes recommendations into four primary categories. Identity Identity focuses on:

Multi-Factor Authentication
Conditional Access
Password protection
Blocking legacy authentication

Since compromised identities remain one of the most common attack vectors, this category carries significant weight. Devices Device recommendations include:

BitLocker
Microsoft Defender Antivirus
Attack Surface Reduction
Tamper Protection

These settings strengthen endpoint security across managed devices. Data Data recommendations focus on:

Sensitivity Labels
Data Loss Prevention
Encryption
Microsoft Purview

These controls help protect sensitive organizational information. Apps Application security evaluates:

App governance
Third-party application permissions
Cloud application security
OAuth management

Together, these four pillars provide a broad overview of Microsoft's recommended security controls across the Microsoft ecosystem.

COMMON MISCONCEPTIONS
Secure Score is frequently misunderstood. A high score does not mean an organization cannot be compromised. It simply indicates that recommended security configurations have been implemented. Likewise, a lower score doesn't necessarily indicate an insecure organization. Another misconception is believing every recommendation should always be implemented. Some recommendations may:

Conflict with business requirements
Require licenses that aren't available
Break legacy applications
Introduce unnecessary operational complexity

Organizations can document accepted risks or alternative mitigations when recommendations aren't appropriate for their environment. Secure Score supports these decisions instead of forcing every recommendation to be implemented.

USING SECURE SCORE AS A ROADMAP
The greatest value of Secure Score comes from its Recommended Actions. Instead of treating the score as a report card, administrators should use it as a prioritized work queue. Each recommendation includes:

Security impact
Required configuration
Implementation guidance
Direct links to configuration pages

Administrators can mark recommendations as:

Planned
Risk Accepted
Resolved through Alternative Mitigation

This creates both technical progress and valuable documentation for future administrators and auditors. Small monthly improvements often provide greater long-term value than trying to complete dozens of recommendations simultaneously.

PART OF A LARGER SECURITY STRATEGY
Secure Score represents only one component of Microsoft's overall security ecosystem. It complements solutions including:

Microsoft Defender XDR
Microsoft Sentinel
Microsoft Entra ID
Microsoft Defender for Endpoint
Microsoft Defender for Office 365

While Secure Score measures configuration coverage, these additional products provide:

Threat detection
Incident response
Identity protection
Security monitoring
Vulnerability management

A strong Secure Score improves an organization's security posture, but effective cybersecurity also requires continuous monitoring, user awareness, patch management, and operational security practices.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Microsoft Defender for Cloud Apps - Simply Explained

Wed, 22 Jul 2026 06:00:03 +0000

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're exploring Microsoft Defender for Cloud Apps—Microsoft's Cloud Access Security Broker (CASB) that helps organizations discover, monitor, and protect the cloud applications employees use every day. Modern organizations rely on hundreds of cloud services, but many of them are never approved by IT. Employees sign up for AI tools, file-sharing platforms, collaboration services, and productivity apps to solve business problems quickly. While these services improve productivity, they can also introduce significant security, compliance, and data protection risks. Microsoft Defender for Cloud Apps helps organizations regain visibility, understand risk, and protect business data without preventing innovation.

THE PROBLEM: SHADOW IT
One of the biggest challenges facing modern IT departments is Shadow IT. Shadow IT refers to cloud applications employees use without official approval from the IT department. Examples include:

File-sharing websites
AI writing assistants
Project management tools
Online collaboration platforms
Personal cloud storage

Employees often adopt these services because they're convenient, but organizations lose visibility into where sensitive business information is being stored and shared. Without visibility, companies cannot adequately manage:

Data leakage
Compliance requirements
Insider threats
Third-party security risks

Microsoft Defender for Cloud Apps was designed specifically to eliminate these blind spots.

WHAT IS MICROSOFT DEFENDER FOR CLOUD APPS?
Microsoft Defender for Cloud Apps acts as a security layer between users and cloud services. Rather than replacing cloud applications, it continuously monitors how they're being used. Its primary responsibilities include:

Discovering cloud applications
Assessing application risk
Detecting suspicious behavior
Protecting sensitive information
Enforcing security policies

As part of the broader Microsoft Defender ecosystem, it integrates closely with Microsoft Entra ID, Microsoft Defender for Endpoint, Microsoft Sentinel, and Microsoft Defender XDR to provide enterprise-wide cloud security.

CLOUD DISCOVERY
The platform's first major capability is Cloud Discovery. Cloud Discovery identifies every cloud application employees access across the organization, including services that IT never approved. Organizations using Microsoft Defender for Endpoint receive continuous automated monitoring, while Microsoft 365 Business Premium customers can upload firewall or proxy logs for periodic analysis. The Cloud Discovery dashboard provides insights into:

Applications in use
Number of users
Network traffic
Data uploads
Geographic locations
Risk ratings

Instead of guessing which cloud services employees use, administrators gain complete visibility into their cloud environment.

THE APP CATALOG
Finding cloud applications is only the beginning. Microsoft maintains an App Catalog containing more than 31,000 cloud applications, each evaluated against over 90 security and compliance factors. Applications receive risk scores based on criteria including:

Encryption
Multi-Factor Authentication
Compliance certifications
Privacy policies
Data ownership
Audit capabilities

Organizations can classify applications as:

Sanctioned
Unsanctioned
Monitored

This allows IT departments to quickly identify trusted services while blocking or closely monitoring applications that introduce unnecessary business risk.

THREAT DETECTION
Microsoft Defender for Cloud Apps continuously monitors user behavior for suspicious activity. Built-in policies automatically detect scenarios such as:

Impossible travel
Mass downloads
Mass deletions
Logins from risky IP addresses
Suspicious email forwarding
Unusual account behavior

Using User and Entity Behavior Analytics (UEBA), the platform learns normal user activity over time and identifies anomalies that could indicate compromised accounts or insider threats. Organizations can respond automatically by:

Sending alerts
Blocking sessions
Suspending accounts
Triggering security workflows

This allows security teams to react quickly before attackers cause significant damage.

DATA PROTECTION
Beyond detecting threats, Defender for Cloud Apps actively protects sensitive information. Integration with Microsoft Information Protection enables automatic application of sensitivity labels based on document content. The platform can also enforce:

Download restrictions
Copy and paste controls
Printing restrictions
Session monitoring
Conditional Access policies

Support extends beyond Microsoft services to third-party platforms including:

Google Workspace
Salesforce
Box
AWS
Dropbox

This consistent protection helps organizations secure data regardless of where employees choose to work.

OAUTH APP GOVERNANCE
Many cloud applications request access through OAuth permissions. While convenient, some applications request far more permissions than necessary. Defender for Cloud Apps monitors OAuth applications and identifies services requesting excessive access to:

Email
Files
Calendars
Contacts
OneDrive
Microsoft 365 data

Administrators can review, approve, or revoke permissions before sensitive business information becomes exposed through third-party applications. This provides another critical layer of protection against data leakage and account compromise.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Dynamics 365 Customer Service - Simply Explained

Wed, 22 Jul 2026 04:17:48 +0000

Support teams lose time and customer trust when email, phone, chat and CRM live in separate tools. This Simply Explained episode is for service leaders and Microsoft 365 admins who want to understand how Dynamics 365 Customer Service connects cases, channels, Copilot and AI agents, Teams and Outlook, self-service and analytics in one platform.

In this episode

00:00 – Why customer support breaks
02:01 – What Dynamics 365 Customer Service is
03:27 – Case management, the heart of the system
05:38 – Omnichannel: one platform, every channel
07:29 – AI agents and Copilot
10:39 – Integration with Teams and Outlook
13:25 – Self-service and knowledge management
15:23 – Analytics, supervisor tools and recap

Key takeaways

Dynamics 365 Customer Service ties every email, chat, call and social interaction to a single case record built on Dataverse, so customers no longer repeat themselves.
Omnichannel routing, Copilot summaries and dedicated AI agents for case management, intent, knowledge and quality take routine work off service reps.
Deep Teams and Outlook integration, Power Pages self-service portals and real-time analytics turn support into one connected, measurable operation.

Worth quoting

“Most users never think about the back end. But it's what makes everything work. And it's part of the broader Microsoft ecosystem. Teams, Outlook, Power Platform, Co-Pilot, they're all connected.” – Mirko Peters (03:03)

“A case is a single customer issue. It's the central record that everything revolves around. Every email, every phone call, every chat message, it all links back to one case record.” – Mirko Peters (03:31)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ on Customer Service
Dynamics 365 Customer Service – the cloud service platform this episode explains, from cases and channels to analytics
AI agent – the case management, intent, knowledge and quality agents that take routine work off service reps
Microsoft Teams – embedded in the agent workspace for chats, calls and swarming channels linked to cases
Related episode: Power Apps - Simply Explained

Dataverse Security - Simply Explained

Tue, 21 Jul 2026 19:00:02 +0000

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're exploring Microsoft Dataverse Security—one of the most important, and often misunderstood, aspects of the Power Platform. When people hear the word security, they usually think about passwords, authentication, or Microsoft Entra ID. While those components are important, Dataverse security goes much further. It determines who can perform actions, which records they can access, and even which individual fields they are allowed to see. Understanding these layers is essential for building secure enterprise applications that protect sensitive business information while allowing employees to work efficiently.

THE THREE LAYERS OF DATAVERSE SECURITY
Dataverse security is built around three distinct layers that work together. The first layer controls what actions users can perform. The second layer determines which records users are allowed to access. The third layer protects individual fields inside those records. Rather than relying on a single permission model, Dataverse combines these layers to provide highly granular security suitable for enterprise environments. Understanding how they interact is the key to designing secure Power Platform solutions.

SECURITY ROLES – WHO CAN DO WHAT
Everything starts with Security Roles. Every Dataverse user must have at least one security role before they can access any data. Security roles define privileges such as:

Create
Read
Write
Delete
Append
Assign
Share

Microsoft provides several built-in roles, including:

Basic User
System Customizer
Environment Maker
System Administrator

Most organizations create custom roles by copying the Basic User role and adding only the permissions required for their own business tables. Following the principle of least privilege reduces security risks while keeping administration manageable.

ACCESS LEVELS – HOW MUCH DATA?
Granting permission to read data isn't enough. Dataverse also defines how much data a user may access through Access Levels. The four primary scopes are:

User
Business Unit
Parent: Child Business Units
Organization

For example, a salesperson might only see opportunities they own, while a sales manager can view opportunities belonging to everyone within the department. One important concept is that permissions are additive. If a user receives multiple security roles, Dataverse grants the broadest permission available. Additional roles never reduce existing permissions—they only increase them. Understanding this behavior helps administrators avoid accidentally granting more access than intended.

BUSINESS UNITS – ORGANIZING ACCESS
Business Units provide organizational separation. They typically represent departments such as:

Sales
Marketing
Finance
HR
Customer Support

Every user belongs to a default Business Unit, and records can also belong to Business Units. Historically, Business Units created strict organizational boundaries, limiting users to records owned by their own department. Modern Dataverse introduces a much more flexible matrix access model, allowing users to receive security roles from multiple Business Units. This enables cross-functional collaboration without forcing organizations to redesign their entire hierarchy whenever employees work across departments or regions.

TEAMS – SHARED OWNERSHIP
While Business Units organize departments, Teams simplify collaboration. Dataverse supports two primary team types. Owning Teams Owning Teams own records collectively. Instead of assigning ownership to a single employee, an entire team becomes responsible for the record. This works particularly well for sales teams, service desks, and project groups where multiple people collaborate continuously. Access Teams Access Teams don't own records. Instead, they provide temporary or scenario-specific access without transferring ownership. Microsoft also integrates Teams with Microsoft Entra ID security groups, allowing administrators to manage membership centrally while Dataverse automatically synchronizes permissions. This significantly reduces administrative effort in larger organizations.

FIELD-LEVEL SECURITY
Sometimes protecting an entire record isn't enough. Sensitive information may exist in only one or two fields. Examples include:

Salary
Tax IDs
Credit card numbers
Social security numbers
Banking details

Field-Level Security (FLS) protects individual columns inside a Dataverse table. Administrators create Field Security Profiles that specify which users or teams may:

Read
Update
Create

secured fields. Even users with Organization-level table permissions cannot view secured columns unless they are explicitly included in the appropriate Field Security Profile. This makes FLS one of the most powerful security mechanisms available within Dataverse.

MASKING AND BEST PRACTICES
Recent Dataverse enhancements introduced column masking, allowing organizations to partially display sensitive information. Instead of revealing an entire credit card number, users may only see the final four digits. Masking occurs on the server, ensuring consistent protection across forms, APIs, reports, and applications. Additional protections include:

App Access Control
Offline security
Server-side enforcement
Secure mobile synchronization

Microsoft recommends applying Field-Level Security only to truly sensitive columns because excessive use can increase complexity and affect performance. The recommended approach is:

Security Roles
Business Units and Teams
Field-Level Security only where necessary

Each layer should solve a specific problem rather than being applied everywhere

COMMON TROUBLESHOOTING SCENARIOS
Many Dataverse security issues follow familiar patterns. A common mistake is creating a custom security role while forgetting to assign the Basic User role, preventing users from accessing the environment. Another frequent misunderstanding involves additive permissions. Assigning another security role never removes existing permissions—it only grants additional access. Administrators should also verify:

Business Unit ownership
Team ownership
Access Levels
Field Security Profiles

A user may have full table permissions yet still be unable to view a field because Field-Level Security overrides table-level access for secured columns. Knowing where to investigate dramatically reduces troubleshooting time.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Power Platform - Simply Explained

Tue, 21 Jul 2026 19:00:02 +0000

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're exploring the Microsoft Power Platform—Microsoft's low-code ecosystem for building applications, automating business processes, analyzing data, and creating AI-powered experiences without traditional software development. Many organizations still rely on spreadsheets, email chains, paper forms, and disconnected business systems. Information lives in multiple places, employees spend hours copying data between applications, and repetitive work slows everyone down. Microsoft Power Platform solves this challenge by connecting your existing Microsoft 365 environment into one intelligent platform where business users and developers can build solutions together using little or no code.

WHY POWER PLATFORM EXISTS
Every business has repetitive work. Employees manually:

Copy information between systems
Process approval requests
Update spreadsheets
Create reports
Build temporary databases
Track projects
Exchange countless emails

Traditional software development is often expensive and slow, while off-the-shelf applications rarely match every business process. Power Platform closes this gap by giving employees the tools to build applications, automate workflows, analyze information, and introduce AI—all while leveraging the Microsoft technologies organizations already use every day.

POWER BI – UNDERSTAND YOUR DATA
Power BI is the analytics component of the Power Platform. It transforms raw business data into interactive dashboards and reports that help organizations make informed decisions. Power BI connects to:

Excel
SQL Server
Dataverse
SharePoint
Salesforce
Azure
Hundreds of additional data sources

Instead of manually creating reports every week, dashboards refresh automatically, giving managers real-time visibility into sales, operations, finances, and performance. Power BI becomes the "eyes" of the Power Platform, helping organizations understand what is happening across the business.

POWER AUTOMATE – AUTOMATE THE WORK
Once organizations understand their data, they often want to automate repetitive tasks. That's where Power Automate comes in. Power Automate uses simple triggers and actions to automate business processes. Typical scenarios include:

Approval workflows
Email notifications
Document processing
File synchronization
Task creation
Data movement
ERP integrations

With more than 1,400 connectors, Power Automate connects Microsoft 365 with countless third-party services including Salesforce, Slack, Dropbox, DocuSign, and many others. Rather than employees repeating the same work every day, Power Automate performs those tasks automatically.

POWER APPS – BUILD BUSINESS APPLICATIONS
Power Apps provides the user interface for business processes. Instead of purchasing expensive custom software, organizations can build applications tailored to their own requirements. Power Apps supports two application models. Canvas Apps Designed visually using drag-and-drop controls. Perfect for:

Mobile apps
Inspection forms
Field workers
Simple business processes
Custom user experiences

Model-Driven Apps Built around Dataverse tables and relationships. Ideal for:

CRM systems
HR solutions
Asset management
Customer databases
Enterprise applications

Power Apps uses Power Fx, an Excel-inspired formula language that enables business users to create application logic without traditional programming languages.

COPILOT STUDIO – ADD AI
One of the newest members of the Power Platform is Microsoft Copilot Studio. Previously known as Power Virtual Agents, it has evolved into a platform for building AI agents that can:

Answer questions
Access business systems
Trigger Power Automate workflows
Retrieve organizational knowledge
Collaborate with other AI agents

Organizations can deploy these agents inside:

Microsoft Teams
Websites
Mobile applications
Microsoft 365 Copilot

With Agent-to-Agent communication, multiple AI agents can coordinate behind the scenes, allowing organizations to automate increasingly complex business processes.

DATAVERSE – THE FOUNDATION
Behind every Power Platform solution sits Microsoft Dataverse. Dataverse provides:

Secure cloud storage
Business tables
Relationships
Role-based security
Business rules
Centralized data management

Instead of maintaining separate spreadsheets and disconnected databases, organizations create a single source of truth that every Power Platform component shares. Power Apps reads from Dataverse. Power Automate updates Dataverse. Power BI reports on Dataverse. Copilot Studio retrieves knowledge from Dataverse. This shared foundation allows every part of the platform to work together seamlessly.

HOW EVERYTHING WORKS TOGETHER
The real strength of the Power Platform isn't any individual product—it's how they integrate. Consider an expense approval process. An employee submits an expense using Power Apps. The information is securely stored in Dataverse. Power Automate detects the submission and routes it to a manager for approval. The manager reviews spending trends through a Power BI dashboard. A Copilot Studio AI agent summarizes the request and recommends an approval decision. Once approved, Power Automate updates financial systems, sends confirmation emails, and records everything automatically. Five different services collaborate to complete one seamless business process with minimal manual effort.

REAL-WORLD ADOPTION
Organizations around the world are already using Power Platform to modernize operations. Companies build:

Employee onboarding solutions
Expense management systems
Customer service portals
Field inspection apps
Inventory management
Executive dashboards
AI-powered assistant

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Power Pages - Simply Explained

Tue, 21 Jul 2026 17:00:03 +0000

Small businesses and IT teams need customer portals, partner hubs and self-service sites but rarely have web developers to build them. This episode explains Microsoft Power Pages: how it connects to Dataverse, how the Design Studio and Copilot speed up building, how security and licensing work, and where single-page apps and AI agents take the platform next.

In this episode

00:00 – What Power Pages is
01:57 – From Power Apps portals to Power Pages
03:05 – Dataverse: the engine behind the site
04:58 – Building with the Design Studio and Copilot
06:55 – Security: who sees what
09:28 – Licensing and costs
11:01 – Real-world use cases
13:09 – What's next: SPAs, server logic and AI agents

Key takeaways

Power Pages is Microsoft's low-code platform for secure, external-facing websites that read and write live business data in Dataverse, unlike marketing sites built with WordPress or Squarespace.
Sites are private by default and protected by a web application firewall, CDN, multiple identity providers, table and page permissions, web roles and the Deep Scan security tool.
Standalone per-site licensing, a 30-day trial and new capabilities such as single-page applications, server logic and AI agents make it a full web application platform.

Worth quoting

“Think of it as a storefront for your business data. You have a back office full of customer records, orders, and service cases. Powerpages is the front door that lets your customers walk in and interact with that data.” – Mirko Peters (00:49)

“A WordPress site shows static content, but a Powerpages site shows live data from your business systems.” – Mirko Peters (01:38)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short Power Pages FAQ
Power Pages – the low-code platform for external business websites that this episode explains end to end
Dataverse – the cloud database behind every Power Pages site, read and written in real time
Power Apps – the internal-app counterpart, and the old home of Power Apps portals before the 2022 rebrand
Related episode: Power Apps - Simply Explained

Power Apps - Simply Explained

Tue, 21 Jul 2026 16:00:02 +0000

Stuck with a messy spreadsheet because a custom app seems to need a developer and months of work? This episode explains Power Apps for business users, citizen developers and IT pros: canvas versus model-driven apps, Dataverse and connectors, security and governance, and how Copilot and AI tools now build apps from plain English.

In this episode

00:00 – Intro: the app you keep putting off
00:22 – What Power Apps actually is
02:30 – Canvas apps versus model-driven apps
04:50 – Dataverse and connectors
07:12 – The ecosystem, security and governance
10:03 – Building your first app without code
12:25 – AI in Power Apps: Copilot, agents and Claude Code
16:54 – When to use Power Apps and next steps

Key takeaways

Power Apps is the low-code app builder of the Power Platform, and its real strength is deep integration with Microsoft 365, Entra ID and hundreds of connectors.
Canvas apps give pixel-level design control for task-focused apps, while model-driven apps generate their interface from Dataverse tables for complex data.
Copilot and external AI tools like Claude Code now generate apps from plain-English descriptions, but preview features still need review before production use.

Worth quoting

“Power Apps is what the industry calls a low-code platform. Low-code means you're writing less code, not zero code. You might still type some formulas, but they're simple.” – Mirko Peters (02:01)

“The real value isn't any single feature. It's the integration. Your app lives inside Teams, pulls data from SharePoint, sends notifications through Outlook, and uses the same security that protects your email.” – Mirko Peters (02:16)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ on Power Apps
Power Apps – the low-code app builder this whole episode explains, from first app to AI-generated apps
Canvas app – the blank-screen app type for task-focused apps where layout and design matter most
Model-driven app – the app type that builds its interface from Dataverse tables for complex data
Dataverse – Microsoft's cloud database that model-driven apps require and growing canvas apps migrate to
Related episode: Power Apps Component Framework - Simply Explained

Power Automate - Simply Explained

Tue, 21 Jul 2026 15:00:02 +0000

Repetitive tasks like copying data, forwarding approvals and sending the same emails eat hours every week. This beginner-friendly episode explains Power Automate in plain English for Microsoft 365 users, covering triggers, actions, connectors, cloud and desktop flows, and how to build your first flow in minutes without code.

In this episode

00:00 – What Power Automate is
00:37 – The problem Power Automate solves
01:53 – Trigger plus action
03:27 – The three types of flows
05:01 – Connectors
06:35 – Cloud flows vs. desktop flows
09:57 – Real-world examples
11:31 – Your first flow in five minutes

Key takeaways

Every Power Automate flow is a trigger plus one or more actions, and automated, instant and scheduled flows differ only in how the trigger fires.
Hundreds of pre-built connectors let flows link Microsoft 365 apps like SharePoint, Teams and Outlook with third-party services, and custom connectors cover any system with an API.
Cloud flows run on Microsoft's servers for modern services, while desktop flows use RPA to drive legacy applications by mouse and keyboard.

Worth quoting

“Most people think power automate is complicated, but strip away all the marketing and technical jargon and it's really just when this happens, do that.” – Mirko Peters (03:14)

“The core engine is exactly the same for all three types. The only real difference is the trigger. Automated flows use event triggers. Instant flows use manual triggers. Scheduled flows use time triggers” – Mirko Peters (04:44)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a beginner FAQ
Power Automate – the episode's subject, explained as a trigger plus actions across cloud and desktop flows
Connector – the translators that let flows talk to SharePoint, Outlook, Teams and third-party services
SharePoint – a frequent trigger and target, from saving form answers to document approval flows
Microsoft Teams – where the example flows post alerts, approval notifications and a daily task summary
Related episode: Power Automate Desktop - Simply Explained

AI Agents - Simply Explained

Tue, 21 Jul 2026 14:00:02 +0000

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're exploring AI Agents—one of the fastest-growing concepts in artificial intelligence and the foundation of Microsoft's vision for the future of work. The term "AI agent" is often used interchangeably with chatbot, but they're fundamentally different. A chatbot answers questions. An AI agent pursues goals. It can reason, make decisions, interact with business systems, perform tasks autonomously, and report back when the work is complete. Throughout this episode, you'll learn what makes AI agents unique, how Microsoft enables them across Microsoft 365 and Azure, and which platform you should choose depending on your requirements.

CHATBOTS VS. AI AGENTS
The easiest way to understand AI agents is by comparing them with traditional chatbots. A chatbot is reactive. It waits for a user to ask a question, generates an answer, and the interaction ends. Its memory is usually limited to the current conversation, and it cannot perform work outside the chat interface. An AI agent works very differently. Instead of simply answering questions, an agent receives an objective and determines the necessary steps to accomplish it. It can access calendars, send emails, update SharePoint lists, create documents, interact with business systems, and complete workflows without continuous user supervision. Think of a chatbot as a receptionist answering questions at the front desk. An AI agent is more like a project manager who coordinates multiple tasks, communicates with different systems, and returns once the objective has been completed.

WHAT MAKES AN AI AGENT?
An AI agent combines several capabilities that extend far beyond language generation. Modern agents can:

Reason through complex problems
Plan multiple steps
Use external tools
Access enterprise knowledge
Make decisions
Execute actions
Learn from context
Work autonomously toward a goal

Rather than generating isolated responses, agents continuously evaluate what should happen next until the assigned task has been completed. This makes them ideal for business automation, customer service, IT operations, HR, procurement, finance, and countless other enterprise scenarios.

MICROSOFT'S THREE AGENT BUILDING OPTIONS
Microsoft provides three different approaches for building AI agents. Agent Builder Agent Builder is the simplest option. Included with Microsoft 365 Copilot, it enables users to create no-code agents simply by describing what they want in natural language. Knowledge can be sourced from:

SharePoint
OneDrive
Teams
Websites
Uploaded files
Organizational data

This makes Agent Builder perfect for departmental knowledge assistants and internal Q&A solutions. Copilot Studio Copilot Studio introduces low-code capabilities. Developers and power users can connect over a thousand business systems through connectors, build custom conversation flows, trigger workflows automatically, and publish agents to Microsoft Teams, Microsoft 365 Copilot, or external websites. It's designed for organizations that want AI agents capable of interacting with real business processes instead of simply answering questions. Azure AI Foundry Azure AI Foundry provides complete developer control. Organizations can choose different AI models, build multi-agent architectures, customize orchestration logic, integrate advanced memory, and deploy enterprise-scale AI workloads running on managed Azure infrastructure. Foundry is the platform of choice for professional AI engineering teams building production-ready AI solutions.

KNOWLEDGE, MEMORY, AND TOOLS
An AI agent becomes valuable because it combines reasoning with enterprise knowledge. Depending on the platform, agents can retrieve information from:

Microsoft Graph
SharePoint
Teams
OneDrive
Dataverse
Outlook
External business systems
Custom APIs

Unlike traditional AI models that rely only on their training data, enterprise agents continuously ground their responses using current organizational information. This dramatically improves accuracy while reducing hallucinations and ensuring answers remain relevant to the latest business data.

DIGITAL IDENTITIES FOR AGENTS
One of Microsoft's most significant innovations is giving AI agents their own digital identities. Each enterprise agent receives an identity within Microsoft Entra ID, similar to a human employee. This identity can include:

A mailbox
OneDrive storage
Teams presence
Security permissions
Authentication credentials

Because agents authenticate through Microsoft Entra ID, they follow the same permission model as human users. If an agent isn't authorized to access a document, it cannot retrieve or use that information. This creates a secure foundation for enterprise AI adoption.

WORK IQ AND ENTERPRISE GROUNDING
Microsoft uses Work IQ to provide agents with organizational context. Instead of relying purely on general AI knowledge, Work IQ searches:

Emails
Documents
Teams conversations
Calendar events
SharePoint content
Microsoft Graph data

Every query respects existing security permissions. Users only receive answers based on information they are already authorized to access, preserving enterprise security boundaries while significantly improving response quality.

REAL-WORLD PROCUREMENT AGENT
The episode demonstrates Microsoft's procurement agent as a practical example. The workflow begins with an approved agent published through an internal agent catalog. After receiving procurement policies, supplier information, and purchasing guidelines, the agent can independently:

Evaluate supplier options
Compare pricing
Review SLAs
Create purchase orders
Update SharePoint tracking systems
Report progress through Microsoft Teams

Users simply assign the objective while the agent coordinates the individual tasks autonomously. This illustrates the transition from AI assistants toward digital coworkers capable of performing meaningful business work.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

From Data to Intelligent Agents: Building Trusted Enterprise AI with Microsoft AI Foundry with Shubhangi Goyal [MVP]

Tue, 21 Jul 2026 13:00:02 +0000

Enterprise AI is entering a new phase where success is no longer measured by impressive demos but by real business outcomes. Organizations are moving beyond experimenting with large language models and are now focused on building intelligent AI agents that are secure, scalable, and trusted by employees and customers alike. In this episode of the M365.fm podcast, Microsoft MVP Shubhangi Goyal joins Mirko Peters to explore how Microsoft AI Foundry enables enterprises to design, deploy, and govern AI solutions that create measurable value.

WHY DATA QUALITY IS THE FOUNDATION OF EVERY SUCCESSFUL AI PROJECT
One of the biggest takeaways from this conversation is that AI is only as good as the data behind it. Shubhangi explains why organizations must prioritize high-quality, well-governed data before investing heavily in AI initiatives. The discussion covers AI readiness, context engineering, responsible AI, and why clean enterprise data remains the most valuable asset for building reliable AI agents that users can actually trust.

MICROSOFT AI FOUNDRY EXPLAINED: FROM MODELS TO PRODUCTION-READY AI AGENTS
Discover how Microsoft AI Foundry brings together foundation models, AI agents, evaluation tools, observability, guardrails, and enterprise governance into a single platform. Shubhangi explains how AI Foundry integrates with Microsoft Fabric, Azure AI Search, and enterprise knowledge sources while comparing its capabilities with Copilot Studio and discussing when each platform is the right choice for different AI scenarios.

BUILDING RESPONSIBLE AI WITH GOVERNANCE, SECURITY, AND TRUST
Responsible AI is about much more than compliance. This episode explores AI governance frameworks, security controls, guardrails, hallucination mitigation, red teaming, explainable AI, and continuous evaluation. Learn why enterprises must embed governance into every stage of AI development instead of treating it as an afterthought and how trust ultimately determines whether an AI solution succeeds or fails.

MAXIMIZING ROI FROM ENTERPRISE AI INVESTMENTS
Many organizations invest heavily in AI but struggle to demonstrate measurable business value. Shubhangi shares practical advice on identifying high-impact AI use cases, selecting the right models, balancing cost versus performance, improving productivity, and calculating return on investment. She explains why successful AI adoption starts with solving real business problems instead of deploying AI simply because it's the latest trend.

THE FUTURE OF AGENTIC AI AND MICROSOFT'S AI ECOSYSTEM
Looking ahead, the conversation explores the future of enterprise AI, including AI memory management, multi-agent systems, context engineering, enterprise knowledge, and the rapid evolution of Microsoft AI Foundry. Whether you're an IT professional, AI engineer, architect, data scientist, Microsoft partner, or business leader, this episode provides practical insights for building intelligent, trustworthy AI.

WHAT YOU LEARN

What Microsoft AI Foundry is and when to use it
Why data quality is the foundation of successful AI
AI readiness strategies for enterprise organizations
AI governance, Responsible AI, and security best practices
Building intelligent AI agents with Microsoft technologies
Microsoft AI Foundry vs Copilot Studio vs Microsoft Fabric
Reducing hallucinations through evaluation and guardrails
Measuring ROI for enterprise AI investments
The future of agentic AI, memory management, and context engineering
Practical lessons from real-world enterprise AI projects

solutions that are ready for production.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

From AI Hype to AI Harness Engineering – Building AI That People Can Actually Trust with Alan Buscaglia [MVP] from Gentleman Programming

Mon, 20 Jul 2026 13:00:02 +0000

AI demos are easy, but AI systems that deliver consistent, trustworthy results take real engineering. This conversation is for developers, tech leads and teams adopting AI coding agents. Alan Buscaglia explains how harnesses, skills, tests, guardrails and a human in the loop turn unpredictable AI into dependable output.

In this episode

00:00 – Welcome and introducing Alan Buscaglia
01:41 – Alan's path and building Gentleman Programming
12:34 – Using AI in the community and staying in the loop
16:46 – What AI harness engineering is
22:38 – Testing, benchmarking and guardrails
30:10 – Tips for teams: skills over prompts
40:14 – Learning, orchestration and soft skills
46:06 – The AI race, costs and the future of developers

Key takeaways

Every AI coding tool answers differently because of the harness behind it, and teams can engineer their own harnesses, loops and skills to guide agents toward consistent results.
Reliable AI output needs end-to-end tests, benchmarks for tokens, time and cost, and guardrail gates, while over-engineered harnesses waste context and money.
Keep a human in the loop, share team conventions with the AI as skills, and invest in soft skills and fundamentals, because AI is a tool and not your boss.

Worth quoting

“The flow will be, I implement something, I committed something, I create a pull request and boom, I merged it if it passes. That flow is a harness.” – Alan Buscaglia (18:26)

“when you harness something, you give context, and when you give context, you are getting the context from the agent, okay? So you're reducing the amount of context window that the agent can use” – Alan Buscaglia (21:21)

Explore more on M365.FM

Episode page: the full conversation with chapters, Alan's key quotes and an FAQ
Alan Buscaglia – the guest, creator of Gentleman Programming and an open source collection of AI coding harnesses
Agent harness – the guided flow behind every coding agent, which Alan builds, benchmarks and tests for consistent output
Human in the loop – Alan's rule to never let AI pull the trigger and always stay the overseer
Related episode: From Financial Data to AI-Ready Decisions: Power BI, Microsoft Fabric, Semantic Models & AI Agents with Rishi Sapra [MVP]

Agent-to-Agent (A2A) Communication - Simply Explained

Mon, 20 Jul 2026 06:00:03 +0000

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're exploring Agent-to-Agent (A2A) Communication, the open protocol that allows AI agents to discover one another, delegate work, and collaborate as intelligent teams. Today's AI agents are often highly specialized but isolated. One agent may excel at booking flights, another at checking weather, and another at managing IT tickets—but without a common communication standard, connecting them quickly becomes a maintenance nightmare. A2A solves this problem by providing a standardized way for AI agents to communicate regardless of which vendor or platform they were built on.

THE PROBLEM WITH ISOLATED AI AGENTS
Most AI agents today operate independently. As organizations build more specialized AI solutions, every new capability often requires custom integrations between agents. A travel assistant may need to communicate with weather, hotel, calendar, and airline services. Without a standard communication protocol, developers must create individual integrations between every pair of agents. Over time these point-to-point integrations become difficult to maintain, expensive to scale, and highly fragile. Every new agent increases complexity, creating what many developers describe as "integration spaghetti." A2A addresses this challenge by introducing a common communication protocol that allows independent AI agents to cooperate without requiring custom bridges between every service.

WHAT IS AGENT-TO-AGENT (A2A)?
Agent-to-Agent (A2A) is an open communication protocol that enables AI agents to exchange requests, delegate tasks, and return results. A useful analogy is HTTP for websites. Just as web browsers and servers communicate using HTTP, AI agents can communicate using A2A regardless of which platform they run on. The protocol is supported by major technology companies including Microsoft, Google, Cisco, Salesforce, SAP, and others through the Linux Foundation, making it an industry standard rather than a proprietary technology. A2A is built on familiar web technologies including HTTP and JSON-RPC, allowing developers to adopt it using existing networking and API knowledge. A2A VS MCP A2A is frequently compared with the Model Context Protocol (MCP), but the two solve different problems. MCP connects AI agents to tools, APIs, databases, and external systems. A2A connects AI agents directly to other AI agents. Rather than competing technologies, they complement one another. An AI agent may use MCP to retrieve information from a CRM system and then use A2A to delegate another portion of the overall task to a specialist AI agent. This creates both vertical integration with business systems and horizontal collaboration between intelligent agents.

AGENT CARDS
Every A2A-compatible agent publishes an Agent Card. Think of it as a machine-readable business card or résumé describing what an agent can do. The Agent Card contains information such as:

Agent name
Description
Skills
Endpoint URL
Authentication requirements
Supported input formats
Supported output formats

Agent Cards are published using a standard location (/.well-known/agent-card.json), allowing orchestrators to automatically discover specialist agents and understand their capabilities without manual configuration. This decentralized approach removes the need for a central registry while making it easy to introduce new agents into an existing ecosystem.

HOW A2A COMMUNICATION WORKS
Communication between agents takes place using standard HTTP requests carrying JSON-RPC messages. A2A supports three communication models depending on the workload. Instant responses are used for quick synchronous requests such as retrieving today's weather. Streaming responses allow agents to continuously report progress during longer-running operations using Server-Sent Events. Asynchronous tasks support workflows that may take minutes, hours, or even days. Each request receives a task identifier that allows progress tracking while the work continues in the background. Every interaction is represented as a task containing messages, structured content, attachments, or references to external files. Authentication relies on familiar technologies such as OAuth, bearer tokens, or API keys, making integration straightforward for enterprise environments.

THE ORCHESTRATOR-SPECIALIST PATTERN
Most production multi-agent systems follow the Orchestrator-Specialist architecture. The orchestrator receives the user's request, understands the overall objective, and decides which specialist agents should perform each part of the work. Specialist agents focus on a single business capability such as:

Flight booking
Hotel reservations
Weather forecasting
Ticket resolution
HR onboarding
Financial processing

The orchestrator never performs the specialist work itself. Instead, it delegates tasks, waits for responses, and combines the individual results into a single answer for the user. Microsoft Copilot Studio uses this architecture natively, allowing a primary Copilot to coordinate child agents and connected agents through A2A.

REAL-WORLD USE CASES A2A
enables AI systems to collaborate across many business scenarios. A travel planning assistant can delegate weather forecasts, flight searches, and hotel recommendations to independent specialist agents before combining the responses into a complete itinerary. IT support workflows can automatically distribute work between diagnosis agents, remediation agents, and ticket management agents. Employee onboarding can coordinate IT provisioning, HR processes, facilities management, and security access across multiple days using asynchronous task tracking. Organizations are already adopting this model. Microsoft highlights customers using Copilot Studio and Dynamics 365 where orchestrated agents automate complex planning activities that previously required significant manual effort, reducing repetitive work while improving operational efficiency.

MICROSOFT'S A2A ECOSYSTEM
Microsoft has fully embraced A2A across its AI platform. Copilot Studio supports connected A2A agents, allowing developers to integrate agents hosted on Microsoft Azure, Google Cloud, AWS, or other A2A-compatible platforms. Adding a connected agent is straightforward. Developers provide the agent endpoint, Copilot Studio retrieves the Agent Card, understands the agent's capabilities, and automatically creates the necessary integration. Azure AI Foundry Agent Service also exposes A2A endpoints, enabling frameworks such as Semantic Kernel, LangChain, and AutoGen to interact with Azure-hosted agents. This open architecture allows organizations to build multi-agent ecosystems without being locked into a single cloud provider or AI framework.

BENEFITS AND BEST PRACTICES
The greatest strength of A2A is modularity. Organizations can introduce new specialist agents without redesigning existing workflows. Agents become reusable building blocks that can be replaced, upgraded, or expanded independently. When designing multi-agent systems, it is important to:

Keep specialist domains clearly separated
Avoid overlapping responsibilities
Let orchestrators coordinate rather than execute work
Minimize unnecessary delegation layers to reduce latency

Following these principles creates scalable, maintainable AI architectures capable of growing alongside business requirements.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Microsoft Entra External ID - Simply Explained

Mon, 20 Jul 2026 05:00:04 +0000

Building sign-up, sign-in and security for customer-facing apps is hard, and Azure AD B2C is no longer where Microsoft invests. This episode helps identity admins and developers understand Microsoft Entra External ID, pick the right tenant model, secure external users and plan the move away from B2C.

In this episode

00:00 – Intro: why customer identity is hard
00:39 – The old way: identity silos and Azure AD B2C
01:58 – What Entra External ID actually is
03:03 – Three use cases: B2C, B2B and M2M
05:11 – Workforce tenant vs. external tenant
07:34 – Security, MFA and Conditional Access
09:14 – Branding and user experience
10:41 – Migration from B2C and developer experience

Key takeaways

Microsoft Entra External ID is Microsoft's CIAM service for customers, partners and guests and replaces Azure AD B2C, swapping XML custom policies for user flows and custom authentication extensions.
It covers customer sign-up (B2C), partner collaboration (B2B) and machine-to-machine scenarios, and customer-facing apps should usually run in a separate external tenant rather than the workforce tenant.
B2C stays supported until at least 2030 but gets no new features, so new projects should start on External ID and existing B2C tenants should plan a step-by-step migration.

Worth quoting

“Here's the simplest definition. It's a cloud identity service for external users, customers, partners and guests. Not employees.” – Mirko Peters (02:02)

“If you're building a customer facing app with thousands of users, you don't want those customers living in the same directory as your employees. That's a security risk.” – Mirko Peters (05:54)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a migration FAQ
Microsoft Entra – the identity family that External ID belongs to, built for customers instead of employees
Multifactor authentication (MFA) – email and SMS one-time passcodes for customers, plus step-up authentication for sensitive app areas
Conditional Access – risk-based rules such as requiring MFA on medium sign-in risk or blocking certain countries
Related episode: Entra Workload Identities - Simply Explained

Microsoft Graph Connectors - Simply Explained

Mon, 20 Jul 2026 04:00:03 +0000

Copilot cannot answer questions about data that lives in your CRM, ticketing system or wiki unless you connect it. This episode helps Microsoft 365 admins and Copilot owners understand Graph and Copilot connectors, choose between synced and federated models, and keep permissions and compliance intact.

In this episode

00:00 – Intro: Copilot's blind spot outside Microsoft 365
01:03 – The problem: your data is everywhere
02:38 – What is a Graph connector?
03:51 – Two models: synced vs. federated
05:41 – Synced connectors deep dive
07:38 – Federated connectors deep dive
11:21 – Security and compliance
13:09 – Getting started and wrap-up

Key takeaways

Out of the box, Microsoft 365 Copilot only sees Microsoft 365 content; Graph connectors, now called Copilot connectors, bring external systems such as Salesforce, ServiceNow or Confluence into reach.
Synced connectors copy and semantically index data into Microsoft Graph, while federated connectors query the source live through the Model Context Protocol and store nothing in Microsoft 365.
Every connected item needs a correct access control list, and many organizations combine synced connectors for static knowledge with federated connectors for live operational data.

Worth quoting

“A Graph connector is a piece of software that brings external data into the Microsoft Graph. Now, the Microsoft Graph is the same index that powers Microsoft Search, SharePoint Search, and now Copilot.” – Mirko Peters (02:40)

“With a federated connector, no data gets stored in Microsoft 365 at all. When a user asks co-pilot a question, co-pilot sends a request to the external system using the model context protocol or MCP.” – Mirko Peters (07:44)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a connectors FAQ
Copilot connectors – the new name for Graph connectors and the main subject of the episode
Microsoft 365 Copilot – the assistant that cannot see CRM, ticketing or wiki data without connectors
Microsoft Graph – the index that synced connectors feed and that powers Microsoft Search and Copilot
Related episode: Extending Microsoft 365 Copilot: Agents, MCP & Production-Grade AI with Yves Habersaat [MVP]

Azure Advisor - Simply Explained

Mon, 20 Jul 2026 03:00:02 +0000

Many teams treat Azure Advisor as a passive list of suggestions they ignore. This episode is for Azure admins and beginners and explains its five pillars, how the Advisor score is calculated and how to act on high-impact recommendations to cut costs and improve security and reliability.

In this episode

00:00 – What Azure Advisor is
01:14 – How Advisor works and its five pillars
03:00 – Cost optimization
04:18 – Security
04:58 – Reliability
07:21 – Performance
09:12 – Operational excellence
11:02 – The Advisor score and getting started

Key takeaways

Azure Advisor is free and built into the Azure portal; it compares your resources against the Azure Well-Architected Framework and gives personalized recommendations across cost, security, reliability, performance and operational excellence.
Recommendations carry high, medium or low impact, and the Advisor score from 0 to 100% shows per pillar where your environment falls short so you can tackle the lowest score and high-impact items first.
Pairing Advisor with Azure Policy and a regular weekly or monthly review cadence turns one-time fixes into ongoing compliance.

Worth quoting

“Azure Advisor is a free, built-in cloud consultant that analyzes your entire Azure environment. It doesn't just sit there. It actively scans your resources and compares them against Microsoft's best practices.” – Mirko Peters (00:33)

“A backup you've never restored isn't a backup. It's a hope. Advisor will remind you to test your restore process regularly.” – Mirko Peters (06:43)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an Azure Advisor FAQ
Microsoft Azure – the cloud environment Azure Advisor scans against the Azure Well-Architected Framework
Multifactor authentication (MFA) – named the most common high-priority security recommendation for privileged accounts in Advisor
Azure App Service – gets a reliability recommendation to run at least two instances for production workloads
Azure Traffic Manager – recommended with Azure Front Door to route users to the closest or fastest endpoint
Related episode: Building Azure That Survives the Real World — with Mike Martin [MVP]

Azure Cost Management - Simply Explained

Mon, 20 Jul 2026 02:00:02 +0000

Surprise Azure bills are rarely technical failures; they happen because nobody is watching idle VMs, orphaned disks and forgotten environments. This episode is for admins, developers and finance teams new to Azure, and walks through cost analysis, tags, budgets, alerts and discount options so you can set up your first budget and alert in minutes.

In this episode

00:00 – Cloud bill horror stories
02:16 – Why cost management is non-negotiable
03:59 – What Azure Cost Management actually is
05:41 – Billing hierarchy, resource hierarchy and tags
07:57 – Cost analysis: your financial dashboard
09:39 – Budgets and alerts: your early warning system
11:56 – Saving money without sacrificing performance
15:20 – Building a cost-conscious culture

Key takeaways

Azure Cost Management is a built-in Microsoft Azure service included with every subscription and lets you monitor, analyze, control and optimize cloud spending, with cost data refreshed roughly every four hours.
Tagging resources by project, environment, cost center and owner, enforced with Azure Policy, bridges the billing and resource hierarchies so every charge can be traced to a team.
Budgets with alerts at several thresholds, plus reservations, savings plans, Azure Hybrid Benefit, auto-shutdown, right-sizing and spot instances, prevent surprise bills without sacrificing performance.

Worth quoting

“These aren't technical failures, they're visibility failures. The cloud was working exactly as designed, but nobody was watching.” – Mirko Peters (02:27)

“Cost management isn't optional. It's not something you think about after you get a big bill. It's a must have practice from day one, whether you're a solo developer with a free trial or a company spending millions on Azure.” – Mirko Peters (04:11)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a cost management FAQ
Microsoft Azure – the cloud platform whose bills, hierarchies, budgets and discount options the whole episode explains
FinOps – cited for orphaned-resource waste and as the next step when native cost tools feel limited
Related episode: FinOps - Simply Explained
Related episode: FinOps for Manufacturing IT: Controlling Cloud Cost for Industrial Workloads

Azure Automation - Simply Explained

Mon, 20 Jul 2026 01:00:02 +0000

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're exploring Azure Automation, Microsoft's cloud service for automating repetitive IT tasks across Azure and hybrid environments. Whether you're starting and stopping virtual machines, running maintenance scripts, applying configurations, or responding automatically to alerts, Azure Automation helps eliminate manual work while improving consistency and reducing operational costs. You'll learn how Automation Accounts, Runbooks, Schedules, Hybrid Runbook Workers, Desired State Configuration, Managed Identities, and shared resources all work together to build reliable cloud automation that runs 24/7 without human intervention.

WHY AZURE AUTOMATION MATTERS
Every IT administrator performs repetitive tasks that consume valuable time. Starting and stopping virtual machines, patching servers, cleaning up resources, rotating logs, or running maintenance scripts may seem simple individually, but become overwhelming as environments grow. Manual administration also introduces inconsistency and human error. One forgotten patch, one incorrectly configured server, or one missed maintenance task can quickly lead to operational issues. Azure Automation centralizes these recurring activities inside an Automation Account, allowing organizations to automate repetitive operational tasks, schedule maintenance windows, react to monitoring alerts, and execute scripts consistently across hundreds or even thousands of systems without manual intervention.

RUNBOOKS AND AUTOMATION ACCOUNTS
The heart of Azure Automation is the Runbook. A Runbook is simply a PowerShell or Python script stored inside an Automation Account. Once written and tested, Azure executes the same sequence of actions repeatedly without requiring user interaction. Runbooks can perform almost any administrative task, including:

Starting and stopping Azure Virtual Machines
Managing storage accounts
Executing database maintenance
Sending notifications
Calling REST APIs
Managing Azure resources
Automating cloud governance

Automation Accounts act as the central repository for runbooks, schedules, variables, credentials, certificates, and connections, making automation easier to organize, maintain, and secure across an entire Azure environment.

SCHEDULES, TRIGGERS, AND WEBHOOKS
Automation becomes valuable when runbooks execute without manual intervention. Azure Automation supports several trigger mechanisms. Schedules allow runbooks to execute once, daily, weekly, monthly, or according to custom recurrence patterns. Azure Monitor Alerts can trigger runbooks automatically whenever monitoring detects issues such as high CPU utilization, low disk space, or service failures. Webhooks expose secure URLs that external applications, Logic Apps, DevOps pipelines, or third-party systems can call to launch automation workflows instantly. Because schedules are reusable, a single schedule can trigger multiple runbooks simultaneously, making it easy to automate recurring operational tasks across multiple Azure resources.

HYBRID RUNBOOK WORKERS AND STATE CONFIGURATION
Azure Automation isn't limited to Azure resources. Hybrid Runbook Workers extend automation to on-premises servers, private datacenters, and other non-Azure environments. Instead of executing inside Azure's managed sandbox, runbooks execute locally on Hybrid Workers, providing direct access to internal networks, Active Directory, local databases, file shares, and legacy applications. For configuration management, Azure Automation includes Desired State Configuration (DSC), allowing administrators to define the desired configuration for servers and automatically detect or remediate configuration drift. As Microsoft evolves this capability, Azure Machine Configuration continues expanding these compliance and configuration management features while integrating more closely with Azure Policy.

SHARED RESOURCES AND MANAGED IDENTITIES
Automation workflows often require credentials, configuration values, certificates, or API connections. Azure Automation securely stores these shared resources centrally rather than embedding sensitive information directly inside scripts. Variables, encrypted credentials, certificates, and connection assets can all be reused across multiple runbooks while simplifying maintenance and improving security. Authentication is further simplified through Managed Identities. Instead of storing passwords or service principal secrets, Automation Accounts receive Azure-managed identities that authenticate securely to Azure resources. Azure automatically manages credential rotation, reducing administrative effort while following security best practices. Combined with Azure Role-Based Access Control (RBAC), Managed Identities provide secure, passwordless authentication for automation workloads.

REAL-WORLD AUTOMATION SCENARIOS
Azure Automation is commonly used to reduce operational costs and eliminate repetitive administration. Typical automation scenarios include:

Automatically starting development VMs every morning
Shutting down non-production environments after business hours
Applying scheduled maintenance
Cleaning temporary files
Rotating logs
Running compliance checks
Restarting failed services
Executing patch management tasks
Responding automatically to Azure Monitor alerts
Managing hybrid infrastructure across Azure and on-premises environments

A simple example involves automatically starting development virtual machines at 6 AM and shutting them down at 7 PM every weekday. Using Automation Accounts, Runbooks, Schedules, and Managed Identities, this entire process operates without human intervention while significantly reducing Azure compute costs.

KEY TAKEAWAYS
Azure Automation transforms repetitive operational tasks into reliable, repeatable workflows that execute automatically in the cloud or across hybrid environments. By combining Runbooks, Automation Accounts, Schedules, Hybrid Runbook Workers, Desired State Configuration, Shared Resources, and Managed Identities, organizations can improve operational consistency, strengthen security, reduce administrative effort, and significantly lower infrastructure costs. Whether you're managing a handful of virtual machines or an enterprise-scale Azure environment, Azure Automation provides the foundation for building reliable, scalable, and secure cloud operations.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure Managed Disks - Simply Explained

Mon, 20 Jul 2026 00:00:02 +0000

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're exploring Azure Managed Disks, the storage technology that powers every Azure Virtual Machine. While many people simply attach a disk to a VM and move on, choosing the wrong managed disk can lead to unnecessary costs, poor performance, or both. You'll learn what Azure Managed Disks actually are, how they simplify storage management compared to the old unmanaged disk model, the five available disk types, redundancy options, encryption, snapshots, backups, and practical tips for selecting the right disk for every workload.

WHAT ARE AZURE MANAGED DISKS?
Azure Managed Disks are fully managed block storage volumes that Azure automatically provisions, maintains, replicates, and monitors for your virtual machines. Before managed disks were introduced, administrators had to manually create storage accounts, manage page blobs, monitor storage limits, and carefully distribute disks across multiple storage accounts to avoid performance bottlenecks. Managed Disks eliminate all of this complexity. You simply choose the disk size and performance tier while Azure handles storage accounts, replication, availability, durability, and scaling behind the scenes. By abstracting the storage infrastructure, Azure allows administrators to focus on applications instead of storage management while improving reliability, scalability, and operational simplicity. Managed Disks also automatically distribute storage across storage scale units, reducing the impact of hardware failures and increasing overall VM availability.

UNDERSTANDING THE FIVE MANAGED DISK TYPES
Azure offers five managed disk options designed for different performance and pricing requirements. Ultra Disk delivers Azure's highest storage performance with extremely low latency, configurable IOPS, and throughput for mission-critical workloads like SAP HANA, enterprise databases, and high-performance analytics. Premium SSD v2 provides enterprise-level performance while allowing storage capacity, IOPS, and throughput to be configured independently. This flexibility makes it one of the most cost-efficient options for modern production environments. Premium SSD remains a popular choice for predictable production workloads where performance scales with disk size. It delivers reliable low latency for business-critical applications and virtual desktops. Standard SSD balances affordability with SSD performance, making it ideal for development, testing, web servers, and moderate production workloads. Standard HDD offers the lowest storage cost and is best suited for backup data, archives, logs, and workloads where storage capacity matters more than speed.

HOW DISK PERFORMANCE WORKS
Azure Managed Disks are measured using three important performance characteristics. IOPS (Input/Output Operations Per Second) measures how many read and write operations a disk can perform every second and is particularly important for databases and transactional applications. Throughput measures how much data can be transferred every second, making it critical for file transfers, analytics, and media workloads. Latency measures how quickly data begins transferring after a request. Lower latency results in faster application response times and better user experiences. Premium SSD v2 and Ultra Disk allow administrators to configure IOPS and throughput independently from storage capacity, giving far greater flexibility than traditional disk sizing models. However, it's equally important to remember that Virtual Machines themselves also have storage performance limits, so disk performance should always be matched with the VM's capabilities.

REDUNDANCY, SECURITY, AND DISK TYPES
Azure protects managed disks using multiple redundancy models. Locally Redundant Storage (LRS) maintains three synchronized copies of your data inside a single datacenter, providing exceptional durability against hardware failures. Zone-Redundant Storage (ZRS) extends protection across multiple availability zones within the same Azure region, ensuring workloads remain available even if an entire datacenter experiences an outage. Within every virtual machine, Azure supports three different disk roles. The Operating System Disk contains Windows or Linux and is required for the VM to boot. Data Disks provide persistent storage for applications, databases, and business data, with multiple disks supported depending on VM size. The Temporary Disk offers extremely fast local storage but should never be used for important information because all data is lost whenever the VM is redeployed or moved to another host. Azure also supports Ephemeral OS Disks, enabling extremely fast VM deployments for stateless workloads such as Kubernetes clusters and virtual machine scale sets.

ENCRYPTION, SNAPSHOTS, AND BACKUPS
Security is built directly into Azure Managed Disks. All managed disks are automatically encrypted at rest using platform-managed encryption keys. Organizations requiring greater control can implement customer-managed keys through Azure Key Vault, while Encryption at Host provides an additional security layer protecting temporary disks and cached data. Snapshots create point-in-time copies of managed disks and are perfect for software updates, testing, and quick rollback scenarios. Azure Backup builds on snapshots by automating backup schedules, retention policies, Recovery Services Vault integration, and long-term disaster recovery. Together, these capabilities allow organizations to recover quickly from failures while meeting security, compliance, and business continuity requirements.

COST OPTIMIZATION BEST PRACTICES
One of the most common mistakes in Azure is paying for oversized managed disks. Azure charges based on the provisioned disk size, not the amount of storage actually used. Choosing appropriately sized disks, deleting unattached disks, selecting the correct redundancy option, and using Premium SSD v2 instead of Ultra Disk whenever possible can significantly reduce monthly cloud costs. Standard HDD remains an excellent option for backups and archive workloads, while monitoring Azure Cost Management helps identify unused storage resources and optimization opportunities before costs increase unnecessarily.

KEY TAKEAWAYS
Azure Managed Disks simplify storage management by removing the complexity of storage accounts while delivering enterprise-grade availability, security, and scalability. Understanding the differences between Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD, and Standard HDD allows you to optimize both application performance and infrastructure costs. Selecting the right disk type, redundancy model, backup strategy, and encryption options ensures your Azure Virtual Machines remain secure, resilient, and cost-efficient as your cloud environment continues to grow.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure Disk Storage - Simply Explained

Sun, 19 Jul 2026 23:00:02 +0000

Every Azure VM needs disk storage, and the wrong tier means either overpaying or slow performance. This episode explains Standard SSD, Premium SSD, Premium SSD v2 and Ultra Disk for Azure beginners and admins, with a simple decision guide and cost tips.

In this episode

00:00 – Intro: the virtual hard drive for VMs
00:23 – Why disk type matters
01:19 – OS disks vs data disks
02:19 – Standard SSD
03:22 – Premium SSD
04:35 – Premium SSD v2
06:34 – Ultra Disk
08:22 – Choosing the right disk

Key takeaways

IOPS, throughput and latency determine disk performance, and the goal is to match them to the workload without over- or under-provisioning.
Premium SSD v2 decouples capacity, IOPS and throughput and covers most production databases at a lower price than Ultra Disk.
Ultra Disk is reserved for extreme workloads such as SAP HANA or trading platforms, while Standard SSD is enough for dev/test and low-traffic servers.

Worth quoting

“The trick is matching the disk to what your workload actually needs, so you're not over-provisioning and wasting cash, nor under-provisioning and getting slow performance.” – Mirko Peters (01:06)

“With premium SSD V2, you can independently adjust capacity, IOPS and throughput. No downtime, no disk swaps, just change the settings and it happens.” – Mirko Peters (04:45)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure disk types
Azure Disk Storage – the episode's subject: the four disk tiers for Azure VMs and how to choose
Microsoft Azure – the platform where every VM gets an OS disk and optional data disks
Related episode: Azure Managed Disks - Simply Explained
Related episode: Azure Elastic SAN — Simply Explained
Related episode: Azure Availability Zones - Simply Explained

Azure Blob Storage - Simply Explained

Sun, 19 Jul 2026 22:00:03 +0000

Azure Blob Storage is probably the cloud storage service you use most without knowing it. This episode explains the account-container-blob hierarchy, blob types, access tiers, lifecycle rules, security and redundancy for Azure beginners, so they can store unstructured data safely and cheaply.

In this episode

00:00 – Intro: what Blob Storage is for
00:57 – What is Blob Storage?
02:47 – Storage account, container, blob
04:40 – Block, append and page blobs
06:22 – Hot, cool, cold and archive tiers
08:39 – Lifecycle management
10:49 – Security and access control
13:41 – Redundancy and real-world use cases

Key takeaways

Blob Storage is flat object storage for unstructured data, organized as storage account, container and blob.
Block, append and page blobs serve files, logs and VM disks, while hot, cool, cold and archive tiers trade storage cost against access cost, automated by lifecycle management rules.
Prefer Microsoft Entra ID with Azure RBAC over account keys and SAS tokens, and choose LRS, ZRS or GZRS based on how critical the data is.

Worth quoting

“Unstructured data is anything that doesn't fit neatly into rows and columns. A photo of your dog, a product demo video, a web server, log file, a database backup, a PDF contract.” – Mirko Peters (01:07)

“If it's a file someone uploads or downloads, use a block blob. If it's a continuous stream of log entries or sensor readings, use an append blob. If it's a virtual machine disk, use a page blob” – Mirko Peters (06:10)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure Blob Storage
Microsoft Azure – the cloud platform whose Blob Storage service this episode explains from the ground up
Microsoft Entra ID – recommended with Azure RBAC as the preferred alternative to account keys and SAS tokens
Compliance – drives tier choices like cold and archive, immutable WORM storage and customer-managed keys
Azure Private Link – private endpoints give the storage account a private IP inside your virtual network
Related episode: Azure Kubernetes Service (AKS) - Simply Explained

Scaling CI-CD: The Governance Blueprint

Sun, 19 Jul 2026 17:30:02 +0000

modern platform governance works differently. Rather than enforcing compliance through documentation and manual reviews, governance is embedded directly into templates. These templates automatically include:

Security scanning
Dependency validation
Approval gates
Secrets management
Naming standards
Audit logging

Because these controls are built into the platform itself, development teams don't need to remember every policy. The safest path also becomes the easiest path.

GOLDEN PATHS
A major concept introduced in this episode is the Golden Path. Instead of giving developers blank pipeline templates, organizations provide opinionated deployment paths that already include best practices. Golden Paths define standard approaches for:

Building applications
Running automated tests
Performing security validation
Deploying through environments
Rolling back failed releases

Most services can successfully use only a small number of Golden Path templates, while exceptional workloads extend rather than replace the standard model. This dramatically reduces onboarding time and ensures consistency across engineering teams.

RING-BASED DEPLOYMENTS
Safe deployment at scale requires limiting the blast radius of every release. The episode introduces Microsoft's Ring Deployment model. Instead of deploying directly to every user, releases move progressively through increasingly larger audiences. Typical deployment rings include:

Ring 0 – Internal engineering teams
Ring 1 – Pilot users
Ring 2 – Broad production

Each promotion depends on predefined success criteria including deployment success, latency, error rates, business metrics, and overall system health. Only after a ring meets its objectives does the deployment continue to the next stage.

CANARY RELEASES
While ring deployments target groups of users, Canary Releases gradually increase traffic to a new application version. Instead of exposing everyone immediately, perhaps only 1% of requests use the new version. Observability platforms continuously compare:

Error rates
Response times
Business KPIs
User behavior

If performance remains healthy, traffic gradually increases. If problems appear, traffic immediately returns to the stable version. This minimizes deployment risk while providing real production feedback before a full rollout.

OBSERVABILITY AND AUTOMATED PROMOTION
Deployment governance depends on reliable measurement. Observability provides:

Distributed tracing
Centralized logging
Performance metrics
Health dashboards

These measurements feed automated promotion gates that determine whether deployments satisfy predefined quality thresholds. Instead of requiring manual approval for every promotion, policies evaluate real production metrics and automatically decide whether deployments may continue through the release pipeline. This dramatically reduces deployment latency while maintaining high confidence in production quality.

PLATFORM AS A PRODUCT
One of the strongest messages throughout the episode is that internal platforms should be treated like products. Platform teams should measure:

Developer satisfaction
Adoption rates
Time to first deployment
Self-service success
Golden Path usage

If engineering teams actively choose the platform because it simplifies their work, governance becomes nearly invisible. The platform succeeds not because people are forced to use it, but because it removes friction from software delivery.

IMPLEMENTING THE BLUEPRINT
Successful platform transformations happen gradually. Organizations typically begin by identifying the largest deployment pain point before introducing a single Golden Path and a small platform team. As adoption grows, reusable templates, automated governance, observability, ring deployments, and policy-driven promotion gradually become the standard operating model. Leadership support is critical because platform engineering requires cultural change as much as technical implementation. Teams move from owning individual pipelines to participating in a shared delivery ecosystem that improves reliability, security, and developer productivity.

KEY TAKEAWAYS
Scaling CI/CD isn't about choosing a better pipeline tool. It's about designing a repeatable operating model. Organizations that standardize deployment through reusable templates, Golden Paths, platform governance, ring-based deployments, automated promotion gates, and strong observability can dramatically reduce cognitive load, improve developer productivity, lower operational costs, and strengthen security. The most successful platform teams don't build infrastructure that developers are forced to use—they build products that developers genuinely want to use. By making governance invisible, embedding best practices into templates, and continuously improving the developer experience, organizations create delivery platforms that scale from a handful of teams to hundreds without sacrificing speed, quality, or compliance.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

The Monorepo Myth: Why Your Architecture Is Fragmented

Sun, 19 Jul 2026 12:35:02 +0000

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're tackling one of the biggest misconceptions in software architecture: the Monorepo Myth. For years, engineering teams have debated whether a monorepo or a multirepo is the "correct" repository strategy. Discussions usually focus on Git performance, build speed, repository size, or tooling. But these technical arguments miss the real issue. Your repository strategy isn't primarily a Git decision—it's an organizational decision. The structure of your repositories shapes how teams collaborate, communicate, make decisions, and ultimately how quickly your organization can deliver software.

THE BIGGEST MISCONCEPTION
Most organizations evaluate repository strategies using technical criteria. Questions like:

Can Git handle millions of files?
How fast are clone operations?
How quickly does CI complete?
Which strategy scales better?

These are valid engineering concerns, but they aren't the questions that determine long-term success. The real question is: Where does your organization pay its coordination cost? A repository strategy doesn't eliminate coordination—it simply determines where that coordination happens. Whether you choose a monorepo or a multirepo, your teams still need to collaborate. The only difference is how visible that collaboration becomes.

UNDERSTANDING MONOREPOS
A monorepo stores multiple applications, services, libraries, infrastructure code, and shared components inside a single repository. This creates several important advantages:

Shared tooling
Consistent standards
Easier large-scale refactoring
Unified dependency management
Atomic cross-project changes
Complete visibility across the entire system

When teams are closely aligned, a monorepo enables rapid cross-cutting changes because everything lives together under one build system and one source of truth. However, as organizations grow, coordination becomes increasingly centralized. Shared libraries require approval from multiple teams, dependency updates affect everyone simultaneously, and build systems become more complex as additional teams join the repository. The technical challenges often blamed on monorepos are actually symptoms of growing organizational complexity rather than limitations of Git itself.

THE HIDDEN COST OF MONOREPOS
Large monorepos rarely fail because of technology. Git itself can manage repositories containing millions of files. Companies like Google successfully operate enormous monorepos. Instead, organizations encounter problems such as:

Slow code reviews
Long build pipelines
Complex branching strategies
Frozen dependencies
Endless coordination meetings
Difficult release planning

These issues arise because every significant architectural decision requires agreement across more teams. As organizations grow, the repository doesn't become technically unmanageable—it becomes organizationally expensive. The true scaling challenge is coordination, not source control.

HOW MULTIREPOS WORK
A multirepo architecture separates services, products, or components into independent repositories. Each team owns its own repository, deployment pipeline, testing strategy, and release schedule. The benefits include:

Independent deployments
Clear ownership
Team autonomy
Smaller repositories
Faster local builds
Flexible release cycles

However, the coordination burden doesn't disappear. Instead of coordinating through code reviews and shared repositories, teams coordinate through:

APIs
Versioning
Release notes
Contracts
Documentation
Governance processes

The coordination simply moves from code into communication between teams.

ORGANIZATIONAL DEBT
One of the most valuable ideas discussed in this episode is organizational debt. Unlike technical debt, organizational debt doesn't exist in the codebase. It appears as:

Unclear ownership
Slow approvals
Excessive meetings
Complicated release processes
Duplicate workflows
Ambiguous decision-making

These problems accumulate over time and become the real bottleneck for software delivery. Many organizations attempt to solve organizational debt by changing repository strategies. In reality, neither monorepos nor multirepos solve these problems—they simply expose them differently.

CONWAY'S LAW
A key concept behind repository design is Conway's Law. It states that software systems naturally mirror the communication structure of the organizations that build them. If teams are divided into silos, the architecture will eventually become siloed as well. Changing repository layouts cannot fix poor communication. Likewise, organizations with highly collaborative teams can successfully operate either monorepos or multirepos because the underlying communication patterns already support effective collaboration. Your repository structure is often a reflection of your organizational structure rather than its cause.

THE COMMUNICATION ARCHITECTURE MODEL
Rather than thinking about repositories as storage mechanisms, it is more useful to think of them as communication architectures. A monorepo encourages:

Shared visibility
Continuous collaboration
Immediate feedback
Centralized coordination

A multirepo encourages:

Clear contracts
Independent ownership
Explicit APIs
Autonomous deployments

Neither model is inherently superior. The best choice depends on how your teams naturally communicate and collaborate. Repository strategy should reflect your communication model—not dictate it.

AI IS CHANGING THE EQUATION
The rapid adoption of AI-assisted development introduces a new challenge. AI coding assistants dramatically increase software output. Developers can generate significantly more code than before, but code review and verification have not accelerated at the same pace. This creates what can be described as a verification tax. Organizations capable of generating code twice as fast often find that reviews, architectural validation, testing, and integration become the new bottlenecks. AI doesn't eliminate organizational fragmentation—it amplifies it by increasing the volume of work flowing through existing coordination processes.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Microsoft Graph Data Connect - Simply Explained

Sun, 19 Jul 2026 05:08:56 +0000

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're exploring Microsoft Graph Data Connect, Microsoft's enterprise-scale solution for extracting large volumes of Microsoft 365 data into Azure or Microsoft Fabric for analytics, reporting, machine learning, security investigations, and governance. While the regular Microsoft Graph API works well for real-time requests and smaller datasets, it becomes difficult to manage when organizations need to extract millions of records across SharePoint, Teams, Exchange, OneDrive, and other Microsoft 365 services. Graph Data Connect solves that scale problem through scheduled bulk data pipelines that avoid traditional API pagination and throttling.

WHY MICROSOFT 365 DATA IS DIFFICULT TO EXTRACT
Microsoft 365 generates enormous volumes of business activity every day. Emails, Teams messages, meetings, files, site activity, user interactions, and collaboration signals continuously accumulate across the tenant. The Microsoft Graph API provides access to this information through individual requests. This works well when an application needs a limited number of records in real time. However, large-scale analytics projects quickly encounter pagination, rate limits, HTTP 429 throttling responses, retry logic, and long processing times. Trying to analyze every SharePoint site, mailbox, or Teams interaction across a large organization using traditional API calls can take hours or days. Graph Data Connect was designed specifically for these scenarios, allowing organizations to extract Microsoft 365 datasets in bulk rather than requesting records individually.

WHAT IS MICROSOFT GRAPH DATA CONNECT?
Microsoft Graph Data Connect is a secure bulk data extraction service for Microsoft 365. It allows organizations to define a dataset, select a destination, and run a scheduled pipeline that transfers large volumes of Microsoft 365 data directly into an analytics environment. The extracted data can include information from services such as:

Microsoft Teams
SharePoint Online
OneDrive
Exchange Online
Microsoft 365 Groups
User and collaboration activity

The data is delivered in analytics-friendly formats such as Delta Parquet, making it ready for SQL queries, Power BI reports, machine learning models, and large-scale processing inside Microsoft Fabric or Azure. Graph Data Connect is not a replacement for the Microsoft Graph API. The Graph API is designed for real-time application requests, while Data Connect is optimized for scheduled bulk extraction across an entire Microsoft 365 tenant.

GRAPH API, GRAPH CONNECTORS, AND DATA CONNECT
These three Microsoft Graph technologies solve very different problems. The Microsoft Graph API retrieves Microsoft 365 information through real-time request-and-response calls. It is ideal for applications that need current information about individual users, messages, files, or calendar events. Microsoft Graph Connectors bring external information into Microsoft 365 so it can appear in Microsoft Search and Copilot. Their purpose is ingestion and indexing. Microsoft Graph Data Connect moves Microsoft 365 data out of the tenant and into an external analytics environment. Its purpose is large-scale extraction. A simple way to remember the difference is:

Graph API: request individual Microsoft 365 records
Graph Connectors: bring external data into Microsoft 365
Graph Data Connect: export Microsoft 365 data for analytics

Understanding this distinction helps organizations select the correct tool instead of forcing a real-time API or automation platform to perform bulk analytics workloads.

SECURITY, PRIVACY, AND GOVERNANCE
Because Graph Data Connect can process sensitive organizational information, its security model includes strict governance controls. Every application requires explicit administrator approval before it can access Microsoft 365 datasets. Administrators can control which datasets and properties are available, ensuring that applications receive only the information required for the approved business scenario. Data is encrypted during transfer, and organizations can use customer-managed encryption keys through Azure Key Vault for additional control. Identity obfuscation can replace personal identifiers with non-reversible tokens, allowing organizations to analyze collaboration patterns and behavioral trends without directly exposing individual identities. Every extraction is logged, creating an audit trail showing which application accessed the data, who approved it, which datasets were transferred, and when the pipeline ran. These controls make Graph Data Connect suitable for regulated industries and privacy-sensitive analytics scenarios.

WHERE THE DATA CAN GO
Graph Data Connect integrates with modern Azure and Microsoft analytics platforms. Organizations can deliver extracted data into:

Microsoft Fabric Lakehouses
Azure Data Lake Storage
Azure Blob Storage
Azure Synapse Analytics
Azure Data Factory pipelines
Custom analytics platforms through additional processing pipelines

Microsoft Fabric provides one of the most accessible destinations because the extracted data arrives in Delta Parquet format and can immediately be analyzed using SQL, notebooks, Power BI, or machine learning tools. Once the data has been extracted, it can also be combined with information from CRM, ERP, HR, security, and operational systems to create a broader view of organizational performance.

REAL-WORLD USE CASES
Microsoft Graph Data Connect supports a wide range of enterprise analytics scenarios. Security analytics can detect unusual account behavior, suspicious file activity, abnormal downloads, or unexpected access patterns. Collaboration analytics can examine how teams communicate, which departments work together, and where organizational bottlenecks exist. Content governance can identify stale SharePoint files, duplicate documents, abandoned sites, excessive permissions, and sensitive information. Employee experience analytics can combine Microsoft 365 collaboration signals with HR information while protecting individual identities. Copilot readiness assessments can help organizations understand where information is stored, how permissions are configured, and whether sensitive content could be exposed before deploying Microsoft 365 Copilot. These use cases require large datasets that would be difficult or impractical to retrieve through standard Graph API requests.

HOW TO SET UP GRAPH DATA CONNECT
A typical Graph Data Connect implementation involves several steps. First, Graph Data Connect must be enabled in the Microsoft 365 Admin Center. Administrators then select which datasets should be available. Next, an application registration is created in Microsoft Entra ID to provide the extraction pipeline with a secure identity. A Graph Data Connect application is then configured and linked to the app registration. Administrators select the approved datasets, properties, and destination. The application must pass an explicit Microsoft 365 administrator approval process before it can access organizational information. Finally, a data pipeline is created in Microsoft Fabric or Azure Data Factory. The pipeline selects the Microsoft 365 dataset, applies filters, defines the destination, and schedules the extraction. Once the preparation stage is complete, the data is delivered in structured files that can be analyzed using Power BI, SQL, notebooks, or machine learning tools.

LIMITATIONS AND CONSIDERATIONS
Graph Data Connect is designed for scheduled analytics rather than real-time applications. Pipeline runs include preparation time before data begins transferring, which means the service is better suited to nightly, weekly, or periodic analytics jobs than live dashboards. Not every Microsoft 365 property is available through every dataset, so organizations should confirm dataset coverage before designing a solution. Each application requires administrative approval, and changes to requested datasets or properties may require additional consent. Graph Data Connect also uses consumption-based pricing, meaning larger tenants and broader datasets can generate substantial processing costs. Testing with a limited dataset before scaling to the entire tenant is therefore recommended. The platform also requires knowledge of data pipelines, storage formats, identity management, and governance. It is intended primarily for data engineering and enterprise analytics teams rather than simple citizen-development workflows.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure Storage Accounts - Simply Explained

Sat, 18 Jul 2026 06:00:03 +0000

Azure Storage accounts are everywhere, yet few people can explain what is actually inside them. This episode walks Azure beginners and IT pros through Blob, Files, Queue and Table storage with everyday analogies. You will know which storage type fits which problem and how to choose performance tiers and redundancy.

In this episode

00:00 – Intro
00:26 – What is a storage account?
02:15 – Blob storage
04:21 – Azure Files
06:12 – Queue storage
08:02 – Table storage
09:40 – How it all connects
11:36 – Actionable takeaways

Key takeaways

An Azure Storage account is one container that holds four services: Blob for unstructured files, Files for network shares, Queue for messages and Table for simple structured data.
Choose Standard performance for most workloads and pick redundancy (LRS, ZRS, GRS) based on how much downtime and data loss you can tolerate.
The services are designed to work together under one account with shared billing, security, encryption and networking, so you can start small and add services later.

Worth quoting

“An Azure Storage Account is a container. That's all. A container that holds all your Azure Storage services together.” – Mirko Peters (00:30)

“Once you create a storage account, you can use any or all of the four storage services inside it. You're not locked into one.” – Mirko Peters (01:54)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure Storage accounts
Azure Files – the storage account's managed cloud file share, with SMB, NFS and Azure File Sync
Microsoft Azure – the platform where storage accounts live in a chosen region and resource group
Azure Service Bus – mentioned as the more advanced alternative to Queue storage, with sessions, transactions and FIFO ordering
Azure Cosmos DB – the premium NoSQL database that Table storage undercuts on cost for simple key-value lookups
Related episode: Azure Files - Simply Explained

Azure DDoS Protection - Simply Explained

Sat, 18 Jul 2026 05:00:03 +0000

Many small businesses assume Azure's built-in defenses keep their websites and APIs safe from DDoS attacks, yet moderate attacks can still take a single workload offline. This episode explains in plain English what DDoS attacks are, what the free tier covers, how Azure DDoS Protection and WAF fill the gaps, and how to build a practical layered defense.

In this episode

00:00 – Why DDoS attacks matter for anyone online
00:58 – What a DDoS attack actually is
02:56 – The free infrastructure protection
04:44 – Network Protection vs. IP Protection
07:04 – Layer 7 attacks and where WAF fits
10:31 – The largest DDoS attack Azure has handled
11:47 – Why small businesses need to care
14:00 – A layered DDoS defense strategy

Key takeaways

Every Azure customer gets free infrastructure-level DDoS protection, but it protects Azure's platform and may not mitigate moderate attacks against your specific workload.
Azure DDoS Protection comes as Network Protection, with rapid response support, cost protection and a WAF discount, or as the cheaper per-IP IP Protection, both adding adaptive tuning, metrics and logging.
Because DDoS protection only covers layers 3 and 4, a Web Application Firewall with the HTTP DDoS rule set, rate limiting and bot protection is needed to stop layer 7 attacks.

Worth quoting

“If a moderate attack hits your specific application, the free tier might not step in. From Azure's perspective, the traffic isn't enough to threaten the platform, so it doesn't trigger any mitigation.” – Mirko Peters (04:16)

“Azure DDoS protection only covers layers 3 and 4, the network and transport layers. It looks at IP addresses, ports, protocols and packet rates, but it never inspects the actual content of your HTTP requests.” – Mirko Peters (07:08)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ on DDoS defense
Microsoft Azure – the platform whose free and paid DDoS defenses and WAF options the episode compares
Mirko Peters – hosts this Knowledge Nuggets episode and explains DDoS attacks, Azure's protection tiers and WAF
Related episode: Building Azure That Survives the Real World — with Mike Martin [MVP]
Related episode: Azure Bicep - Simply Explained

Azure Network Security Groups - Simply Explained

Sat, 18 Jul 2026 04:00:02 +0000

Most Azure security incidents start with an overly permissive rule, not a sophisticated exploit. This episode is for Azure beginners and administrators who deploy virtual machines and subnets. You learn how NSG rules, priorities, service tags and application security groups work and which mistakes leave your environment wide open.

In this episode

00:00 – Why an Azure VM without an NSG is an unlocked door
01:55 – What a network security group is
04:09 – How NSG rules work: priority and defaults
06:39 – Common misconfigurations
08:47 – Best practices for NSG rules
10:25 – NSG vs Azure Firewall
12:14 – Walkthrough: creating and applying an NSG

Key takeaways

A network security group filters traffic at layers three and four by source, destination, port and protocol, and it is stateful, free and the first line of defense in Azure.
Rules are evaluated by priority with the first match winning, so leave gaps between priorities, attach one NSG per subnet and check effective security rules when troubleshooting.
Avoid opening sensitive ports to the internet, use application security groups and service tags instead of hard-coded IPs, and add Azure Firewall when you need centralized deep inspection.

Worth quoting

“It works at layers three and four of the network model, which means it looks at IP addresses, ports and protocols without digging into the actual content of the traffic.” – Mirko Peters (02:19)

“NSGs are stateful. What does that mean? If you allow inbound traffic on port 80, the reply traffic goes back out automatically.” – Mirko Peters (02:57)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ on NSG rules
Microsoft Azure – the platform whose VMs and subnets NSGs protect, compared here with Azure Firewall
Mirko Peters – hosts this Knowledge Nuggets episode and walks through NSG rules, mistakes and a portal setup
Related episode: Building Azure That Survives the Real World — with Mike Martin [MVP]
Related episode: Azure Bicep - Simply Explained

Azure Virtual Network - Simply Explained

Sat, 18 Jul 2026 03:00:02 +0000

Many Azure deployments run into trouble because the virtual network underneath was treated as a checkbox. This episode is for cloud beginners, administrators and architects who deploy workloads in Azure. You learn how address spaces, subnets, IPs, NSGs, routing and peering fit together so your network is secure and ready to grow.

In this episode

00:00 – What an Azure Virtual Network is
02:09 – IP addressing and CIDR
04:31 – Subnets: dividing your network
07:02 – Public and private IPs
08:55 – Network security groups
10:50 – Route tables and user-defined routes
12:41 – VNet peering and hub-and-spoke
14:48 – How it all connects

Key takeaways

An Azure Virtual Network is a regional, private network boundary in Microsoft Azure, and its address space should be planned large enough and free of overlaps before anything is deployed.
Subnets separate application tiers, private IPs should be the default, and network security groups plus route tables control what traffic is allowed and where it goes.
VNet peering connects networks privately over the Microsoft backbone but is not transitive, so growing environments typically use a hub-and-spoke design.

Worth quoting

“Your VNet's address space cannot overlap with any other network you plan to connect to. This is a common mistake.” – Mirko Peters (03:10)

“Public IPs are optional. You assign them explicitly because Azure never gives your resources a public IP unless you ask for it. That's by design, the default should be private and public should be a deliberate choice.” – Mirko Peters (07:43)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ on VNet basics
Microsoft Azure – the cloud platform whose virtual networks, subnets, NSGs, routing and peering this episode explains
Related episode: Building Azure That Survives the Real World — with Mike Martin [MVP]
Related episode: Azure Bicep - Simply Explained
Related episode: Fabric SQL Database - Simply Explained

Azure Private Link - Simply Explained

Sat, 18 Jul 2026 02:00:02 +0000

Many Azure admins assume their storage accounts and databases are private just because they run in Azure, but they are reachable from the internet by default. This episode explains Azure Private Link in plain English for cloud beginners and IT pros, covering private endpoints, DNS, alternatives like VPN and ExpressRoute, costs and the gotchas to avoid.

In this episode

00:00 – Why Azure services are not private by default
00:50 – The old way: public endpoints everywhere
02:29 – The private endpoint as a network interface card
04:17 – DNS and private DNS zones
08:08 – Private Link vs. VPN, ExpressRoute and service endpoints
10:11 – Private Link service for your own applications
11:47 – Security, compliance and cost
13:36 – Implementation gotchas and takeaway

Key takeaways

Azure PaaS services such as Storage, SQL and Key Vault ship with public endpoints, and a subscription is a billing boundary, not a network boundary.
Azure Private Link places a private endpoint with a private IP inside your virtual network, and private DNS zones make the existing service URL resolve to it so applications need no changes.
Creating a private endpoint does not disable public access, on-premises clients need DNS forwarding, and the extra per-endpoint cost is best justified for sensitive, regulated production workloads.

Worth quoting

“Your subscription is a billing and management boundary, not a network boundary. By default, your Azure services are reachable from the internet.” – Mirko Peters (02:08)

“Enabling a private endpoint does not turn off the public endpoint automatically. They can both exist at the same time. If you create a private endpoint, but never touch the public endpoint settings, your storage account is still reachable from the internet.” – Mirko Peters (03:25)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure Private Link
Azure Private Link – the service that places a private endpoint with a private IP inside your virtual network
Azure ExpressRoute – the private circuit to Azure that still needs Private Link for private PaaS access
Compliance – how Private Link helps prove sensitive data stays off public networks for HIPAA, GDPR, PCI
Related episode: The Death of the Chatbot: Why Your Dataverse Strategy Is Broken

Azure Traffic Manager - Simply Explained

Sat, 18 Jul 2026 01:00:02 +0000

Users in Tokyo should not wait on a single server in Virginia, and one regional outage should not take your whole app offline. This episode explains Azure Traffic Manager for developers and cloud architects building multi-region apps: how DNS-based routing works, when to use each of its six routing methods, and how it fits alongside Load Balancer, Application Gateway and Front Door.

In this episode

00:00 – Why global traffic routing matters
02:32 – What Traffic Manager actually is
04:16 – Priority routing for disaster recovery
05:58 – Performance routing
07:42 – Weighted and geographic routing
10:57 – Multi-value and subnet routing
12:26 – Health monitoring and failover
14:22 – Decision guide: Traffic Manager vs. other options

Key takeaways

Azure Traffic Manager is a DNS-based global traffic director that never sits in the data path, so it adds no latency to user connections.
Its six routing methods cover different goals: priority for disaster recovery, performance for speed, weighted for canary releases, geographic for compliance, plus multi-value and subnet for niche cases.
Reliable failover depends on well-tuned health probes against a lightweight health endpoint and on regularly testing that backup regions can carry the full load.

Worth quoting

“Traffic manager is a DNS-based load balancer that runs at global scale. Think of it like a smart reception desk at the entrance of a worldwide office building.” – Mirko Peters (02:35)

“Test your failover, actually simulate an outage and watch what happens. That's the only way to know it works.” – Mirko Peters (05:47)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure Traffic Manager
Azure Traffic Manager – the DNS-based global load balancer explained here, from priority to subnet routing
Microsoft Azure – the cloud whose regions, Load Balancer, Application Gateway and Front Door frame the decision guide
Mirko Peters – the host who walks through all six Traffic Manager routing methods in this episode
Related episode: Azure Application Gateway - Simply Explained

Azure DNS - Simply Explained

Sat, 18 Jul 2026 00:00:02 +0000

Everyone uses DNS, but few people understand the chain behind a lookup or how Azure takes over the job. This episode explains Azure DNS for cloud admins and beginners: public and private zones, the record types you actually need, delegation and virtual network links. You will know how to move a domain to Azure DNS without breaking your website or email.

In this episode

00:00 – Intro
00:54 – What DNS actually does
02:14 – What is Azure DNS?
03:28 – Public vs. private DNS zones
05:42 – Record types you'll actually use
08:30 – Delegation
10:51 – Private DNS and virtual network links
13:17 – Security, monitoring and best practices

Key takeaways

Azure DNS is a managed hosting service for DNS zones, so you no longer run, patch or scale your own DNS servers.
Public zones serve names to the internet and require delegation at your registrar, while private zones resolve only inside the virtual networks you link to them.
Use alias records for Azure resources and recreate every existing record in Azure before switching name servers to avoid outages.

Worth quoting

“Computers live on numbers, we live on names, and DNS sits right in the middle, making the translation.” – Mirko Peters (00:23)

“So Azure DNS is Microsoft's managed DNS hosting service. In plain English, that means you never have to run your own DNS servers, patch them, or plan for higher availability.” – Mirko Peters (02:15)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure DNS
Azure DNS – the subject of the episode: public and private zones, alias records, delegation and vnet links
Microsoft Azure – the platform hosting the DNS zones on Microsoft's global infrastructure
Microsoft Defender – Microsoft Defender for Cloud can block resolution of known malicious domains
Microsoft 365 – used as an example: setting it up requires a TXT record to verify your domain
Mirko Peters – hosts the episode and walks through DNS lookups, zones, records and delegation
Related episode: Azure Private Link - Simply Explained

MCP (Model Context Protocol) - Simply Explained

Fri, 17 Jul 2026 23:00:02 +0000

The Model Context Protocol (MCP) is an open standard that allows AI models to securely connect to external tools, applications, and data sources using a single, consistent protocol. Before MCP, every AI assistant needed custom integrations for services like Microsoft 365, SharePoint, Exchange, Dynamics 365, or databases. MCP replaces those one-off integrations with a universal connection layer, making it possible for any compatible AI application to discover available tools, access data, and perform actions through standardized interfaces. Often described as "USB-C for AI," MCP dramatically simplifies how AI agents interact with enterprise systems while remaining secure, flexible, and vendor-neutral. WHY MCP IS A GAME CHANGER FOR AI Large Language Models are incredibly capable, but they only know what they have been trained on unless they can access external information. Without integrations, AI assistants cannot read your SharePoint documents, check your Outlook calendar, query your CRM, or retrieve customer information. Traditionally, every connection required custom APIs, authentication, and development effort. MCP eliminates this complexity by providing one standard protocol that works across thousands of different services. Instead of building a unique connector for every application, developers expose an MCP server once, and any MCP-compatible AI client can immediately discover and use its capabilities. HOW MCP WORKS The Model Context Protocol follows a simple architecture built around three core components: the Host, the MCP Client, and the MCP Server. The Host is the AI application the user interacts with, such as Microsoft Copilot, Claude Desktop, or a custom AI agent. The MCP Client communicates using the protocol, while the MCP Server connects to business systems like SharePoint, Exchange, SQL databases, GitHub, or Microsoft Power Platform. Every server automatically exposes available Tools for taking actions, Resources for reading information, and Prompt Templates that help AI complete common tasks more effectively. Because servers describe their own capabilities, AI applications can discover and use them without requiring additional programming. MCP AND THE MICROSOFT ECOSYSTEM Microsoft has embraced MCP as an important part of its AI strategy. Azure AI Foundry supports connecting remote MCP servers directly to AI agents, while Microsoft has also published official MCP server implementations for Power Platform services such as Power Apps and Power Automate. These servers allow AI agents to trigger workflows, create Dataverse records, automate business processes, and interact with Microsoft services using the same standardized protocol. As more Microsoft 365 services become MCP-enabled, AI assistants gain secure, structured access to enterprise knowledge, making Copilot experiences significantly more powerful without requiring complex custom integrations. SECURITY, GOVERNANCE, AND ENTERPRISE READINESS Despite providing broad access to enterprise systems, MCP does not bypass existing security controls. Authentication typically relies on industry-standard OAuth 2.1, API keys, or secure access tokens, while AI clients request user approval before executing actions such as sending emails, updating records, or modifying files. Organizations continue to use existing Microsoft Entra ID permissions, Conditional Access policies, and role-based security to control exactly what AI agents can access. This ensures that MCP extends existing security models instead of replacing them, making it suitable for enterprise environments where governance and compliance remain critical. WHY MCP IS SHAPING THE FUTURE OF AI AGENTS The Model Context Protocol is becoming the foundation for the next generation of AI assistants and autonomous agents. Rather than acting as isolated chatbots, AI systems can securely interact with business applications, retrieve live information, automate workflows, and coordinate work across multiple platforms using one common standard. Whether building Microsoft Copilot extensions, Azure AI agents, enterprise automation, or Retrieval-Augmented Generation (RAG) solutions, MCP provides the universal connection layer that transforms AI from a standalone language model into a truly useful digital coworker capable of working with real business data in real time.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure AI Search – Simply Explained

Fri, 17 Jul 2026 22:00:02 +0000

Most in-app search returns the wrong results because it matches words, not meaning. This episode helps developers and architects understand how Azure AI Search combines keyword, vector and hybrid search to power better search experiences and grounded RAG assistants.

In this episode

00:00 – Intro: why app search disappoints
00:50 – Why keyword search breaks
02:11 – Vector search and embeddings
04:46 – Hybrid search and Reciprocal Rank Fusion
06:43 – The RAG connection
08:49 – Real-world use cases
10:52 – Data source, indexer and search index
12:29 – Practical next steps

Key takeaways

Keyword search such as BM25 is precise for exact terms but misses meaning, while vector search with embeddings finds semantically similar content but can miss exact matches.
Azure AI Search combines both in hybrid search, merging results with Reciprocal Rank Fusion, and serves as the retrieval layer for RAG-based assistants and agents.
Its building blocks are the data source, the indexer and the search index, and it delivers the most value on unstructured content such as PDFs, emails and support tickets.

Worth quoting

“Keyword search understands spelling. It understands character patterns, but it does not understand meaning. You get results that have the right letters, but often the wrong content.” – Mirko Peters (01:59)

“An embedding is a special type of vector that captures the meaning of text. It takes a sentence, a paragraph, even a whole document, and turns it into a long list of numbers.” – Mirko Peters (02:29)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure AI Search
Azure AI Search – the search service that combines keyword and vector search and powers RAG retrieval
Retrieval-augmented generation (RAG) – the pattern where Azure AI Search retrieves documents that ground an LLM's answers
Microsoft Azure – the platform whose portal import data wizard builds a first search index in under an hour
Related episode: Beyond Copilot: Building AI That Works in the Real World with Azure AI Foundry and Agentic AI for Frontline Workers with Fergus Kidd [MVP]

Microsoft Fabric OneLake - Simply Explained

Fri, 17 Jul 2026 21:00:02 +0000

Most organizations store the same customer and sales data four or five times, and nobody trusts which report is right. This episode explains Microsoft Fabric OneLake for data engineers, analysts and Power BI users: the OneCopy principle, shortcuts, mirroring, the three data stores and a single security model.

In this episode

00:00 – Why the same data gets copied everywhere
02:13 – What OneLake is
03:44 – The OneCopy principle
05:27 – Shortcuts: leave data where it lives
06:57 – Mirroring database data
08:50 – Lakehouse, Warehouse and Eventhouse
10:59 – Security and governance
12:33 – Practical takeaways

Key takeaways

OneLake is a single logical data lake per tenant, built on Azure Data Lake Storage Gen2 and delivered as a SaaS service, where every Fabric workload stores its data in open Delta Parquet format.
The OneCopy principle lets Spark, SQL and Power BI read the same physical data, while shortcuts reference external data in place and mirroring replicates databases in near real time without pipelines.
Lakehouse, Warehouse and Eventhouse are different views over the same storage, governed by one security model with workspace roles, OneLake security roles, the OneLake catalog and Purview integration.

Worth quoting

“One copy means one source of truth when the data updates every report sees the update immediately. No more asking, is this report using last week's data or this week's?” – Mirko Peters (04:51)

“A shortcut is a virtual pointer. Think of it like a symbolic link for your data lake. And it lets you access data that physically lives outside one lake without moving or copying it.” – Mirko Peters (05:31)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on OneLake
Microsoft Fabric – the platform whose single data lake, OneLake, this episode explains
Power BI – reads data straight from OneLake in Direct Lake mode, without extra copies
Semantic model – one of the extra data copies OneLake and the OneCopy principle are meant to avoid
Related episode: A Pragmatic Industrial Data Platform Roadmap for Mid-Sized Manufacturers

SCCM vs Intune - Simply Explained

Fri, 17 Jul 2026 20:00:02 +0000

SCCM and Intune both manage devices, yet they work in completely different ways and picking the wrong one wastes time and money. This episode helps IT admins and decision makers compare on-premises depth with cloud simplicity, understand co-management and choose the right path for their organization.

In this episode

00:00 – Intro
00:39 – Managing devices at scale
01:40 – What is SCCM?
03:30 – What is Intune?
05:11 – On-premises vs. cloud
07:58 – Feature comparison
10:27 – Co-management
12:20 – Decision framework and real-world example

Key takeaways

SCCM is an agent-based on-premises tool with deep control for Windows, OS deployment and servers, but it needs substantial server infrastructure.
Intune is a cloud service that only needs an internet connection, manages Windows, macOS, iOS and Android, and integrates natively with conditional access.
Co-management lets you move workloads such as compliance, endpoint protection and updates to Intune step by step while keeping complex tasks in SCCM.

Worth quoting

“SCCM is an on-premises tool that you run on your own servers inside your own building on your own network.” – Mirko Peters (01:54)

“The big difference between SCCM and Intune comes down to just one thing-- infrastructure. SCCM needs a lot of it.” – Mirko Peters (05:14)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on SCCM and Intune
Microsoft Intune – the cloud-based half of the comparison, covering Autopilot, update rings and mobile devices
Conditional Access – blocks non-compliant devices from company data based on Intune compliance status
Compliance – compliance reporting and policies, one of the first workloads moved to Intune
Microsoft Entra ID – named as Azure Active Directory, which Intune integrates with natively for access control
Microsoft 365 – E3 and E5 licenses usually include rights to both SCCM and Intune
Related episode: Microsoft Intune - Simply Explained

Microsoft Intune - Simply Explained

Fri, 17 Jul 2026 19:00:02 +0000

Managing laptops and phones by hand or through on-premises servers no longer works when people work from anywhere on their own devices. This episode is for IT beginners and decision-makers and explains how Intune enrolls and secures devices, protects data on personal phones and feeds Conditional Access for Zero Trust.

In this episode

00:00 – From hand-built laptops to the cloud
00:35 – What Microsoft Intune is
01:46 – The old way versus the Intune way
03:16 – Enrollment, configuration and compliance policies
05:19 – Mobile Application Management for BYOD
06:44 – Identity, Conditional Access and Zero Trust
08:16 – Admin and user experience
09:48 – Alternatives and what's coming next

Key takeaways

Microsoft Intune is a cloud service that enrolls devices, enforces configuration and compliance policies, deploys apps and tracks device health across Windows, macOS, iOS, Android and some Linux devices.
Mobile Application Management protects work data inside apps like Outlook, Teams and OneDrive on personal phones, so IT can wipe corporate data without touching personal content.
Intune reports device health to Entra ID, where Conditional Access combines identity and device signals into Zero Trust access decisions.

Worth quoting

“Intune is not a VPN, not antivirus software, and not a remote desktop tool. It's a device management platform.” – Mirko Peters (01:08)

“Intune's answer to this is something called Mobile Application Management, or MAM for short. Instead of managing the whole device, Intune manages only the work apps.” – Mirko Peters (05:47)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on Intune basics
Microsoft Intune – the device management service explained here, from enrollment and policies to app protection
Conditional Access – uses the device health signal from Intune to allow or block access
Microsoft Entra ID – the identity service Intune sits on top of and reports device compliance to
Zero Trust – the security model that Intune device checks make possible, as the episode describes
Related episode: ENTRA PIM EXPLAINED: Securing Privileged Access with Mark Orr [MVP]

Azure Virtual Desktop - Simply Explained

Fri, 17 Jul 2026 18:00:02 +0000

Buying, imaging and securing a laptop for every employee is slow and expensive, and remote work made it riskier. This episode explains Azure Virtual Desktop for IT admins and decision-makers: host pools, application groups, workspaces, Entra ID sign-in, FSLogix profiles and how autoscaling cuts costs.

In this episode

00:00 – What AVD is not
00:48 – The big picture: desktops streamed from Azure
03:37 – The old way versus the new way
05:18 – Host pools, session hosts and scaling
08:01 – Application groups and workspaces
11:28 – Identity and access with Entra ID
13:34 – User profiles with FSLogix
15:30 – Security and cost benefits

Key takeaways

Azure Virtual Desktop delivers Windows desktops and apps from Azure to any device through the Windows App, with Windows multi-session letting several users share one virtual machine.
Host pools, application groups and workspaces are the core building blocks, while Microsoft Entra ID, MFA, Conditional Access and the Virtual Machine User Login role control who can connect.
Start with a pooled host pool, depth-first load balancing and autoscaling for cost efficiency, use FSLogix for profiles from day one and assign access through groups rather than individual users.

Worth quoting

“Azure Virtual Desktop is Windows and Windows applications delivered from the cloud to any device. Think of it like a streaming service, but instead of streaming movies and TV shows, you're streaming your work desktop and business applications.” – Mirko Peters (00:52)

“Pooled host pools with Depth first load balancing and auto scaling can dramatically reduce your costs.” – Mirko Peters (07:43)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on AVD basics
Azure Virtual Desktop – the service explained here, from host pools and workspaces to FSLogix and autoscaling
Microsoft Entra ID – handles sign-in to AVD and the group-based assignment of application groups
Microsoft Azure – runs the session host virtual machines that stream desktops and apps to users
Related episode: Windows 365 or Azure Virtual Desktop: Choosing the Right Cloud PC Model

Azure ExpressRoute - Simply Explained

Fri, 17 Jul 2026 17:00:02 +0000

Is Azure ExpressRoute just an expensive VPN? This episode explains for IT and network decision makers how ExpressRoute circuits, peerings and gateways build a private highway into Microsoft's network. You will learn when it is worth the cost, how to plan for resiliency and how long provisioning really takes.

In this episode

00:00 – Intro
00:46 – The private highway analogy
01:41 – Building blocks: circuit, peering, gateway
03:12 – Provider vs. ExpressRoute Direct
04:24 – Resiliency and redundancy
05:53 – ExpressRoute vs. site-to-site VPN
07:55 – Real-world use cases
10:01 – Provisioning and is it right for you?

Key takeaways

ExpressRoute is a private connection from your network into Microsoft's backbone that bypasses the public internet for predictable latency, high bandwidth and an SLA.
Each circuit has built-in redundant links, but mission-critical workloads should use high or maximum resiliency across peering locations, optionally with a VPN as backup.
Provisioning needs your connectivity provider and can take weeks, so start early and choose ExpressRoute only when performance, predictability or compliance justify the cost over a VPN.

Worth quoting

“Azure Express route is the private lane. A dedicated physical link from your office or data center directly into Microsoft's network.” – Mirko Peters (00:31)

“Microsoft wants you to think bigger. The real danger isn't a single broken fiber. It's losing an entire peering location.” – Mirko Peters (04:37)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on ExpressRoute
Azure ExpressRoute – the subject of the episode: circuits, peerings, gateways, resiliency, cost and provisioning
Microsoft Azure – the cloud that ExpressRoute connects your on-premises network to, off the public internet
Microsoft 365 – one of the public Microsoft services reachable through Microsoft Peering on a circuit
Dynamics 365 – mentioned briefly as a Microsoft service reachable through Microsoft Peering
Related episode: Subnetting and CIDR - Simply Explained

Azure Site Recovery - Simply Explained

Fri, 17 Jul 2026 16:00:03 +0000

Many organizations believe their backups make them disaster-proof, until a site outage shows how long a restore really takes. This episode explains Azure Site Recovery in plain English for IT admins and decision makers: how replication, failover and failback work, why ASR is not backup, and when the cost is worth it.

In this episode

00:00 – Why disaster recovery matters
01:49 – What Azure Site Recovery is
03:20 – How replication works
05:23 – Failover and failback
07:13 – ASR versus Azure Backup
09:48 – When to use ASR
11:50 – Pitfalls and best practices

Key takeaways

Azure Site Recovery continuously replicates entire servers to another region so workloads can fail over in minutes rather than being restored over hours or days.
ASR does not replace backup: it replicates ransomware and corruption too, so mission-critical workloads need both backup for data and ASR for continuity.
Replicate only workloads where downtime has real financial impact, use recovery plans for dependencies and DNS, and run test failovers regularly.

Worth quoting

“Disaster recovery focuses on keeping your business running not just saving your files. It's about business continuity, not data preservation. Backup saves your data, while disaster recovery saves your operations and those are two very different things.” – Mirko Peters (01:32)

“ASR does not protect against ransomware or data corruption. It replicates whatever is on the disk including infections.” – Mirko Peters (04:55)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on Azure Site Recovery
Microsoft Azure – the platform where ASR replicates whole servers between regions or from on-premises
Azure Traffic Manager – mentioned as one option to route users to the new region after failover
Azure Disk Storage – the replicated disks from which ASR builds the new VM in the target region during failover
Related episode: Azure Front Door - Simply Explained
Related episode: Azure Load Balancer — Simply Explained

Azure Backup - Simply Explained

Fri, 17 Jul 2026 15:00:02 +0000

Losing a server or VM to failure or ransomware is every IT team's nightmare, and tape-era backups only proved themselves when you tried to restore. This episode explains Azure Backup for IT admins and cloud beginners: what it protects, how snapshots and vaults work, how it resists attacks, what it costs, and why you must test your restores.

In this episode

00:00 – Why backups used to be painful
00:35 – What Azure Backup actually is
02:05 – What Azure Backup protects
04:15 – How backup works: snapshot and vault transfer
06:30 – The security layer: soft delete, immutability, MUA
09:00 – Azure Backup versus the alternatives
11:05 – What Azure Backup costs
13:30 – The biggest mistake and your first three steps

Key takeaways

Azure Backup is a managed platform that protects Azure VMs, SQL Server and SAP HANA databases, file shares, blobs, disks and on-premises servers from one vault, driven by policies.
Encryption, soft delete, immutability, multi-user authorization and Defender for Cloud malware scanning make backups hard for ransomware attackers to destroy or poison.
A backup is only proven once it has been restored, so schedule regular restore drills and review retention policies to avoid paying for recovery points you never need.

Worth quoting

“Here's a hard truth that most organizations learn the hard way. The only good backup is one you've actually restored and validated.” – Mirko Peters (13:34)

“A backup strategy without a restore test is just an expensive hope. You're paying for protection, you haven't confirmed works.” – Mirko Peters (14:56)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure Backup
Microsoft Azure – the cloud platform whose built-in backup service, portal, RBAC and Azure Policy integration the episode explains
Azure Files – cloud file shares that Azure Backup can roll back after accidental deletion or ransomware
Azure Disk Storage – individual Azure disks that Azure Backup can protect without backing up the entire VM
Related episode: Azure Arc - Simply Explained
Related episode: Azure Elastic SAN — Simply Explained

Azure NetApp Files - Simply Explained

Fri, 17 Jul 2026 14:00:03 +0000

Some workloads simply cannot wait on storage: SAP HANA logs, large simulations and VDI logon storms. This episode explains for Azure architects and IT pros what Azure NetApp Files is, where it beats Azure Files, and how the flexible service level keeps high performance storage affordable.

In this episode

00:00 – Why Azure NetApp Files exists
00:48 – What Azure NetApp Files is
02:05 – Problems regular storage can't solve
03:20 – Use case: SAP HANA
05:09 – Use case: high performance computing
07:05 – Use case: virtual desktops
09:12 – Azure NetApp Files vs. Azure Files
11:06 – Flexible service level

Key takeaways

Azure NetApp Files is a first-party, fully managed Azure file service on NetApp technology that delivers sub-millisecond latency and very high throughput over SMB and NFS.
Its sweet spots are SAP HANA, high performance computing and VDI profile storage, while Azure Files remains the cost-effective choice for general file shares.
The flexible service level decouples capacity from throughput, so you no longer over-provision storage just to get the performance a workload needs.

Worth quoting

“The issue isn't that Azure files is bad. It's a great service for what it's designed to do. But it's optimized for cost. Not peak performance.” – Mirko Peters (02:54)

“Flexible service level changes that completely. It decouples capacity from throughput, two independent knobs instead of one. You decide how much storage you need and separately how much performance you need.” – Mirko Peters (11:44)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on Azure NetApp Files
Azure NetApp Files – the high performance file storage service this episode explains, from SAP HANA to VDI
Azure Files – the cost-optimized comparison point, still recommended for general file shares and everyday workloads
Microsoft Azure – the platform offering Azure NetApp Files as a first-party service beside blob, files and disk
Related episode: Windows 365 or Azure Virtual Desktop: Choosing the Right Cloud PC Model

AI, Power Platform & Developer Experience: The Next Frontier with Reza Niroomand [MVP]

Fri, 17 Jul 2026 13:00:03 +0000

AI lets anyone build an app in minutes, but who keeps it maintainable and secure? Mirko Peters and Microsoft MVP Reza Niroomand discuss AI-native fusion development, ALM, Git and Terraform for Power Platform makers, developers and architects, plus the tools XRM Tools and PSDataverse.

In this episode

00:00 – Intro and Reza's journey to the Microsoft ecosystem
08:55 – Three generations of Power Platform
16:56 – Scalability and discipline in the AI era
19:37 – Clean architecture and where business logic lives
25:51 – Code, AI and the review challenge
32:06 – CI/CD, Git and Terraform
43:00 – XRM Tools and PSDataverse
57:03 – Rapid-fire round

Key takeaways

Power Platform has moved from low-code productivity through fusion development to AI-native fusion, where AI joins the team without eliminating existing roles.
AI makes building apps fast, but maintainability, security, architecture and a disciplined ALM with Git as the single source of truth still decide success.
Reza Niroomand's XRM Tools brings plug-in and custom API registration into code inside Visual Studio, while PSDataverse uses PowerShell to move large volumes of data reliably in and out of Dataverse.

Worth quoting

“So this does not eliminate the existing roles. You still have the same roles. Instead it changes how they spend their time, basically.” – Reza Niroomand (12:29)

“creating app was not the biggest problem. You could build apps fast, right? It's a lot faster now, of course, but there is a discipline to it. Like how are you going to maintain it? How are you going to secure it?” – Reza Niroomand (17:59)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Power Platform engineering
Reza Niroomand – solution architect and creator of XRM Tools and PSDataverse, explaining AI-native fusion development
Sandra Kiel – mentioned briefly by the host for her sessions on gamification in Power Apps
Power Platform – traced through three generations, from low-code productivity to AI-native fusion development
Related episode: Architecting Power Platform for Complex Enterprise Solutions with Ian Tweedie [MVP]

Azure Files - Simply Explained

Fri, 17 Jul 2026 12:00:02 +0000

Aging file servers in a closet still cause failed backups, patch weekends and slow branch-office access for many small teams. This episode explains Azure Files for IT admins and small businesses: how mounting via SMB and NFS works, what the new standalone file shares resource changes, and when Azure Files is the right choice.

In this episode

00:00 – The file server problem
00:39 – What Azure Files is
01:43 – Pain of traditional file servers
03:33 – How it works: SMB, NFS and mounting
05:28 – The old way: storage accounts
07:22 – The new file shares resource
09:43 – When to use Azure Files
12:20 – Performance, security and cost

Key takeaways

Azure Files is a fully managed cloud file share that you mount like a network drive over SMB or NFS, with no server, hardware or patching to manage.
The new standalone file shares resource removes the storage account parent, giving each share its own limits, network rules, identity-based access and billing.
Use Azure Files for lift-and-shift apps, shared configuration and hybrid caching with Azure File Sync, but not for databases or for collaboration that SharePoint and Teams already cover.

Worth quoting

“Azure files is a cloud-based file share you can mount like a network drive with no server to manage, no hardware, no operating system updates, no backup schedules to lose sleep over.” – Mirko Peters (00:43)

“Third, there's no storage account key. Remember that all powerful key that gave access to everything gone. Authentication is identity based or through network rules.” – Mirko Peters (08:32)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on Azure Files
Azure Files – the managed cloud file share this episode explains, including the new standalone file shares resource
Microsoft Azure – the cloud platform hosting the file shares, from storage accounts to Azure File Sync and Defender
SharePoint – named as the better fit when people co-author documents in real time
Microsoft Entra ID – mentioned as Azure Active Directory for identity-based access to file shares instead of storage account keys
Related episode: Azure Storage Accounts - Simply Explained

Azure Kubernetes Service (AKS) - Simply Explained

Fri, 17 Jul 2026 10:00:03 +0000

Kubernetes is the industry standard for running containers, but operating it yourself is a full-time job. This plain-English episode is for developers and IT pros new to containers: it walks through what Azure Kubernetes Service manages for you, from the control plane to nodes, networking and security, plus what it really costs and the pitfalls to avoid.

In this episode

00:00 – The container problem
02:02 – What Azure Kubernetes Service is
03:30 – The control plane
05:37 – Nodes and node pools
07:47 – Networking
10:28 – Security
12:56 – Common pitfalls
15:04 – Costs and when to use AKS

Key takeaways

AKS is managed Kubernetes: Microsoft runs and patches the control plane, while you choose, scale and pay for the worker node virtual machines.
Plan subnet sizes for growth from day one and secure clusters in layers with Entra ID and Kubernetes RBAC, private clusters, Azure Policy and Key Vault for secrets.
Most AKS cost comes from worker nodes, so right-size them, use the cluster autoscaler, reservations or spot VMs, and avoid AKS for simple monolithic apps.

Worth quoting

“It's the industry standard for container orchestration, but Kubernetes solves one problem and creates another. Running it yourself is complex.” – Mirko Peters (01:28)

“AKS is the landlord. Microsoft handles the foundation, the control plane, networking, security patches, and upgrades. You bring the furniture, your containerized applications, configurations, and deployment pipelines.” – Mirko Peters (02:30)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure Kubernetes Service
Microsoft Azure – the platform whose managed Kubernetes service, monitoring and policy tools AKS integrates with
Microsoft Entra ID – connected to AKS for sign-in, with Entra groups mapped to Kubernetes roles
Azure Key Vault – the recommended store for secrets, mounted into pods via the secret store CSI driver
Related episode: Internal Developer Platforms (IDPs) - Simply Explained

Azure Container Apps - Simply Explained

Fri, 17 Jul 2026 09:01:07 +0000

Running containers often feels like a choice between a single container and a full Kubernetes cluster that needs its own team. This episode is for developers and small teams who want modern container features without becoming Kubernetes admins: it explains Azure Container Apps, how KEDA, Dapr and Envoy power it, its limits, and what it costs.

In this episode

00:00 – Containers: the missing middle ground
01:52 – Three options: ACI, AKS and Container Apps
03:33 – What Azure Container Apps is
05:28 – KEDA, Dapr and Envoy
07:35 – The Kubernetes without Kubernetes myth
09:17 – When to use it
11:37 – Cost
13:35 – Getting started in three steps

Key takeaways

Azure Container Apps sits between Azure Container Instances and AKS, offering Kubernetes-level features like autoscaling, ingress and revisions while Microsoft manages the cluster.
KEDA, Dapr and Envoy provide event-driven scaling to zero, microservice building blocks and managed ingress with traffic splitting out of the box.
Start new container projects on Container Apps and move to AKS only if you need Helm, custom resources, Windows containers or full cluster control.

Worth quoting

“Most people don't need either extreme. They want something in the middle, and that middle ground is exactly where Azure Container apps lives.” – Mirko Peters (01:45)

“Traditional auto-scaling watches CPU or memory. If your CPU hits 80%, spin up another instance. That works, but it's reactive. By the time your CPU is high, your users have already felt the lag.” – Mirko Peters (05:39)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure Container Apps
Microsoft Azure – the cloud platform offering Container Instances, Container Apps and AKS as the three container options
Azure App Service – compared on cost, since App Service always keeps at least one instance running
Visual Studio Code – one of the tools developers can use to deploy to Container Apps directly
Mirko Peters – the host who explains Azure Container Apps and when to choose it over AKS
Related episode: Managed Identities - Simply Explained

Azure Arc - Simply Explained

Fri, 17 Jul 2026 01:00:02 +0000

Servers spread across your data center, Azure, AWS and Google Cloud, each with its own console? This episode explains Azure Arc in plain English for IT admins managing hybrid and multi-cloud estates, showing how one control plane brings governance, security, monitoring and patching to every server.

In this episode

00:00 – The problem: too many consoles
01:29 – What Azure Arc actually is
03:06 – The Connected Machine agent
04:46 – Governance at scale
06:43 – Security and monitoring
08:58 – Updates and remote management
10:40 – Kubernetes, SQL Server and multi-cloud
14:00 – What Arc is not and getting started

Key takeaways

Azure Arc is not a cloud and moves nothing; it projects servers, Kubernetes clusters and SQL Server instances outside Azure into Azure Resource Manager.
The free Connected Machine agent connects outbound over HTTPS, so Azure Policy, RBAC, tags, Defender for Cloud, Sentinel, Azure Monitor and Update Manager work the same on-premises, in AWS and in GCP.
Start small: register the resource providers, onboard one test server with the generated script, then add policy, Defender and update management step by step.

Worth quoting

“Azure Arc is not a cloud. It doesn't replace your data center. It doesn't migrate your servers anywhere. Think of it as a bridge.” – Mirko Peters (01:36)

“You don't need to migrate anything to get Azure's management capabilities. You don't move your workloads. You don't re-architect your applications. You just connect what you already have to Azure's management plane.” – Mirko Peters (02:27)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure Arc
Related episode: Azure Resource Manager - Simply Explained
Related episode: Azure Local - Simply Explained
Related episode: Azure Monitor — Simply Explained
Related episode: Compliance as Code: The Architect’s Blueprint for Automated Trust
Related episode: Azure Management Groups and Subscriptions - Simply Explained

Microsoft AI Agent Harness - Simply Explained

Fri, 17 Jul 2026 00:00:02 +0000

Why do AI agents that shine in demos fall apart on long, real-world tasks? This episode explains the agent harness, the system around the model that adds memory, tools, orchestration and guardrails, and shows how Microsoft Foundry and the Agent Framework provide it. For architects and developers who want to move from clever prompts to reliable production agents.

In this episode

00:00 – Why Prompting Isn't Enough
02:01 – Three Phases of AI Evolution
03:35 – What a Harness Contains
05:35 – Microsoft AI Foundry as Enterprise Harness
07:15 – Building Harnesses with the Agent Framework
09:28 – Claw-Style Agents and Hermes
11:15 – Agents in Teams and Copilot
13:16 – Responsible AI and Governance

Key takeaways

An AI agent is a model plus a harness, and the harness supplies the agent loop, context management, tools, memory, guardrails and orchestration.
Microsoft Foundry delivers the harness as a managed service, including Entra agent identities, enterprise connectors, memory and one-click publishing to Microsoft 365 Copilot and Teams.
Guardrails such as step limits, tool restrictions, human approval gates and audit trails turn powerful agents into safe, governable systems.

Worth quoting

“Because reliability, memory, orchestration, and guardrails don't come from the model itself, they come from the system you build around it.” – Mirko Peters (02:53)

“An agent equals a model plus a harness. The harness is everything else. The model does the thinking, the harness does the rest” – Mirko Peters (03:02)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on agent harnesses
Agent harness – the system around the model that supplies loop, context, tools, memory, guardrails and orchestration
Microsoft Foundry – Microsoft's platform that delivers the agent harness as a managed service for enterprises
AI agent – defined in this episode as a model plus the harness built around it
Agent loop – the think, call a tool, check the result cycle at the base of every harness
Related episode: The Copilot Assumption That's Holding You Back — Agentic RAG

Platform Engineering - Simply Explained

Thu, 16 Jul 2026 23:00:02 +0000

Developers who were supposed to gain speed from DevOps now spend days on Terraform, Kubernetes and YAML instead of product code. This episode explains platform engineering, internal developer platforms and golden paths for engineering leaders and developers, and shows how to start small with one path that removes real pain.

In this episode

00:00 – The Mess DevOps Left Behind
02:25 – What Platform Engineering Is
04:08 – The Internal Developer Platform
06:16 – Golden Paths
08:23 – Cutting Cognitive Load
10:21 – Treating the Platform as a Product
12:04 – Why Now: The AI Wave
14:18 – Start with One Golden Path

Key takeaways

Shift left overloaded developers with infrastructure, security and operations work, and platform engineering puts a central layer in place to absorb that complexity.
An internal developer platform with golden paths makes the secure, tested route the easiest one, while escape hatches keep it from becoming a cage.
Run the platform as a product: talk to developers, start with one painful workflow and measure voluntary adoption instead of making it mandatory.

Worth quoting

“It's called platform engineering. And here's the simplest way to think about it. This discipline creates an internal layer that absorbs complexity for developers.” – Mirko Peters (02:28)

“A golden path is a recommended pre-built workflow that makes the right thing the easiest thing to do.” – Mirko Peters (06:22)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on platform engineering
Terraform – an example of the infrastructure work that shift left pushed onto developers
GitHub Copilot – the example of AI coding tools that increase code volume and platform pressure
Mirko Peters – the host who explains internal developer platforms and golden paths in plain English
Related episode: Bicep - Simply Explained
Related episode: Azure Platform Engineering, Azure Landing Zones, Cloud Adoption Framework & Building Enterprise Cloud Platforms Jev Suchoi [MVP]

GitOps - Simply Explained

Thu, 16 Jul 2026 22:00:02 +0000

Manual kubectl fixes and configuration drift make Kubernetes clusters behave in ways nobody can explain. This episode explains GitOps for Azure and Kubernetes engineers: declarative state in Git, pull-based deployments, the reconciliation loop, Flux versus Argo CD and the built-in GitOps support in AKS. You learn how to get trivial rollbacks, self-healing clusters and a built-in audit trail.

In this episode

00:00 – The Old Way and Configuration Drift
02:06 – What GitOps Actually Is
03:55 – Pull-Based vs Push-Based Deployments
05:46 – The Reconciliation Loop
07:39 – Argo CD vs Flux
09:52 – GitOps on Azure: AKS, Azure Arc and Azure DevOps
12:08 – Key Benefits
14:14 – Common Myths and Getting Started

Key takeaways

GitOps makes Git the single source of truth for infrastructure, so the cluster always matches what is declared and versioned in the repository.
In the pull-based model an operator such as Flux or Argo CD reconciles the cluster with Git continuously, which removes drift and keeps cluster credentials out of CI pipelines.
On Azure, Flux v2 is built into AKS and Azure Arc, so a team can start with one small cluster pointed at a Git repo and gain instant rollbacks and a full audit trail.

Worth quoting

“Git becomes your single source of truth, not just for your code, but for everything your infrastructure needs to run. Every configuration, every deployment, manifest, every environment variable, it all lives in Git.” – Mirko Peters (02:11)

“Now, GitOps isn't a tool you can buy. It's an operating model, like DevOps or DevSecOps. A set of principles that guide how you manage your infrastructure.” – Mirko Peters (02:25)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a GitOps FAQ
Microsoft Azure – the cloud where the episode runs GitOps, using AKS, Azure Arc and Flux v2
Azure DevOps – the CI side of the pattern, where Azure Pipelines builds images and updates manifests
GitHub Actions – an alternative CI tool that can build images and update the GitOps repository
Azure Key Vault – the recommended place for secrets, since secrets should never be stored in Git
Related episode: Internal Developer Platforms (IDPs) - Simply Explained

Vector Databases - Simply Explained

Thu, 16 Jul 2026 21:00:02 +0000

Keyword search fails when users and documents use different words for the same thing. This episode is for IT pros and developers curious about AI search, and explains in plain English how embeddings and vector databases work, where they live in Azure, and how to run your first similarity query in under an hour.

In this episode

00:00 – Why search understands crimson coat
00:46 – What a vector is
02:05 – From vectors to embeddings
03:37 – Why traditional databases fall short
05:05 – How vector databases work: ingestion, indexing and query
07:07 – Vectors in the Microsoft ecosystem
09:28 – Real-world use cases: RAG, recommendations, semantic search
11:37 – Vector ETL and getting started

Key takeaways

Embeddings turn text, images or audio into vectors that capture meaning, so a vector database can find similar content by distance instead of exact keywords.
Indexes such as IVF and HNSW make similarity search over millions of vectors fast enough for real-time AI features like Copilot and retrieval-augmented generation.
Microsoft adds vector capabilities to Azure AI Search, Cosmos DB, SQL Server 2025 and Azure SQL Database, and keeping vectors in sync requires incremental vector ETL with source, model version and timestamp metadata.

Worth quoting

“A Vector is really just a list of numbers. A one-dimensional array that represents something in a format the computer can work with.” – Mirko Peters (01:05)

“A regular database is like a filing cabinet. You need to know the exact file name to find what you're looking for. A vector database is like a librarian who understands what you mean.” – Mirko Peters (04:39)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on vector databases
Retrieval-augmented generation (RAG) – named as the biggest real-world use case, where vector search supplies documents to the model
Azure AI Search – described as the most common vector store for enterprise RAG, with hybrid search and integrated vectorization
Azure Cosmos DB – now offers native vector search with DiskANN indexing for operational data already stored there
Related episode: RAG on Azure — Simply Explained

RAG on Azure — Simply Explained

Thu, 16 Jul 2026 20:00:02 +0000

Large language models do not know your company's data and their knowledge is frozen in time. This Simply Explained episode shows developers, architects and IT pros how retrieval-augmented generation on Azure solves that with Azure AI Search, Azure OpenAI and Azure AI Foundry, and how to start building it the right way.

In this episode

00:00 – What RAG is and why it matters
01:36 – The two problems LLMs have
03:05 – How retrieval-augmented generation works
04:50 – Azure AI Search: indexing and searching
06:37 – Azure OpenAI and Azure AI Foundry
09:03 – Classic RAG vs. agentic RAG
10:28 – End-to-end example
12:10 – How to start building RAG on Azure

Key takeaways

RAG first retrieves relevant content from your own data and passes it to the model with the question, so answers are current and grounded instead of guessed from training memory.
On Azure, Azure AI Search indexes and retrieves chunks with vector or hybrid search, Azure OpenAI generates the answer, and Azure AI Foundry wires the agent together.
Start with your data, get retrieval right before adding the LLM, and choose agentic RAG only for complex questions where accuracy is worth the extra tokens and latency.

Worth quoting

“Ragh isn't a new model. It's not a bigger or better GPT. It's a different approach entirely.” – Mirko Peters (00:42)

“The LLM never sees your raw data. It only sees what the retrieval system hands it. It's not a drawback, so it's a security feature. Your sensitive documents stay in your own storage.” – Mirko Peters (04:08)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on building RAG on Azure
Retrieval-augmented generation (RAG) – the core pattern of the episode: retrieve your own content first, then let the model answer
Azure AI Search – the retrieval layer that chunks, embeds and indexes your documents and finds the best matches
Azure OpenAI Service – provides the GPT model that generates grounded answers from the retrieved context
Related episode: Vector Databases - Simply Explained

Azure AI Foundry - Simply Explained

Thu, 16 Jul 2026 19:00:02 +0000

Cognitive Services, Azure AI Studio, Azure AI Foundry, Microsoft Foundry: the constant renaming leaves many developers unsure what the platform actually is. This episode explains Foundry resources, projects, the model catalog, agents and the architecture behind them in plain English, for developers who want to build custom AI solutions on Azure, and ends with concrete first steps.

In this episode

00:00 – Why the Name Is So Confusing
01:32 – What Azure AI Foundry Actually Is
02:51 – Foundry Projects
04:12 – The Model Catalog
05:58 – Building AI Agents
08:52 – Architecture Under the Hood
11:17 – How Everything Connects
12:46 – Getting Started

Key takeaways

Azure AI Foundry, now Microsoft Foundry, is one unified platform that replaces stitching together Azure OpenAI, AI Search, Machine Learning and other services by hand.
A Foundry resource is the security and billing boundary, while Foundry projects give each AI solution an isolated workspace with its own models, agents and knowledge.
Agents in Foundry combine instructions, a model from the catalog, tools, knowledge and memory, and new users should skip classic hubs and start with one project and one agent.

Worth quoting

“It's a unified platform for building, testing, and deploying AI applications all in one place. That's the simplest definition.” – Mirko Peters (01:36)

“It's not about adding another tool. It's about removing the friction of managing a dozen separate services.” – Mirko Peters (02:46)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on Foundry
Azure AI Foundry – the unified platform this episode explains, from its many name changes to first steps
AI agent – the core build target here, assembled from instructions, model, tools, knowledge and memory
Foundry Agent Service – the runtime that hosts Foundry agents, calls models and tools and scales automatically
Related episode: Beyond Copilot: Building AI That Works in the Real World with Azure AI Foundry and Agentic AI for Frontline Workers with Fergus Kidd [MVP]

Microsoft Defender XDR - Simply Explained

Thu, 16 Jul 2026 18:00:02 +0000

Separate alerts from email, identity and endpoint tools hide the one attack that connects them. This episode explains Microsoft Defender XDR, its five building blocks and how they combine into single incidents with automated response, for IT and security teams using Microsoft 365. You also get three concrete steps to unlock protection you may already be paying for.

In this episode

00:00 – Too Many Disconnected Alerts
00:45 – The Problem: Siloed Security
01:57 – What Defender XDR Is
03:48 – The Five Components
06:06 – How They Work Together
07:50 – What It Does for You
09:41 – The Real Power Is Integration
11:45 – Takeaways: What to Do Next

Key takeaways

Microsoft Defender XDR is a unifying layer that correlates signals from Defender for Endpoint, Office 365, Identity, Cloud Apps and vulnerability management into single incidents.
Correlated incidents and automated remediation cut alert noise and can shrink response times from hours to minutes.
Start by checking your Microsoft 365 licensing, turn on the unified incident experience and deploy the Defender for Office 365 preset policies before adding more components.

Worth quoting

“Security isn't about any single product. It's about connecting the dots across everything happening in your environment.” – Mirko Peters (10:17)

“Defender XDR isn't some brand new product you have to go out and buy. It's more like a unifying layer that sits on top of security tools you might already own.” – Mirko Peters (02:38)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a FAQ on Defender XDR
Microsoft Defender – Defender XDR is the layer that correlates alerts from all Defender products into incidents
Microsoft Defender for Identity – one of the five components, detecting credential theft and lateral movement in Active Directory
Microsoft 365 – Defender XDR correlates signals across Microsoft 365 and comes with E5 licensing
Microsoft Secure Score – recommended for tracking progress once Defender XDR protections are running
Related episode: Microsoft Defender for Identity - Simply Explained

Microsoft Sentinel - Simply Explained

Thu, 16 Jul 2026 17:00:02 +0000

Security signals in Microsoft 365 are scattered across Entra, Exchange, SharePoint and Defender, so slow attacks slip through unnoticed. This episode explains Microsoft Sentinel in plain English for Microsoft 365 admins, from SIEM and SOAR to the new data lake, graphs and AI. You will learn how to get started with one connector and one detection rule without a big security budget.

In this episode

00:00 – Why scattered logs leave you blind
01:19 – SIEM: connecting the dots
02:39 – SOAR and playbooks
04:09 – Sentinel in the Microsoft security stack
05:44 – The unified data lake
07:11 – Threat hunting across years of data
08:40 – Graphs, Security Copilot and MCP
10:38 – Getting started and the big picture

Key takeaways

Microsoft Sentinel combines SIEM correlation and SOAR automation so signals from Entra, Exchange, SharePoint and Defender become one story instead of scattered alerts.
The Sentinel data lake separates cheap storage from compute, making multi-year log retention affordable and enabling hunting for low-and-slow attacks.
Start small: enable Sentinel in the Defender portal, connect Entra ID sign-in logs and install one detection rule from the content hub.

Worth quoting

“You can't protect what you can't see. If your security data is scattered across 20 dashboards, you're blind.” – Mirko Peters (02:24)

“By the time you stumble to your laptop and log in, the attack has already done what they came to do. Automation isn't a luxury. It's a necessity.” – Mirko Peters (03:49)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a FAQ on Microsoft Sentinel
Microsoft Defender – Sentinel moves into the Defender portal, which becomes the single place for security operations
Kusto Query Language (KQL) – the query language for hunting in Sentinel, for example across years of failed sign-ins
Microsoft Entra – Entra ID sign-in logs are the recommended first data source to connect to Sentinel
Microsoft 365 – the tenant whose scattered Entra, Exchange and SharePoint logs Sentinel brings together
Related episode: Microsoft Agent 365 - Simply Explained

Microsoft Purview - Simply Explained

Thu, 16 Jul 2026 16:00:03 +0000

Firewalls do nothing once a trusted user moves sensitive data. This episode explains Microsoft Purview in simple terms for IT, security and compliance teams, showing how governance, sensitivity labels, DLP and Compliance Manager work together, including for Copilot and AI.

In this episode

00:00 – Why walls around data are not enough
01:48 – Pillar 1: Data governance
04:04 – Pillar 2: Sensitivity labels
05:59 – Data loss prevention
07:50 – Pillar 3: Data compliance
10:50 – AI governance and Copilot
13:25 – How the three pillars connect
15:25 – Your first steps

Key takeaways

Microsoft Purview moves protection from the network to the data itself through governance, security and compliance.
Sensitivity labels travel with documents and drive DLP policies, which you should test in simulation mode before enforcing.
Copilot exposes unlabeled, overshared data, so start with a data classification scan and use Compliance Manager as your roadmap.

Worth quoting

“This is the fundamental shift. Protection needs to move from the infrastructure layer to the data layer itself. Instead of just guarding the building, you need to guard the files inside it.” – Mirko Peters (01:35)

“Here's the thing about labels, they travel with the data, if a document is marked confidential and someone attaches it to an email, the label stays attached.” – Mirko Peters (04:28)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on Microsoft Purview
Microsoft Purview – the family of data protection solutions this episode breaks into three pillars
Sensitivity labels – the classification tags that travel with files and trigger encryption and restrictions
Data loss prevention (DLP) – the policies that block risky sharing, best tested in simulation mode first
Data governance – the first pillar, using the data map and unified catalog to find your data
Related episode: Microsoft Purview Data Map - Simply Explained

Conditional Access - Simply Explained

Thu, 16 Jul 2026 15:00:02 +0000

A stolen password should not be enough to walk into your Microsoft 365 tenant. This episode explains Conditional Access in plain English for admins and IT decision makers: the signals it checks, how policies decide, and which baseline policies to deploy first. You will also learn how to roll out policies safely without locking yourself out.

In this episode

00:00 – What happens when you sign in
00:41 – What Conditional Access is
01:47 – Why passwords aren't enough
03:06 – The signals
05:23 – How policies work
06:53 – Three baseline policies for day one
09:38 – Risk and persona-based policies
11:57 – From security defaults to custom policies

Key takeaways

Conditional Access evaluates signals such as identity, location, device, app and sign-in risk after the password check and turns a flat yes or no into a layered decision.
Every tenant should start with three baseline policies: strong MFA for all users, blocking legacy authentication and compliant devices for admins.
Create break-glass accounts first, test new policies in report-only mode and with the What If tool, and roll them out in phases.

Worth quoting

“Conditional access is a policy engine that checks context before letting someone in. It doesn't just look at your password and say good enough.” – Mirko Peters (00:44)

“Now block is the most powerful control. If any policy says block, block wins, there are no exceptions.” – Mirko Peters (06:18)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Conditional Access
Conditional Access – the policy engine this episode explains, from sign-in signals to baseline policies and rollout
Multifactor authentication (MFA) – the second factor Conditional Access enforces, ideally limited to strong phishing-resistant methods
Microsoft Entra – where admins build and test policies; risk-based policies need an Entra ID P2 license
Microsoft 365 – the tenant whose sign-ins Conditional Access checks before letting users in
Related episode: Microsoft Intune - Simply Explained

Privileged Identity Management (PIM) - Simply Explained

Thu, 16 Jul 2026 14:00:02 +0000

Most organizations give admins permanent rights they use for only a few minutes a week, leaving the door open for attackers. This episode explains Microsoft Entra Privileged Identity Management in plain English for admins and security owners. You will learn how eligible assignments, just-in-time activation and approvals shrink your attack surface and which pitfalls to avoid.

In this episode

00:00 – The stolen admin account
01:00 – The standing privilege problem
02:47 – What is PIM
04:21 – Eligible versus active assignments
06:16 – The activation workflow
08:29 – PIM for groups
10:23 – PIM for Azure resources and audit benefits
13:40 – Common pitfalls and best practices

Key takeaways

Standing privileges leave admin rights active around the clock although they are used only briefly, turning every compromised admin account into a potential disaster.
PIM makes users eligible instead of permanently active, so roles are activated just in time with a time limit, MFA, justification and optional approval, and every activation is audited.
Start by making your global admin accounts eligible, keep activation windows short, require MFA on activation and keep separate break-glass accounts.

Worth quoting

“It's not that people have admin rights, it's that they have them all the time, even when they're not using them.” – Mirko Peters (00:33)

“In plain terms, eligible means you can. Active means you do. That distinction is everything.” – Mirko Peters (04:53)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a FAQ on PIM
Multifactor authentication (MFA) – required as a fresh check at role activation, so a stolen password alone cannot activate roles
Microsoft Entra – the home of PIM, which controls how and when Entra roles get activated
Microsoft Azure – PIM also governs Azure RBAC roles like owner and contributor on subscriptions and resources
Related episode: Conditional Access - Simply Explained

Building a Secure Microsoft-First MSP: Intune, Defender & Entra ID at Scale with Albin Klinaku [MVP]

Thu, 16 Jul 2026 13:00:02 +0000

Running a Microsoft-first MSP means turning Intune, Defender and Entra ID into a repeatable security service across many customers. Intune MVP Albin Klinaku shares what separates good from great deployments, which Defender and Conditional Access features are often missed, and why phishing-resistant MFA and token protection matter now. A practical episode for MSP owners, IT admins and security architects.

In this episode

00:00 – Intro and Albin's journey to a Microsoft-first MSP
06:22 – Becoming a Microsoft partner and an MVP
08:30 – Intune: evolution, security baselines and great deployments
17:57 – Device lifecycle, Autopilot and device preparation
20:50 – Defender: ASR rules, alert fatigue and threat hunting
30:32 – Vulnerability and patch management
32:45 – Entra ID, Conditional Access and phishing-resistant MFA
43:40 – Automation, metrics, Security Copilot and security culture

Key takeaways

A great Intune deployment applies security baselines to all devices, blocks unwanted enrollment such as personal devices, and is built with a cloud-native mindset rather than copying the old MDM.
In Defender, attack surface reduction rules should move from audit to block mode after reviewing the audit logs, and patch management must be in place before vulnerability management makes sense.
For identities, organizations should move to phishing-resistant authentication with passkeys or Windows Hello for Business and make full use of Conditional Access features such as risk-based policies and token protection.

Worth quoting

“I personally use them, especially at some smaller customers because they are getting you fast off the ground. You could build them yourself.” – Albin Klinaku (11:50)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on MSP security
Albin Klinaku – Intune MVP and MSP founder sharing field lessons on Intune, Defender and Entra ID
Microsoft Intune – covered through security baselines, enrollment restrictions and device preparation for deployments
Microsoft Defender – discussed for attack surface reduction rules, alert fatigue, threat hunting and licensing gaps
Related episode: ENTRA PIM EXPLAINED: Securing Privileged Access with Mark Orr [MVP]

Microsoft Entra Permissions Management - Simply Explained

Thu, 16 Jul 2026 12:00:02 +0000

Over time, users, service principals and scripts pile up cloud permissions nobody remembers granting, and attackers love that. This episode explains Microsoft Entra Permissions Management in plain English for cloud and security admins running Azure, AWS or GCP. You will learn how it discovers, right-sizes and monitors permissions and how it differs from PIM.

In this episode

00:00 – Introduction and the permission problem
01:09 – Why the old way is broken
02:30 – What Entra Permissions Management is
03:48 – Discover, remediate, monitor across clouds
06:14 – The Permission Creep Index
07:49 – Permissions on demand
09:20 – Permissions Management versus PIM
11:16 – Getting started safely

Key takeaways

Permission creep happens when identities keep permissions long after projects end, and Entra Permissions Management reveals the gap between granted and actually used permissions across Azure, AWS and GCP.
The Permission Creep Index gives each identity a measurable risk score, and permissions on demand replaces just-in-case rights with time-limited, scoped access.
PIM controls when privileged roles are active while Permissions Management controls what permissions exist; start with a pilot subscription, the free trial and simulation mode.

Worth quoting

“Most people think managing permissions is about assigning roles. You give someone, contributor or owner, and you're done. But that's not the real problem. The real problem is losing track of who has too much power.” – Mirko Peters (00:41)

“Then it watches what those identities actually do, not what they can do. That gap between granted permissions and used permissions is where the risk lives.” – Mirko Peters (03:10)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and FAQ on permission creep
Microsoft Azure – one of the three clouds Permissions Management scans for unused permissions, alongside AWS and GCP
Microsoft Entra – the product family that both Permissions Management and PIM belong to
Mirko Peters – host of Microsoft Knowledge Nuggets, explaining Entra Permissions Management in plain English
Related episode: Azure Role-Based Access Control (RBAC) - Simply Explained

Managed Identities - Simply Explained

Thu, 16 Jul 2026 11:00:03 +0000

Connection strings in config files, leaked secrets on GitHub and certificates expiring at 3 a.m. are everyday pain for Azure teams. This episode explains managed identities in plain English for developers and cloud admins: the two types, how tokens are issued and where the limits are. You will learn how to replace secrets with permissions in your own workloads.

In this episode

00:00 – The credential problem
00:53 – Secrets everywhere
02:19 – The solution: managed identity
04:19 – System-assigned versus user-assigned
06:56 – How it works under the hood
09:33 – From dev to production
12:10 – Old world versus new world
14:18 – When not to use managed identities

Key takeaways

Managed identities give Azure resources their own Entra ID identity so code obtains tokens from IMDS instead of storing connection strings or client secrets.
Use system-assigned identities for a single resource with zero overhead and user-assigned identities when several resources share permissions or the identity must outlive them.
Managed identities only work for workloads running in Azure; outside Azure use service principals with Key Vault or workload identity federation.

Worth quoting

“Your code never sees a secret. It doesn't store one. It doesn't read one from a config file. It just asks for a token and gets one.” – Mirko Peters (03:32)

“When you're building a new Azure workload, managed identity should be your first thought, not an after thought.” – Mirko Peters (04:01)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on managed identities
Microsoft Azure – the platform whose fabric issues tokens to workloads and rotates managed identity certificates automatically
Azure Key Vault – once the place to store secrets, now accessed via the Key Vault Secrets User role
Microsoft Entra ID – where each managed identity lives as a service principal and gets its OAuth 2.0 tokens
Azure App Service – the example deployment target where one toggle enables a system-assigned identity
Related episode: Internal Developer Platforms (IDPs) - Simply Explained

Azure API Management - Simply Explained

Thu, 16 Jul 2026 09:57:39 +0000

As applications split into dozens of microservices, every team ends up reinventing authentication, logging and rate limiting, and nobody has a single view of API traffic. This Simply Explained episode is for developers, architects and Azure admins who want to understand Azure API Management in plain English: the gateway, policies, products, the developer portal, security and pricing tiers.

In this episode

00:00 – Why many APIs turn into chaos
01:06 – The problem: too many APIs, no control
02:30 – What Azure API Management is: gateway, management plane, developer portal
04:16 – The gateway, your API's front door
05:59 – Policies, the engine that controls everything
07:31 – Products and subscriptions
09:11 – The developer portal
10:26 – Security, pricing tiers and wrap-up

Key takeaways

Azure API Management is a managed service in front of your backend APIs that covers their full lifecycle through a gateway, a management plane and a developer portal.
Policies let you add authentication, rate limiting, caching and transformations at the gateway without changing backend code, while products and subscription keys package APIs for different consumers.
For production, combine OAuth 2.0 with Entra ID, Key Vault-backed named values, managed identities and network isolation, and pick the tier from developer for testing to standard or premium for production.

Worth quoting

“It's a managed service that sits between your back-end APIs and the apps, websites, devices, and partners that consume them. But here's the thing. It's not just a proxy.” – Mirko Peters (02:46)

“One more thing, the gateway hides your real backend URL. Clients only see the gateway address. Your backend servers stay hidden from the internet.” – Mirko Peters (05:49)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on Azure API Management
Azure API Management – the managed service this episode explains, from gateway and policies to pricing tiers
Microsoft Entra ID – the recommended identity provider for OAuth 2.0 and for restricting developer portal access
Azure Key Vault – the vault that backs named values so secrets stay encrypted and rotate automatically
Related episode: AI Turns Integration into an Organism as a Service — How Azure Logic Apps Are Changing Enterprise Integration with Sonny Gillissen [MVP]

Azure Load Balancer — Simply Explained

Thu, 16 Jul 2026 09:00:14 +0000

If your app runs on a single VM, one crash or traffic spike takes it offline. This episode explains Azure Load Balancer in plain English for admins and developers new to Azure networking, from frontend IPs and health probes to distribution logic and SKUs. You will also learn the common pitfalls and when to choose Application Gateway, Front Door or Traffic Manager instead.

In this episode

00:00 – Why one server is not enough
01:51 – The smart reception desk
03:09 – Frontend IP, backend pool and rules
04:51 – Health probes
06:30 – How traffic gets distributed
08:36 – Public versus internal
10:11 – Standard, gateway, basic and common pitfalls
14:00 – Load balancer vs. Application Gateway vs. Traffic Manager

Key takeaways

Azure Load Balancer is a layer 4 traffic director: a frontend IP receives traffic, rules map it to a backend pool, and health probes keep failed servers out of rotation.
Traffic is spread by a five-tuple hash per flow, and session persistence should only be enabled when an application truly needs it.
Use the Standard SKU with at least two backend instances and check NSG rules, probe port and route tables first when probes report unhealthy servers.

Worth quoting

“The load balancer itself doesn't do the work. It's a traffic cop, not a worker.” – Mirko Peters (02:46)

“Without health probes, your load balancer would just blindly send traffic to every server in the pool, even the dead ones.” – Mirko Peters (04:57)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure Load Balancer
Microsoft Azure – the cloud platform whose layer 4 load balancer, SKUs and related traffic services are explained
Azure Traffic Manager – the DNS-level option for routing users to the nearest region, compared at the end
Mirko Peters – host who explains Azure Load Balancer with a smart reception desk analogy
Related episode: Azure Front Door - Simply Explained

Azure Front Door - Simply Explained

Thu, 16 Jul 2026 08:00:03 +0000

Users around the world expect your web app to be fast, secure and always available, no matter where it is hosted. This Simply Explained episode walks cloud beginners and web teams through how Azure Front Door routes traffic, caches content, blocks attacks at the edge and which tier to choose.

In this episode

00:00 – Why global users need smart traffic routing
01:04 – Azure Front Door as a global traffic cop
02:52 – Three layers of resiliency
05:45 – Routing with origin groups and health probes
08:15 – Security at the edge: WAF, bot protection and Private Link
10:36 – Caching and acceleration
12:35 – Pricing tiers: Standard vs. Premium
14:42 – A real-world e-commerce example

Key takeaways

Azure Front Door is a layer-7 global entry point that routes each user over Microsoft's backbone to the best healthy origin based on priority, latency and weight.
The built-in web application firewall, bot protection and Private Link stop attacks at the edge and keep origin servers hidden from the public internet.
Standard is the sweet spot for most websites and APIs, while Premium is worth it for regulated industries that need managed rule sets and Private Link.

Worth quoting

“Most load balancers work at layer four, looking at IP addresses and ports to route traffic. That's fine for basic needs. But Azure Front Door works at layer seven, meaning it understands HTTP and HTTPS traffic.” – Mirko Peters (01:26)

“The point is, no system is perfect, but Front Door's three layer architecture is designed to survive regional outages, traffic spikes and even some configuration errors.” – Mirko Peters (05:26)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on Azure Front Door
Azure Private Link – a Premium-tier feature that hides origin servers so only Front Door can reach them
Microsoft Azure – the cloud platform whose global network and private backbone Front Door runs on
Azure Traffic Manager – mentioned briefly as an optional break-glass path layered in front of Front Door
Related episode: Azure Web Application Firewall - Simply Explained

Azure Virtual WAN - Simply Explained

Thu, 16 Jul 2026 07:00:03 +0000

Building a global Azure network manually becomes increasingly difficult as your organization grows. What starts as a simple hub-and-spoke deployment quickly turns into a maze of virtual network peerings, route tables, VPN gateways, firewall rules, and regional connectivity challenges. Every new Azure region introduces additional complexity, making network management harder, slower, and more expensive. In this episode of m365.fm, we explain Azure Virtual WAN in plain English and show how Microsoft's managed networking platform simplifies global connectivity by replacing complex manual networking with an intelligent cloud-native backbone. Whether you're connecting branch offices, remote users, data centers, or Azure workloads across multiple regions, Azure Virtual WAN provides a scalable networking foundation built for modern enterprises.

WHY TRADITIONAL HUB-AND-SPOKE REACHES ITS LIMITS
Hub-and-spoke architecture remains an excellent networking model for smaller Azure environments, but as organizations expand globally, maintaining hundreds of peerings, user-defined routes, firewall policies, and VPN gateways becomes increasingly difficult. We explain why traditional networking creates operational overhead, how routing complexity grows exponentially with every new region, and why many large enterprises eventually struggle to manage their Azure connectivity. Through practical examples, you'll understand why Azure Virtual WAN was designed to eliminate manual networking tasks while preserving centralized security, routing, and governance across geographically distributed Azure environments.

VIRTUAL HUBS, MICROSOFT'S GLOBAL BACKBONE, AND CONNECTIVITY
At the heart of Azure Virtual WAN are Virtual Hubs—Microsoft-managed regional networking hubs that automatically connect your virtual networks, branch offices, ExpressRoute circuits, VPN gateways, and remote users through Microsoft's global private backbone. This episode explains the Virtual WAN resource, Virtual Hubs, spoke virtual networks, Site-to-Site VPN, Point-to-Site VPN, ExpressRoute, Microsoft Entra ID authentication, and automatic inter-hub routing using simple analogies that make enterprise networking easy to understand. Instead of manually configuring dozens of peerings and routing tables, Azure Virtual WAN allows organizations to connect each workload once while Microsoft manages the global routing infrastructure automatically.

BUILT-IN ROUTING, SECURITY, AND AZURE FIREWALL INTEGRATION
Azure Virtual WAN doesn't just simplify connectivity—it also simplifies security. Learn how Routing Intent automatically directs traffic through Azure Firewall or supported third-party next-generation firewalls without requiring complex User Defined Routes (UDRs). We explain secured Virtual Hubs, Azure Firewall integration, IPsec encryption, ExpressRoute, Azure Firewall Manager, Zero Trust networking principles, and centralized policy management across multiple Azure regions. You'll discover how Virtual WAN creates a globally consistent security model where routing, inspection, and policy enforcement are managed centrally rather than separately for every virtual network.

WHEN TO USE AZURE VIRTUAL WAN
The episode concludes by comparing Azure Virtual WAN with traditional Hub-and-Spoke networking and helping you choose the right architecture for your environment. We discuss deployment scenarios including global retailers, multinational enterprises, remote workforces, hybrid cloud environments, MPLS replacement projects, and cloud-first organizations expanding into multiple Azure regions. We also cover migration strategies, Virtual WAN Standard versus Basic, operational cost savings, Microsoft Learn resources, and practical deployment recommendations. Whether you're designing a new enterprise Azure network or modernizing an existing cloud infrastructure, this episode provides the practical knowledge needed to understand when Azure Virtual WAN becomes the right architectural choice—and how it helps organizations scale global networking without scaling operational complexity.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure Firewall - Simply Explained

Thu, 16 Jul 2026 06:00:02 +0000

Cloud networks have no single front door, so a physical firewall at the edge no longer protects your workloads. This episode is for Azure admins and anyone new to Azure networking, and explains what Azure Firewall does, how its SKUs, rules and hub-and-spoke placement work, and which setup to start with today.

In this episode

00:00 – A security desk for a building without walls
00:47 – What a firewall is
01:43 – Why cloud firewalls are different
03:01 – Introducing Azure Firewall
04:20 – The three SKUs: Basic, Standard and Premium
06:35 – Architecture and traffic flow
08:25 – Rules deep dive: NAT, network and application rules
10:22 – Advanced protection, cost tips and next steps

Key takeaways

Azure Firewall is a fully managed, cloud-native firewall service with built-in high availability and autoscaling that inspects inbound, outbound and east-west traffic.
Basic, Standard and Premium SKUs add capabilities step by step, from IP and port filtering to threat intelligence in deny mode, web categories, TLS inspection, IDPS and URL filtering.
Traffic is only inspected if it passes through the firewall, so a hub-and-spoke design, correctly ordered NAT, network and application rules, and cost controls like the Log Analytics basic table plan matter as much as the SKU.

Worth quoting

“You can't install a physical firewall box in a data center you don't own. And even if you could, it wouldn't help because there's no single door to guard anymore.” – Mirko Peters (01:37)

“Both directions need inspection. If a hacker gets into one workload, you don't want them roaming freely to others. That's how breaches spread.” – Mirko Peters (02:20)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure Firewall
Microsoft Azure – the cloud platform whose virtual networks Azure Firewall protects across north-south and east-west traffic
Azure Virtual WAN – the managed networking option for larger organizations, with Azure Firewall integrated into the hub
Azure Automation – a cost tip: stop the firewall in non-production environments outside working hours
Azure Private Link – mentioned briefly as private endpoints, letting trusted services skip firewall routing to cut processing charges
Related episode: Azure Network Security Groups - Simply Explained

Azure Bastion - Simply Explained

Thu, 16 Jul 2026 05:00:03 +0000

Every VM with a public IP and an open RDP port is a target, and jump boxes add their own patching burden. This episode explains Azure Bastion for Azure admins and cloud architects: how it works, what the Entra ID integration adds and which SKU fits your budget. You will know how to remove public IPs and move to identity-based VM access.

In this episode

00:00 – Why open RDP ports are a problem
00:47 – The old way: jump boxes and public RDP
02:22 – What Azure Bastion is
03:43 – How Azure Bastion works
05:04 – Entra ID authentication for VM logins
06:58 – SKUs, pricing and the real cost of jump boxes
08:38 – The big picture
09:57 – Getting started with Bastion

Key takeaways

Azure Bastion is a fully managed service that gives secure RDP and SSH access to Azure VMs over HTTPS, so the VMs need no public IP and no exposed management ports.
Native Entra ID authentication brings MFA, Conditional Access and Azure RBAC roles to VM logins and removes the need for local accounts and passwords on each machine.
Choose the Standard or Premium SKU for production, deploy into a dedicated AzureBastionSubnet, remove public IPs and restrict NSGs to the Bastion subnet, starting with your most critical VMs.

Worth quoting

“Here's the thing, every exposed port is a target, and ransomware gangs scan for open RDP constantly.” – Mirko Peters (00:24)

“The problem isn't that it can't work. It's that it takes constant work to keep it safe.” – Mirko Peters (01:36)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Azure Bastion
Azure Bastion – the managed service that replaces public RDP and jump boxes for private VM access over HTTPS
Microsoft Entra ID – the identity layer that since 2025 lets you sign into Windows VMs without local accounts
Multifactor authentication (MFA) – the sign-in check that Entra ID brings to VM logins through Bastion, just like for email
Conditional Access – the policies that now apply to RDP sessions, for example blocking sign-ins from untrusted locations
Mirko Peters – the host who walks through Azure Bastion, its Entra ID integration and SKUs
Related episode: Azure Virtual Network - Simply Explained

Azure Landing Zones - Simply Explained

Thu, 16 Jul 2026 04:00:02 +0000

Building workloads in Azure is easy. Building an Azure environment that remains secure, scalable, compliant, and manageable for years is much harder. Without a solid foundation, organizations quickly end up with inconsistent subscriptions, overlapping networks, missing policies, unclear ownership, and rapidly increasing cloud costs. In this episode of m365.fm, we explain Azure Landing Zones in plain English and show why they have become Microsoft's recommended foundation for enterprise cloud adoption. You'll learn what a Landing Zone really is, why it isn't a product you simply deploy, and how it creates a governed platform that allows application teams to innovate without sacrificing security or operational control. Whether you're an Azure administrator, cloud architect, or IT leader, understanding Landing Zones is essential for building Azure environments that scale successfully.

WHAT AN AZURE LANDING ZONE REALLY IS
Despite the name, Azure Landing Zones are not a single Azure service. They are a pre-configured cloud environment where networking, identity, governance, monitoring, and security are already established before the first workload is deployed. We explain why subscriptions—not resource groups—form the primary isolation boundary, how Management Groups organize Azure environments at scale, and why Azure Policy enforces organizational standards automatically instead of relying on documentation or manual reviews. You'll discover how guardrails such as allowed regions, mandatory tagging, diagnostic settings, and security baselines are inherited across your Azure hierarchy, creating governance that is built directly into the platform.

THE EIGHT DESIGN AREAS EXPLAINED
Microsoft's Cloud Adoption Framework defines eight core design areas that together form a complete Landing Zone architecture. This episode breaks down identity and Microsoft Entra ID, billing and subscription design, Management Groups, networking, security, governance, management, and platform automation using practical examples that make each concept easy to understand. We also explore Hub-and-Spoke networking, Azure Virtual WAN, Azure Firewall, Microsoft Defender for Cloud, centralized Log Analytics, Azure Policy initiatives, Infrastructure as Code, subscription vending, and automated governance. By understanding how these components work together, you'll see how Azure Landing Zones create repeatable, enterprise-ready cloud platforms instead of isolated Azure subscriptions.

PLATFORM LANDING ZONES VS. APPLICATION LANDING ZONES
One of the most common sources of confusion is the difference between Platform Landing Zones and Application Landing Zones. We explain why platform subscriptions host shared services such as identity, networking, connectivity, monitoring, and security, while application subscriptions remain isolated environments owned by individual workload teams. You'll learn why separating these responsibilities improves scalability, simplifies governance, and allows centralized platform teams to support hundreds of Azure subscriptions without becoming operational bottlenecks. We also discuss common architectural mistakes, including placing shared services inside application subscriptions, and explain how proper separation creates a more maintainable Azure environment over the long term.

BUILDING A SCALABLE AZURE FOUNDATION
The episode concludes with practical guidance for implementing Azure Landing Zones without unnecessary complexity. Learn why starting with a Minimum Viable Landing Zone often delivers better long-term results than attempting to build a perfect enterprise architecture on day one. We explore Azure Landing Zone Accelerators, Policy Audit mode, IP address planning, subscription automation, Infrastructure as Code with Bicep and Terraform, and Microsoft's Cloud Adoption Framework recommendations for continuous platform evolution. Whether you're creating your first Azure environment or modernizing an existing cloud estate, this episode provides the practical knowledge needed to build a secure, scalable, and well-governed Azure platform that supports business growth for years to come.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure Resource Manager - Simply Explained

Thu, 16 Jul 2026 03:00:02 +0000

Most Azure users never notice the engine behind every deployment. This episode explains Azure Resource Manager in plain English for Azure beginners and admins, covering RBAC, resource groups, policies and ARM templates so deployments become consistent, governed and repeatable.

In this episode

00:00 – What Azure Resource Manager actually is
02:15 – Authentication and authorization with RBAC
03:48 – Resource groups
05:58 – Tags, locks and policies
08:28 – Infrastructure as code with ARM templates
10:32 – Real-world scenario: deploying a web app
12:25 – How it all fits together
14:22 – Actionable takeaways

Key takeaways

Azure Resource Manager is the control plane every portal click, CLI command and template passes through, which is why results are consistent.
Resource groups, RBAC, tags, locks and Azure Policy form one governance system that ARM enforces on every request.
ARM templates and Bicep make deployments declarative and repeatable; export a template from an existing resource group to get started.

Worth quoting

“Every request to create, update, or delete a resource goes through ARM first. It doesn't matter how you make that request, whether it's through the Azure portal, the command line, power shell, or the SDKs, they all hit the same front door.” – Mirko Peters (01:02)

“Here's the rule you need to remember. Every single resource in Azure must belong to exactly one resource group, no exceptions.” – Mirko Peters (04:15)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a plain-English FAQ on ARM
Microsoft Entra ID – the directory ARM relies on to verify your identity and issue the token for every request
Infrastructure as code – the approach behind ARM templates, so environments become version controlled and repeatable
Bicep – the simpler language Microsoft created that compiles to ARM templates when JSON feels too heavy
Microsoft Azure – the platform whose portal, CLI, PowerShell and SDK requests all pass through ARM
Related episode: ARM Templates - Simply Explained

Azure Policy - Simply Explained

Thu, 16 Jul 2026 02:00:02 +0000

As organizations move to the cloud, governance becomes one of the biggest challenges they face. In traditional datacenters, infrastructure teams reviewed every server request before anything was deployed. In Azure, developers and administrators can provision resources instantly through the portal, APIs, Infrastructure as Code, or automation tools. Without guardrails, this flexibility can quickly lead to security risks, compliance violations, inconsistent configurations, and unnecessary costs. In this episode of m365.fm, we explain Azure Policy in plain English and show how it acts as the invisible rulebook that automatically enforces your organization's standards across Azure. Whether you're an Azure administrator, cloud architect, security professional, or developer, understanding Azure Policy is essential for building secure and well-governed cloud environments.

WHY CLOUD GOVERNANCE MATTERS
The cloud makes deploying resources incredibly easy—but that convenience also creates new risks. Virtual machines may be deployed in the wrong region, storage accounts might expose sensitive data publicly, expensive GPU instances can be provisioned accidentally, and required governance tags are often forgotten. We explain why manual approval processes no longer scale in modern cloud environments and how Azure Policy automatically validates every deployment regardless of whether it's created through the Azure Portal, Azure CLI, ARM templates, Bicep, Terraform, or REST APIs. You'll discover how Azure Policy continuously enforces organizational standards without slowing down development teams.

POLICY DEFINITIONS, ASSIGNMENTS, AND EFFECTS
Every Azure Policy begins with a simple principle: If this condition is true, then perform this action. This episode explores Policy Definitions, Policy Assignments, inheritance, scopes, parameters, and exemptions using practical examples that make governance easy to understand. We explain how policies evaluate resource properties, how assignments work across Management Groups, Subscriptions, and Resource Groups, and why inheritance allows organizations to manage governance at enterprise scale. You'll also learn the differences between Deny, Audit, Modify, Append, and DeployIfNotExists effects, when each should be used, and how they automatically enforce security, compliance, and operational standards without requiring manual intervention.

INITIATIVES, COMPLIANCE, AND REAL-WORLD GOVERNANCE
Managing hundreds of individual policies would quickly become overwhelming, which is why Azure Policy supports Initiatives—collections of related policies grouped around common objectives. We explain how initiatives simplify compliance reporting, support regulatory frameworks like ISO 27001, CIS, PCI DSS, HIPAA, and the Azure Security Benchmark, and provide centralized visibility into your organization's governance posture. Through practical examples—including location restrictions, mandatory resource tagging, VM size limitations, storage account security, and naming convention enforcement—you'll see how Azure Policy helps organizations improve security, reduce cloud costs, and maintain operational consistency across thousands of Azure resources.

BUILDING A MODERN AZURE GOVERNANCE STRATEGY
Azure Policy is far more than a standalone governance service—it's one of the core building blocks of Microsoft's Cloud Adoption Framework. In this episode, we explain how Azure Policy integrates with Azure Resource Manager, Management Groups, Role-Based Access Control (RBAC), Microsoft Defender for Cloud, Azure Advisor, Policy as Code, Git repositories, and CI/CD pipelines to create a scalable governance platform. You'll also discover why Policy as Code has become a best practice for enterprise organizations, enabling version control, automated deployments, and consistent governance across multiple Azure environments. Whether you're managing a single Azure subscription or an enterprise cloud platform, this episode provides a practical foundation for implementing Azure Policy and building secure, compliant, and well-governed Azure environments from day one.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure Monitor — Simply Explained

Thu, 16 Jul 2026 01:00:02 +0000

Jumping between five screens whenever something breaks? This episode explains Azure Monitor in plain English for Azure beginners and admins, covering metrics, logs, KQL, workbooks, alerts and the 2026 changes, plus practical tips to keep monitoring costs under control.

In this episode

00:00 – Too many dashboards
00:35 – What is Azure Monitor?
01:48 – Metrics and logs
03:19 – Where the data comes from
05:19 – Visualization: workbooks and dashboards
07:07 – Alerts and automation
09:13 – What's new in 2026
10:42 – Cost optimization and how it all fits together

Key takeaways

Azure Monitor is Microsoft's central observability platform: metrics tell you something is wrong, logs in a Log Analytics workspace queried with KQL tell you why.
Data flows in from Azure resources, Application Insights, the Azure Monitor Agent (also via Azure Arc), Entra ID and security tools, and is visualized in workbooks and acted on with alerts, action groups and Logic Apps.
Migrate off the retired Log Analytics agent, adopt OpenTelemetry, and control cost by tiering logs, setting per-table retention and using sampling and budget alerts.

Worth quoting

“Azure Monitor isn't a single tool. It's a platform that pulls together metrics, logs, traces, and alerts from Azure on premises and even other clouds.” – Mirko Peters (01:07)

“Metrics tell you something is wrong, logs tell you why. Imagine driving your car. The check engine light comes on, and that's a metric telling you something is wrong right now” – Mirko Peters (02:35)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on Azure Monitor
Kusto Query Language (KQL) – the query language used to search logs in a Log Analytics workspace and write log alerts
Microsoft Entra ID – streams sign-in and audit logs into Azure Monitor and now secures Application Insights queries
Azure Logic Apps – triggered by action groups for automated remediation, such as running a disk cleanup script
Power BI – the option for sharing monitoring reports with stakeholders who don't work in Azure
Related episode: Log Analytics - Simply Explained

Azure Logic Apps - Simply Explained

Thu, 16 Jul 2026 00:00:03 +0000

Copying information between SharePoint, Teams, email and databases by hand is slow and error-prone, and custom integration code takes weeks. This episode explains Azure Logic Apps in plain English for IT pros, business analysts and Microsoft admins, covering triggers, connectors, pricing models, real examples and the shift to agentic automation.

In this episode

00:00 – Why automation needs glue
01:41 – What Logic Apps actually is
03:16 – Building blocks: triggers and actions
05:04 – Connectors, the real superpower
06:55 – Consumption versus Standard
09:15 – Real-world examples in action
11:30 – Agentic automation and AI agents
13:20 – Getting started with Logic Apps

Key takeaways

Azure Logic Apps is a serverless workflow service that connects systems like SharePoint, Teams, Outlook, SQL and Salesforce through triggers, actions and more than 1,400 connectors.
Start with the Consumption plan for low or spiky workloads and move to Standard only when high volumes make its fixed monthly price cheaper or you need dedicated compute and network control.
Logic Apps is evolving into an orchestration layer for AI, where natural-language workflow creation and AI agents handle exceptions that rigid workflows could not.

Worth quoting

“The problem isn't that people don't want to automate. It's that connecting different systems is hard. Each system has its own way of handling authentication, its own data format, its own rules.” – Mirko Peters (01:15)

“Think of Power Automate as a bicycle. Great for getting around the office. Logic Apps is a delivery truck. Built for heavier loads and longer routes.” – Mirko Peters (02:52)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on Logic Apps
Azure Logic Apps – the serverless workflow service at the center of this episode, from triggers to agents
Connector – called the real superpower, with over 1,400 pre-built, built-in and managed connectors
Power Automate – compared as the bicycle for simple personal workflows next to the Logic Apps truck
AI agent – now usable as workflow steps that reason, use tools and handle exceptions
Related episode: AI Turns Integration into an Organism as a Service — How Azure Logic Apps Are Changing Enterprise Integration with Sonny Gillissen [MVP]

Azure Functions - Simply Explained

Wed, 15 Jul 2026 23:00:02 +0000

Serverless is one of the most talked-about concepts in cloud computing, yet it's also one of the most misunderstood. Many developers assume "serverless" means there are no servers involved, but the reality is quite different. In this episode of m365.fm, we explain Azure Functions in plain English and show why serverless computing has fundamentally changed how modern cloud applications are built. You'll learn what Azure Functions really are, how they work behind the scenes, how the pricing model actually works, and when serverless is the right architectural choice. Whether you're just starting with Azure or preparing for certification exams, this episode gives you a practical understanding of one of Microsoft's most important cloud services. WHAT SERVERLESS REALLY MEANS Despite its name, serverless doesn't eliminate servers—it eliminates the need for developers to manage them. We explain how Azure Functions abstracts away infrastructure, operating system maintenance, security updates, scaling, and availability so you can focus entirely on your application logic. Instead of paying for virtual machines that sit idle around the clock, Azure Functions only execute when they're needed, making serverless applications both simpler to operate and significantly more cost-efficient. Through relatable real-world analogies, you'll understand why event-driven computing has become the preferred architecture for modern cloud-native solutions. FUNCTIONS, TRIGGERS, AND BINDINGS EXPLAINED Every Azure Function is designed to perform one focused task in response to a specific event. This episode explains the core building blocks including Function Apps, individual Functions, triggers, bindings, and stateless execution. Learn how HTTP requests, Blob Storage uploads, queue messages, and timer schedules automatically trigger your code without constantly running background services. We also explore input and output bindings, showing how Azure Functions seamlessly integrate with Azure Storage, Service Bus, databases, and many other Azure services while dramatically reducing the amount of infrastructure code developers need to write. PRICING, SCALING, AND REAL-WORLD SCENARIOS One of the biggest advantages of Azure Functions is its consumption-based pricing model. We explain how executions, execution time, memory usage, and Microsoft's generous free tier work together to make serverless applications extremely affordable for many workloads. Through practical examples including automatic image compression, welcome email automation, scheduled maintenance tasks, webhook processing, API endpoints, and background data transformation, you'll discover why Azure Functions have become the backbone of many event-driven cloud architectures. We also compare the Consumption, Flex Consumption, Premium, and Dedicated hosting plans to help you choose the right option for your workload. WHEN TO USE AZURE FUNCTIONS — AND WHEN NOT TO Azure Functions are incredibly powerful, but they aren't the right solution for every scenario. This episode explores the ideal use cases for serverless computing while explaining where Azure App Service, Container Apps, Logic Apps, Durable Functions, or Virtual Machines may be better choices. We also cover common beginner mistakes including long-running executions, cold starts, authentication configuration, deployment strategies, monitoring with Application Insights, and storage account best practices. Whether you're building APIs, automating cloud workflows, integrating Azure services, or modernizing enterprise applications, this episode provides the practical foundation you need to confidently start building with Azure Functions and serverless computing.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure Service Bus - Simply Explained

Wed, 15 Jul 2026 22:00:02 +0000

Apps that call each other directly break the moment one service is slow or offline. This episode explains Azure Service Bus in plain English for developers and cloud architects: queues, topics, message lifecycle, dead-lettering, sessions and when to pick Event Hubs, Event Grid or Kafka instead. You will understand how to build systems that keep working when things go wrong.

In this episode

00:00 – Tight coupling and the need for a middleman
00:47 – What a message broker is
02:31 – Anatomy and lifecycle of a message
05:19 – Dead-lettering, sessions, duplicate detection and transactions
08:07 – Service Bus vs. Storage Queues, Event Hubs, Event Grid and Kafka
09:41 – Real-world use cases
12:50 – The big picture: decouple, buffer, route

Key takeaways

Azure Service Bus is Microsoft's fully managed message broker that decouples applications so senders and receivers can fail, scale and change independently.
Queues deliver to one consumer, topics with filtered subscriptions fan out to many, and features such as dead-letter queues, sessions, duplicate detection, transactions and scheduled delivery handle the hard edge cases.
Choose Storage Queues for simple background jobs, Event Hubs and Kafka for high-throughput streaming, Event Grid for lightweight reactive events and Service Bus for reliable business workflows.

Worth quoting

“When two apps are decoupled, they can fail independently. If the receiver crashes, the sender doesn't even notice. The message just sits in the broker waiting.” – Mirko Peters (01:07)

“If you're regularly sending data larger than that, you probably shouldn't be putting it in a message. Store the large data somewhere else and put a reference in the message.” – Mirko Peters (03:57)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on Service Bus
Azure Service Bus – the fully managed message broker this whole episode explains, from queues to sessions
Azure Event Hubs – contrasted as a high-throughput streaming and ingestion pipeline, not a message broker
Microsoft Azure – the cloud platform where Service Bus and the compared Storage Queues and Event Grid run
Related episode: Azure Event Grid - Simply Explained

Azure Event Hubs - Simply Explained

Wed, 15 Jul 2026 21:00:02 +0000

Modern applications generate an incredible amount of data every second. IoT devices stream telemetry, applications produce logs, websites capture user interactions, and financial systems process millions of transactions in real time. Traditional databases and message queues quickly become bottlenecks when faced with this scale. In this episode of m365.fm, we explain Azure Event Hubs in plain English and show why it has become one of Microsoft's most important cloud services for real-time data streaming. You'll learn how Event Hubs ingests millions of events per second, enables scalable event-driven architectures, and serves as the foundation for modern analytics, monitoring, and AI workloads.

WHY REAL-TIME STREAMING MATTERS
Many organizations still rely on batch processing, collecting data throughout the day before processing it overnight. While this worked in the past, today's businesses need immediate insights. We explore why traditional databases and message queues struggle with high-volume streaming workloads and explain how Azure Event Hubs solves this challenge by acting as a high-speed ingestion layer for continuous event streams. Through practical examples from manufacturing, IoT, web applications, and financial services, you'll discover why modern cloud architectures increasingly depend on real-time streaming instead of delayed batch processing.

PARTITIONS, CONSUMER GROUPS, AND THROUGHPUT UNITS
Understanding Event Hubs starts with its core building blocks. This episode explains partitions, consumer groups, throughput units, offsets, checkpointing, retention, and replay using simple analogies that make complex streaming concepts easy to understand. Learn how partitions enable massive parallel processing while preserving event order, why multiple consumer groups can independently process the same event stream, and how throughput units determine the ingestion capacity of your Event Hub. We also cover Kafka compatibility, producer and consumer architecture, checkpoint recovery, and how Event Hubs maintains reliable streaming at enormous scale.

REAL-WORLD AZURE EVENT HUBS SCENARIOS
Azure Event Hubs powers some of the largest real-time workloads in the Microsoft ecosystem. We explore practical use cases including IoT telemetry, application logging, centralized monitoring, clickstream analytics, fraud detection, predictive maintenance, and large-scale data pipelines. You'll see how Event Hubs integrates with Azure Functions, Stream Analytics, Azure Data Lake, Databricks, Power BI, and machine learning solutions to transform raw event streams into actionable business insights. By separating producers from consumers, Event Hubs enables highly scalable architectures where multiple systems analyze the same data simultaneously without impacting one another.

EVENT HUBS VS. EVENT GRID VS. SERVICE BUS
One of the biggest sources of confusion in Azure architecture is choosing between Event Hubs, Event Grid, and Service Bus. This episode provides a clear comparison, explaining when to use each service and why they complement rather than replace one another. Learn why Event Grid is optimized for lightweight event notifications, Service Bus excels at reliable enterprise messaging and ordered workflows, and Event Hubs is purpose-built for high-volume real-time streaming. We also discuss pricing tiers, scaling strategies, throughput optimization, and best practices for building your first production-ready streaming architecture in Azure. Whether you're preparing for Azure certifications or designing enterprise cloud solutions, this episode gives you the practical knowledge needed to confidently work with Azure Event Hubs.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Event Grid - Simply Explained

Wed, 15 Jul 2026 20:00:02 +0000

Learn Azure Event Grid in plain English: event sources, subscriptions, filtering, delivery, handlers, and practical event-driven Azure architecture.

Modern cloud applications need to react instantly when something happens. A file is uploaded, a virtual machine is created, or an order is placed—and the right services should respond automatically without constantly checking for changes. In this episode of m365.fm, we explain Azure Event Grid in plain English, showing how it enables event-driven architectures that are faster, more efficient, and easier to scale than traditional polling-based systems. Through simple real-world examples and an easy-to-understand smart home analogy, you'll learn how Event Grid helps Azure services communicate automatically while reducing unnecessary compute, network traffic, and operational complexity.

WHY POLLING IS HOLDING YOUR APPLICATIONS BACK
Many applications still rely on polling, repeatedly asking whether something has changed even when nothing has happened. This creates unnecessary CPU usage, network traffic, and cloud costs while introducing delays between an event occurring and an application responding. We explain why event-driven architectures solve this problem by replacing constant requests with intelligent notifications. Instead of repeatedly checking for updates, applications simply wait until Event Grid tells them something important has happened, creating faster, more responsive, and significantly more efficient systems.

EVENTS, TOPICS, AND SUBSCRIPTIONS EXPLAINED
Understanding Event Grid starts with understanding its core building blocks. Learn the difference between events, topics, subscriptions, and event handlers, and discover how Azure services publish lightweight notifications that are automatically routed to the right destinations. We explain System Topics, Custom Topics, Azure Functions, Logic Apps, Webhooks, Storage Queues, and fan-out scenarios where a single event can trigger multiple automated workflows simultaneously. By separating publishers from subscribers, Event Grid creates loosely coupled applications that are easier to maintain, extend, and scale.

FILTERING, RELIABILITY, AND EVENT DELIVERY
Not every service needs every event. This episode explores Event Grid's powerful filtering capabilities, allowing subscriptions to receive only the notifications they actually need based on event type, resource path, prefixes, suffixes, or custom properties. We also cover enterprise-grade reliability features including automatic retries, exponential backoff, dead-lettering, and failure handling. You'll learn how Event Grid ensures important business events aren't silently lost while giving administrators complete visibility into failed deliveries and processing issues.

EVENT GRID VS. EVENT HUBS VS. SERVICE BUS
Azure offers several messaging services, and understanding when to use each one is critical. We compare Event Grid, Event Hubs, and Azure Service Bus, explaining the unique role each service plays within modern cloud architectures. Discover why Event Grid is designed for event notifications and serverless automation, Event Hubs excels at high-throughput telemetry and streaming workloads, and Service Bus provides reliable enterprise messaging with guaranteed delivery and ordered processing. Whether you're building cloud-native applications, automating Azure resources, or designing enterprise integration solutions, this episode provides the practical knowledge you need to choose the right Azure messaging service for every scenario.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

API Gateway - Simply Explained

Wed, 15 Jul 2026 19:00:02 +0000

Too many services, each with its own URL, security and error handling? This episode explains the API gateway pattern in plain English for developers and architects building on Azure or any microservices platform, and shows how one front door simplifies routing, security and traffic management.

In this episode

00:00 – The problem: too many doors
01:08 – What is an API gateway?
02:30 – Part 1: Routing traffic
04:31 – Part 2: Security at the front door
06:00 – Part 3: Traffic management
07:25 – Part 4: Data transformation
09:15 – How it all connects
10:20 – Actionable takeaways

Key takeaways

An API gateway gives clients one front door to many backend services and hides where those services live.
Routing, authentication, rate limiting, load balancing and data transformation run in one pipeline with central visibility.
Once you have three or more services or external API consumers, start by centralizing authentication at the gateway, then add rate limiting.

Worth quoting

“It's a single entry point that sits between your clients and your backend services. Every request goes through the Gateway first. It decides where to send it, whether to allow it, and what to send back.” – Mirko Peters (01:58)

“The Gateway is a single place to revoke access when something goes wrong. If a client's API key is compromised, you revoke it at the Gateway.” – Mirko Peters (05:25)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and FAQ
Azure API Management – named as Azure's full API platform, with the gateway as its traffic-handling core
Microsoft Azure – the cloud where the episode suggests Azure API Management as a solid gateway choice
Related episode: Azure API Management - Simply Explained
Related episode: Microsoft Graph Webhooks - Simply Explained
Related episode: AI Turns Integration into an Organism as a Service — How Azure Logic Apps Are Changing Enterprise Integration with Sonny Gillissen [MVP]

The Partnership Mistakes That Cost Partners Millions

Wed, 15 Jul 2026 18:00:02 +0000

Many Microsoft partners win deals yet stall because of execution gaps that quietly cost them millions. This episode walks MSPs, CSPs, ISVs and consulting partners through twelve common partnership mistakes, from marketplace expectations and co-sell overload to unused incentives, and shows how Veeam turned its partnership around.

In this episode

00:00 – Why winning deals is not building a business
00:38 – The expectation gap: marketplace is not lead flow
01:35 – The ownership void and sales compensation
02:56 – The readiness gap: finance and messaging
04:44 – The credibility trap: certifications and the one-page plan
06:05 – The data black hole: referrals and co-sell overload
07:52 – Growth bottlenecks, ops and the feedback loop
10:55 – The recovery playbook: lessons from Veeam

Key takeaways

Microsoft is an amplifier, not a lead engine: listing on the marketplace or earning a designation only pays off once you bring a clear story and demonstrated value.
Partnerships need a dedicated owner, aligned sales compensation, a finance team ready for marketplace and incentive payments, and messaging mapped to specific Microsoft seller roles.
Be surgical with co-sell by focusing on a few high-value deals, reinvest incentives instead of letting them disappear into revenue, and keep a weekly rhythm with your partner development manager.

Explore more on M365.FM

Episode page: the full episode with chapters, all twelve mistakes and FAQ
Microsoft Marketplace – the listing channel the episode calls an amplifier for partners, not a source of lead flow
Microsoft – the partner whose sellers, PDMs, incentives and co-sell programs partners must learn to work with
Related episode: How to Become a High: Performing Microsoft Partner
Related episode: The Microsoft Partner Journey Explained

Azure DevOps in 2026: The Quiet Backbone of Enterprise AI

Wed, 15 Jul 2026 17:00:02 +0000

Everyone is talking about GitHub, Copilot, and AI-powered development, leading many to believe Azure DevOps is becoming obsolete. But inside Fortune 500 enterprises, a very different story is unfolding. While GitHub has become the preferred platform for developer productivity and AI-assisted coding, Azure DevOps continues to power the governance, compliance, and operational backbone of enterprise software delivery. In this episode, we explore why Azure DevOps remains indispensable in 2026 and why its role has become even more critical as organizations deploy regulated AI solutions at scale.

WHY ENTERPRISES ARE NOT ABANDONING AZURE DEVOPS
The widespread narrative suggests every organization is migrating to GitHub, but regulated industries such as banking, healthcare, pharmaceuticals, and government are following a far more pragmatic strategy. Instead of replacing Azure DevOps, they are adopting hybrid architectures that combine GitHub's developer experience with Azure DevOps' mature governance capabilities. We examine why compliance requirements, auditability, release management, and enterprise traceability continue to make Azure DevOps the platform of choice for mission-critical workloads, even as GitHub dominates developer mindshare.

AI GOVERNANCE IS CHANGING THE DEVOPS LANDSCAPE
Artificial Intelligence has fundamentally changed software delivery. Modern AI applications require continuous evaluation, approval workflows, safety testing, model monitoring, prompt versioning, retrieval validation, and complete audit trails. This episode explains how Azure DevOps Pipelines naturally evolve into an enterprise LLMOps control plane, orchestrating every stage of AI deployment while producing the evidence required by regulations such as the EU AI Act. Rather than simply deploying code, Azure DevOps becomes the system responsible for governing AI throughout its entire lifecycle.

THE RISE OF HYBRID DEVOPS ARCHITECTURES
Forward-thinking organizations are no longer asking whether GitHub or Azure DevOps is better. Instead, they are designing architectures that leverage the strengths of both platforms. GitHub accelerates innovation through repositories, pull requests, GitHub Actions, and Copilot, while Azure DevOps manages enterprise planning, governance, release approvals, compliance, and portfolio management. You'll learn why hybrid operating models consistently outperform full migrations in both cost and risk while providing greater flexibility for modern engineering organizations.

UNDERSTANDING THE TRUE COST OF MIGRATION
Migrating from Azure DevOps to GitHub is far more complex than copying repositories. We examine the hidden costs of rebuilding pipelines, replacing governance processes, retraining teams, maintaining parallel platforms, and redesigning enterprise integrations. You'll discover why many organizations experience significant first-year cost increases during full migrations and why selective adoption often delivers a far stronger long-term return on investment. HOW CIOS

SHOULD APPROACH PLATFORM STRATEGY
Technology leaders should stop viewing GitHub and Azure DevOps as competing products. Instead, they should classify workloads according to business risk, regulatory exposure, innovation requirements, and governance needs. This episode presents a practical framework for designing an enterprise DevOps strategy that balances developer productivity with compliance, enabling organizations to build secure, scalable, and AI-ready software delivery platforms for the years ahead.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Your AppSource Listing Is Costing You Deals

Wed, 15 Jul 2026 16:00:02 +0000

Many Microsoft partners publish an AppSource listing once and wonder why it never generates pipeline. This episode is for ISVs and partner marketers, and explains a three-layer framework of SEO, generative engine optimization and buyer psychology, plus three concrete moves to make this week.

In this episode

00:00 – Three layers: SEO, GEO and buyer psychology
00:37 – Why your listing isn't producing pipeline
02:23 – How the AppSource ranking algorithm works
04:14 – The SEO layer: title, keywords and visuals
06:05 – The GEO layer: AI discovery and Copilot
08:02 – Building citations and authority for AI
09:54 – The psychology layer: five triggers that convert
12:10 – Structuring the listing and three moves for this week

Key takeaways

An AppSource listing has to work on three layers at once: SEO so buyers find it, generative engine optimization so AI assistants cite it, and buyer psychology so visitors act.
Titles that combine brand, function and search keyword, outcome-led first 50 words, captioned screenshots and use-case-specific social proof drive ranking and conversion.
AI systems cite brands that appear on trusted external sources such as Reddit, LinkedIn and the Microsoft Tech Community, so partners should test buyer prompts in ChatGPT and Copilot and run App Advisor on their listing.

Explore more on M365.FM

Episode page: the full episode with chapters, the three-layer framework and FAQ
Microsoft AppSource – the marketplace whose listings the episode shows how to optimize for search, AI citation and conversion
ChatGPT – an AI assistant buyers now ask for solutions, used to test whether your listing gets cited
Dynamics 365 – the platform behind most example buyer prompts and listing titles in the episode
Microsoft 365 Copilot – named with ChatGPT as an AI surface where buyers ask for recommendations and partners test prompts
Related episode: Microsoft AppSource - Simply Explained

The Hard Way to Get Listed on Microsoft Marketplace

Wed, 15 Jul 2026 15:00:02 +0000

Getting your solution listed on Microsoft Marketplace sounds simple—until you actually try to do it. Microsoft provides a straightforward checklist, but behind every requirement lies weeks of engineering, legal reviews, technical integration, and operational planning. In this episode of m365.fm, we break down the complete Microsoft Marketplace publishing journey, uncover the most common mistakes that delay approvals, and explain why so many partners underestimate what it really takes to become Marketplace-ready. Whether you're publishing to Azure Marketplace or AppSource, this episode provides the roadmap to avoid costly mistakes and accelerate your path to a successful listing.

UNDERSTANDING THE REAL REQUIREMENTS
Microsoft officially outlines seven major requirements for Marketplace publishing, including partner enrollment, technical integration, pricing models, compliance documentation, go-to-market assets, and operational readiness. However, each requirement is far more involved than it first appears. We explore why identity verification, banking validation, international tax profiles, Microsoft Entra ID integration, SaaS fulfillment APIs, ARM templates, usage metering, privacy policies, legal documentation, and security reviews all require careful planning long before you click "Submit." Treating Marketplace publishing as an engineering project instead of an administrative task is often the difference between approval and repeated rejection.

THE FIVE MISTAKES THAT CAUSE MOST REJECTIONS
One of the most valuable sections of this episode covers the five administrative errors responsible for the majority of Microsoft Marketplace review failures. Learn why missing Terms of Use, incomplete Privacy Policies, inadequate reviewer testing instructions, undisclosed service dependencies, and hidden purchase requirements repeatedly send submissions back for correction. These aren't technical failures—they're avoidable documentation mistakes that can add weeks or even months to your publishing timeline. We also explain how to prepare your submission so Microsoft reviewers can validate your solution quickly and efficiently on the first attempt.

APPSOURCE VS. AZURE MARKETPLACE
Choosing the wrong storefront can significantly reduce your visibility and delay your go-to-market strategy. This episode compares Azure Marketplace and Microsoft AppSource, explains the different buyer personas each platform serves, and highlights why business applications, SaaS offerings, infrastructure solutions, and Azure-native services require different publishing strategies. We also discuss Microsoft's long-term Marketplace unification plans, multi-year pricing implications, customer purchasing experiences, Azure subscription requirements, and how selecting the right storefront impacts discoverability, enterprise procurement, and long-term sales success.

FROM MARKETPLACE LISTING TO REAL BUSINESS GROWTH
Publishing your offer is only the beginning. We explain why Marketplace listings don't automatically generate pipeline, how Microsoft operates its agency model, and why seller enablement, co-sell readiness, Azure IP Co-Sell eligibility, MACC (Microsoft Azure Consumption Commitment), and ongoing marketplace optimization are essential for sustained growth. You'll learn how to activate Microsoft's field sellers, prepare effective go-to-market assets, maintain Marketplace visibility, and build a repeatable sales engine that turns Marketplace into a scalable revenue channel instead of simply another product directory. Whether you're an ISV, MSP, CSP, or Azure consulting partner, this episode provides practical guidance for building a successful Microsoft Marketplace strategy from day one.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

The FY26 Partner Designation Restructuring Is Coming — Most Partners Aren't Ready

Wed, 15 Jul 2026 14:00:03 +0000

Microsoft's FY26 Partner Program changes represent the biggest transformation to the Microsoft AI Cloud Partner Program since the retirement of Silver and Gold competencies. In this episode of m365.fm, we explore what the new FY26 Partner Designation restructuring means for Microsoft partners, Managed Service Providers (MSPs), Cloud Solution Providers (CSPs), Independent Software Vendors (ISVs), and Azure consulting firms. You'll learn why Microsoft is consolidating solution areas, introducing new partner designations, expanding AI-focused opportunities, and fundamentally changing how partners are evaluated, discovered, and rewarded. If your business depends on Microsoft incentives, co-sell, Azure consumption, or marketplace visibility, understanding these changes is essential for remaining competitive.

WHY MICROSOFT IS RESTRUCTURING THE PARTNER PROGRAM
For years, Microsoft's partner ecosystem relied on six separate solution areas, creating fragmented partner strategies and making it difficult for Microsoft sellers to identify true delivery expertise. FY26 changes that completely. This episode explains why Microsoft is consolidating its commercial solution areas, how AI Business Solutions and Cloud & AI Platforms reshape partner positioning, and why Security remains a dedicated specialization with significantly higher validation standards. You'll discover how Microsoft's entire go-to-market strategy is shifting toward measurable customer outcomes, AI transformation, cloud adoption, and deeper technical capability instead of simply collecting multiple partner badges.

NEW DESIGNATIONS, SPECIALIZATIONS, AND FRONTIER PARTNERS
FY26 introduces far more than new names. We examine the new Support Services, Distributor, Device, and Copilot-focused designations, along with Microsoft's new Frontier Partner status for elite organizations delivering end-to-end AI transformation. Learn what each designation unlocks, how Advanced Specializations become even more valuable, and why Microsoft's third-party validation process is becoming increasingly important. We also explain how these designations influence Partner Center visibility, Azure Marketplace discovery, Microsoft field seller recommendations, and future co-sell opportunities. Partners who understand these changes early will gain a significant competitive advantage while others struggle to adapt after renewal deadlines arrive.

INCENTIVES, AZURE ACCELERATE, ECIF, AND CO-SELL
The financial impact of FY26 could be substantial. This episode breaks down Azure Accelerate, increased Copilot and Power Platform funding, Security investment growth, Partner Earned Credit (PEC), ECIF (End Customer Investment Funds), and Microsoft's renewed focus on outcome-based partner incentives. You'll learn why Advanced Specializations are now the gateway to Microsoft's largest deployment investments, how proper attribution through PAL and CPOR drives Partner Capability Score improvements, and why many partners unknowingly leave hundreds of thousands of dollars in available funding on the table each year. We also explore how Marketplace transactions, Azure consumption, and co-sell activities are becoming increasingly interconnected under Microsoft's new commercial strategy.

BUILDING YOUR FY26 PARTNER STRATEGY
Rather than chasing every new badge, successful partners will need a deliberate roadmap. We explain how to choose your anchor designation, sequence additional designations efficiently, maximize overlapping qualification windows, and align certifications with future Advanced Specializations. You'll also learn how to update your Marketplace presence, modernize your messaging around Microsoft's new commercial solution areas, improve Partner Capability Score performance, and position your organization for long-term growth under the FY26 model. Whether you're an MSP, CSP, ISV, Azure consultancy, Security specialist, or Microsoft distributor, this episode provides practical guidance to help you prepare for Microsoft's largest partner ecosystem transformation in years and ensure your business is ready before the changes fully take effect.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Beyond Chat: Building Real Business Value with Microsoft 365 Copilot Agents featuring Steve Corey [MVP]

Wed, 15 Jul 2026 13:00:03 +0000

Many organizations stop at chatting with AI and never build agents that deliver business value. Mirko Peters and Microsoft MVP Steve Corey walk IT decision-makers, architects and developers through agent anatomy, tool choice from SharePoint agents to Foundry, and the security model that keeps agents from going rogue.

In this episode

00:00 – Welcome and Steve Corey's journey
05:00 – What is a Microsoft 365 Copilot agent?
09:09 – Instructions, knowledge and tools
19:10 – Protocols, ecosystems and getting started
25:45 – Real-world example: an intranet agent
33:10 – SharePoint agents, Agent Builder, Copilot Studio or Foundry?
35:50 – Security, permissions and agent harnesses
52:30 – Autonomous and multi-agent future, rapid-fire round

Key takeaways

Microsoft 365 Copilot is a generalist, while agents are specialists built from instructions, knowledge and tools to do one job exceptionally well.
Secure and govern your data before turning on AI, because agents and Copilot will surface every overshared file.
Start with the simplest option, such as a SharePoint agent, and apply least privilege before moving to Copilot Studio, custom engine agents or Foundry.

Worth quoting

“The agent is the opposite of that. It's not designed to do everything under the sun. It's designed to do one thing, and it's designed to do it exceptionally well, because you're going to teach this agent what it needs to know.” – Steve Corey (05:50)

“But really those three things, instructions, knowledge and tools are the core things that make up an agent.” – Steve Corey (11:45)

Explore more on M365.FM

Episode page: the full conversation with chapters, quotes and FAQ on Copilot agents
Steve Corey – Microsoft MVP who explains agent anatomy, tool choice and least-privilege security for agents
AI agent – defined as a specialist built from instructions, knowledge and tools for one job
Microsoft 365 Copilot – the generalist assistant that agents complement, and the base for declarative agents
Related episode: Copilot Agents - Simply Explained

How to Become a High: Performing Microsoft Partner

Wed, 15 Jul 2026 12:00:04 +0000

Many Microsoft partners win deals but stall because they never connect their work to the partner program's scorecard. This episode is for partner leaders and practice owners who want a practical path through the Partner Capability Score, CPOR, Partner Admin Link, designations, specializations, co-sell, ECIF and MACC so that each customer engagement compounds into incentives and funding.

In this episode

00:00 – Why winning deals is not the same as building a business
00:52 – The mindset shift: deals versus systems
01:55 – The Partner Capability Score
03:41 – CPOR, the hidden accelerator
05:48 – From designations to advanced specializations
07:51 – Co-sell and the marketplace
10:50 – The funding stack: ECIF, MACC and credits
13:40 – Data, attribution and the flywheel

Key takeaways

The Microsoft partner program rewards systems rather than single deals: every onboarded customer, certification and usage metric feeds the Partner Capability Score, and 70 points with at least one point per subcategory earns a Solutions Partner designation.
Attribution decides whether your work counts, so file CPOR claims with a properly signed proof of execution and set up Partner Admin Link for every Azure customer you support.
Advanced specializations unlock ECIF funding, while marketplace offers that are MACC-eligible and co-sell ready make it easier for Microsoft sellers and enterprise customers to buy from you.

Explore more on M365.FM

Episode page: the full episode with chapters, step-by-step claim tips and a short FAQ
Microsoft Marketplace – the system of record for co-sell, MACC-eligible offers and published consulting services
Microsoft 365 Certified: Fundamentals (MS-900) – the fundamentals exam that gives five skilling points per person toward the Partner Capability Score
Related episode: The Microsoft Partner Journey Explained
Related episode: The Partnership Mistakes That Cost Partners Millions
Related episode: Microsoft AppSource - Simply Explained

The Microsoft Partner Journey Explained

Wed, 15 Jul 2026 11:00:03 +0000

Many Microsoft partners still think in Silver and Gold tiers and leave real money on the table. This episode explains to partner owners and alliance managers how membership, Solutions Partner designations and specializations work today, what the Partner Capability Score measures and how incentives and MDF really pay out.

In this episode

00:00 – Why the old Silver and Gold model is gone
02:16 – The membership layer
03:33 – What a Solutions Partner designation requires
05:20 – The six solution areas and the coming consolidation
06:32 – Benefits and incentives of a Solutions Partner
08:53 – Specializations, where the economics change
10:36 – Co-op, MDF and money left on the table
11:58 – Building your partner journey roadmap

Key takeaways

The Microsoft partner journey has three layers, membership, Solutions Partner designation and specialization, and the program now measures customer outcomes instead of certifications.
A Solutions Partner designation requires 70 of 100 Partner Capability Score points with no zero in any metric, and customer success through usage growth and deployments carries the most weight.
Partners should check their capability score and MDF balance in Partner Center, start with one solution area such as Modern Work and then target a first specialization.

Explore more on M365.FM

Episode page: the full episode with chapters, costs, scoring rules and a short FAQ
Microsoft Azure – provides the starter credits in membership bundles and three of the six solution areas
Microsoft 365 – behind the Modern Work designation, named as the easiest first solution area for most partners
Dynamics 365 – maps to the Business Applications solution area and appears among membership license benefits
Related episode: How to Become a High: Performing Microsoft Partner
Related episode: The Partnership Mistakes That Cost Partners Millions

How to Build a Winning Microsoft Partner Strategy

Wed, 15 Jul 2026 10:00:02 +0000

Learn how to build a Microsoft partner strategy with focused positioning, customer value, Microsoft alignment, proof, sales execution, and measurable growth.

What separates Microsoft partners that consistently grow from those that simply maintain their status? In this episode of m365.fm, we break down the four strategic pillars that transform Microsoft partner program participation into measurable business growth. Learn why simply earning a Solutions Partner designation is no longer enough in 2026 and discover how successful partners align certifications, co-sell opportunities, marketplace strategy, and operational excellence to accelerate revenue and strengthen their position in the Microsoft ecosystem.

WHY MOST PARTNER STRATEGIES FAIL
Many organizations focus on collecting partner designations instead of building a sustainable business strategy. We explore the most common mistakes Microsoft partners make, including chasing Partner Capability Score points without a clear revenue plan, relying on outdated reseller business models, and overlooking the importance of marketplace visibility. You'll learn why customer outcomes, cloud consumption, and AI-driven transformation have become the foundation of Microsoft's partner ecosystem.

THE FOUR PILLARS OF SUCCESS
Discover how to choose the right Microsoft Solutions Partner designations, build an effective co-sell strategy with Microsoft field teams, leverage Azure Marketplace and AppSource as scalable sales channels, and create the operational processes needed to maximize incentives, Partner Center insights, and long-term profitability. The episode also covers new 2026 partner requirements, marketplace trends, MACC alignment, certified software expectations, and how to prepare your organization for future growth.

YOUR 90-DAY MICROSOFT PARTNER ACTION PLAN
The episode concludes with a practical 90-day roadmap designed to help Microsoft partners audit their current Partner Capability Score, optimize designations, improve co-sell readiness, publish marketplace offers, and establish operational governance that supports sustainable growth. Whether you're a reseller, managed service provider, systems integrator, or ISV, this episode provides actionable guidance to help you build a winning Microsoft partner strategy for 2026 and beyond.

Explore more on M365.FM

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure MCP Server - Simply Explained

Wed, 15 Jul 2026 09:00:20 +0000

AI agents only become useful when they can safely touch real systems, yet every custom integration adds code, credentials and risk. This Simply Explained episode is for Azure admins, cloud engineers and developers who want to understand MCP and Azure MCP Server in plain English, and how one protocol lets agents query logs, check configuration and fix issues using your existing Azure security model.

In this episode

00:00 – Why AI agents need a standard way to connect
01:48 – What MCP is: tools, resources and prompts
03:25 – The integration tax and fragmentation problem
05:34 – What Azure MCP Server is
07:41 – Azure services you can reach
10:00 – Under the hood: Entra ID, RBAC, transport and OBO
12:44 – Real-world troubleshooting example
15:02 – The bigger picture and what comes next

Key takeaways

MCP is an open standard, originally created by Anthropic, that gives AI agents one common way to discover and call tools, resources and prompts instead of custom glue code per integration.
Azure MCP Server is Microsoft's open-source MCP implementation that exposes Azure Storage, Cosmos DB, Azure Monitor, App Configuration and the Azure CLI to any MCP-compatible agent.
Security is inherited rather than invented: Entra ID authentication, Azure RBAC authorization, on-behalf-of identity pass-through and optional Azure API Management governance.

Worth quoting

“MCP stands for model context protocol, and it's an open standard that tells AI agents how to talk to external tools, APIs, and data sources. Think of it as a common language for AI.” – Mirko Peters (01:58)

“Instead of writing custom code for every AI tool, you build one MCP server. That server exposes your tools and data through a standard interface. Then any MCP compatible agent can use it.” – Mirko Peters (05:25)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ
Model Context Protocol (MCP) – the open protocol behind the episode, built on JSON-RPC 2.0 with tools, resources and prompts
AI agent – the agents that use MCP to query logs, change configuration and deploy fixes
Microsoft Azure – the platform whose Storage, Cosmos DB, Monitor and App Configuration the MCP server exposes
Related episode: Microsoft AI Gateway - Simply Explained

Dynamics 365 ERP MCP Server - Simply Explained

Wed, 15 Jul 2026 08:00:03 +0000

Connecting AI assistants to an ERP used to mean custom APIs, connectors and security workarounds. This Simply Explained episode is for Dynamics 365 users, IT pros and partners who want to understand how the Dynamics 365 ERP MCP server and the analytics MCP server let agents read ERP data and act on it through natural language, and how to try it safely in Copilot Studio or VS Code.

In this episode

00:00 – Why ERP data is hard to bring into AI
00:46 – What the Model Context Protocol is
01:52 – Static vs. dynamic ERP MCP server
03:36 – The analytics MCP server and BPA
05:25 – Real-world use cases from Microsoft and partners
07:25 – How to get started: prerequisites, Copilot Studio, VS Code
09:33 – Roadmap and future direction
11:26 – What this means for users, IT and partners

Key takeaways

The Dynamics 365 ERP MCP server exposes finance and operations functions to AI agents through one governed interface, and the dynamic version lets agents work through forms, including customizations and ISV extensions.
The analytics MCP server on Business Performance Analytics needs only two tools, get dataset schema and execute DAX query, and combining it with the action server turns insights into ERP actions.
Agents inherit the connected user's Dynamics 365 security, but the preview has limits such as a 120-second timeout, so start with low-risk tasks and keep a human in the loop for high-risk actions.

Worth quoting

“MCP is an open standard that lets AI applications discover and call tools and data sources in a structured way. Think of it like a universal remote.” – Mirko Peters (00:49)

“Customizations and ISV extensions become automatically visible to the agent. You don't need to write special code to expose your custom fields or custom processes.” – Mirko Peters (03:27)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on ERP MCP
Model Context Protocol (MCP) – the open standard that lets AI agents discover and call ERP tools through one interface
Dynamics 365 Finance and Operations – the ERP whose forms, actions and customizations the MCP server exposes to agents
ERP Analytics MCP – the separate server that lets agents query Business Performance Analytics data with DAX
Related episode: THE DEATH OF THE PROXY: Architecting Dataverse for the Agent Fabric

Canvas Apps vs Model-Driven Apps - Simply Explained

Wed, 15 Jul 2026 07:00:02 +0000

Microsoft Power Apps offers two primary ways to build business applications: Canvas Apps and Model-Driven Apps. At first glance they may appear similar, but they are designed for very different scenarios. Choosing the wrong app type can lead to unnecessary complexity, expensive redesigns, and weeks of additional work. In this episode, we explain the differences in plain English, helping you understand when to choose each approach and why the decision is based on your business requirements—not on how the app looks. Whether you're a Power Platform beginner, citizen developer, or enterprise architect, this episode gives you a practical framework for selecting the right tool for your next project.

UNDERSTANDING THE FUNDAMENTAL DIFFERENCE
The biggest difference between Canvas Apps and Model-Driven Apps isn't the user interface—it's where development begins. Canvas Apps start with the user experience. You begin with a blank screen and design every button, image, form, and navigation element yourself before connecting data. Model-Driven Apps take the opposite approach. They begin with your business data model in Microsoft Dataverse, automatically generating forms, views, dashboards, and navigation based on your data structure. One is design-first, while the other is data-first, and that single difference influences every design decision that follows.

CANVAS APPS – COMPLETE DESIGN FREEDOM
Canvas Apps provide maximum flexibility for creating custom user experiences. Developers can design every screen exactly as they want while connecting to hundreds of different data sources including SharePoint, Excel, SQL Server, Salesforce, Microsoft Dataverse, and many other systems. This makes Canvas Apps ideal for mobile-first applications, inspection forms, approval processes, dashboards, field service solutions, and task-focused business apps where branding, usability, and custom layouts are critical. The trade-off is that developers are responsible for building navigation, validation, business logic, and user interactions themselves.

MODEL-DRIVEN APPS – DATA COMES FIRST
Model-Driven Apps are built around Microsoft Dataverse and automatically generate a professional business application from your data model. Instead of designing screens manually, you define tables, relationships, security roles, and business rules. Power Apps then creates forms, views, navigation, dashboards, and responsive layouts automatically. This approach is ideal for enterprise applications such as CRM systems, case management, project tracking, compliance solutions, and business process automation where structured data, governance, and consistency are more important than visual customization.

REAL-WORLD USE CASES
Canvas Apps excel when users need highly customized interfaces, mobile experiences, offline capabilities, or applications that combine information from multiple external systems. Model-Driven Apps perform best when organizations require centralized business data, complex relationships, role-based security, auditing, and standardized business processes. Instead of asking which app type is better, organizations should focus on which business problem they are solving, because each platform has been optimized for a different category of application.

LICENSING CONSIDERATIONS
Licensing is another important factor when selecting an app type. Canvas Apps using only standard Microsoft 365 connectors such as SharePoint, Excel, Outlook, and OneDrive are often included within existing Microsoft 365 subscriptions. However, once an app uses Microsoft Dataverse or premium connectors, premium Power Apps licensing is required. Since Model-Driven Apps always rely on Dataverse, they require premium licensing by design. Understanding these licensing differences helps organizations avoid unexpected costs while planning new Power Platform solutions.

THE HYBRID APPROACH
Many successful organizations don't choose one app type—they combine both. A common architecture uses a Model-Driven App as the enterprise system of record while embedding Canvas Apps for specialized user experiences such as mobile inspections, guided workflows, or simplified data entry screens. Power Automate connects both environments, allowing organizations to combine enterprise governance with exceptional user experiences while keeping all business data centralized inside Microsoft Dataverse.

A SIMPLE DECISION FRAMEWORK
Choosing the correct app becomes much easier by asking four simple questions. Does your solution require Microsoft Dataverse? Is the primary focus user experience or business data? Do you need enterprise capabilities such as auditing, security roles, and business process flows? Finally, what licensing already exists within your organization? Answering these questions quickly identifies which Power Apps approach best fits your technical requirements, business goals, and budget without relying on guesswork.

COMMON MISTAKES TO AVOID
Many beginners select Canvas Apps simply because they enjoy designing interfaces, only to discover later that they need enterprise governance, auditing, or complex business processes that Model-Driven Apps provide automatically. Others choose Model-Driven Apps expecting unlimited design flexibility, only to find themselves fighting the platform's standardized interface. Understanding the strengths and limitations of both approaches before starting a project can prevent expensive redesigns and significantly improve long-term maintainability.

KEY TAKEAWAYS
Canvas Apps and Model-Driven Apps are not competing technologies—they solve different business challenges. Canvas Apps prioritize flexibility, user experience, and custom design across multiple data sources. Model-Driven Apps prioritize structured business data, governance, automation, and enterprise scalability through Microsoft Dataverse. Many of the best Power Platform solutions combine both approaches, allowing organizations to deliver exceptional user experiences while maintaining secure, scalable, and well-governed business applications.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Infrastructure as Code - Simply Explained

Wed, 15 Jul 2026 06:00:02 +0000

Managing cloud infrastructure by clicking through the Azure Portal might work for a single virtual machine, but it quickly becomes slow, inconsistent, and difficult to maintain as environments grow. Infrastructure as Code (IaC) changes that completely. In this episode, we explain Infrastructure as Code in plain English, showing how organizations automate Azure deployments using reusable templates instead of manual configuration. Whether you're an IT administrator, cloud engineer, developer, or just beginning your Azure journey, this episode provides a practical introduction to one of the most important concepts in modern cloud computing.

THE PROBLEM WITH MANUAL DEPLOYMENTS
Creating Azure resources manually through the portal introduces human error, inconsistent configurations, and configuration drift between development, testing, and production environments. Every mouse click becomes an opportunity to select the wrong region, choose an incorrect virtual machine size, misconfigure networking, or overlook important security settings. As organizations scale, these small inconsistencies become major operational challenges that consume valuable time and increase business risk. Infrastructure as Code eliminates these problems by replacing manual deployment with repeatable automation.

WHAT IS INFRASTRUCTURE AS CODE?
Infrastructure as Code, often abbreviated as IaC, is the practice of describing cloud infrastructure in source code instead of configuring resources manually. Rather than clicking through deployment wizards, administrators write files that define the desired infrastructure. Azure then reads these files and automatically provisions resource groups, virtual networks, storage accounts, virtual machines, databases, and security settings exactly as specified. This declarative approach focuses on the desired outcome while Azure handles the deployment process automatically.

THE AZURE INFRASTRUCTURE AS CODE TOOLKIT
Microsoft provides several technologies for implementing Infrastructure as Code. ARM Templates were the original deployment format, offering complete Azure coverage through JSON-based templates. Bicep builds upon ARM by providing a cleaner, easier-to-read language that compiles directly into ARM Templates while dramatically improving the authoring experience. Organizations operating across multiple cloud providers often choose Terraform, while Azure-focused teams increasingly adopt Bicep because of its native Azure integration, simplified syntax, and immediate support for new Azure services.

VERSION CONTROL CHANGES EVERYTHING
The greatest advantage of Infrastructure as Code is not simply automation—it's version control. By storing infrastructure definitions in Git repositories, organizations gain complete visibility into every infrastructure change. Teams can review modifications through pull requests, track deployment history, roll back problematic changes, and ensure development, testing, and production environments are built from the exact same source files. Infrastructure becomes fully auditable, collaborative, and significantly easier to maintain over time.

SECURITY BUILT INTO EVERY DEPLOYMENT
Infrastructure as Code enables organizations to standardize security from the very beginning. Encryption, networking policies, firewall rules, HTTPS enforcement, and compliance requirements become part of the deployment template itself instead of relying on manual configuration. Combined with Azure Policy, Azure Key Vault, and automated deployment pipelines, Infrastructure as Code helps organizations prevent configuration drift while ensuring every new environment follows the same secure baseline.

GETTING STARTED WITH IAC
Adopting Infrastructure as Code doesn't require rebuilding an entire Azure environment overnight. A practical starting point is exporting an existing Azure deployment as an ARM Template, studying its structure, and gradually transitioning to Bicep for future deployments. Microsoft provides free tooling through Azure CLI, Visual Studio Code, and the official Bicep extension, allowing administrators to learn incrementally while automating increasingly complex Azure workloads over time.

COMMON MISTAKES TO AVOID
New users often make several predictable mistakes when adopting Infrastructure as Code. Hardcoding passwords instead of using Azure Key Vault, treating templates as one-time deployment scripts, and making quick manual changes directly in the Azure Portal all introduce security risks and configuration drift. Maintaining descriptive templates, storing everything in source control, validating deployments before execution, and avoiding manual production changes help ensure long-term success with Infrastructure as Code.

WHY EVERY AZURE PROFESSIONAL SHOULD LEARN IAC
Infrastructure as Code has become a foundational skill for modern Azure administration. It improves deployment consistency, simplifies disaster recovery, enables CI/CD automation, strengthens security, supports collaboration, and dramatically reduces human error. Whether you're managing a single Azure subscription or enterprise-scale cloud platforms, Infrastructure as Code provides a reliable and scalable way to build, maintain, and evolve your cloud infrastructure with confidence.

KEY TAKEAWAYS
Infrastructure as Code replaces manual Azure configuration with repeatable, version-controlled deployment files that become the single source of truth for your cloud environment. By combining automation, security, governance, and collaboration into one modern workflow, IaC allows organizations to deploy Azure resources faster, reduce operational risk, and maintain consistent environments across every stage of the application lifecycle. It's no longer an advanced cloud technique—it's the standard approach to managing modern Azure infrastructure.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Bicep - Simply Explained

Wed, 15 Jul 2026 05:00:03 +0000

Deploying Azure resources by clicking through the portal is hard to repeat, document and hand off. This episode is for Azure admins, cloud engineers and developers new to infrastructure as code, and explains what Bicep is, how it compares with ARM templates and Terraform, and how to deploy your first file.

In this episode

00:00 – Why clicking around in the portal fails
01:26 – What infrastructure as code means
02:35 – The ARM template problem
04:04 – What Bicep is
06:02 – Bicep versus ARM templates
08:17 – Bicep versus Terraform
09:57 – Getting started with Azure CLI and VS Code
12:15 – Idempotency and where Bicep fits in Azure

Key takeaways

Infrastructure as code replaces manual portal deployments with declarative, version-controlled files that produce the same result every time they run.
Bicep compiles to ARM JSON and uses the same Azure Resource Manager engine, but needs roughly half the code, infers dependencies automatically and adds modules and what-if previews.
For Azure-focused teams Bicep avoids Terraform's state file and supports new Azure features on day one; getting started only takes the Azure CLI and the Bicep extension for VS Code.

Worth quoting

“Here's the thing, clicking around works for learning. It fails for production. So what's the alternative? You write a file that describes what you want, then you tell Azure to build it.” – Mirko Peters (01:24)

“That's an important distinction. Infrastructure as code is the concept. Bicep is just one tool that implements it.” – Mirko Peters (02:29)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on Bicep
Bicep – the episode's main subject: a language that compiles to ARM JSON with simpler syntax
Infrastructure as code – the concept Bicep implements, replacing portal clicking with declarative, version-controlled files
Terraform – compared with Bicep on multi-cloud reach, state files and support for new Azure features
Microsoft Azure – the platform whose portal-based deployments Bicep replaces with repeatable files
Mirko Peters – hosts this episode and walks through a first Bicep deployment step by step
Related episode: ARM Templates - Simply Explained

ARM Templates - Simply Explained

Wed, 15 Jul 2026 04:00:03 +0000

Still clicking through the Azure portal to build the same environment again and again? This episode explains ARM templates and infrastructure as code in plain English for Azure admins and developers, and shows how to deploy repeatable environments, make templates reusable and when to move to Bicep.

In this episode

00:00 – Intro: stop clicking through the portal
00:42 – What Azure Resource Manager is
02:20 – Infrastructure as code: the big idea
04:30 – Anatomy of an ARM template
06:50 – Making templates reusable
08:51 – How deployment works
10:55 – The Bicep evolution
13:03 – Common mistakes and how to avoid them

Key takeaways

Azure Resource Manager is the control layer behind every Azure request, and ARM templates are its declarative, idempotent JSON blueprints.
Parameters, variables, conditions, copy loops and linked templates let one template serve development, test and production environments.
Bicep is recommended for new deployments and compiles to ARM JSON, so understanding ARM still helps when troubleshooting deployments.

Worth quoting

“The second approach is declarative, and that's what Arm templates use. Instead of telling Azure how to build something, you just describe what you want the end result to look like.” – Mirko Peters (03:20)

“Arm templates are idempotent. That's a fancy word meaning you can deploy the same template 100 times and get the same result.” – Mirko Peters (04:12)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on ARM templates
Bicep – presented as the cleaner language that compiles to ARM JSON and is recommended for new deployments
Infrastructure as code – the core idea behind ARM templates, explained through declarative versus imperative deployment
Visual Studio Code – recommended with the ARM Tools extension to catch JSON syntax errors and name mismatches
Mirko Peters – hosts this Knowledge Nugget and walks through ARM templates from structure to deployment
Related episode: Azure Resource Manager - Simply Explained

Teams Telephony - Simply Explained

Wed, 15 Jul 2026 03:00:02 +0000

Microsoft Teams Telephony transforms Microsoft Teams into a complete cloud-based business phone system, replacing traditional office PBXs with a modern, software-powered solution. In this episode, we explain Teams Telephony in plain English, showing how it enables organizations to make and receive business calls from virtually any device while integrating seamlessly with Microsoft 365. Whether you're an IT administrator, business owner, or simply curious about Microsoft's calling platform, this episode breaks down everything you need to know—from cloud PBX and licensing to calling plans, security, and real-world business benefits.

WHAT IS MICROSOFT TEAMS TELEPHONY?
Teams Telephony is Microsoft's cloud-based business phone system built directly into Microsoft Teams. Instead of relying on traditional desk phones connected to physical PBX hardware, your business phone number follows your Microsoft account across your laptop, smartphone, tablet, desktop computer, or certified Teams phone. Every device becomes your office phone, allowing employees to work from anywhere while maintaining the same business number, voicemail, contacts, and call history.

REPLACING THE TRADITIONAL PBX
Traditional phone systems required expensive hardware, dedicated phone lines, onsite maintenance, and complex upgrades. Teams Telephony replaces this entire infrastructure with a cloud-hosted Phone System managed by Microsoft. Organizations no longer need to maintain PBX hardware, install new phone lines for employees, or schedule technicians for everyday configuration changes. New users can often be provisioned in minutes simply by assigning licenses and phone numbers through the Microsoft 365 administration portal.

THREE WAYS TO CONNECT TO THE PUBLIC PHONE NETWORK
Connecting Teams to the public telephone network is one of the most important concepts to understand. Microsoft offers three primary connectivity options. Microsoft Calling Plans provide the simplest fully managed experience directly from Microsoft. Operator Connect allows organizations to continue using approved telecommunications providers while integrating seamlessly with Teams. Direct Routing offers maximum flexibility by connecting existing phone infrastructure through certified Session Border Controllers, making it ideal for organizations with more advanced telephony requirements or existing carrier investments.

LICENSING AND COSTS
Teams Telephony is licensed separately from the standard Microsoft Teams application. Organizations typically require a Teams Phone license alongside their chosen calling connectivity option. While pricing varies depending on licensing, calling plans, and deployment model, many businesses experience significant cost savings compared to maintaining traditional on-premises PBX systems. Reduced hardware investments, simplified administration, and cloud-based management often lower both operational costs and long-term infrastructure expenses.

ENTERPRISE FEATURES FOR EVERY BUSINESS
Teams Telephony includes advanced enterprise calling capabilities that were traditionally available only through expensive business phone systems. Features such as voicemail transcription, auto attendants, call queues, delegation, call park, presence integration, and intelligent call routing are built directly into the platform. These capabilities allow even small organizations to deliver professional customer experiences while simplifying internal communication and reducing administrative overhead.

SECURITY, COMPLIANCE AND RELIABILITY
Microsoft secures Teams Telephony using enterprise-grade encryption, Microsoft Entra identity, multi-factor authentication, and global cloud infrastructure. Organizations benefit from high availability, encrypted voice traffic, compliance capabilities, and centralized administration through Microsoft 365. Features supporting regulatory requirements such as GDPR and HIPAA help organizations protect sensitive communications while meeting industry compliance obligations.

HOW EVERYTHING WORKS TOGETHER
The true strength of Teams Telephony comes from the integration of its individual components. Incoming calls flow through auto attendants, call queues intelligently distribute conversations, voicemail automatically generates transcripts, and presence information helps users understand colleague availability. Because every capability operates inside Microsoft Teams, employees no longer need separate applications or disconnected communication systems. The result is a unified communication platform that combines chat, meetings, collaboration, and enterprise telephony into a single experience.

GETTING STARTED WITH TEAMS TELEPHONY
Organizations adopting Teams Telephony should begin by reviewing their existing Microsoft 365 licensing, evaluating the most suitable PSTN connectivity option, and running a pilot deployment with a small group of users before expanding company-wide. This phased approach allows businesses to validate call quality, user experience, and configuration while minimizing deployment risks and ensuring a smooth migration from legacy phone systems.

KEY TAKEAWAYS
Teams Telephony is much more than internet calling—it's a complete cloud-native business phone platform designed for the modern workplace. By replacing traditional PBX hardware with Microsoft Teams, organizations gain greater flexibility, lower infrastructure costs, stronger security, enterprise-grade calling features, and seamless integration with Microsoft 365. Whether employees work in the office, remotely, or on the move, Teams Telephony delivers a consistent business calling experience from virtually any device.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure DevOps - Simply Explained

Wed, 15 Jul 2026 02:00:02 +0000

Juggling separate tools for tasks, code, testing and deployment that never talk to each other? This episode explains Azure DevOps in plain English for beginners, makers and IT pros, and shows how its five connected services take a feature from idea to production.

In this episode

00:00 – Intro: too many disconnected tools
01:08 – What Azure DevOps is
02:37 – Azure Boards: planning and tracking
05:04 – Azure Repos: version control with Git
07:00 – Azure Pipelines: CI/CD automation
09:27 – Azure Test Plans: structured testing
11:49 – Azure Artifacts: shared packages
13:35 – How it all fits together and first steps

Key takeaways

Azure DevOps is one connected platform of five services: Boards for planning, Repos for code, Pipelines for automation, Test Plans for quality and Artifacts for packages.
Linking work items, commits, pipeline runs, test cases and bugs gives full traceability from a user story to the deployed feature.
Start small on the free tier: create a project in Boards, track a few tasks, then add Repos and Pipelines one step at a time.

Worth quoting

“It's one connected platform that handles the entire software development lifecycle, planning, coding, testing, deploying, all in one place.” – Mirko Peters (00:51)

“Because manual deployments are the number one source of production incidents. Someone forgets the step. Someone copies the wrong file. Someone deploys to the wrong environment. Pipelines eliminate all of that.” – Mirko Peters (08:58)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short Azure DevOps FAQ
Azure DevOps – the episode's subject: Boards, Repos, Pipelines, Test Plans and Artifacts in one platform
Mirko Peters – host walking beginners through the five Azure DevOps services and how they connect
Related episode: Git - Simply Explained
Related episode: GitHub Actions - Simply Explained

PowerShell - Simply Explained

Wed, 15 Jul 2026 01:00:02 +0000

Still clicking through the same menus every day? This episode explains PowerShell in plain English for IT admins and beginners, from the verb-noun pattern and objects to the pipeline and the five cmdlet groups that cover most daily work, so you can write your first automation today.

In this episode

00:00 – The hidden superpower on your computer
00:37 – What PowerShell actually is
01:58 – The verb-noun pattern
03:29 – Objects, not text
05:48 – The five essential cmdlet groups
08:09 – Discovery first: Get-Help, Get-Command, Get-Member
09:52 – Filtering, shaping and exporting
11:55 – The pipeline in action and first steps

Key takeaways

PowerShell combines a command-line shell, a scripting language and remote management in one cross-platform tool that reaches Windows, Azure, Microsoft 365, Exchange and Active Directory.
Cmdlets follow a consistent verb-noun pattern and return objects, so Get-Help, Get-Command and Get-Member let you discover everything from inside the tool.
The pipeline chains filtering, shaping and exporting into repeatable one-liners; start by automating the task you do most often.

Worth quoting

“PowerShell is a full automation platform. Think of it as a command line shell, a scripting language, and a remote management tool all in one.” – Mirko Peters (00:47)

“You don't learn power shell by memorizing a thousand commands. You learn the pattern and you can figure out the rest as you go.” – Mirko Peters (03:12)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short PowerShell FAQ
Automation – the core goal: turning repeated admin tasks into one-liners, scheduled reports and scripts
Active Directory – the example for finding and unlocking locked-out user accounts in one pipeline
Exchange Online – one of the services PowerShell manages with the same pattern, such as Get-Mailbox
Mirko Peters – host of this Knowledge Nuggets episode explaining PowerShell for beginners and IT admins
Related episode: PowerShell for Microsoft 365 - Simply Explained

Dataverse - Simply Explained

Wed, 15 Jul 2026 00:00:02 +0000

Still running business data on Excel files and SharePoint lists that hit the 5,000-item wall? This episode explains Dataverse in plain English for Power Platform makers and IT pros: tables, relationships, role-based security and how Power Apps, Power Automate and Power BI build on it. You will know when Dataverse is the right foundation and how to start your first data model.

In this episode

00:00 – Why Dataverse exists
02:32 – Tables: the foundation
04:26 – One-to-many relationships and lookup columns
06:36 – Many-to-many relationships and intersection tables
08:34 – Role-based security, business units and teams
11:02 – Dataverse versus SharePoint
13:01 – Power Platform integration and AI
15:46 – Getting started with your data model

Key takeaways

Dataverse is a managed relational data platform that handles tables, relationships, security and business logic so every Power Platform app, flow and report shares one foundation.
Lookup columns, enforced referential integrity and role-based security with business units, teams and column-level security make Dataverse far more robust than spreadsheets or SharePoint lists.
Use SharePoint for simple trackers and documents, choose Dataverse for business-critical systems of record, and start with standard tables and a data model planned on paper.

Worth quoting

“Here's something important to understand. Security and dataverse is additive, not subtractive. If a user has two roles, they get the most permissive access from either role.” – Mirko Peters (09:40)

“The golden rule of dataverse security is this, don't assign system administrator to everyone. That role gives full access to everything in the environment.” – Mirko Peters (10:23)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on Dataverse
Dataverse – the episode's subject: tables, relationships, role-based security and when to use it
Power Platform – the platform whose apps, flows and reports all share Dataverse as their data layer
SharePoint – compared directly with Dataverse on cost, scale, relationships and security, plus a hybrid pattern
Microsoft Lists – SharePoint lists as the step up from Excel that hits the 5,000-item view threshold
Related episode: Dynamics 365 Dataverse Integration - Simply Explained

Kubernetes - Simply Explained

Tue, 14 Jul 2026 23:00:02 +0000

Kubernetes has become one of the most important technologies in modern cloud computing, yet it's also one of the most misunderstood. Many people know the name but struggle to explain what it actually does. In this episode, we break Kubernetes down into plain English, exploring why it was created, how it works with containers, and why platforms like Azure Kubernetes Service (AKS) have made enterprise container orchestration accessible to organizations of every size. Whether you're a developer, IT professional, cloud architect, or simply curious about modern infrastructure, this episode gives you a practical foundation without overwhelming technical complexity.

WHY CONTAINERS CHANGED EVERYTHING
Before containers, organizations relied on physical servers and virtual machines to host applications. While virtual machines improved hardware utilization, they remained resource-intensive and difficult to manage at scale. Containers revolutionized software deployment by packaging applications together with all of their dependencies, creating lightweight, portable environments that run consistently across development, testing, and production. Technologies like Docker solved the "it works on my machine" problem, but managing hundreds or thousands of containers introduced an entirely new operational challenge.

WHAT IS KUBERNETES?
Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, networking, recovery, and lifecycle management of containerized applications. Rather than manually deciding where every container should run, Kubernetes treats your infrastructure as one large pool of computing resources and automatically schedules workloads where they belong. It continuously monitors applications, replaces failed containers, balances workloads, and ensures your desired application state is always maintained.

UNDERSTANDING PODS, NODES AND CLUSTERS
At the heart of Kubernetes are a few core building blocks. Applications run inside Pods, which represent the smallest deployable unit in Kubernetes. Pods execute on Nodes, which are physical or virtual servers participating in a Kubernetes Cluster. Together, the cluster functions as a single distributed platform capable of automatically moving workloads, recovering from failures, and scaling applications based on business demand. Services provide stable networking, ensuring applications remain accessible even as Pods are constantly created, replaced, or relocated.

THE CONTROL PLANE – THE BRAIN OF KUBERNETES
The Kubernetes Control Plane acts as the intelligent management layer for the entire cluster. Components such as the API Server, Scheduler, Controller Manager, and etcd database work together to process deployment requests, assign workloads to available infrastructure, maintain cluster health, and continuously reconcile the desired state with the actual environment. This declarative approach allows engineers to describe what they want while Kubernetes determines how to achieve it automatically.

AUTOMATED DEPLOYMENTS AND SCALING
Kubernetes simplifies application management through Deployments, Services, rolling updates, automatic recovery, and horizontal scaling. Instead of manually restarting applications or provisioning additional servers during traffic spikes, Kubernetes continuously monitors workloads and automatically adds or removes application instances based on defined performance thresholds. This enables highly available applications with minimal downtime while significantly reducing operational effort.

SELF-MANAGED KUBERNETES VS AZURE KUBERNETES SERVICE
Running Kubernetes independently provides maximum flexibility but also introduces significant operational complexity. Organizations become responsible for cluster upgrades, security patches, networking, backups, and control plane maintenance. Azure Kubernetes Service (AKS) removes much of this burden by delivering a fully managed Kubernetes control plane while allowing organizations to focus on building and deploying applications instead of maintaining infrastructure. This makes Kubernetes practical for organizations that want enterprise-grade container orchestration without dedicated platform engineering teams.

WHY AKS IS THE PREFERRED CHOICE ON AZURE
Azure Kubernetes Service integrates seamlessly with Microsoft technologies including Microsoft Entra ID, Azure Monitor, Azure Container Registry, Azure Policy, GitHub Actions, and Azure DevOps. Automated upgrades, built-in security, simplified scaling, and AKS Automatic mode enable teams to adopt Kubernetes quickly while still using industry-standard Kubernetes underneath. Skills learned on AKS remain transferable to virtually any Kubernetes environment, making it an excellent starting point for organizations embracing cloud-native application development.

KEY TAKEAWAYS
Containers package applications, but Kubernetes brings them to life at scale. By automating deployment, scaling, recovery, networking, and infrastructure management, Kubernetes has become the industry standard for running modern cloud-native applications. With managed platforms like Azure Kubernetes Service, organizations no longer need to become Kubernetes experts to benefit from its powerful capabilities. Whether you're modernizing legacy applications, building microservices, or adopting DevOps practices, Kubernetes provides the foundation for scalable, resilient, and highly automated cloud infrastructure.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Windows 365 – Simply Explained

Tue, 14 Jul 2026 22:05:02 +0000

What if your Windows PC wasn't tied to a physical device? What if you could access the exact same desktop, applications, and files from your laptop, tablet, Mac, smartphone, or even a web browser? That's exactly what Windows 365 delivers. In this episode, we break down Microsoft's Cloud PC platform in plain English, exploring how it works, why organizations are adopting it, and where it fits into today's hybrid work environment. Whether you're an IT professional, business owner, or simply curious about Microsoft's cloud strategy, this episode gives you a practical introduction without unnecessary technical jargon.

WHY WINDOWS 365 EXISTS
Traditional device management is expensive, time-consuming, and inflexible. Every new employee or contractor typically requires purchasing, configuring, shipping, maintaining, and eventually replacing a physical laptop. As remote work, hybrid work, and BYOD (Bring Your Own Device) become increasingly common, businesses need a better solution that provides flexibility without sacrificing security. Windows 365 was designed to solve exactly this challenge by separating the Windows experience from the physical hardware.

WHAT IS A CLOUD PC?
Windows 365 provides a complete Windows desktop running entirely inside Microsoft's cloud. Instead of storing your operating system, applications, and files on your local device, everything lives securely inside Microsoft's datacenters. Users simply stream their personal Windows desktop to virtually any supported device while enjoying the same familiar Windows experience they already know. The result is a fully personalized PC that's available wherever there's an internet connection.

HOW WINDOWS 365 WORKS
Every user receives their own dedicated Cloud PC with allocated CPU, memory, storage, applications, and settings. Keyboard and mouse input are transmitted securely to Microsoft's cloud while the display is streamed back in real time. Because the actual computing happens remotely, users can switch devices without losing their session. Microsoft also manages infrastructure, operating system updates, patching, and platform availability, reducing the operational burden on IT departments.

BUSINESS, ENTERPRISE, FRONTLINE AND FLEX
Windows 365 is available in multiple editions designed for different organizational needs. Windows 365 Business targets smaller organizations with simplified deployment, while Windows 365 Enterprise integrates deeply with Microsoft Intune, Microsoft Entra ID, and enterprise security policies. Additional offerings such as Windows 365 Frontline and Windows 365 Flex introduce cost-effective options for shift workers, temporary staff, and shared usage scenarios, making Cloud PCs accessible across a wide range of business models.

REAL-WORLD USE CASES
Windows 365 shines in scenarios involving contractors, seasonal workers, remote employees, mergers and acquisitions, business continuity, and BYOD environments. Organizations can provision secure corporate desktops within minutes without shipping hardware, allowing employees to remain productive from virtually anywhere. If a device is lost or damaged, users simply sign in from another device and continue working exactly where they left off.

BUILT-IN SECURITY ADVANTAGES
One of Windows 365's greatest strengths is security. Corporate data remains inside Microsoft's cloud instead of being stored on personal devices. Organizations can enforce Conditional Access policies, disable local device redirection, integrate Microsoft Defender, and leverage enterprise-grade identity protection through Microsoft Entra. This dramatically reduces the risks associated with remote work while simplifying compliance requirements across regulated industries.

COSTS AND BUSINESS VALUE
Rather than purchasing laptops every few years, organizations pay a predictable monthly subscription for each Cloud PC. While pricing varies depending on the hardware configuration, many businesses benefit from reduced deployment effort, faster employee onboarding, simplified device management, and lower support costs. The financial advantages become particularly compelling for organizations employing contractors, temporary workers, or rapidly growing remote teams.

WINDOWS 365 VS AZURE VIRTUAL DESKTOP
Although both services deliver Windows desktops from the cloud, they address different needs. Windows 365 focuses on simplicity, predictable pricing, and minimal administration, making it ideal for dedicated users. Azure Virtual Desktop provides greater flexibility and pay-as-you-go infrastructure but requires significantly more Azure expertise and ongoing management. Understanding these differences helps organizations select the platform that best matches their workforce and operational model.

KEY TAKEAWAYS
Windows 365 represents a fundamental shift in how organizations think about personal computing. Instead of managing physical hardware, businesses manage secure Cloud PCs that employees can access from almost anywhere. For organizations embracing hybrid work, remote employees, contractors, or BYOD strategies, Windows 365 delivers a compelling combination of flexibility, security, simplified management, and predictable costs. It's not just another Windows product—it's a modern approach to delivering the Windows experience as a cloud service.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure Sphere - Simply Explained

Tue, 14 Jul 2026 19:00:02 +0000

Many IoT devices ship without secure boot or a way to patch them. This episode explains Azure Sphere in plain English for IoT developers, architects and security teams, showing how Microsoft secures devices from the chip to the cloud and when the platform is worth the trade-offs.

In this episode

00:00 – Why IoT devices were never built to be secure
01:32 – What Azure Sphere actually is
03:32 – Layer 1: the silicon and Pluton
05:53 – Layer 2: the locked-down Linux OS
08:14 – Layer 3: the Azure Sphere Security Service
11:46 – How the three layers work together
14:42 – Vulnerabilities and the honest picture
16:52 – Who Azure Sphere is for

Key takeaways

Azure Sphere combines a certified microcontroller, a locked-down Linux-based OS and a cloud security service, so IoT security starts at the silicon instead of being bolted on later.
The Pluton security subsystem provides a hardware root of trust and secure boot, while Microsoft pushes mandatory OS updates and certificate-based authentication to every device for at least ten years.
Azure Sphere is worth it for long-lived industrial, commercial, infrastructure and healthcare devices where a breach would cost more than the device, not for cheap home gadgets.

Worth quoting

“Azure Sphere takes a different approach, security is built in from the start, not added later, the chip itself has security features baked into the silicon, the operating system is designed specifically to run securely, the cloud service manages the whole fleet” – Mirko Peters (02:32)

“Because every line of code is a potential vulnerability. The more code you have, the more bugs you can have. By keeping the operating system small, Microsoft reduces what security researchers call the trusted computing base.” – Mirko Peters (06:31)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on IoT security
Azure Sphere – the IoT security platform explained layer by layer, from Pluton silicon to the cloud security service
Related episode: Azure DDoS Protection - Simply Explained
Related episode: Azure Front Door - Simply Explained
Related episode: Digital Twins on Azure: What Should You Actually Model?

Azure Open Datasets - Simply Explained

Tue, 14 Jul 2026 16:00:03 +0000

Learning data science but stuck without clean, interesting data to practice on? This episode explains Azure Open Datasets for beginners, analysts and ML learners: what is in the catalog, how to pull it into Python, Azure Machine Learning or Power BI, and what really costs money. You will be able to grab ready-to-use data in minutes without scraping or cleaning.

In this episode

00:00 – The missing-data problem
00:49 – What Azure Open Datasets actually is
02:54 – Discovery, preparation, scale and reproducibility
05:03 – Catalog: weather and holidays
06:39 – Catalog: census and labor data
07:56 – Catalog: taxi trips, public safety, COVID-19 and ML benchmarks
11:01 – Access via Python, Azure ML, Power BI, Synapse and Databricks
13:45 – The cost question: compute and egress

Key takeaways

Azure Open Datasets is a free catalog of curated public data, such as NOAA weather, holidays, US Census and NYC taxi trips, that Microsoft cleans, stores in Parquet and keeps refreshed in Azure.
You can load the data with the azureml-opendatasets Python package, register it in Azure Machine Learning, connect Power BI through the Blob Storage connector or query it with Synapse serverless SQL and Databricks.
The data and its storage are free, but compute, egress and your own storage are not, so keep compute in the dataset's region and sample before you scale.

Worth quoting

“Here's the key point, the data itself is free and Microsoft pays for the storage always. You only pay for compute if you process it” – Mirko Peters (02:13)

“Most people think machine learning is just about the algorithm. But the real insight from Microsoft is that most machine learning problems are impacted by real world factors.” – Mirko Peters (04:17)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on free public data
Azure Open Datasets – the free catalog of curated public data this episode explains, from weather to taxi trips
Power BI – one access path discussed, connecting to dataset storage URLs through the Azure Blob Storage connector
Microsoft Azure – the cloud where the datasets are stored and where compute and egress costs arise
Related episode: Predictive Maintenance on Azure for Manufacturers: What You Actually Need Before the Model

AVD vs Windows 365: Choosing the Right Virtual Desktop Strategy for the AI Era with Dieter Kempeneers [MVP] & Dominiek Verham [MVP]

Tue, 14 Jul 2026 13:00:02 +0000

Choosing between Azure Virtual Desktop and Windows 365 is harder than it looks once licensing, skills, security and AI-ready endpoints enter the picture. In this episode, IT architects and decision makers hear from Dieter Kempeneers and Dominiek Verham how both platforms differ, which building blocks matter and how to pick the right virtual desktop strategy for their business case.

In this episode

00:00 – Welcome and guest introductions
03:12 – AVD and Windows 365 explained
08:01 – AVD core components: host pools, workspaces, FSLogix and storage
15:14 – Images: gallery, golden images and custom image templates
20:02 – What Windows 365 is, licensing and cost
30:27 – GPUs, Copilot+ PCs and advising the CIO
38:28 – Security, infrastructure as code and monitoring
49:41 – Rapid-fire questions and closing advice

Key takeaways

Azure Virtual Desktop offers maximum flexibility and cost-optimization options but requires VDI skills and a solid Azure foundation, while Windows 365 packages the same capabilities as a simpler, per-user licensed service managed through Intune.
Profile management with FSLogix, the right storage choice and a lean image strategy, preferably Microsoft gallery images over hand-built golden images, are key to a healthy AVD environment.
Security baselines, Conditional Access and device-aware redirection apply to both platforms, so the decision should start from the business use case, and many organizations end up running both.

Worth quoting

“Today we are talking about one of the hottest topics and modern IT infrastructure virtual desktops organizations are rethinking how employees access applications and data” – Mirko Peters (00:10)

Explore more on M365.FM

Episode page: the full conversation with chapters, quotes and FAQ on AVD and Windows 365
Dominiek Verham – cloud solution architect who explains why Windows 365 makes AVD capabilities simple to deploy
Dieter Kempeneers – cloud solutions architect with over 12 years in VDI, explaining host pools and session hosts
Azure Virtual Desktop – the flexible platform discussed in depth, from host pools and FSLogix to cost optimization
Related episode: Windows 365 or Azure Virtual Desktop: Choosing the Right Cloud PC Model

Azure Key Vault - Simply Explained

Tue, 14 Jul 2026 10:00:02 +0000

Every modern application relies on secrets—API keys, database passwords, connection strings, encryption keys, and certificates. Yet one of the biggest security mistakes developers and administrators still make is storing these credentials directly inside source code, configuration files, or deployment pipelines. In this episode of Microsoft Knowledge Nuggets on M365 FM, Mirko Peters explains Azure Key Vault in plain English, showing how Microsoft helps organizations securely store, manage, rotate, and protect sensitive information across Azure. Whether you're a developer, cloud architect, DevOps engineer, security professional, or IT administrator, this episode explains why Azure Key Vault has become a fundamental building block of every secure cloud architecture.

WHAT IS AZURE KEY VAULT?
Azure Key Vault is Microsoft's fully managed cloud service for securely storing secrets, encryption keys, and digital certificates. Rather than embedding sensitive credentials inside applications, organizations store them centrally inside Key Vault where Azure handles security, availability, patching, and auditing. Applications retrieve secrets only when needed, significantly reducing the risk of accidental exposure while simplifying credential management across development, testing, and production environments.

SECRETS, KEYS, AND CERTIFICATES
Azure Key Vault supports three primary object types: secrets, cryptographic keys, and certificates. Secrets include API keys, passwords, connection strings, and storage account keys. Cryptographic keys protect encrypted workloads such as Azure Storage, SQL databases, and virtual machines using customer-managed encryption. Certificates simplify TLS and SSL lifecycle management through centralized storage, automated renewal, and secure deployment across applications and services. Versioning allows previous secret values to remain available for rollback scenarios while simplifying password rotation and operational recovery.

UNDERSTANDING ACCESS CONTROL
Security depends not only on where secrets are stored but also on who can access them. The episode explains why Azure Role-Based Access Control (RBAC) has become Microsoft's recommended permission model, replacing legacy access policies. You'll learn the differences between management-plane and data-plane permissions, Key Vault Reader, Secrets User, Secrets Officer, Contributor, and Owner roles, along with the principle of least privilege that minimizes unnecessary access throughout an organization.

MANAGED IDENTITY ELIMINATES PASSWORDS
One of Azure's most powerful security features is Managed Identity. Instead of storing client secrets inside applications, Azure automatically creates secure identities for services such as App Service, Azure Functions, Virtual Machines, AKS, Synapse, Logic Apps, and Azure Data Factory. These identities authenticate directly with Microsoft Entra ID and securely retrieve secrets from Azure Key Vault without developers managing credentials manually. This significantly reduces attack surfaces while simplifying cloud-native authentication.

AVOIDING COMMON SECURITY MISTAKES
The episode also highlights one of the most common Key Vault configuration mistakes: relying on legacy access policies together with overly broad Contributor permissions. Organizations should migrate to Azure RBAC, audit existing permissions regularly, separate development, test, and production vaults, enable Soft Delete and Purge Protection, and limit access using dedicated Key Vault roles. Combined with monitoring, audit logging, and Microsoft Entra ID, these practices dramatically improve overall cloud security while reducing operational risk.

KEY TAKEAWAYS
Azure Key Vault is much more than a secure password manager. It is the central trust anchor for modern Azure security, enabling applications to authenticate without embedded credentials while protecting secrets, encryption keys, and certificates throughout their lifecycle. Combined with Microsoft Entra ID, Azure RBAC, Managed Identity, and Zero Trust principles, Azure Key Vault helps organizations build secure, scalable, and compliant cloud solutions that are easier to manage and significantly harder to compromise.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure Chaos Studio - Simply Explained

Tue, 14 Jul 2026 07:00:03 +0000

Traditional tests assume everything works, but production rarely does. In this episode Mirko Peters explains Azure Chaos Studio for cloud architects, DevOps engineers and SREs, showing how controlled failure experiments reveal weaknesses before your customers do.

In this episode

00:00 – Intro: why traditional testing isn't enough
01:28 – What chaos engineering actually is
02:30 – Introducing Azure Chaos Studio
04:10 – Building blocks: targets, steps, branches, actions
06:12 – Running your first chaos experiment
08:08 – Safety first
10:12 – Shifting left, shifting right and game days
12:04 – The real value: building confidence

Key takeaways

Chaos engineering injects real, controlled failures to test a hypothesis about how your system survives them.
Azure Chaos Studio runs service-direct and agent-based faults through experiments built from targets, steps, branches and actions.
Start small in non-production, use managed identities and fault enablement as safety nets, and make experiments a continuous practice.

Worth quoting

“Chaos engineering is a practical method. You inject real controlled failures into your system and observe how it reacts. This doesn't happen in a lab or a simulation. It happens on your actual resources.” – Mirko Peters (01:37)

“Here's the thing, chaos engineering is not random destruction. It's not a developer walking into the server room and pulling cables for fun. It's scientific, repeatable, and safety constrained.” – Mirko Peters (02:02)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on chaos experiments
Azure Chaos Studio – the managed service explained here, from fault types and experiment structure to safety controls
Microsoft Azure – the cloud whose VMs, AKS clusters and Cosmos DB resources Chaos Studio injects faults into
Mirko Peters – hosts this episode and walks through a zone-outage chaos experiment step by step
Related episode: Azure Virtual Machine Scale Sets - Simply Explained

Your AI Landing Zone Is A Liability

Tue, 14 Jul 2026 04:00:08 +0000

Deploying Azure OpenAI in the portal works for a proof of concept, but it turns into audit failures, data exposure and untraceable token costs at scale. This masterclass shows cloud architects and platform teams how to build a hardened AI landing zone with Bicep, from identity and network isolation to policy, FinOps and API Management.

In this episode

00:00 – Intro: the perimeter, not the model
01:10 – Why standard landing zones fail with AI
03:41 – Cost and the hidden assumption
09:21 – What auditors actually look for
12:28 – Bicep as the control plane and three perimeter layers
23:46 – Private endpoints, identities and Azure Policy
38:50 – Foundry, observability and FinOps
61:08 – API gateway, RAG governance and CI/CD

Key takeaways

Manually deployed AI infrastructure leads to configuration drift, invisible token costs and audit failures, so the perimeter must be built in code from day one.
A hardened AI perimeter combines managed identities, private endpoints, Azure Policy with management groups, token-level observability and orchestration through Azure AI Foundry and API Management.
Reusable Bicep modules validated in CI/CD pipelines turn governance, cost attribution and security into defaults instead of afterthoughts.

Worth quoting

“Enterprise AI isn't about the model, it's about the perimeter. The perimeter is the structural boundary that keeps your data safe, your costs visible, and your reasoning auditable.” – Mirko Peters (00:28)

“This assumption is broken for AI in a way it never was for traditional infrastructure, security debt compounds faster with AI than any other workload type.” – Mirko Peters (07:06)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on hardening AI landing zones
Bicep – the infrastructure-as-code language the episode treats as the control plane for the AI perimeter
Azure OpenAI Service – the model endpoint whose manual portal deployments, API keys and public access create the liability
Azure Private Link – the basis for private endpoints that keep LLM traffic off the public internet
Related episode: How to Architect Low-Cost AI Agents in the Microsoft Cloud

Data Analysis Expressions (DAX) - Simply Explained

Tue, 14 Jul 2026 01:00:02 +0000

Many Power BI users think DAX is just Excel formulas with a new name and then wonder why their numbers don't add up. This episode explains DAX in plain English for Power BI beginners and analysts: measures versus calculated columns, filter context, CALCULATE, iterators, time intelligence and the pitfalls to avoid.

In this episode

00:00 – What DAX really is
01:55 – Calculated columns versus measures
03:28 – The big idea: filter context
05:02 – CALCULATE, the most important function
07:11 – Iterator functions
09:03 – Time intelligence made simple
11:06 – Common beginner pitfalls
13:09 – Putting it all together

Key takeaways

DAX works on whole tables and columns rather than cells, so treating it like Excel formulas leads to wrong results.
Prefer measures over calculated columns, because measures recalculate in the current filter context while columns stay static and bloat the model.
Master filter context and CALCULATE, use iterators only for row-by-row logic, and mark a proper date table so time intelligence works.

Worth quoting

“Here's the thing, most people think DAX is basically Excel formulas with a different name, but it isn't. DAX is a whole different way of thinking about calculations.” – Mirko Peters (00:10)

“If the number needs to change when someone clicks a button, use a measure. If it is the same no matter what, a calculated column is fine.” – Mirko Peters (02:49)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and FAQ on DAX basics
DAX – the formula language the episode explains, from measures to CALCULATE and iterators
Power BI – where DAX measures react to slicers, visuals and filters in every report
Microsoft Excel – the comparison point, since DAX works on tables and columns, not individual cells
Semantic model – the data model and relationships that DAX depends on, so fix it first
Related episode: From DAX to Community: The Power BI Journey with Bernat Agulló Roselló (MVP)

Graph API - Simply Explained

Mon, 13 Jul 2026 22:05:02 +0000

Microsoft Graph API is one of the most important technologies in the Microsoft ecosystem, yet it's often misunderstood. Is it a database? A service? Or simply another developer tool? In this episode of Microsoft Knowledge Nuggets on M365 FM, Mirko Peters breaks down Microsoft Graph API in plain English using simple real-world analogies that make even complex concepts easy to understand. Whether you're an IT administrator, developer, Power Platform maker, or Microsoft 365 enthusiast, you'll learn why Graph has become the universal gateway to Microsoft's cloud services and why it's now essential for automation, integrations, and AI-powered solutions.

FROM DISCONNECTED APIS TO ONE UNIFIED PLATFORM
Before Microsoft Graph, every Microsoft service had its own API. Exchange Online, SharePoint, Azure Active Directory (now Microsoft Entra ID), OneDrive, and Microsoft Teams all required separate authentication methods, documentation, and programming models. Automating even simple business processes meant working with multiple technologies simultaneously. Microsoft Graph changed that by introducing one unified API endpoint that connects every major Microsoft 365 service through a consistent interface, dramatically simplifying development and automation. UNDERSTANDING GRAPH THROUGH SIMPLE ANALOGIES Rather than diving into technical documentation, this episode explains Microsoft Graph using relatable examples. Imagine Microsoft 365 as a modern office building where every service represents a different department. Instead of visiting each room individually, Microsoft Graph acts as the central reception desk that coordinates everything behind the scenes. This simple analogy makes it easy to understand how Graph connects users, files, calendars, mailboxes, Teams, SharePoint sites, and security information into one interconnected platform.

HOW AUTHENTICATION, PERMISSIONS, AND SECURITY WORK
Every Graph request starts with authentication through Microsoft Entra ID before authorization determines exactly which resources an application can access. The episode explains delegated permissions, app-only permissions, OAuth tokens, consent, scopes, and Microsoft's least-privilege security model without unnecessary technical complexity. You'll also understand why Graph is considered one of the most secure ways to access Microsoft 365 data and how administrators maintain complete control over application permissions.

AUTOMATING MICROSOFT 365 WITH GRAPH API
Microsoft Graph enables organizations to automate virtually every aspect of Microsoft 365. From creating users and assigning licenses to managing Teams, SharePoint documents, Outlook mailboxes, OneDrive files, calendars, Microsoft Defender alerts, and security operations, Graph provides a single interface for enterprise automation. The episode also demonstrates how developers, administrators, and IT professionals can build powerful workflows while reducing complexity compared to legacy Microsoft APIs.

GRAPH API FOR POWER PLATFORM AND LOW-CODE USERS
You don't have to be a professional developer to benefit from Microsoft Graph. Power Automate, Power Apps, Microsoft Copilot, and Graph Explorer make Graph accessible to citizen developers and business users through low-code experiences. Even advanced Graph endpoints can be integrated using custom HTTP actions, allowing organizations to build sophisticated automations without writing large amounts of code. This opens enterprise-grade automation capabilities to a much wider audience.

WHY GRAPH API IS THE FUTURE OF MICROSOFT 365
Microsoft continues to retire older technologies while investing heavily in Graph API. Legacy APIs such as Exchange Web Services are reaching end of life, while new Microsoft 365 capabilities increasingly become available only through Graph. Understanding Graph today prepares organizations for future AI experiences, Microsoft Copilot integrations, intelligent agents, Power Platform automation, and enterprise cloud development.

KEY TAKEAWAYS
Microsoft Graph API is the universal gateway to Microsoft 365. One endpoint provides secure access to users, mail, files, Teams, SharePoint, calendars, devices, security data, and much more. Whether you're building applications, automating business processes, integrating Microsoft services, or preparing for the AI era, Graph API forms the foundation of the modern Microsoft cloud. Understanding how it works is one of the most valuable skills for anyone working with Microsoft technologies today.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Microsoft Agent Builder — Simply Explained

Mon, 13 Jul 2026 19:00:02 +0000

Everyone talks about AI agents, but do you need to be a developer to build one? This episode explains Microsoft Agent Builder for business users and IT pros: how to create an agent from a sentence, connect knowledge sources, respect permissions and know when to step up to Copilot Studio or AI Foundry.

In this episode

00:00 – Introduction: AI agents without code
00:32 – What Agent Builder actually is
02:35 – The creation flow step by step
04:41 – Knowledge sources
06:41 – The template shortcut
08:13 – Agent Builder vs Copilot Studio vs AI Foundry
11:06 – The hard limits
13:31 – Security and governance

Key takeaways

Agent Builder lets business users create declarative agents inside Microsoft 365 Copilot by describing what they need, with no code required.
Knowledge sources such as SharePoint sites and files are what make an agent useful, and the only-use-specified-sources toggle is the main defense against hallucinations.
Move to Copilot Studio only when you need external-facing agents, non-Microsoft 365 data sources or agentic actions; AI Foundry is for professional developers.

Worth quoting

“Without knowledge sources, the agent is just a chatbot with a personality. It doesn't know anything about your company.” – Mirko Peters (03:36)

“The agent respects your existing Microsoft 365 permissions. It doesn't get special access. If you add a SharePoint site as a knowledge source, the agent can only return information that the person asking the question is already allowed to see.” – Mirko Peters (06:21)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a FAQ on building agents
AI agent – the episode explains what an agent is and how business users build one without code
Knowledge source – SharePoint, OneDrive, files, URLs, Teams chats and emails that give an agent its company knowledge
Microsoft 365 Copilot – Agent Builder lives in its sidebar, and SharePoint grounding needs a full Copilot license
Related episode: Beyond Copilot: Building Enterprise AI Agents That Actually Work with Copilot Studio with Manpreet Singh [MVP-MCT]

Copilot for Dynamics 365 Finance and Operations - Simply Explained

Mon, 13 Jul 2026 16:00:06 +0000

Most finance teams hear Copilot and picture a chatbot, but what does it really do on a Tuesday morning? This episode walks finance professionals and Dynamics 365 Finance and Operations users through collections, month-end close, cash flow forecasting and AP, plus the requirements and adoption steps that decide whether it pays off.

In this episode

00:00 – Introduction and the problem Copilot solves
01:24 – Copilot for collections and AR
02:45 – Financial close and reporting
04:40 – Cash flow and forecasting
05:54 – Expense management and AP
07:19 – Requirements to get started
08:33 – Driving adoption
09:47 – The big picture

Key takeaways

Copilot in Dynamics 365 Finance and Operations brings customer summaries, draft emails, variance explanations and forecasts into the finance workflow instead of making people chase data across screens.
Collections is the fastest-value starting point, followed by financial close, cash flow forecasting and expense and AP automation.
Copilot requires a recent F&O version, Dataverse integration, a cloud-hosted environment and a separate Microsoft 365 Copilot license, and adoption needs targeted pilots and scenario-based training.

Worth quoting

“Finance teams don't lack information. They have plenty. The friction is in how you access it and act on it.” – Mirko Peters (01:01)

“Co-pilot amplifies good processes and bad ones equally. If your collections workflow is a mess, Co-pilot won't fix it. It'll just help you generate messy emails faster.” – Mirko Peters (08:56)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a finance-focused FAQ
Microsoft 365 Copilot – its separate Microsoft 365 Copilot license is required on top of the D365 license
Dynamics 365 Finance and Operations – the ERP where Copilot summarizes customers, explains variances and forecasts cash flow
Copilot adoption – why only about 35% use Copilot without planning, and how pilots and scenario training help
Related episode: Beyond the Prompt: Mastering Microsoft Copilot for Real Productivity with Jess Stratton [MVP]

AI Under Attack: Building Zero Trust Security with Microsoft Copilot, Azure & Microsoft 365 - Mourtaza Fazlehoussen [MVP]

Mon, 13 Jul 2026 13:00:06 +0000

AI is reshaping both attacks and defenses: how do you embrace it without opening new risks? Mirko talks with Microsoft MVP and CISO Mourtaza Fazlehoussen about Security Copilot, AI governance, Zero Trust for AI and the first hour of a ransomware incident, giving security and IT leaders practical guidance before deploying AI.

In this episode

00:00 – Introduction
01:42 – Mourtaza's journey into cybersecurity
07:32 – Today's threat landscape and tool sprawl
17:16 – Microsoft Security Copilot: what it is and isn't
31:15 – AI governance and AI policies
39:55 – Zero Trust in the age of AI
50:26 – The first hour of a ransomware attack
55:55 – Autonomous SOCs and rapid fire

Key takeaways

Microsoft Security Copilot helps SOC analysts triage, correlate and summarize incidents faster, but it does not replace security architecture, controls or human decisions.
AI governance needs concrete policies on approved AI tools, data classification and responsible prompting, supported by Microsoft Purview, Entra and Defender.
Zero Trust principles of verify explicitly, least privilege and assume breach apply directly to AI agents and Copilot, and incident readiness must include business continuity planning.

Worth quoting

“Microsoft Security Co-Pilot is a powerful tool. However, it remains a security assistant, but it's not a complete, I would say, a security solution. It helps you to augment your security team.” – Mourtaza Fazlehoussen (17:37)

“if I buy security copilot, then I am safe. Like, you know, it will protect entirely my company, which is not true.” – Mourtaza Fazlehoussen (27:56)

Explore more on M365.FM

Episode page: the full conversation with chapters, quotes and FAQ on Copilot and AI security
Mourtaza Fazlehoussen – Microsoft MVP and CISO who explains Security Copilot, AI governance and ransomware response
AI governance – the policies, processes and controls he says must be in place before deploying AI
Zero Trust – verify explicitly, least privilege and assume breach, applied to AI agents and Copilot
Related episode: Agent Governance Explained- How IT Can Enable the AI Agent Revolution with Thomas Zou [Microsoft]

Copilot in Microsoft Entra ID - Simply Explained

Mon, 13 Jul 2026 10:00:06 +0000

Troubleshooting a blocked sign-in in Entra can mean jumping between logs, policies and risk reports for twenty minutes. This episode explains Copilot in Microsoft Entra ID for identity admins, help desk staff and security analysts: how it turns raw logs into plain-English answers and why it respects your existing permissions. You will see where it saves time and how it stays governed.

In this episode

00:00 – The identity troubleshooting problem
02:34 – What Security Copilot in Entra ID is
04:10 – Use case one: sign-in troubleshooting
06:17 – Use case two: investigating risky users
08:14 – Use case three: Conditional Access insights
10:11 – The evidence: does it actually help?
11:24 – Is it safe? Governance and security
12:58 – Who benefits

Key takeaways

Copilot in Microsoft Entra ID is an AI assistant embedded in the Entra admin center that answers plain-English questions by pulling together sign-in logs, audit logs, Conditional Access and Identity Protection data.
It shortens sign-in troubleshooting, summarizes risky users with recommended next steps and explains which Conditional Access policies applied and why.
Copilot inherits the admin's existing roles and Conditional Access, logs its prompts in audit logs and only suggests actions, so humans stay in control.

Worth quoting

“Co-pilot doesn't just dump raw data on you. It gives you a summary, a narrative, and explanation.” – Mirko Peters (03:22)

“Co-pilot inherits your existing intra roles and permissions. That's the key point. If you don't have permission to view a specific log or resource, Co-pilot can't see it either.” – Mirko Peters (11:40)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Copilot in Entra ID
Microsoft Entra ID – the identity service whose logs and policies Copilot queries and explains in plain English
Conditional Access – Copilot explains which policies applied to a sign-in and which block most often
Microsoft Entra – its admin center is where Copilot is embedded, replacing jumps between separate blades
Related episode: Microsoft Entra ID Protection - Simply Explained

Copilot for Microsoft Fabric - Simply Explained

Mon, 13 Jul 2026 07:00:03 +0000

Not every Copilot is the same. This episode explains Copilot for Microsoft Fabric in plain English for data beginners, analysts and IT pros, showing where it works across Data Factory, notebooks, the warehouse and Power BI, what you need to turn it on, and why human review still matters.

In this episode

00:00 – The Copilot confusion
01:09 – What Copilot for Fabric actually is
02:23 – Data Factory and data engineering
03:40 – Data warehouse and Power BI
04:58 – Real examples in practice
06:45 – What you need to use it
08:10 – Why beginners should care
10:09 – The human still matters

Key takeaways

Copilot in Microsoft Fabric is a data-focused AI assistant, distinct from Microsoft 365 Copilot and GitHub Copilot, that turns plain English into SQL, DAX, PySpark, pipelines and Power BI reports.
It needs a paid Fabric capacity and an admin-enabled tenant setting, costs nothing extra, and only works with data you already have permission to see.
Treat every output as a first draft: clean, well-modeled data and human review remain essential, while Copilot frees IT pros for architecture and tuning.

Worth quoting

“Copilot for fabric is an AI assistant built right into Microsoft fabric. You type what you need in plain English, and it writes the code, builds the queries, or creates the reports for you.” – Mirko Peters (01:31)

“Copilot only works with data you already have access to. It respects your existing permissions. If you can't see a table in the warehouse, Copilot can't see it either.” – Mirko Peters (07:48)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Copilot in Fabric
Microsoft Fabric – the data platform where this Copilot lives, separate from Microsoft 365 Copilot
Power BI – where Copilot builds reports, writes measures and summarizes dashboards in plain English
DAX – the measure language Copilot writes and explains, which you still need to test
Related episode: Microsoft Fabric End-to-End: From Raw Data to Business Decisions with Amit Chandak [MVP]

Platform Engineering: The New Operating Model for Azure

Mon, 13 Jul 2026 04:00:05 +0000

DevOps gave developers cloud autonomy but also buried them in networking, security, policy and approval queues. This episode shows Azure platform teams, architects and engineering leaders how platform engineering, golden paths, Bicep modules and automated governance remove that cognitive load and turn ops from gatekeeper into enabler.

In this episode

00:00 – Why DevOps failed at scale and the cognitive load crisis
07:18 – What platform engineering is and the golden path concept
14:00 – Self-service and internal developer platforms
21:30 – Azure Bicep, modules as products and Azure Verified Modules
32:35 – Policy as code and the shift from tickets to templates
39:40 – Measuring cognitive load, the business case and adoption
48:35 – Bicep modules in governance, Bicep vs Terraform and registries
58:20 – CI/CD automation, gatekeeper to enabler and platform ROI

Key takeaways

DevOps at enterprise scale shifted infrastructure complexity onto developers, and platform engineering fixes this by treating infrastructure as a product developers consume through golden paths.
Azure Bicep modules, Azure Verified Modules, Azure Policy as code, versioned registries and CI/CD pipelines encode security and compliance so the right way becomes the only easy way.
Platform teams must run their internal developer platform as a product, earning adoption rather than forcing it and measuring DORA metrics, satisfaction, adoption and cost avoidance together.

Worth quoting

“But then organizations scaled. 50 developers, 100, 500, and the model broke. DevOps promised shared responsibility, but what it actually delivered was distributed complexity.” – Mirko Peters (01:21)

“A golden path is the simplest, most supported way to get a task done. It is not the only way. You still have escape hatches for the weird edge cases.” – Mirko Peters (09:07)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ
Bicep – the Azure-native language whose versioned modules carry golden paths and governance baselines
Terraform – the multi-cloud alternative, compared on provider lag and suited to genuine multi-cloud estates
Azure landing zone – the baseline module that sets up networking, identity and logging for every new subscription
Related episode: The DevOps Tax: Why Your Platform is Failing

Power BI Copilot - Simply Explained

Mon, 13 Jul 2026 01:00:04 +0000

Tried Power BI Copilot once, got a wrong answer and gave up? This episode explains what Copilot in Power BI can and cannot do for report authors, analysts and beginners, and shows how to phrase questions, prepare your data model and verify results so you get reliable answers.

In this episode

00:00 – What Power BI Copilot actually is
01:20 – Copilot's three superpowers
02:50 – The big gotcha: confident wrong answers
04:22 – How to ask Copilot the right way
05:30 – What Copilot cannot do
06:47 – What makes Copilot work well
07:55 – What it means for beginners
09:20 – A practical framework for today

Key takeaways

Copilot in Power BI drafts DAX measures, builds report pages and answers data questions using your tables, columns, measures and relationships.
It can return confident but wrong and non-deterministic answers, so use the exact terms from your report and always click through to verify the source visual.
Invest in clean names, clear relationships and Prep data for AI, and treat every Copilot result as a rough draft rather than a finished product.

Worth quoting

“Copilot can sound absolutely certain and be completely wrong at the same time. And because it sounds so confident, you might not think to double check it.” – Mirko Peters (02:59)

“Don't rephrase into everyday language. Copilot matches vocabulary, not meaning. So a specific question using the report's own language gets you a consistent correct answer every time.” – Mirko Peters (04:36)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Copilot in Power BI
Power BI – the tool whose built-in Copilot this episode explains, including its limits and pitfalls
DAX – Copilot drafts DAX measures from plain English and explains each part of the formula
Semantic model – Copilot reads your tables, columns and relationships, so model quality decides answer quality
Power BI Desktop – where a Copilot button in the ribbon opens the chat pane for report authors
Power BI Service – the web version, with a similar chat pane for questions about published reports
Related episode: Power BI Semantic Models - Simply Explained

Microsoft Security Copilot - Simply Explained

Sun, 12 Jul 2026 22:05:04 +0000

It's two in the morning and the alerts won't stop: what if an AI assistant could triage them for you? This episode explains Microsoft Security Copilot for small IT and security teams, covering Security Compute Units, the built-in agents, licensing with E5 and the governance basics to check before you switch it on.

In this episode

00:00 – Introduction: 2 a.m. alert storm
00:38 – The problem: alert overload
01:21 – What Security Copilot actually is
02:38 – SCUs and integrations
03:59 – The agents: your AI security team
06:37 – A day in the life
08:34 – Who it's for
10:31 – Getting started and trade-offs

Key takeaways

Microsoft Security Copilot is an AI layer on top of Defender, Entra, Intune and Purview that triages alerts, summarizes incidents and recommends actions using your own tenant data.
Pre-built agents such as phishing triage and conditional access optimization do the repetitive work, while humans still approve the actions.
Microsoft 365 E5 includes a monthly allotment of Security Compute Units, but you should audit permissions and oversharing before enabling it and start with a single agent.

Worth quoting

“ChatGPT knows the public internet, but security copilot knows your environment, your sign-ins, your devices, your alerts.” – Mirko Peters (01:53)

“Copilot doesn't copy or store your data. It queries your systems in real time so everything stays inside your tenant.” – Mirko Peters (03:28)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a short FAQ on Security Copilot
AI agent – pre-built agents for phishing triage, access policies, patching and threat briefings, with humans approving actions
Microsoft Defender – home of the phishing triage agent and the portal where the Monday morning summary appears
Microsoft Intune – source for device compliance questions and home of the vulnerability remediation agent
Microsoft Entra – hosts the conditional access optimization agent and supplies the sign-in logs Copilot queries
Related episode: Microsoft Graph: The Enterprise Nervous System

Copilot in Business Central - Simply Explained

Sun, 12 Jul 2026 16:00:06 +0000

Business Central users keep hearing about Copilot and agents but rarely know what is free, what costs money and what actually does work for them. This episode walks finance and operations teams through the three layers: built-in features, Microsoft-built agents and custom agents, including Copilot credit costs and security controls.

In this episode

00:00 – What Copilot in Business Central is
01:29 – Free built-in Copilot features
03:22 – Microsoft-built agents
05:20 – Copilot credits and costs
06:42 – Building custom agents
08:31 – From email to order: a scenario
10:13 – Security and governance

Key takeaways

Built-in Copilot features in Business Central such as analysis assist, autofill and bank reconciliation are included in the license at no extra cost.
Microsoft-built agents like the Sales Order Agent and Payables Agent act in the background but consume Copilot credits and require human approval for critical actions.
Custom agents can be created with the Agent Designer from plain-English instructions, and they inherit the same permission model and billing as Microsoft's agents.

Worth quoting

“The built-in Copilot features help you move through tasks faster. They give you information, they fill in fields, they suggest text, but you're still the one doing the work. Agents are different because they can act on your behalf.” – Mirko Peters (01:07)

“They use something called co-pilot credits, which is basically a usage-based currency for AI actions.” – Mirko Peters (05:41)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a FAQ on Business Central Copilot
Dynamics 365 Business Central – the ERP where Copilot works directly on customers, sales orders and inventory data
Copilot Credits – the usage-based currency agents consume per answer or action, unlike the free built-in features
AI agent – the Sales Order Agent, Payables Agent and custom agents that act in the background
Related episode: Power Platform Copilot Integration - Simply Explained

Copilot Cowork - Simply Explained

Sun, 12 Jul 2026 13:00:04 +0000

Copilot drafts and summarizes quickly, but you still spend your time coordinating meetings, emails and follow-ups across apps. This episode explains Copilot Cowork in plain English for Microsoft 365 users and admins: how it executes whole goals, how it differs from regular Copilot, and what you need to start delegating multi-step work.

In this episode

00:00 – What Copilot Cowork is in one sentence
01:06 – Why regular Copilot leaves you doing the heavy lifting
02:35 – What Copilot Cowork actually is
03:45 – The office building analogy
05:20 – How Cowork differs from regular Copilot
06:55 – Built-in skills and a weekly planning example
09:38 – What you need to get started
10:45 – What this means for your workday

Key takeaways

Copilot Cowork is an AI agent in Microsoft 365 that takes a whole goal, plans the steps and executes them across Word, Excel, PowerPoint, Outlook, Teams and SharePoint in the background.
Unlike chat-based Copilot, Cowork is task-based, runs for minutes or hours, picks from built-in skills automatically, supports recurring tasks and asks for approval before sensitive actions.
Getting started requires a Microsoft 365 business or enterprise plan, a Copilot license, files in OneDrive or SharePoint and, where needed, admin enablement via the Frontier program.

Worth quoting

“The real bottleneck isn't generating content anymore. It's coordinating across apps and steps and that coordination is where most of your time actually goes.” – Mirko Peters (01:43)

“Instead of prompting for one output at a time, you describe an outcome and let it figure out the steps.” – Mirko Peters (03:10)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Copilot Cowork
Copilot Cowork – the episode's subject: an agent that plans and executes whole goals across Microsoft 365 apps
Microsoft 365 Copilot – the chat-based assistant Cowork is contrasted with, and whose license Cowork requires
Agent skill – Cowork ships with 13 built-in skills such as Word, Excel, calendar and deep research
AI agent – the episode defines Cowork as an AI agent that reasons across your work context
Related episode: Beyond the Prompt: Mastering Microsoft Copilot for Real Productivity with Jess Stratton [MVP]

Copilot Skills - Simply Explained

Sun, 12 Jul 2026 10:00:05 +0000

Microsoft calls the same idea agents in one product and skills in another, which leaves many Copilot users confused. This episode explains in plain English what a Copilot skill is, where it lives in Copilot Chat, Copilot Studio and Copilot Cowork, and how beginners can build their first reliable, reusable skill.

In this episode

00:00 – Why skills are confusing
00:41 – What a Copilot skill is
01:45 – Where skills live
03:23 – Creating a skill with Agent Builder
05:02 – Skills in Copilot Studio
06:42 – Skills in Copilot Cowork
08:36 – What makes a good skill
10:50 – Skills vs. instructions vs. workflows

Key takeaways

A Copilot skill is a reusable instruction set made of a name, a trigger description and step-by-step instructions that runs only when a request matches.
Skills live in three homes: Agent Builder in Copilot Chat for no-code creation, Copilot Studio for Markdown files with scripts, and Copilot Cowork for skill files in OneDrive.
Good skills have precise names, specific triggers, short instructions, a defined output format and explicit rules, and they improve through testing and iteration.

Worth quoting

“A copilot skill is a reusable instruction set for AI. Think of it like writing a job description for a temporary worker.” – Mirko Peters (00:46)

“A skill is not a chatbot that you sit and talk to. It's a specialist that only activates when needed.” – Mirko Peters (01:13)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and a FAQ on Copilot skills
Agent skill – the episode's core topic: a reusable instruction set with name, trigger and steps
Microsoft 365 Copilot – the umbrella in which skills run automatically whenever a request matches their trigger
Copilot Cowork – stores skills as Markdown files in OneDrive and runs a quality check after creation
Copilot Studio – the builder platform where skills are Markdown packages that can bundle Python scripts and templates
Related episode: Copilot Cowork - Simply Explained

Microsoft Scout - Simply Explained

Sun, 12 Jul 2026 07:00:02 +0000

Copilot, Cowork and Scout sound like alphabet soup to most Microsoft 365 users and IT leaders. This episode explains in plain English what Microsoft Scout is, how its always-on Autopilot model differs from Copilot, what it needs in licensing and why preparing agent governance now pays off.

In this episode

00:00 – The Copilot family tree
02:02 – What Scout actually is
03:23 – Autopilot vs. Copilot
05:22 – What Scout can do
08:14 – How Scout works under the hood
10:35 – Licensing and availability
12:13 – Why Scout matters
14:17 – What to do right now

Key takeaways

Scout is Microsoft's first Autopilot: unlike Copilot and Cowork, it acts proactively on schedules and triggers without waiting for a prompt.
Scout runs as a desktop app under its own identity, connects to Microsoft 365 via Work IQ, local files, the web and MCP servers, and gates sensitive actions with approvals.
Scout is in private Frontier preview and needs Microsoft 365 Copilot, a GitHub Copilot license and Intune policies, so organizations should start with Copilot, Cowork skills and agent governance now.

Worth quoting

“Co-pilot and co-work both wait for you to initiate. You start the conversation, you give the task, scout doesn't wait. It watches, it monitors, it acts on its own.” – Mirko Peters (01:32)

“When co-pilot acts, it acts as you. It uses your permissions, your access, your identity. When scout acts, it has its own identity. It's a separate digital worker with its own permissions.” – Mirko Peters (04:16)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ on Scout
Microsoft 365 Copilot – the on-demand first layer that waits for your prompt, contrasted with Scout's Autopilot model
Copilot Cowork – the task executor for multi-step jobs, whose skills are expected to transfer to Scout
AI agent – the shift from AI as a tool you use to an agent working alongside you
GitHub Copilot – a required Business or Enterprise license, since Scout's usage is billed through GitHub
Related episode: Copilot Cowork - Simply Explained

Compliance as Code: The Architect’s Blueprint for Automated Trust

Sun, 12 Jul 2026 04:00:06 +0000

Manual governance with PDFs, spreadsheets and change boards cannot keep pace with pipelines that deploy in minutes, so drift and over-privileged identities pile up unnoticed. This episode is for Azure architects and security engineers, and lays out a complete blueprint with Azure Policy, RBAC, PIM, managed identities, Key Vault and Entra ID Governance to make compliance automatic, auditable and developer friendly.

In this episode

00:00 – The gap between governance speed and deployment speed
03:48 – RBAC versus Azure Policy
07:16 – The governance stack, management groups and landing zones
10:45 – Azure Policy effects, initiatives, safe rollout and policy as code
19:07 – RBAC drift and PIM just-in-time access
27:45 – Service principals, managed identities and Key Vault
43:00 – Developer self-service and golden paths
49:50 – Entra ID Governance, Purview, Zero Trust, monitoring and roadmap

Key takeaways

RBAC decides who can act while Azure Policy decides what may exist, and governance at scale needs both, layered with identity governance, resource locks and monitoring through a management group hierarchy.
Policies should roll out audit first, then modify or deploy-if-not-exists, then deny, ring by ring and managed as code in Git with pull requests and pipelines.
Group-based RBAC, PIM, managed identities, Key Vault with RBAC authorization and purge protection, golden paths and Entra ID Governance turn compliance into a continuous, self-enforcing system aligned with Zero Trust.

Worth quoting

“Policies exist on paper, they're reviewed annually, they're signed and filed, but they're never technically enforced. A policy that lives only in a document is not a control, it's a wish.” – Mirko Peters (03:08)

“RBAC governs the actor, policy governs the environment. One without the other leaves you exposed in ways you won't see until something breaks.” – Mirko Peters (05:32)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and a short FAQ
Azure Key Vault – the trust anchor, with RBAC authorization, purge protection and runtime secret retrieval in pipelines
Zero Trust – the operating principle behind least privilege, just-in-time PIM access and assume-breach scoping
Microsoft Purview – governs data behavior while Azure Policy governs infrastructure state, ideally designed in one session
Related episode: Entra ID Governance: Access Reviews, Entitlement Management and Lifecycle Workflows

Power Apps Code Apps - Simply Explained

Sun, 12 Jul 2026 01:00:03 +0000

Hit the limits of the drag-and-drop canvas? This episode explains Power Apps code apps in plain English for pro developers and makers, covering how they differ from canvas apps, how the SDK connects your React code to Power Platform data, and how governance and licensing work.

In this episode

00:00 – Intro: what are code apps?
00:34 – Code apps versus canvas apps
02:15 – Where canvas apps stop and code steps in
04:01 – The developer toolbox: VS Code, CLI, React
06:06 – What the Power Apps SDK does
08:01 – Data sources and connectors
09:31 – Governance and licensing
11:01 – How it all fits together and next steps

Key takeaways

Power Apps code apps are written in JavaScript, TypeScript and React in VS Code but still run inside Power Apps with hosting and authentication handled by the platform.
The Power Apps SDK generates typed model and service files for Dataverse, SharePoint and other connectors, and DLP and environment policies still apply.
Code apps need a Power Apps Premium license and must be enabled per environment by an admin; they extend canvas apps rather than replace them.

Worth quoting

“A code app is a power app that you write in code instead of dragging and dropping.” – Mirko Peters (00:40)

“Canvas apps are pre-furnished rooms. You walk in the furniture is already there. You just rearrange things to your liking. Code apps are empty rooms where you bring your own furniture.” – Mirko Peters (01:32)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on Power Apps code apps
Power Apps code apps – the episode's subject: Power Apps written in React and TypeScript in VS Code
Power Apps – hosts, authenticates and manages code apps once they are pushed from the CLI
Canvas app – the drag-and-drop baseline whose styling and library limits code apps are meant to overcome
Power Platform – supplies connectors, Dataverse, DLP policies, solutions and pipelines that code apps inherit
Related episode: Power Apps - Simply Explained

Your AI Agents Are Orphaned: The Structural Shift to Agent ID

Sat, 11 Jul 2026 14:00:02 +0000

AI agents are multiplying across tenants with broad access, scattered credentials and no accountable owner. This episode shows identity, security and compliance leaders why service principals fail for AI and how Agent 365 and Microsoft Entra Agent ID, with blueprints, sponsors and conditional access, turn orphaned agents into governed digital workers.

In this episode

00:00 – The orphaned agent problem
03:02 – Why service principals fail for AI
05:58 – Agent ID and blueprints
13:39 – Governance as physics
16:28 – Data access and security shift
21:50 – Licensing, registry and conditional access
34:34 – The 30-day roadmap
60:32 – Mistakes and the structural shift

Key takeaways

Service principals were built for static applications and cannot handle instancing, credential sprawl, per-agent logging or lifecycle governance for AI agents.
Microsoft Entra Agent ID makes agents first-class identities with blueprints that centralize credentials, mandatory human sponsors, access reviews, conditional access and agent-specific risk detection.
Organizations should inventory existing agents, assign sponsors, build blueprints and harden them with conditional access, Purview and Defender before auditors or incidents force the issue.

Worth quoting

“You're treating AI agents like simple apps or service accounts. That's a structural error. It's going to cost you control of your data, your identity fabric, and your compliance posture.” – Mirko Peters (00:11)

“Every agent identity now requires a sponsor. Not a developer, not a team alias, but a named human who is accountable for why that agent exists, what it's allowed to touch, and whether it still needs to exist next quarter.” – Mirko Peters (07:29)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on governing AI agent identities
Microsoft Entra Agent ID – the new Entra identity type with blueprints and sponsors that the whole episode builds on
AI agent – the non-human workers multiplying in tenants without owners, inventory or lifecycle governance
Microsoft Agent 365 – the platform that reached general availability alongside Agent ID, licensed per governing user
Related episode: Stop Treating Agents Like Service Accounts

The Architecture of Agility: Bicep at Scale

Sat, 11 Jul 2026 04:00:03 +0000

Your Azure landing zone may be slowing teams down so much that they build around it. This episode is for cloud architects and platform teams running Azure at scale, and shows how Bicep modules, subscription vending and guardrail-style governance turn the official path into the fastest path.

In this episode

00:00 – Why rigid landing zones create shadow IT
03:42 – Subscription strategy and subscription vending
08:37 – Network architecture and the connectivity tax
12:19 – Shared services and multi-region design
19:42 – Bicep modules as infrastructure contracts
35:42 – Policy as code, identity and observability
48:01 – Cost governance, security baselines and shadow IT signals
59:43 – Platform engineering, KPIs and designing for evolution

Key takeaways

Landing zone code encodes organizational decision rights, and gatekeeper governance that slows provisioning pushes teams into shadow IT.
Subscription vending, versioned Bicep modules consumed by pinned version, and audit-first policy rollout make the governed path faster than the ungoverned one.
Treat the landing zone as a versioned platform product: centralize what must be uniform, distribute what must move fast, and measure provisioning time, compliance trends and drift.

Worth quoting

“Every decision encoded in those bicep templates is actually a decision about who gets to decide things. Who can create a resource? Who approves policy changes? How fast can a team get what they need?” – Mirko Peters (01:41)

“Gatekeeper governance designed to reduce risk actually increases it. Because the more friction you create in the official path, the more teams find unofficial paths.” – Mirko Peters (02:27)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on landing zones at scale
Azure landing zone – treated as a versioned platform product whose rigidity can push teams into shadow IT
Bicep – used for subscription vending and versioned, pinned modules that act as infrastructure contracts
Governance – shifted from gatekeeper approvals to guardrails, audit-first policy and a centralize-or-distribute framework
Related episode: The IaC Trap:Terraform vs. Bicep – Which One Wins?

Designing the Future. AI, UX, and the Next Generation of Microsoft Power Platform with Tchesco Ayih [MVP-MCT]

Fri, 10 Jul 2026 14:00:02 +0000

In https://www.m365.fm/designing-the-future-ai-ux-and-the-next-generation-of-microsoft-power-platform-with-tchesco-ayih/ of the M365 Podcast, Mirko Peters sits down with Tchesco Ayih, Microsoft MVP, Microsoft Certified Trainer (MCT), international speaker, mentor, and https://www.m365.fm/power-platform-simply-explained/ expert. Tchesco shares his inspiring journey into the Microsoft ecosystem, discusses the growing importance of user experience (UX) in low-code development, and explores how artificial intelligence is transforming the way organizations build business applications. From Power Apps and Dataverse to https://www.m365.fm/categories/copilot-talk/ Studio and AI-powered development, this conversation provides valuable insights for anyone working with Microsoft technologies, citizen development, low-code platforms, or digital transformation initiatives. Tchesco explains why beautiful design is not just a nice-to-have feature but a critical component of successful business applications, and why user-centric thinking should always come before functionality.

FROM TRADITIONAL DEVELOPMENT TO MICROSOFT POWER PLATFORM
Tchesco's journey into the Microsoft ecosystem started as a traditional developer with a passion for user interfaces and design. After earning Azure certifications and sharing his learning journey online, an opportunity emerged that introduced him to Microsoft Power Platform. What initially began as curiosity quickly developed into a career dedicated to helping organizations build efficient business solutions using low-code technologies. Throughout the discussion, Tchesco highlights how continuous learning, community engagement, and technical curiosity played essential roles in shaping his professional path. His story serves as a reminder that modern technology careers often evolve through experimentation, networking, and a willingness to embrace emerging platforms.

THE MVP AND MCT JOURNEY
Becoming a Microsoft MVP and Microsoft Certified Trainer did not happen overnight. Tchesco discusses how helping others in online communities became the foundation of his recognition within the Microsoft ecosystem. By answering technical questions, delivering community sessions, supporting Microsoft Learn Student Ambassadors, and consistently sharing knowledge, he built a reputation that eventually led to an MVP nomination. Key lessons from his journey include:

- Consistently contribute to technical communities.
- Share knowledge freely and help solve real problems.
- Build expertise through hands-on experience.
- Pursue Microsoft certifications to validate skills.
- Seek mentorship from experienced professionals.
- Give back to the community that helped your own growth.
WHY UX IS THE SECRET INGREDIENT OF GREAT BUSINESS
APPS One of the most passionate parts of the discussion centers around User Experience (UX). According to Tchesco, many Power Platform developers become overly focused on functionality and process automation while neglecting how users actually experience the application. A business process may work perfectly from a technical perspective, but if the application feels confusing, cluttered, or difficult to navigate, user adoption can suffer significantly. Tchesco argues that every application should be designed with accessibility, usability, and user satisfaction in mind. He emphasizes that developers should think beyond buttons and forms and consider:

- User accessibility requirements.
- Application navigation flows.
- Visual hierarchy and layout.
- User feedback cycles.
- Readability and simplicity.
- Long-term adoption and engagement.
Rather than viewing UX as a separate discipline, Tchesco believes UX should be integrated into every stage of Power Platform development.

DESIGN FIRST, FEATURES SECOND
One of the most powerful takeaways from the conversation is Tchesco's belief that developers should begin with the user interface before implementing features. Many developers immediately start building databases, business logic, and automation workflows. However, Tchesco recommends designing the application's screens first, creating a clear structure for how users will interact with information before any technical implementation begins. A thoughtful interface helps developers:

- Organize business processes logically.
- Clarify data requirements.
- Reduce development rework.
- Improve stakeholder alignment.
- Create more intuitive user journeys.
- Increase overall user satisfaction.
This design-first mindset helps teams build solutions that are both technically effective and enjoyable to use.

UNDERSTANDING THE MICROSOFT POWER PLATFORM ECOSYSTEM
For listeners new to the Power Platform, Tchesco provides a practical overview of the platform's major components and how they work together to accelerate digital transformation initiatives. The Microsoft Power Platform consists of:

- Power Apps for low-code application development.
- https://www.m365.fm/power-automate-simply-explained/ for workflow automation.
- Dataverse as a scalable relational data platform.
- https://www.m365.fm/power-pages-simply-explained/ for external-facing business websites.
- Copilot Studio for conversational AI experiences.
- Connectors that integrate hundreds of business systems.
Together, these tools enable organizations to rapidly automate processes, modernize legacy workflows, and reduce development timelines that traditionally required months of custom coding.

DATAVERSE: THE FOUNDATION OF MODERN BUSINESS SOLUTIONS
The conversation explores why Dataverse has become one of the most important components of the Power Platform ecosystem. Tchesco describes Dataverse as much more than a simple database. Its relational architecture, deep integration with Microsoft services, security model, and performance capabilities make it a strong choice for enterprise-grade business applications. Compared to traditional approaches relying heavily on SharePoint lists, Dataverse enables more scalable and maintainable business solutions while supporting advanced application scenarios and automation workflows.

AI, COPILOT STUDIO, AND THE FUTURE OF APPLICATION DEVELOPMENT
Artificial Intelligence plays a major role throughout the discussion. Tchesco shares how AI has already transformed many aspects of his daily work, helping accelerate development, generate ideas, improve productivity, and reduce repetitive tasks. The conversation explores the growing role of:

- AI-assisted development.
- Prompt engineering.
- Copilot Studio.
- Agent-based experiences.
- AI-powered business automation.
- Conversational user interfaces.
Rather than replacing developers, Tchesco views AI as a powerful assistant that increases productivity when used correctly. He compares AI to a junior colleague that can help complete tasks faster, while experienced professionals remain responsible for validation, governance, and final decision-making.

PROMPT ENGINEERING IS BECOMING A CRITICAL SKILL
One particularly interesting topic is the emergence of prompt engineering as an essential skill for modern developers. According to Tchesco, professionals who learn how to communicate effectively with AI systems will gain a significant advantage. Knowing how to provide clear context, detailed requirements, and accurate instructions can dramatically improve the quality of AI-generated outputs. As AI becomes increasingly embedded across Microsoft products and business applications, prompt-driven development is likely to become a standard part of the software development process.

GOVERNANCE AND RESPONSIBLE AI ADOPTION
While enthusiastic about AI's potential, Tchesco also stresses the importance of governance. Organizations must establish clear guidelines around:

- Data security.
- Privacy protection.
- AI usage policies.
- Information sharing restrictions.
- Compliance requirements.
- Human oversight and validation.
Successful AI adoption requires balancing innovation with responsible governance. Businesses that introduce AI without adequate controls may expose sensitive information or create risks that outweigh the benefits.

COMMUNITY, LEARNING, AND GIVING BACK
Beyond technology, this episode highlights the importance of community engagement. Tchesco attributes much of his professional growth to the Microsoft community. By participating in forums, speaking at conferences, mentoring others, and sharing knowledge, he has developed both technical expertise and professional opportunities. His message is clear: growth accelerates when individuals actively contribute rather than simply consume information. Whether through local user groups, virtual events, online forums, or international conferences, communities remain one of the most valuable resources available to technology professionals.

LOOKING AHEAD: THE FUTURE OF LOW-CODE DEVELOPMENT
As the conversation concludes, Tchesco shares his perspective on the future of low-code technology. He believes low-code platforms will continue to expand rapidly over the coming years, enabling organizations to build solutions faster while empowering more people to participate in application development. At the same time, strong foundations in UX, governance, architecture, and problem-solving will remain essential. Technology may evolve, but understanding users and solving business ch

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.

Azure Bicep Fundamentals for Real Projects

Fri, 10 Jul 2026 04:00:02 +0000

Most Bicep files are just portal clicks translated into code, which is automation, not architecture. This episode is for Azure architects and platform teams and shows how to use Bicep, deployment stacks, management groups, Azure Policy and Azure Verified Modules to build governed, predictable infrastructure that survives organizational change.

In this episode

00:00 – Why Bicep is more than ARM with better syntax
03:06 – What changed in 2026
06:13 – The scope problem
09:33 – Parameters, variables and modules as contracts
19:02 – Deployment stacks and state management
23:02 – Governance at the tenant level: policy, RBAC and AVM
43:22 – Landing zones, environments and pipelines
58:32 – Bicep versus Terraform, drift and brownfield

Key takeaways

Enterprise Bicep is about lifecycle, ownership and governance: scope above subscriptions, contracts enforced in parameters and modules, and state managed through deployment stacks.
Management groups, Azure Policy and role assignments defined in Bicep let governance cascade automatically to every subscription and landing zone.
Build on Azure Verified Modules, publish versioned modules to a registry, deploy through gated pipelines and validate continuously against drift.

Worth quoting

“A module isn't just a reusable template. That's a technical description. A module is a contract. It says, this is how we do networking in our organization.” – Mirko Peters (12:31)

“When you write bicep at management groups scope, you're not deploying resources anymore. You're defining the rules that govern how resources can be deployed.” – Mirko Peters (08:13)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and FAQ on enterprise Bicep
Bicep – the episode's subject, presented as the vehicle for governance, deployment stacks and versioned modules
Azure landing zone – pre-configured subscriptions composed from Bicep modules, with the ALZ reference architecture as blueprint
Infrastructure as code – reframed as the control plane, with drift, pipelines and brownfield migration as ongoing discipline
Related episode: ARM Templates Were a Mistake: Lessons from the Bicep Shift

Beyond Prompt a Page: Building Enterprise-Ready AI Experiences in Power Apps with Sara Lagerquist [MVP]

Thu, 09 Jul 2026 14:00:02 +0000

Generative pages promise AI-built UIs in Power Apps, but how do you get from a quick demo to something an enterprise can maintain? Microsoft MVP Sara Lagerquist explains when to extend model-driven apps with generative pages, why the code-first route beats the maker portal, and how governance and process design keep citizen-built apps under control.

In this episode

00:00 – Intro and Sara's journey from CRM admin to MVP
02:41 – Why Power Platform and model-driven apps
05:22 – Generative pages inside model-driven apps
08:04 – Maker portal vs. coding tools like VS Code
15:14 – Prompting, documentation and maintainability
21:30 – New data sources, form embedding and PCF
26:52 – Governance, citizen development and the CoE
34:56 – Community Sweden, speaking and career advice

Key takeaways

Generative pages let you keep the out-of-the-box strengths of a model-driven app and extend only the UI where it falls short.
For production-ready generative pages, build them through a coding tool such as VS Code with GitHub Copilot and Microsoft's skill rather than the maker portal, which is best for trying things out.
As AI makes app creation fast, the hard parts become process design, adoption and governance, so makers should invest in designing processes first.

Worth quoting

“So the combination of all the benefits of model driven apps plus a gen page is like the future of apps.” – Sara Lagerquist (07:25)

“I would say the UI way of doing it, the maker portal way of doing it, it's mostly for trying it out and maybe at most doing a proof of concept maybe.” – Sara Lagerquist (10:06)

Explore more on M365.FM

Episode page: the full interview with chapters, quotes and FAQ on generative pages in Power Apps
Sara Lagerquist – Microsoft MVP and applications architect explaining how she builds generative pages in model-driven apps
Generative pages – the AI-generated pages Sara calls her favorite feature and recommends building through code tools
Model-driven app – the app type generative pages extend, keeping its out-of-the-box navigation, search and fast development
Related episode: Power Apps - Simply Explained

ARM Templates Were a Mistake: Lessons from the Bicep Shift

Thu, 09 Jul 2026 04:00:02 +0000

Portal clicks feel fast, but they quietly create configuration drift that breaks governance at scale. This episode is for Azure architects and platform teams deciding between ARM, Bicep and Terraform, and it explains how infrastructure as code, policy as code and guardrails keep both humans and AI agents under control.

In this episode

00:00 – The death of ClickOps and configuration drift
07:22 – From imperative to declarative infrastructure
10:26 – ARM templates: the necessary mistake and cognitive load
17:48 – Bicep: designed for humans, compiled for machines
23:56 – Drift as a governance epidemic and IaC as the control plane
30:41 – AI agents, guardrails and Bicep vs. Terraform
41:44 – Governance as an operating model and continuous compliance
55:14 – Infrastructure as intent, lessons and next steps for leaders

Key takeaways

Configuration drift from manual portal changes is a governance failure, and only declarative infrastructure as code makes the actual state visible, reviewable and correctable.
Bicep compiles to ARM JSON but removes its syntax noise, which is why new Azure projects default to it while legacy ARM templates persist because of switching costs.
AI agents can generate infrastructure code quickly, but it must flow through policy as code, human review and CI/CD so that automation never outpaces control.

Worth quoting

“If you treat it like a technical problem, you'll miss what's actually happening. You'll spend money on tools and miss the structural failure underneath because drift is a governance failure.” – Mirko Peters (04:00)

“AI agents must operate within policy guardrails, not autonomously, not with broad permissions, not trusted to make security decisions without oversight. They generate proposals, policies validate those proposals, humans review the validated output.” – Mirko Peters (34:06)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on Bicep and drift
Bicep – the Azure-native language that compiles to ARM JSON while removing its syntax noise
Infrastructure as code – presented as the governance control plane that makes drift visible and correctable
Governance – reframed from approval gates to an operating model of structural controls, policy and enforcement
Related episode: The IaC Trap:Terraform vs. Bicep – Which One Wins?

Can Google Sheets Beat Excel: Microsoft MVP David Benaim Settles the Debate

Wed, 08 Jul 2026 14:00:03 +0000

Excel has been around for 40 years, yet Google Sheets now matches or beats it in several areas that many Microsoft-centric teams overlook. In this conversation Excel MVP and comedian David Benaim compares tables, formulas, collaboration, scripting and AI assistants in both tools to help analysts and business users choose the right spreadsheet for each job.

In this episode

00:00 – Meet David Benaim, the Excel comedian
06:47 – Is Excel dead? A short history of spreadsheets
12:34 – Google Sheets vs. Excel: tables, Power Query and collaboration
21:30 – AI in spreadsheets: Copilot, Claude and Gemini
28:11 – Formulas, VBA, Office Scripts and Apps Script
33:08 – From Power Pivot to Power BI
42:35 – Spreadsheet bugs, comedy and the future of spreadsheets
50:49 – Rapid-fire round

Key takeaways

Neither tool simply wins: Excel leads with Power Query, Power Pivot and the Microsoft ecosystem, while Google Sheets has more functions, group-by views and friction-free collaboration across organizations.
AI is reshaping spreadsheets fast, from Copilot's editing agent and Claude's Excel add-in to Gemini features in Google Sheets such as smart fill and canvas views.
Spreadsheets will still exist in ten years, and the most valuable habit to adopt now is using proper tables in either Excel or Google Sheets.

Worth quoting

“spreadsheets in general allow for that flexibility that I think the office employee is going to want for the very, very foreseeable future.” – David Benaim (07:53)

“I think that Excel has power query and power query is absolutely game-changing. And for that reason, until Google sheets has an equivalent, I will favor Excel.” – David Benaim (14:54)

Explore more on M365.FM

Episode page: the full conversation with chapters, quotes and FAQ on Excel versus Google Sheets
David Benaim – Excel MVP, trainer and stand-up comedian who compares Excel and Google Sheets feature by feature
Microsoft Excel – the 40-year-old spreadsheet David still favors, mainly because of Power Query
Power Query – the data cleanup feature David calls the main reason Excel still beats Google Sheets
Related episode: From Excel Expert to Microsoft MVP: Empowering Millions with Data, Dashboards & AI with Karen Abecia [Microsoft MVP]

LinkedIn + Dynamics 365: The Architecture of Modern Selling

Wed, 08 Jul 2026 04:00:02 +0000

Your CRM holds records, but your business runs on relationships that live on LinkedIn. This episode shows sales leaders and Dynamics 365 architects how to connect LinkedIn and Dynamics 365 with Sales Navigator, relationship health scoring, Copilot and orchestrated agents while staying within rate limits, GDPR and good governance.

In this episode

00:00 – Why your CRM is blind
02:40 – The three disconnects
06:07 – LinkedIn APIs, Sales Navigator sync and Power Automate
16:49 – Native integration and relationship health
22:54 – Copilot for Sales and sales agents
29:20 – Orchestration, rate limits and timeouts
41:49 – Governance, roadmap and the changing seller role
64:28 – Multi-agent B2B and the risks

Key takeaways

LinkedIn holds the relationship graph and Dynamics 365 holds the process, so modern selling needs an architecture that connects them through official channels such as Sales Navigator CRM sync.
Relationship health scoring, Copilot for Sales and orchestrated sales agents turn synced data into insight and action, but they must be designed around API rate limits, timeouts and governance.
Roll out in phases, treat LinkedIn data like regulated data and keep humans reviewing agent decisions to manage hallucination, bias and over-reliance risks.

Worth quoting

“Your CRM is a database of records, but your actual business is a network of relationships.” – Mirko Peters (01:47)

“GDPR does not care how clever your integration is. It requires a lawful basis for collecting personal data. And linked in profiles are definitely personal data.” – Mirko Peters (42:40)

Explore more on M365.FM

Episode page: the full episode with chapters, key quotes and an FAQ on the architecture
Dynamics 365 – the process half of the architecture, holding the records that LinkedIn signals should feed
AI agent – sales research, development and orchestrated specialist agents that research, qualify and route leads
Dynamics 365 Sales – the CRM where Sales Navigator sync, relationship health scoring and native LinkedIn features land
Related episode: Dynamics 365 Agents - Simply Explained

Azure Networking Unlocked: Secure Azure Functions, Virtual Network Manager & Infrastructure as Code with Rex de Koning [MVP-MCT]

Tue, 07 Jul 2026 14:00:02 +0000

Many teams assume Microsoft takes care of networking in the cloud, then find gaps in security and routing later. Azure MVP Rex de Koning explains to cloud architects and admins how Azure networking really works, from hub-and-spoke and Virtual Network Manager to securing Azure Functions. You come away with practical guidance on building network foundations with infrastructure as code.

In this episode

00:00 – Why networking is the foundation
02:11 – Rex's path into Azure
06:54 – Azure networking misconceptions and topologies
13:50 – Azure Virtual Network Manager
24:22 – Landing zones and infrastructure as code
42:01 – Securing Azure Functions
51:19 – Final advice

Key takeaways

In Azure, routing happens at the resource level, so network security groups remain essential even behind a central firewall.
Azure Virtual Network Manager centralizes IP address management, connectivity, security admin rules and routing across many virtual networks.
Deploy networks and Azure Functions through infrastructure as code with private endpoints and VNet integration, and feed any emergency portal fix back into code.

Worth quoting

“And with Azure Virtual Network Manager, you have basically an admin rule that you can push towards all network security groups that are connected to the Azure Virtual Network Manager.” – Rex de Koning (17:34)

“So if you set it up in infrastructure as code that it has multiple advantages, it will always set things up always in the same way that you want it.” – Rex de Koning (30:03)

Explore more on M365.FM

Episode page: the full conversation with chapters, quotes and FAQ on Azure networking
Rex de Koning – Azure MVP and MCT who explains Azure networking, Virtual Network Manager and securing Azure Functions
Infrastructure as code – Rex's default for networks and functions, with what-if checks and emergency fixes fed back into code
Microsoft Azure – the cloud platform whose resource-level routing, hub-and-spoke designs and landing zones frame the whole conversation
Related episode: Azure Local and Landing Zones: How to Build Hybrid Cloud the Right Way with Christoffer Klarskov Jakobsen [MVP]

The PowerShell Ceiling: Why You Need Bicep

Tue, 07 Jul 2026 04:00:02 +0000

You have dozens of PowerShell scripts that work, but nobody could rebuild the platform behind them in three hours. This episode is for Microsoft 365 and Azure automation engineers who have hit the scripting ceiling. Learn how Bicep turns infrastructure and identity into versioned, auditable code and how to start the transition next Monday.

In this episode

00:00 – 50 Scripts Nobody Can Govern
01:08 – The Automation Journey
03:17 – What PowerShell Is and Isn't
09:21 – The Declarative Shift with Bicep
15:38 – Identity as Infrastructure with Graph Bicep
24:56 – Governance as Code, Modules and Git
35:40 – CI/CD Pipelines and Career Impact
58:56 – Limitations, Terraform and First Steps

Key takeaways

Script sprawl fails not because PowerShell is bad but because imperative scripts never declare the infrastructure, identities and permissions they depend on.
Bicep, now including Microsoft Graph resources, lets you declare Azure infrastructure and Entra ID identity in Git, with modules, what-if previews and pipelines enforcing governance by default.
Use Bicep for infrastructure, PowerShell for operations and Graph for data, and choose Terraform only when you genuinely operate across multiple clouds.

Worth quoting

“It does not fail because the scripts are bad. It fails because automation that scales becomes infrastructure that nobody can govern.” – Mirko Peters (00:30)

“PowerShell is a tool for doing things. It is not a tool for defining what things should be.” – Mirko Peters (05:58)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on Bicep
Bicep – the Azure-native declarative language the episode recommends for defining infrastructure and identity as code
Infrastructure as code – the shift from imperative scripts to declared, versioned infrastructure kept in Git
Governance – the hidden cost of script sprawl, solved by modules that enforce naming, tags and logging
Terraform – the multi-cloud alternative, recommended only when you actually run workloads beyond Azure
Related episode: ARM Templates Were a Mistake: Lessons from the Bicep Shift

Beyond the Prompt: Architecting Multi-Agent AI Solutions with Microsoft Copilot & SharePoint with Reshmee Auckloo [MVP]

Mon, 06 Jul 2026 14:00:02 +0000

Many organizations want AI agents but struggle to move from demo to a trustworthy enterprise solution. This episode is for Microsoft 365 architects, makers and governance leads, and covers with MVP Reshmee Auckloo how to roll out Copilot responsibly and design multi-agent solutions with Copilot Studio, Foundry, MCP and SharePoint.

In this episode

00:00 – Introduction and Reshmee's journey into Microsoft technologies
03:33 – Responsible Copilot adoption, permissions and Purview
08:52 – Customer concerns about AI and keeping up with change
15:04 – Microsoft Build announcements and Copilot readiness
23:03 – Copilot extensibility: from SharePoint agents to Foundry
31:55 – Multi-agent systems, autonomy and MCP
44:19 – Identity, governance, metadata and information architecture
51:25 – Quick-fire round and community contributions

Key takeaways

Rolling out Copilot safely starts with permission hygiene and Purview guardrails, because Copilot surfaces any data a user already has access to.
Copilot extensibility spans SharePoint agents, Agent Builder, Copilot Studio, the Agents Toolkit and Microsoft Foundry, and the right choice depends on the use case.
Multi-agent solutions use an orchestrator with smaller specialized agents that are easier to test and maintain, while MCP tools, Entra-based agent identity and good metadata keep them controllable.

Explore more on M365.FM

Episode page: the full conversation with chapters, quotes and FAQ on multi-agent design
Reshmee Auckloo – Microsoft MVP and PnP PowerShell maintainer who shares her approach to governed Copilot and agent rollouts
Copilot Studio – the low-code option for connected agents, workflows and cross-platform multi-agent orchestration
Microsoft 365 Copilot – rolled out safely only after permission hygiene, Purview guardrails and a readiness assessment
Related episode: Extending Microsoft 365 Copilot: Agents, MCP & Production-Grade AI with Yves Habersaat [MVP]

How To Trick Microsoft Graph Into Securing Your Entire Tenant

Mon, 06 Jul 2026 04:00:02 +0000

Green dashboards and quarterly permission reviews give security teams a false sense of control over Microsoft 365. This episode shows admins and security architects how to use Microsoft Graph to monitor risky users, conditional access, audit and activity logs and OAuth permissions continuously. You learn how to build automated, governed security workflows that respond in minutes instead of days.

In this episode

00:00 – Why portals create false confidence
03:16 – From state to flow
06:12 – Graph as the control plane
09:41 – The identity and token illusion
12:50 – The application permissions crisis
16:34 – Alerts, automation and latency
34:18 – Activity logs, permissions and detection
50:48 – Graph-driven SOC and governance

Key takeaways

Microsoft Graph is the control plane beneath every Microsoft 365 portal, so security built on Graph sees continuous flow instead of snapshots.
OAuth application permissions are the real perimeter; inventory them, verify actual use with Graph activity logs and revoke or reduce unused scopes continuously.
Design Graph-based security for latency and failure with tiered automation, approval gates, efficient queries and idempotent pipelines.

Worth quoting

“Graph is not just an API. It is not a wrapper around M365 that lets you do what you could already do in the portal. Graph is the control plane.” – Mirko Peters (06:41)

“Your perimeter isn't a firewall. It isn't your network boundary. Your real perimeter is OAuth permissions.” – Mirko Peters (37:23)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on Graph-based tenant security
Microsoft Graph – positioned as the control plane beneath every portal and the engine for automating tenant security
Conditional Access – policies managed as code through Graph, with propagation delays of up to 24 hours
Automation – tiered by risk from enrichment to destructive actions, with approval gates and audit trails
Related episode: The Hidden Logic of Microsoft Graph

Microsoft Graph: The Enterprise Nervous System

Sun, 05 Jul 2026 14:00:02 +0000

Most IT teams still find bad permissions, ownerless teams and overshared data by hand, long after the damage is done. This episode is for Microsoft 365 administrators, architects and security leads, and it explains how Microsoft Graph, Agent 365 and policy-driven automation turn reactive administration into self-healing, autonomous governance.

In this episode

00:00 – Enterprise IT without a nervous system
00:59 – From GUI to PowerShell to Microsoft Graph
03:56 – Why manual governance is breaking
09:54 – Graph as nervous system: detection, evaluation and remediation layers
22:29 – The 2026 inflection point, Agent 365 and Entra Agent ID
33:54 – Self-healing tenants, economics and Copilot as automation builder
47:17 – Security risks, humans in the loop and the future of PowerShell
57:27 – The 2030 operating model and what to do now

Key takeaways

Microsoft Graph is more than a developer API: it is the unified data plane through which detection, policy evaluation and remediation across Entra, Purview, Defender, Teams and SharePoint can run continuously.
Manual governance cannot keep up with configuration drift and AI-scale exposure, so organizations should define desired state as executable policy, detect deviations through events and continuous scans, and automate low-risk remediation first.
Agents must be governed like employees, with their own Entra Agent ID, an owner and sponsor, least-privilege permissions, conditional access and access reviews, while humans move to setting policy and handling exceptions.

Explore more on M365.FM

Episode page: the full episode with chapters, migration deadlines and FAQ on autonomous governance
Microsoft Graph – described as the unified data plane for detection, evaluation and remediation across Microsoft 365
Governance – the shift from manual reviews to policy-driven, self-healing governance is the episode's core argument
AI agent – agents are framed as digital workers that need owners, sponsors and least-privilege access
Related episode: The Architect's Guide to Graph-Powered Agents: Moving Beyond Chat

Beyond the Script: The Architect's Guide to Microsoft Graph Platforms

Sun, 05 Jul 2026 04:00:02 +0000

Many organizations drown in disconnected PowerShell scripts and Power Automate flows that break silently when their author leaves. This episode shows architects and automation teams how to move from fragile scripts to a governed Microsoft Graph platform with Logic Apps, Azure Functions, managed identities and reconciliation, ready for autonomous agents.

In this episode

00:00 – The hero-script trap and automation maturity
03:12 – Orchestration with Microsoft Graph subscriptions and delta queries
06:29 – Logic Apps vs. Azure Functions
09:29 – Silent failures and reconciliation
12:24 – Managed identities and governance as code
18:43 – The agent layer and a real-world blueprint
24:53 – Migration path, business case and operating model
59:24 – CI/CD, Key Vault and event-driven architecture

Key takeaways

Fragile hero scripts become a hidden cost at scale; orchestration through Microsoft Graph subscriptions, Logic Apps and Azure Functions turns them into a shared, governed platform.
Reliability comes from pairing webhooks with daily delta-query reconciliation, using managed identities and Key Vault instead of stored credentials, and enforcing governance as code.
Migrate incrementally, run old and new automations in parallel, apply CI/CD with Git, Pester and pipelines, and build the identity and governance foundation that agents and Agent 365 will need.

Explore more on M365.FM

Episode page: the full episode with chapters, a reference blueprint and a step-by-step migration path
Automation – the shift from fragile hero scripts to an orchestrated, governed automation platform
Microsoft Graph – the unified interface that acts as the central nervous system for orchestrated workflows
Change notifications and webhooks – pairing Graph subscriptions with a daily delta query so missed events are reconciled
Related episode: Beyond the Portal: The Strategic Architecture of Microsoft Graph and PowerShell

The Architect's Guide to Graph-Powered Agents: Moving Beyond Chat

Sat, 04 Jul 2026 14:00:02 +0000

Many organizations build agents as smarter chatbots and then wonder why they hallucinate or stall in pilots. This episode is for architects and IT leaders who want to understand how Microsoft Graph, MCP, LangGraph-style orchestration and Agent 365 combine into governed, graph-powered agents that can act safely at enterprise scale.

In this episode

00:00 – Why chat-only agents fail: the context gap
03:07 – Microsoft Graph as enterprise memory and the read/write boundary
09:41 – Tool calling and LangGraph workflows
13:40 – MCP as the standardization layer
17:20 – Graph connectors and Graph Data Connect
24:11 – Supervisor pattern, handoffs, identity and audit trails
42:13 – Agent 365, ownership and data protection
54:26 – Real-world patterns, scorecards and the road ahead

Key takeaways

Enterprise agents need context, memory and the authority to act, and Microsoft Graph supplies the organizational context that an LLM alone lacks.
Tool calling, MCP and orchestration frameworks such as LangGraph turn that context into governed actions, with supervisor agents coordinating specialists through shared state.
Scaling agents requires dedicated agent identities, least privilege, Purview audit and DLP, human approval for high-risk actions and Agent 365 as the inventory and governance control plane.

Explore more on M365.FM

Episode page: the full episode with chapters, real deployment patterns and a governance checklist
Microsoft Graph – the organizational context and memory that grounds agents and lets them act on real business data
AI agent – why agents need context, memory and authority to act rather than being smarter chatbots
Model Context Protocol (MCP) – the standard protocol that turns custom tool integrations into one governed layer for agent tool calls
Related episode: The Copilot Credit Trap- Why Your AI Economy is Already Broken

The Hidden Logic of Microsoft Graph

Sat, 04 Jul 2026 04:00:02 +0000

Most Microsoft 365 admins only ever touch three Graph endpoints and miss the reporting, audit, identity governance and security data underneath. This episode is for IT pros and decision makers who want to turn Microsoft Graph into a governance and intelligence layer. You learn which Graph surfaces to build on, from change notifications to Data Connect and hidden gems like Planner and Places.

In this episode

00:00 – What Graph really is
03:44 – Why teams stop at users and groups
07:19 – Reporting APIs and executive dashboards
14:14 – Audit and sign-in logs
17:27 – Delta queries and change notifications
20:49 – Identity governance and guest access
26:58 – Security, risk and compliance APIs
46:58 – Copilot control plane, hidden gems and roadmap

Key takeaways

Microsoft Graph is the control plane beneath Microsoft 365, and most organizations use only users and groups while reporting, audit, governance and security APIs sit unused.
Combining delta queries with change notifications replaces fragile polling with near real-time, event-driven governance and security automation.
Copilot quality and agent readiness depend on Graph maturity, including clean permissions, governed connectors and a documented consent ledger for app-only access.

Worth quoting

“Graph isn't a REST API you call to get data, it's the unified abstraction layer that sits over identity, collaboration, security, compliance, and analytics across the entire Microsoft Cloud.” – Mirko Peters (01:06)

“Subscriptions for immediacy. Delta tokens for precision. Neither alone gives you the full picture. Together, they give you a near real-time change stream over your organizational data that is both efficient and complete.” – Mirko Peters (19:43)

Explore more on M365.FM

Episode page: the full episode with chapters, quotes and an FAQ on the Graph surfaces covered
Microsoft Graph – the unified layer over identity, collaboration, security and compliance that the whole episode unpacks
Governance – treated as engineering work, enforced automatically through Graph events instead of policy documents
Audit logs – directory audit, sign-in and provisioning logs used as organizational memory and compliance evidence
Related episode: How To Trick Microsoft Graph Into Securing Your Entire Tenant

Everything Microsoft Didn't Tell You About Teams with Everything Microsoft Didn't Tell You About Teams with Josh Blalock [MVP]

Fri, 03 Jul 2026 14:00:02 +0000

Most organizations still treat meeting-room audio as an afterthought, even though Copilot now depends on it. In this episode, Microsoft MVP Josh Blalock explains to IT leaders and meeting-room planners how Teams evolved from Skype for Business, why audio beats video, what Teams certification really means and how to plan rooms that give AI clean data.

In this episode

00:00 – Welcome and Josh's path from Air Force IT to unified communications
03:39 – From Skype for Business to Microsoft Teams
06:12 – Becoming an MVP and the Shure Ignition program
17:55 – Why audio matters more than video
23:36 – Hardware vs. software: onboard DSPs and cloud audio processing
30:42 – Teams certified devices and why certification matters
34:48 – Planning meeting rooms for challenging acoustics
40:10 – Comms vNext and Josh's next chapter

Key takeaways

In AI-enabled meetings, audio is no longer just sound but the real-time data Copilot uses for summaries, action items and documents, so 'good enough' audio limits your AI investment.
Clean audio should be produced in the room, for example by onboard software DSPs in microphones and room kits, before Microsoft Teams processes it in the cloud.
Teams certified devices pass rigorous Microsoft testing and are the supported option, and complex rooms still benefit from an integrator, a proof of concept and acoustic treatment.

Worth quoting

“If your video fails, it's okay. The meeting can still go on. You can still hear people with audio. If your audio fails, now you're done. Your meeting is over.” – Josh Blalock (19:48)

“It's no longer just spoken words and audio. Now audio is actually real-time data that co-pilot is going to use to do a whole bunch of stuff to build documents, to create task lists, to send emails” – Josh Blalock (20:54)

Explore more on M365.FM

Episode page: the full interview with chapters, Josh's key quotes and FAQ on meeting-room audio
Josh Blalock – Microsoft MVP and Shure team member explaining why meeting-room audio now feeds Copilot
Microsoft Teams – traced from Skype for Business to Teams, with cloud audio processing complementing in-room hardware
Microsoft Teams Rooms – the meeting-room systems where Shure equipment and its Ignition program are focused
Related episode: Microsoft Places - Simply Explained