Back
Explore every episode of the podcast M365.FM - Modern work, security, and productivity with Microsoft 365
Dive into the complete episode list for M365.FM - Modern work, security, and productivity with Microsoft 365. Each episode is cataloged with detailed descriptions, making it easy to find and explore specific topics. Keep track of all episodes from your favorite podcast and never miss a moment of insightful content.
| Title | Pub. Date | Duration | |
|---|---|---|---|
| Dataverse licensing Power Apps: stop the cost explosion before your project goes live | 03 Nov 2025 | 00:23:48 | |
Dataverse licensing Power Apps: this episode of M365.fm breaks down why your Dataverse‑backed Power Apps project suddenly feels “too expensive” and how to design licensing, capacity, and environments so costs stay predictable instead of exploding right before go‑live. Mirko Peters starts with the Dataverse cost illusion: everyone assumes it “comes with” Microsoft 365, until premium connectors, per‑app vs. per‑user licenses, and separate storage tiers quietly stack up into a bill that shocks both project owners and finance. Mirko dissects the invisible premium inside Dataverse: licensing models that multiply with every additional app, environment, and user; capacity packs for database, file, and log storage; and API limits that push you toward higher‑tier licenses when automation gets serious. He explains why Dataverse is not “just a database” but a full data platform with enterprise compliance, security, and transactional guarantees—and why that power is overkill and overpriced for some scenarios, but absolutely justified for others. You’ll learn how premature Dataverse adoption can double or triple your costs when a simpler setup would have been enough. The episode then walks through the main licensing landmines. Mirko explains the difference between M365‑included Power Apps versus premium Dataverse usage, why “everyone is already licensed” is a myth, and how per‑app vs. per‑user choices change your cost curve as soon as a second app or environment is added. He also covers external users and portals, clarifying why guest access in Azure AD is not the same as free Dataverse usage, and how capacity consumption for external scenarios can surprise even experienced architects if it isn’t modeled upfront. You also get a practical playbook for designing Dataverse architectures that your budget can live with. Mirko outlines how to forecast capacity using environments × apps × users × data growth, when to stick with SharePoint or SQL and when Dataverse is truly worth the premium, and how to use sandboxes, shared environments, and careful connector choices to avoid unnecessary license escalation. By the end, you’ll have a clear view of when Dataverse is the right engine, when it’s an expensive luxury, and how to keep your next Power Apps project from becoming a licensing horror story. WHAT YOU WILL LEARN
Dataverse is not too expensive—using it blindly is. Once you understand how licensing, capacity, and environments really work, you can reserve Dataverse for the apps that truly need its enterprise guarantees and keep everything else on cheaper foundations, turning “licensing surprise” into deliberate, transparent design. WHO THIS EPISODE IS FOR This episode is ideal for Power Apps makers, solution architects, IT leaders, and finance partners who are planning Dataverse‑backed apps or discovering premium requirements late in the project. It is especially valuable if you need to justify Dataverse to budget owners, avoid hidden licensing traps, and build a repeatable cost model for your Power Platform portfolio. ABOUT THE HOST Mirko Peters is a Microsoft 365 and Power Platform consultant focused on building governed, scalable low‑code platforms with Dataverse, Power Apps, Power Automate, and Microsoft 365. Through M365.fm, he shares practical cost‑control patterns, licensing playbooks, and real‑world migration stories that help organizations ship serious apps without losing control of their Power Platform spend. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Governance risk in Copilot Notebooks: why your AI summaries are a compliance time bomb | 02 Nov 2025 | 00:21:53 | |
Copilot Notebooks governance risk: this episode of M365.fm reveals why Copilot Notebooks look like a productivity upgrade but quietly create a compliance and data‑lineage nightmare inside Microsoft 365. Mirko Peters shows how every “innocent” AI summary becomes a new, unlabeled data artifact that inherits no sensitivity labels, retention policies, or Purview visibility—turning powerful contextual answers into governance blind spots. Mirko starts by explaining what Copilot Notebooks really are: not tidy documents, but dynamic aggregation layers that pull context from SharePoint, OneDrive, Teams, email, and more into a temporary AI workspace. Each prompt fuses multiple sources into new text that lives in the cracks between systems—no clear owner, no clear location, and no automatic policy inheritance. You’ll learn why this “composite content” behaves like a scratch pad in the UI, but behaves like a Shadow Data Lake from a compliance perspective. He then unpacks the moment governance breaks. When Copilot blends HR, finance, and operations data into a single paragraph, the original labels and retention rules effectively fall off. The AI‑generated summary looks harmless (“engagement trends improved last quarter”), yet encodes insights from regulated sources that are no longer traceable to their origin. Mirko explains how Purview and DLP are built to see files and objects, not ephemeral AI context, and why that gap means Notebook outputs can be copied into emails, documents, and decks without any of the original controls following them. The episode goes deep on data lineage and regulatory impact. Mirko shows how Notebooks sever the “family tree” of information: Copilot does not embed source citations or structured provenance, so auditors cannot see which HR record, finance sheet, or legal memo fed a specific sentence. He walks through concrete scenarios where GDPR “right to be forgotten,” PCI, or internal retention rules become impossible to prove, because derivative Notebook content has been pasted into downstream assets that no catalog or sensitivity label can reliably discover. Finally, you get a pragmatic governance response plan. Mirko outlines how to frame Copilot Notebooks as high‑risk workspaces, when and where to allow them, and which guardrails to apply: user education, restricted use cases, export policies, and stronger Purview monitoring around AI‑generated content. He shares language you can use with security, legal, and business leaders to shift the question from “Is Copilot safe?” to “How do we keep derivative AI content inside our existing governance model instead of creating a hidden parallel system?”. WHAT YOU WILL LEARN
Copilot Notebooks don’t just summarize your data—they quietly dissolve your governance model. Unless you treat Notebook outputs as first‑class regulated content with owners, policies, and lineage, every productive AI session becomes a small compliance centrifuge, spinning sensitive inputs into untracked, unlabelled text. WHO THIS EPISODE IS FOR This episode is ideal for security and compliance teams, Microsoft 365 and Purview administrators, data protection officers, and digital workplace leaders evaluating Copilot Notebooks. It is especially valuable if you are under regulatory pressure and need to understand how AI‑generated summaries fit (or fail to fit) into your existing classification, retention, and audit frameworks. ABOUT THE HOST Mirko Peters is a Microsoft 365 consultant and digital workplace architect focused on building governed, scalable platforms with Microsoft 365, Purview, Copilot, and the Power Platform. Through M365.fm, he shares practical governance patterns, AI risk stories, and implementation playbooks that help organizations adopt Copilot capabilities without losing control of compliance and data protection. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Power Apps Generative Pages licensing: avoid the Dataverse premium trap before you click “Generate” | 29 Oct 2025 | 00:21:37 | |
Power Apps Generative Pages licensing: in this episode of M365.fm, Mirko Peters breaks down the “free lunch” illusion behind Generative Pages in Power Apps and explains how a single click on “Describe your page” can silently upgrade you into Dataverse‑backed, premium‑licensed territory. He shows how AI‑generated pages look like harmless prototypes—pretty calendars, dashboards, and forms built from a sentence—while under the hood they deploy Dataverse schema, model‑driven plumbing, and premium capabilities that finance will absolutely notice later. Mirko starts with what Generative Pages actually do. Copilot takes your natural‑language prompt, uses existing Dataverse tables or creates new ones, and scaffolds a React‑based page inside a model‑driven app—complete with relationships, security, and automation hooks. It feels like no‑code magic, but the reality is scaffolding, not sorcery: the AI wires you into Dataverse’s full enterprise stack, with all the compliance and licensing implications that come with it. What looks like a quick experiment is, from the platform’s perspective, a premium app. He then exposes the Dataverse “silent upgrade” most makers never see. As soon as a Generative Page binds to Dataverse, your app crosses from standard connectors (SharePoint, Excel) into premium land, where every active user now requires a Power Apps Premium license and your environment consumes Dataverse capacity for database, file, and log storage. Mirko explains why this is by design: Dataverse brings relational integrity, audit trails, and enterprise security—but that power is priced accordingly, and Generative Pages are built on the assumption you’re ready to pay for it. The episode also dismantles the SharePoint virtual table mirage. Many teams believe they can dodge Dataverse licensing by exposing SharePoint lists as virtual tables and letting Generative Pages sit on top “for free.” Mirko explains why this still relies on Dataverse as the metadata and security engine: virtual tables are Dataverse assets, not shortcuts around it. The platform still counts premium usage, and you end up with Dataverse complexity plus SharePoint limitations, instead of a genuinely cheaper architecture. Throughout the conversation, Mirko gives you a practical decision framework. You’ll learn when Generative Pages plus Dataverse are absolutely worth it—regulated workloads, complex relational models, long‑lived apps—and when you should stick to Canvas Apps on standard connectors or other patterns to avoid surprise licensing explosions. He closes with concrete steps for platform owners: documenting premium patterns, setting environment guardrails, educating makers about the “generate = premium” rule, and budgeting Generative Pages as enterprise assets instead of free experiments. WHAT YOU WILL LEARN
Generative Pages are not free UI toys—they are Dataverse deployment buttons with good marketing. Once you see that “Describe your page” really means “Stand up a premium, governed Dataverse app,” you can stop sleepwalking into licensing traps and start treating these pages like the enterprise assets they actually are. WHO THIS EPISODE IS FOR This episode is ideal for Power Apps makers, solution architects, Power Platform admins, and IT or finance leaders who are piloting Generative Pages or seeing unexpected premium usage in their tenant. It is especially valuable if you need clear language and a concrete framework to explain to stakeholders when Generative Pages are worth the Dataverse investment—and when they are an expensive way to solve a simple problem. ABOUT THE HOST Mirko Peters is a Microsoft 365 and Power Platform consultant focused on building governed, scalable low‑code platforms with Power Apps, Dataverse, Power Automate, and Microsoft Copilot. Through M365.fm, he shares practical licensing playbooks, architecture patterns, and real‑world migration stories that help organizations get the benefits of AI‑assisted app building without losing control of costs and governance. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| The Dataverse Migration Nobody Wants (But Needs): SharePoint Lists vs Dataverse vs SQL, Costs, Licensing & When To Move | 23 Sep 2025 | 00:18:27 | |
Look, we all joke about Microsoft licensing being a Rubik’s cube with missing stickers—but Dataverse isn’t just that headache, it’s the moment you admit your SharePoint lists and SQL leftovers can’t carry “version 3.0” of your app anymore. In this episode, we start from exactly where most teams are stuck: business‑critical processes living in oversized SharePoint lists, half‑documented SQL databases, and Power Apps that bend under the weight of added columns, lookups, and flows. You’ll hear why Dataverse is more than “a nicer list”—proper relationships, row‑ and field‑level security, auditing, APIs—and how migration pain is usually the bill for years of duct‑tape design rather than some cruel Microsoft upsell. We walk through the real trade‑offs between Lists, Dataverse, and SQL Server so you know when to stay, when to move, and how to avoid the classic trap of discovering premium licensing only after you’ve gone all‑in. WHAT EVEN IS DATAVERSE, AND WHY ISN’T IT JUST ANOTHER LIST? https://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266We start by killing the “Dataverse = fancy list” myth. Dataverse is built as the data backbone for the Power Platform—tables, relationships, role‑based security, auditing, and API endpoints you can depend on—while SharePoint lists are brilliant for quick capture and lightweight apps but buckle once you stack relationships, lookups, and scale. You’ll hear real scenarios where a simple tracker list quietly grew into a mission‑critical app: flows started failing, view thresholds hit, permissions became unmanageable, and suddenly Dataverse didn’t look like overkill anymore, it looked like the life raft. We give you a three‑question gut‑check you can run on any workload (relationships, security, long‑term criticality) to decide if staying on Lists is realistic or if you’re already betting your business on something that was never meant to scale. THE GOOD, THE BAD AND THE UGLY: LISTS VS DATAVERSE VS SQL https://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266Next, we stop pretending any of these tools are perfect. Lists win on speed and zero extra license friction; they’re fantastic for prototypes, trackers, and genuinely small processes—but overload them and you’re fighting view limits, broken lookups, and flows that stall at the worst possible moment. Dataverse gives you structural integrity—normalized tables, relationships, security, auditing, and automation—but it brings real costs in storage, premium licensing, and skill requirements that you must plan for early instead of discovering during rollout. SQL Server still has the deepest power and history, but for most maker‑led Power Platform scenarios it’s effectively locked behind DBA skills, permission complexity, and governance overhead that leaves citizen developers frozen. We break down where each fails, when each shines, and how to avoid choosing a tool on day one that guarantees emergency tickets six months later.https://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266 THE COST NOBODY PUTS IN THE DEMO SLIDE https://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266Then we talk about money and time—the part that never appears in the marketing deck. Dataverse’s real cost doesn’t stop when the app loads; storage, premium capacity, and capability‑based licensing all stack up over time. We walk through a budgeting checklist you can actually use: estimate data growth, identify premium connectors and features, check which licenses your users really have, and factor in the skills ramp you’ll need so Dataverse isn’t just “that thing only one person understands.” You’ll learn why relying on trials and assumptions is the fastest way to get burned, how to bring procurement into the conversation before migration, and how to frame Dataverse cost against the hours you currently burn patching broken lists, flows, and shadow SQL instances. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Dataverse isn’t “the expensive option,” it’s the platform you reach for when you stop pretending a glorified list or legacy SQL box can safely run a business‑critical app. Migration pain is real—but it’s also the price of finally getting proper relationships, security, and governance instead of living in a swamp of brittle lists and half‑managed databases. Once you choose the right data platform for the right job—and budget honestly for Dataverse where it fits—you trade surprise outages and hidden risk for something boring, predictable, and scalable. https://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67867890/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and Power Platform consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, Dataverse, SQL, and Power Apps as one integrated operating system instead of a patchwork of lists, legacy databases, and one‑off apps. He works with teams running on Microsoft 365 and Azure to design architectures, migration paths, and governance so that Dataverse, SharePoint, and SQL each do the job they’re best at—without surprise costs or weekend‑killing outages. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| How Data Goblins Wreck Copilot For Everyone: Clean Inputs, Real Adoption & The 10 Steps To A Copilot Rollout That Actually Works | 23 Sep 2025 | 00:18:01 | |
Picture your data as a swarm of goblins: messy, multiplying in the dark, and definitely not helping you win over users. Drop Copilot into that chaos and you don’t get magic productivity—you get polished wrong answers: outdated contract summaries, conflicting numbers, and “confident” nonsense that looks like it came from 2017. The fix isn’t another slide deck, it’s hunting those goblins before rollout: cleaning a small, high‑value slice of content, tightening metadata and governance, and proving Copilot works there first. In this episode, I walk through the Top 10 actions that make Copilot genuinely useful—concrete steps you can run this week—not theory, plus a free checklist at m365.show so your rollout doesn’t fail before anyone even touches it. WHY DEPLOYMENTS FAIL BEFORE DAY ONE https://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266Too many Copilot deployments fail before users ever give it a fair shot—not because of a bad Microsoft update, but because we flip the switch on top of a dumpster‑fire data estate. When your tenant is full of untagged files, duplicate spreadsheets, “Final\_v7\_REALLY.xlsx” versions, and contract libraries where expired drafts still pretend to be current, Copilot just turns that garbage into fluent garbage. Users ask simple questions like “show me open contracts with supplier X,” get answers mixed with outdated or wrong documents, and immediately label the tool “unreliable.” Trust dies on the first bad answer, not the tenth—and once hallway chat brands Copilot as “just another gimmick,” adoption flatlines no matter how much you spent on licenses or comms. The only way out is to start small and surgical: clean one critical content area, enforce structure and metadata, connect Copilot to that slice, and use the before/after difference as your internal case study for everything else. HOW ORGANIZATIONS GOT PEOPLE TO WANT COPILOT https://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266The teams that made Copilot stick didn’t win with strategy decks, they won with visible, local wins that made people ask, “Why don’t we have this?” Instead of a big‑bang rollout to everyone, they ran tight pilots: small groups in finance, sales, or operations where real work—report prep, status summaries, email drafts—was measured before and after Copilot. When analysts suddenly saved hours on monthly reporting or backlogs shrank because updates wrote themselves, the story spread through Teams chats and hallway conversations, not just corporate comms. That “taco bar effect”—seeing another team get something clearly better—turned Copilot from a tolerated tool into something people queued up for, flipping the usual pattern where IT pushes adoption into one where demand comes from the business. FRAMEWORKS THAT DON’T FEEL LIKE SALES PITCHES https://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266Classic change‑management frameworks can feel like MBA theater, but stripped down, something like ADKAR actually works for Copilot when you translate it into user language. Awareness becomes short, role‑specific demos; Desire is powered by one or two concrete tasks where Copilot clearly saves time or improves quality; Knowledge comes from micro‑learning and checklists, not 40‑slide decks. Ability shows up as safe sandboxes and non‑critical use cases where people can practice without fear, and Reinforcement means managers recognizing real wins and embedding Copilot into templates and daily routines. When you design rollout this way—small wins, real stories, and simple guardrails—you stop “selling AI” and start making it the obvious choice for the kind of work people already hate doing. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Copilot doesn’t invent knowledge or fix chaos— it amplifies whatever you give it. If your tenant is full of shadow content and bad metadata, Copilot turns that into confident, wrong answers that kill trust on day one; if you first tame a focused slice of content, prove real time savings, and use simple frameworks to support users, Copilot turns into the assistant people actually ask for instead of another icon they ignore. https://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67860348/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and AI governance consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, Copilot, and their content estate as one integrated operating system instead of a pile of shadow files and forgotten pilots. He works with teams running on Microsoft 365 and Azure to design data readiness, rollout, and enablement strategies so Copilot delivers accurate, grounded answers users trust—instead of becoming yet another tool they abandon after the first bad result. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| GitHub, Azure DevOps, or Fabric – Who’s Actually In Charge? Medallion Architecture, CI/CD & GitOps for Fabric Warehouse | 22 Sep 2025 | 00:18:04 | |
Here’s the uncomfortable truth: without CI/CD, your beautiful Medallion Architecture is just a very expensive CSV swamp wearing a Gold badge. In this episode, we start right where most Fabric teams are stuck—Bronze ingestion scripts living in notebooks, Silver transformations hacked in prod, and Gold dashboards patched at 3 a.m.—and show how GitHub or Azure DevOps becomes the actual control plane. You’ll see how treating notebooks, SQL scripts, and pipeline configs as code (versioned, reviewed, and promoted) turns Fabric Warehouse from “please don’t break” into something you can roll back, test, and move between dev, test, and prod without midnight firefights. BRONZE WITHOUT ROLLBACK – YOUR CSV GRAVEYARD https://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266Bronze is where the first goblins spawn: corrupted feeds, schema drift, duplicate loads—quietly poisoning everything upstream while pipelines still show a comforting green checkmark. We walk through how bad timestamps, header changes, and extra columns in “raw” zones become permanent damage when ingestion logic isn’t in Git and deployments go straight to production. You’ll learn three non‑negotiables for Bronze: keep every ingestion notebook/script in source control, parameterize connections and schemas instead of hard‑coding prod, and run pre‑deploy schema/dry‑run checks in CI so bad changes never hit your landing zone. With those guardrails, an ingestion failure becomes a quick rollback and redeploy—not a weeks‑long data‑rebuild panic. SILVER: WHERE GOVERNANCE DIES QUIETLY https://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266Silver looks clean on the surface—standardized types, deduped rows, pretty column names—but this is where governance often dies in silence. When fixes live in ad‑hoc notebooks and “just this once” patches against production, dev, test, and prod stop matching, and you only notice when numbers don’t reconcile in front of leadership. We show how to force discipline into Silver: every transformation change goes through a pull request, automated data‑quality checks (nulls, uniqueness, schema compatibility) run in CI, and promotions happen only via pipelines—not manual edits. That way, Silver becomes the first layer where “what happens in dev is exactly what happens in prod,” instead of three different realities with the same table names. GOLD AT 3 A.M. – ANALYTICS UNDER PRESSURE https://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266Gold is the only layer executives actually see—dashboards, KPIs, quarter‑end numbers—and it’s where shortcuts cost the most. One untested schema tweak in Silver or a hotfix in Gold can break trust instantly when financials or key metrics suddenly don’t match past reports. We talk about building mirrored environments (dev/test/prod) for Gold models and reports, wiring deployment pipelines from Git so only tested changes ship, and banning “panic SQL” edits in production warehouses. When GitHub or Azure DevOps becomes the single source of truth for Gold, 3 a.m. calls turn from “what changed?” into “which commit broke this?”—and that’s a problem you can actually solve. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that GitHub or Azure DevOps—not Fabric itself—decides whether your warehouse is safe. When every ingestion script, transformation, and Gold model lives in source control, moves through CI/CD checks, and promotes via pipelines, you stop betting your Medallion Architecture on luck and start treating it like real product code—with versions, tests, and rollbacks you can trust. https://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67853161/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and data platform consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, Fabric, and their warehouses as one integrated operating system instead of a pile of one‑off scripts and dashboards. He works with teams running on Microsoft 365, Azure, and Fabric to design Medallion Architectures, GitOps workflows, and CI/CD guardrails so that Bronze, Silver, and Gold layers stay versioned, testable, and recoverable—even when things go wrong at 3 a.m. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Your Power Automate Approval Flow Isn’t Audit‑Proof: Run History Limits, Logging, Dynamic Approvers & Restartable Workflows | 22 Sep 2025 | 00:19:31 | |
Here’s the catch Microsoft doesn’t highlight: Power Automate’s run history is time‑limited by default, tied to your plan and license—and once that retention window passes, your approval trail is gone as if it never existed. That’s fine for Microsoft’s storage bill, but terrible for audits, investigations, or basic accountability; designing without permanent logging is like deleting your CCTV before anyone checks the footage. In this episode, we break down why run history is only a temporary debugging aid, how to build durable approval logs outside that buffer, and how to redesign flows so you can restart from a specific stage, use dynamic approvers, and keep escalations and reminders under control instead of flooding inboxes.https://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266 WHY YOUR FLOW HISTORY VANISHES (AND WHY IT MATTERS) https://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266Power Automate’s run history looks comforting—until you realise it’s a rolling window, not a permanent archive. Retention is defined by your tenant configuration and licensing, so older approvals simply age out: great for cloud housekeeping, disastrous when HR, Legal, or auditors ask for proof from last year and your logs are empty. In the episode, we walk through how to check your real retention window, why screenshots don’t count as evidence, and how to move from trusting ephemeral run logs to writing structured approval records (dates, decisions, actors) into durable stores like Dataverse, SharePoint, or SQL that you actually control. DESIGNING APPROVAL FLOWS THAT DON’T COLLAPSE https://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266Most approval flows implode because they’re built as thin demos: single‑stage, hard‑coded emails, no state tracking, no restart concept. That works until org structure changes, people leave, or departments demand different rules—then your flow becomes a brittle monster of nested conditions nobody wants to touch. We show how to design for reality instead: store roles instead of individual addresses, look up approvers dynamically from AD, SharePoint, or Dataverse, and keep a persistent “stage” field so you can restart at the correct step without resending the whole process. The result is a modular, restartable approval engine that survives staff changes, rule updates, and errors without forcing you to rebuild from scratch. ESCALATIONS AND REMINDERS WITHOUT THE SPAM STORM https://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266Bad flows solve stuck approvals with brute force: wave after wave of reminder emails until people start ignoring everything from “Flow Notifications.” We unpack how to replace spam cannons with sane escalation logic—time‑based reminders with clear limits, reassignment rules when someone is away, and escalation paths that go to the right roles instead of everyone in CC. You’ll learn how to use persistent state and logging so you always know where a request is, who’s blocking it, and how to nudge or re‑route it without drowning inboxes. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that if you rely on default run history, you don’t have an approval record at all—just a temporary trace that disappears on Microsoft’s schedule, not yours. Once you treat logging, state, and role management as first‑class design elements, your Power Automate approvals become restartable, auditable workflows instead of fragile black boxes that crumble the moment someone asks, “Can you prove this was actually approved?” https://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67846983/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and Power Platform consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, Power Automate, and Dataverse as one integrated operating system instead of a patchwork of fragile, unlogged flows. He works with teams running on Microsoft 365 and Azure to design approval architectures, logging strategies, and governance so that workflows are restartable, auditable, and resilient instead of disappearing the moment run history rolls off. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Why Leadership Thinks Copilot Is Useless (And Where The Numbers Back Them Up): Entra vs Insights, Real Telemetry & How To Prove Adoption | 21 Sep 2025 | 00:18:00 | |
Most organizations quietly assume Copilot is under‑used—not because people hate it, but because the dashboards leadership is staring at are counting the wrong thing. In this episode, we walk through the “gym card swipe” problem: Entra and app sign‑in charts look impressive in a slide deck, yet they only prove that people opened Word or Teams, not that anyone actually used prompts to get work done. You’ll see how that mismatch between identity telemetry and real Copilot behavior fuels the narrative that “nobody uses it,” and how to flip the script by pulling the right usage signals, telling the story in CFO‑ready language, and targeting adoption where the data proves Copilot already helps.https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266 THE CFO’S REPORT DOESN’T LIE – BUT IT’S NOT THE FULL TRUTH https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266We start with the classic scene: a CFO storms in waving an admin report that says “low Copilot adoption” and demands to know why the spend was approved. The chart isn’t fake, it’s just incomplete—showing app sign‑ins, not Copilot actions. You’ll learn how to explain, in one leadership‑friendly sentence, why a graph of Word sign‑ins is like counting gym check‑ins instead of workouts, and how to defend your rollout without hand‑waving: “sign‑ins show who opened the app; Copilot adoption means prompts and actions, which live in different telemetry.” From there, we outline a concrete plan: verify which Copilot usage reports your tenant actually exposes, enable or request the right Insights where needed, and prep a simple side‑by‑side view—door counts vs real Copilot actions—that resets the conversation from “no one uses this” to “here’s where it actually helps today.” ENTRA VS INSIGHTS: TWO DASHBOARDS, TWO STORIES https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266Next, we dissect the “two dashboards” problem that quietly wrecks most adoption slides. Entra (and similar identity views) is brilliant at what it does: tracking who signed in, from where, and on which app—but it is not designed to tell a Copilot ROI story. Insights, by contrast, is where you start seeing behavior: prompt counts, app‑level Copilot activity, and sometimes department‑level patterns depending on your tenant configuration. We walk you through a practical three‑step workflow: confirm which Copilot/Insights telemetry you can see with your admin role, identify at least three dimensions (app, usage volume, department), and build anonymized, aggregated views that leadership can trust without turning adoption reporting into a privacy nightmare. The goal: stop treating door‑logs as productivity metrics and start using behavior data to decide where to invest training and enablement.https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266 WHERE COPILOT CLICKS ACTUALLY HAPPEN https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266Marketing demos love to show Copilot rewriting entire strategies in PowerPoint, but real usage patterns are much more grounded. In many tenants, Copilot activity clusters in Outlook, Teams, and Word—places where people already spend their day cleaning up emails, writing updates, and fixing phrasing under time pressure. We explain why these “small win” scenarios drive sticky adoption: low risk, high repetition, and immediate payoff. Your job is to validate that pattern against your own tenant—look at which apps show actual Copilot actions, then start enablement there instead of pushing generic, all‑apps training. That shift lets you tailor stories and examples to where people already click, turning Copilot from a theoretical platform feature into something that quietly saves time in the tools they live in.https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266 WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Copilot isn’t “useless”—your telemetry storytelling might be. As long as leadership only sees identity‑level charts, they’ll assume Copilot is an expensive treadmill nobody runs on; once you surface real prompt and action data, app‑by‑app, you can show where Copilot already changes workflows, where it stalls, and what to fix next. That’s how you move the conversation from defending a license line item to co‑designing a roadmap based on evidence. https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67842319/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and AI governance consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, Copilot, and their telemetry as one integrated operating system instead of a mess of dashboards nobody trusts. He works with teams running on Microsoft 365 and Azure to design data‑driven Copilot rollouts—tying licensing, usage, and business outcomes together so conversations with leadership are grounded in real signals, not wishful graphs. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| The Power BI Gateway Horror Story No One Warned You About: Firewall Rules, Outbound Traffic & How To Bulletproof Your Setup | 21 Sep 2025 | 00:18:39 | |
You know what’s truly horrifying? A Power BI gateway that works flawlessly in your test tenant—green checks everywhere, dashboards refreshing like a dream—then completely collapses in production because the one outbound firewall rule that actually matters was never opened. In this episode, I break down the real communication architecture of the gateway, how test tenants lull you into a false sense of security, and why passing a single portal connectivity test means almost nothing once packets start hitting your corporate firewall. You’ll learn the exact diagnostics path that cost me a full weekend and two gallons of coffee—from vague “connection failure” logs and misleading green checks to the moment we finally realized outbound filtering and missing FQDN whitelisting were quietly choking Service Bus traffic in production.https://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266 THE SETUP THAT LOOKED SIMPLE… UNTIL IT WASN’T https://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266On paper, our plan was textbook: one dedicated gateway server, supported OS, patched, standard firewall ports opened, validate against a test tenant, then flip to production. The wizard made it look like a “next, next, finish” job, and for a few dangerous hours that illusion held—connection tests passed, reports refreshed, and we muttered, “Why does everyone complain about gateways?” The moment we switched to the real tenant, everything cracked: executive dashboards failed in the middle of morning meetings, red error banners replaced numbers, and an avalanche of tickets, calls, and emails followed. The logs were the worst part—vague, fortune‑cookie‑style messages about “connection failures” that pointed us everywhere and nowhere at once, while documentation insisted we had done everything right. That’s when the painful truth hit: passing a single connectivity test only proves one handshake worked once; it doesn’t mean your network design can sustain real‑world gateway traffic.https://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266 THE FIREWALL RULE NOBODY TALKS ABOUT https://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266The real culprit turned out not to be server config, patches, or even inbound rules—it was outbound filtering. Our test environment had relaxed outbound controls, so the gateway happily reached Azure Service Bus and other dependencies; production, locked down with strict outbound rules, simply dropped those calls. The evidence only surfaced after we dug through firewall logs, temporarily opened outbound traffic in a maintenance window, and watched everything spring back to life—proving the app wasn’t broken, the network was. From there, packet captures and DNS traces revealed what should have been obvious all along: we needed controlled outbound access based on FQDN whitelisting instead of fragile, ever‑changing IP ranges. Once we added the right FQDNs for gateway services and adjusted the outbound rules, the constant Service Bus errors vanished, refreshes stabilized, and the “random” failures stopped cold. That’s the part most guides skip: if you treat gateway networking like a one‑time port‑opening exercise instead of an ongoing design problem, test will lie to you and production will punch you in the face. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Power BI gateway outages in production rarely come from a single missed checkbox—they come from misunderstanding how the gateway talks across your network. Until you design outbound access and FQDN whitelisting as deliberately as you choose the server and install the software, every green check in test is just a mirage—and the real horror story is waiting for you in production. https://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67835305/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and data platform consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, Power BI, and their hybrid connectivity as one integrated operating system instead of a pile of fragile, undocumented links. He works with teams running on Microsoft 365, Azure, and on‑prem data sources to design gateway architectures, firewall configurations, and troubleshooting playbooks that keep reports online—even when the network fights back. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| You’re Probably Using Teams Channels Wrong: Standard vs Private vs Shared, Oversharing Risk & How To Pick The Right One | 20 Sep 2025 | 00:17:26 | |
Let’s be real—Teams channels are just three kinds of roommates. Standard channels are the open‑door living room, Private channels are the locked bedroom, and Shared channels are when your roommate’s cousin “stays for a few weeks” and suddenly your fridge looks like a crime scene. The problem isn’t the labels, it’s treating all three like the same thing: by the end of this episode, you’ll know exactly which channel type to use for marketing, dev, and external vendors—without accidentally leaking sensitive files or building silos nobody can see into. We unpack what really happens under the hood in Microsoft 365 when you pick Standard, Private, or Shared, why that choice sets your security perimeter and file visibility for the entire project, and how a simple channel playbook at kickoff can save you from governance drama and “please delete that file” emails later. WHY PICKING THE WRONG CHANNEL WRECKS YOUR PROJECT https://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266Channel choice isn’t cosmetic—it’s who can see what, by design. Use a Standard channel when only a subset should see the content and you’ve just handed interns, externals, or the wrong department a front‑row seat to things they shouldn’t touch, from financial forecasts to raw builds. In this episode, we walk through real‑world failures: product launches where marketing and dev shared a Standard channel and accidentally exposed embargoed press kits to people who only needed bug lists, or leadership chats that landed in the same space as junior staff updates. You’ll learn a simple rule set: Standard when every Team member truly needs visibility, Private when only an inner circle should see the conversation and files, and Shared when you bring in external partners who must collaborate without getting the full house key. STANDARD, PRIVATE, SHARED – CUTTING THE MARKETING FLUFF https://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266Microsoft loves calling every channel a “collaboration space,” but under the hood they’re three different security and storage models wearing the same UI. Standard channels use the parent Team’s SharePoint site and are visible to every member of the Team—perfect for broad project chatter and shared artefacts, dangerous for anything confidential. Private channels restrict membership to a subset of the Team and back their files with a separate SharePoint site, so only invited members even see that channel exists—ideal for finance, HR, or leadership work inside a bigger Team. Shared channels are designed for cross‑Team and external collaboration: they give partners or other internal Teams access to a single channel (often with its own backing site) without adding them to the entire Team, so vendors and clients can join the conversation without roaming through the rest of your workspace. Once you map “what it is, where files live, who sees it, when to use it” for each type, channel choice stops being guesswork and starts being a deliberate part of your security model. PICKING THE RIGHT CHANNEL WITHOUT GETTING BURNED https://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266The real fix is to stop letting anyone spawn channels on instinct and start treating channel creation as a governance decision. We give you a practical playbook: during project kickoff, decide the audience first, then match it to Standard/Private/Shared using a simple grid, and restrict who is allowed to create new channels so you don’t end up with a sprawl of random Standards leaking files and ghost Private channels no one remembers owning. You’ll hear concrete patterns for typical scenarios—cross‑department projects, vendor workspaces, leadership areas—and a three‑step test (who should see it, what files land there, what happens if someone leaves) you can run before clicking “Create.” Done right, your channels turn from accidental leak vectors into clear containers that match how your organization actually works. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that a Teams channel is not “just a conversation,” it’s a security and storage boundary that decides who sees your files for the entire life of a project. Once you stop clicking “new channel” like a vending machine button and start applying a simple decision framework—Standard for full‑Team transparency, Private for inner circles, Shared for external and cross‑Team work—you dramatically cut oversharing risk, cleanup drama, and late‑stage governance firefighting. https://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67832118/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 consultant and host of the M365.FM podcast, helping organizations treat Teams, SharePoint, and Entra ID as one integrated operating system instead of a patchwork of random channels and sites. He works with teams running on Microsoft 365 and Azure to design channel strategies, permission models, and governance playbooks so collaboration stays fast and flexible without leaking sensitive content to the wrong audience. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Live Data In SPFx: How To Fix Static Web Parts With Microsoft Graph, Permissions, Caching & Real‑Time Updates | 20 Sep 2025 | 00:19:42 | |
Your SPFx web part looks great—but if it’s not pulling live data, users will treat it like a lobby poster: nice to look at, useless to trust. In this episode, we walk through three concrete wins you can actually ship this month:
WHEN PRETTY ISN’T ENOUGH https://www.spreaker.com/cms/episodes/67830874/edit/info?filter=NETWORK&network=18613266We start with the core problem: a polished but static SPFx dashboard dies the moment users realize it isn’t current. You’ll hear why stale “team contacts” and status boards actively damage trust, how Microsoft’s own SPFx case studies show people data goes stale unless it’s pulled live, and why your first priority is wiring into live sources—not tweaking padding. We show how to use the plumbing SPFx already gives you—SharePoint REST, Microsoft Graph, and PnP—to turn your web part from a frozen brochure into a surface users rely on because it always reflects reality.https://www.spreaker.com/cms/episodes/67830874/edit/info?filter=NETWORK&network=18613266 BEATING AUTHENTICATION HEADACHES https://www.spreaker.com/cms/episodes/67830874/edit/info?filter=NETWORK&network=18613266Next, we tackle the part that kills most projects: authentication. Instead of drowning in OAuth diagrams, you’ll learn how SPFx’s MSGraphClient and REST helpers handle tokens behind the scenes if you request the right scopes and get an admin to approve them. We walk through the three‑step roadmap—declare scopes in webApiPermissionRequests, deploy and approve in the App Catalog, then test with a normal user—and show why “works for admin” is the biggest trap in Graph integrations. Done right, Graph calls start to feel like a cheat code: live user profiles, Teams membership, calendars, and more, all without hand‑crafting token flows.https://www.spreaker.com/cms/episodes/67830874/edit/info?filter=NETWORK&network=18613266 MAKING GRAPH CALLS SNAPPY https://www.spreaker.com/cms/episodes/67830874/edit/info?filter=NETWORK&network=18613266Finally, we focus on performance so your live data doesn’t feel slower than a CSV export. You’ll see how to use $select to request only the fields you need, how to avoid bloated payloads that trigger throttling, and how to layer caching so repeat calls don’t hammer Graph. We also cover when to move from simple REST/Graph calls to webhooks and signal‑based updates, so your SPFx web part stays responsive even as usage scales. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67830874/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67830874/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that SPFx wasn’t built for static content—it’s a front door to live Microsoft 365 data. Once you stop obsessing over CSS polish and focus on wiring secure, fast, real‑time connections to Graph and SharePoint, your web part stops being decoration and becomes a living dashboard users return to because they know it’s telling the truth right now. https://www.spreaker.com/cms/episodes/67830874/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67830874/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67830874/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and SPFx consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, SharePoint, and Graph as one integrated operating system instead of a set of disconnected APIs and pretty but static web parts. He works with teams running on Microsoft 365 and Azure to design SPFx, Graph, and performance patterns so their web parts feel alive, stay secure, and scale without turning into another abandoned dashboard. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Surviving Purview: Retention Policy Traps, Storage Bloat & How IA, Governance & Copilot Really Fit Together | 20 Sep 2025 | 00:20:25 | |
One wrong Purview retention rule can chew through your storage like Pac‑Man on Red Bull—locking files, bloating preservation copies, and turning your intranet into a haunted house of “can’t delete” errors. In this episode, I break down what Purview really is (your tenant’s compliance inspector), why it’s not “just IT’s problem,” and how bad information architecture turns it from a precision tool into a blunt‑force hammer. We use real‑world patterns to show how IA, retention, labels, and Copilot all intersect—so you stop treating Purview as a scary checkbox and start using it as an ally that enforces the structure you actually want. WHAT EVEN IS PURVIEW (FOR REAL)? https://www.spreaker.com/cms/episodes/67828404/edit/info?filter=NETWORK&network=18613266Purview is Microsoft’s compliance and governance layer for your tenant: the engine behind retention, classification, sensitivity labels, eDiscovery, and lifecycle across SharePoint, OneDrive, Exchange, Teams, and more. Think of it as the building inspector: it doesn’t care how pretty your intranet looks, it cares whether the fire exits (retention, access, lifecycle) exist and work. If your information architecture is sloppy—no metadata, weak content types, random libraries—Purview will still enforce rules, but in the worst possible way: contracts and lunch flyers get treated the same, “paranoid” filters hoard junk, and compliance reports become unreadable noise. When your IA is strong, Purview finally has a map: it can retain only regulated content, sweep out trash, and support Copilot by ensuring that the content search relies on is structured, labeled, and governed instead of chaotic. THE RETENTION POLICY TRAP https://www.spreaker.com/cms/episodes/67828404/edit/info?filter=NETWORK&network=18613266Retention is where most admins fall into the pit. Broad policies sound harmless—“keep everything for X years”—until you realize you’ve effectively frozen entire workloads: meeting notes, project files, Teams chats, even throwaway content, all locked under the same rule. Users experience this as “the system is broken” when they can’t delete or clean up, while in reality Purview is just doing exactly what you told it to. We walk through why you should never start with tenant‑wide retention, how to pilot policies in controlled scopes, and why some “immutable” label settings are effectively permanent tattoos that must be tested in isolation before rollout. We also call out the hidden storage bill: retention keeps preserved copies even after users delete, which means poorly scoped policies quietly inflate your capacity until finance starts asking hard questions. WHY IA + PURVIEW + COPILOT ARE ONE SYSTEM https://www.spreaker.com/cms/episodes/67828404/edit/info?filter=NETWORK&network=18613266Copilot feeds from Microsoft Search; Search quality depends on your information architecture; Purview governs what stays, how long, and under which label. If IA is weak and retention is blunt, Copilot becomes a chaos engine—surfacing wrong versions, outdated drafts, or sensitive content that should have been locked or removed. In the episode, we tie this together into a practical sequence: first fix structure (sites, libraries, content types, metadata), then design targeted retention and labels that align with that structure, and only then roll out Copilot so it has clean, governed content to work with. Done right, Purview stops feeling like an enemy and becomes the enforcement layer that keeps your IA and Copilot from drifting into chaos over time. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67828404/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67828404/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Purview doesn’t “understand” your content, it only enforces whatever structure you’ve already built. If your information architecture is strong, Purview becomes your automated safety inspector; if it’s weak, Purview amplifies chaos—locking junk, hoarding copies, and breaking user trust just when you need Copilot and compliance to work together. https://www.spreaker.com/cms/episodes/67828404/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67828404/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67828404/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and information architecture consultant and host of the M365.FM podcast, helping organizations treat Purview, Copilot, and their content estate as one integrated operating system instead of scattered sites and random policies. He works with teams running on Microsoft 365 and Azure to design IA, retention, and labeling strategies that keep storage under control, support compliance, and give Copilot high‑quality content to work with instead of digital junk. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Your Teams Notifications Are Dumb: How To Fix Them With Microsoft Lists, Adaptive Cards & Power Automate | 19 Sep 2025 | 00:19:06 | |
Your Teams notifications are dumb. They spam reminders nobody reads and look like they were designed in 2003. In this episode, we fix that by walking through three pieces: structuring your data in Microsoft Lists, designing an Adaptive Card that’s actually clickable, and wiring it together with Power Automate so users can act directly in chat. Once those pieces connect, boring alerts turn into mini‑apps inside Teams—approve, snooze, update—without anyone leaving the conversation. WHY TEAMS NOTIFICATIONS FAIL https://www.spreaker.com/cms/episodes/67823814/edit/info?filter=NETWORK&network=18613266Most Teams alerts are static “FYI” messages with no real action, so users swipe them away on autopilot. We break down why generic bot posts and empty reminders destroy response rates, how they push real work back into email, chats, and spreadsheets, and why requesters end up chasing people manually for approvals that should have been one click. Using real examples (like a purchase approval that stalled for weeks because the notification was useless), we show the pattern: no context, no buttons, no clear choice equals no action. Adaptive Cards flip that script by embedding the decision—approve, reject, snooze, update—directly in the message so the notification itself becomes the workflow.https://www.spreaker.com/cms/episodes/67823814/edit/info?filter=NETWORK&network=18613266 THE SECRET WEAPON: MICROSOFT LISTS https://www.spreaker.com/cms/episodes/67823814/edit/info?filter=NETWORK&network=18613266Adaptive Cards are only as good as the data behind them, and that’s where Microsoft Lists quietly becomes the engine of the whole setup. We show how to move from messy, free‑text “Notes” fields to clean columns for TaskName, DueDate, Owner, and Status so your cards can display clear labels, due dates, and people instead of vague blobs of text. You’ll learn how to pick the right column types (choice, date, person) so reminders and buttons make sense, and how to think of Lists as your schema: the structured pantry that feeds every Adaptive Card recipe. With a clean List, your cards stop being random text blocks and start behaving like simple apps that users can trust. DESIGNING YOUR FIRST ADAPTIVE CARD (WITHOUT GOING MAD) https://www.spreaker.com/cms/episodes/67823814/edit/info?filter=NETWORK&network=18613266Designing Adaptive Cards doesn’t have to mean fighting raw JSON. We walk through using the Adaptive Card Designer as a no‑risk sandbox: add text blocks, fields, and buttons visually, test how the card looks in Teams, and only then copy the JSON into Power Automate. You’ll see a concrete pattern for a task card—title, due date, owner, and two buttons (Done / Snooze)—and how each element maps back to your List columns. The result is a card that reads like a clear question with obvious actions instead of a wall of text that people ignore.https://www.spreaker.com/cms/episodes/67823814/edit/info?filter=NETWORK&network=18613266 WIRING IT TOGETHER WITH POWER AUTOMATE https://www.spreaker.com/cms/episodes/67823814/edit/info?filter=NETWORK&network=18613266Finally, we connect everything with Power Automate so the card isn’t just pretty, it actually updates your data. We show how to trigger on List changes or schedules, send the Adaptive Card into Teams, capture the button response, and write the result back into Microsoft Lists—changing status, updating dates, or logging who clicked what. You’ll learn how to avoid noisy flows that spam channels, how to target the right user or channel for each card, and how to keep the loop tight so one click in Teams really means “task done” in your system of record. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67823814/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67823814/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Teams notifications fail because they’re static and context‑free, not because people “don’t like change.” Once you pair structured data in Microsoft Lists with Adaptive Cards and Power Automate, every alert becomes a one‑click decision surface—turning noisy pings into workflows that users actually finish inside Teams instead of quietly ignoring. https://www.spreaker.com/cms/episodes/67823814/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67823814/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67823814/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and Power Platform consultant and host of the M365.FM podcast, helping organizations treat Teams, Microsoft Lists, Power Automate, and Adaptive Cards as one integrated operating system instead of a pile of disconnected bots and email reminders. He works with teams running on Microsoft 365 and Azure to design structured data, notifications, and automation patterns so that every ping in Teams becomes a chance to finish work—not another message people swipe away. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Power Apps manual UI vs Generative Pages: is vibe coding the better way to build apps? | 28 Oct 2025 | 00:23:39 | |
Power Apps manual UI vs AI Pages: in this episode of M365.fm, Mirko Peters dissects the UI paradox in Power Apps—why teams still drag rectangles around like it’s 2019 while Generative Pages and “vibe coding” let you describe layouts in natural language and let AI build them. He contrasts the handcrafted Canvas era, where every pixel is manually aligned and every app becomes a fragile one‑off, with the emerging model where you supervise intelligence instead of babysitting controls. Mirko breaks down the “manual UI” era as digital pottery: noble, slow, and completely impractical at scale. He shows how canvas apps turn makers into pixel mechanics who spend more time fixing margins, containers, and responsive layouts than modeling data, performance, and security. Every extra screen multiplies technical debt—slightly different headers, inconsistent filters, and layout quirks that make maintenance feel like archaeology instead of engineering. He then introduces Generative Pages as the vibe‑coding alternative. Instead of dragging controls, you start from Dataverse or existing data and tell Copilot what you want: “show order records as cards with customer name, payment type, and paid date,” “make it responsive,” “apply our corporate colors.” The App Agent interprets intent, scaffolds React‑based pages tied to your schema, and lets you iterate conversationally—“add a date filter,” “make cards clickable,” “switch to dark mode”—regenerating safe, consistent layouts without rummaging through nested formulas.https://www.spreaker.com/cms/episodes/68316030/edit/info?filter=NETWORK&network=18613266 The episode also explores where AI layout generation truly shines and where manual design still has a place. Mirko explains how Generative Pages bring built‑in responsiveness, Fluent‑based components, and consistent UX that scale across apps, while Canvas still matters for edge‑case experiences and heavy customization—provided you accept the maintenance cost. He walks through governance and team workflows: how vibe coding fits into environments, versioning, and design standards, and how to stop treating every UI change as a bespoke craft project. Throughout the conversation, you get a ruthless cost‑benefit view of vibe coding: hours saved per screen, reduced layout variance across environments, and lower UI‑related technical debt over the lifecycle of an app. Mirko gives you language to challenge “I like to hand‑craft my screens” and replace it with a healthier model: use AI to generate the 80% baseline, then apply human judgement only where it materially improves user outcomes instead of feeding perfectionism.https://www.spreaker.com/cms/episodes/68316030/edit/info?filter=NETWORK&network=18613266 WHAT YOU WILL LEARN
Manual UI in Power Apps made sense when AI couldn’t design—but that era is over. Generative Pages and vibe coding turn layout into a conversation with an agent, so the real question is not “can I still hand‑build this screen?” but “why would I choose pixel pain over AI‑driven structure unless there’s a very good reason?”. https://www.spreaker.com/cms/episodes/68316030/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FOR This episode is ideal for Power Apps makers, UX‑minded developers, COE teams, and platform owners who are deciding whether to double down on classic Canvas Apps or shift new projects to AI‑generated Generative Pages. It is especially valuable if your backlog is full of UI tweaks, responsive fixes, and design refactors and you want a credible path to spend that time on data, logic, and governance instead. https://www.spreaker.com/cms/episodes/68316030/edit/info?filter=NETWORK&network=18613266ABOUT THE HOST Mirko Peters is a Microsoft 365 and Power Platform consultant focused on building governed, scalable applications with Power Apps, Dataverse, Microsoft Copilot, and modern low‑code architecture patterns. Through M365.fm, he shares practical app‑modernization stories, AI‑assisted build techniques, and governance models that help organizations move from handcrafted UIs to durable, AI‑generated experiences.https://www.spreaker.com/cms/episodes/68316030/edit/info?filter=NETWORK&network=18613266 Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Fabric Domains, Workspaces & Capacities Explained: How To Avoid Sprawl, Broken Governance & Surprise Premium Bills | 18 Sep 2025 | 00:18:40 | |
Admins, remember when Power BI Premium felt like your biggest headache? Overnight you became Fabric admins, staring at domains, workspaces, and capacities like an IKEA manual written in Klingon. In this episode, we unpack why Microsoft’s promise of “simpler organization” actually means more moving parts, and how you can still build something stable: clear domain taxonomy, purpose‑driven workspaces, and capacity rules that won’t blow your budget at quarter‑end. By the end, you’ll know what to lock down in the first 30, 60, and 90 days so Fabric doesn’t turn into a very expensive CSV swamp with Gold badges on top. FABRIC DOMAINS: ORDER OR JUST FANCY NAME TAGS? https://www.spreaker.com/cms/episodes/67811267/edit/info?filter=NETWORK&network=18613266Domains look harmless—HR here, Finance there, Marketing somewhere else—but they change how data, people, and governance collide across your tenant. We break down why treating domains like renamed workspaces is a trap: each brings its own owners, policies, and permission logic that can quietly override workspace rules. You’ll hear how “Sales,” “Sales Reporting,” and “Sales 2025” domains show up when nobody defines a taxonomy, how domain sprawl accelerates faster than workspace sprawl, and how to stop it with three boring but essential moves: agree domain purpose (department vs function vs project), assign a single owner with escalation, and pilot policies in one domain before going tenant‑wide. WORKSPACES: FROM LEGO BOX TO JENGA TOWER https://www.spreaker.com/cms/episodes/67811267/edit/info?filter=NETWORK&network=18613266Old Power BI workspaces were simple—few reports, one dataset. Fabric workspaces are everything: lakehouses, warehouses, notebooks, pipelines, and dashboards all crammed into the same container. We show how this overload turns simple “report spaces” into Jenga towers where raw ingests, staging, experiments, and production reporting all sit side‑by‑side, and why applying old Viewer/Member/Admin habits isn’t enough anymore. You’ll learn a practical pattern: separate staging, production, and experimentation into different workspaces; enforce naming and lifecycle rules so abandoned workspaces don’t eat capacity; and use templates so every new workspace starts with the right owners, tags, and purpose instead of becoming the next junk drawer. CAPACITIES: WHEN PREMIUM STOPPED BEING JUST “MORE HORSEPOWER ”https://www.spreaker.com/cms/episodes/67811267/edit/info?filter=NETWORK&network=18613266Fabric capacities aren’t just Power BI Premium with a new coat of paint—they’re shared fuel tanks for everything: reports, warehouse queries, pipelines, notebooks, and more. We explain why old “Premium per workspace” mental models break down when multiple domains and workspaces hammer the same capacity, and how that shows up as throttling, random slowdowns, or surprise cost spikes. You’ll get a simple capacity playbook: map which workloads are allowed on which capacities, set guardrails for noisy engineering workloads vs business reporting, and monitor utilization so you can adjust assignments before the CFO’s bill shock email lands in your inbox. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67811267/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67811267/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Fabric didn’t actually simplify your life—it just exposed the architecture you already needed but never had to design. Domains, workspaces, and capacities can give you real control, but only if you decide early what they mean, who owns them, and which workloads go where; otherwise, you get a neat‑looking UI wrapped around the same old chaos, now with a bigger compute bill. https://www.spreaker.com/cms/episodes/67811267/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67811267/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67811267/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and data platform consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, Power BI, and Fabric as one integrated operating system instead of a pile of isolated tools and capacities. He works with teams running on Microsoft 365, Azure, and Fabric to design domain taxonomies, workspace architectures, and capacity strategies so analytics stays fast, governed, and affordable—even when usage takes off. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| LINQ to SQL With EF Core Explained: Expression Trees, Query Provider, Caching & Why Your LINQ Becomes Weird SQL | 18 Sep 2025 | 00:19:58 | |
Have you ever written a LINQ query that worked perfectly in C#, but when you checked the SQL it generated you wondered how it turned into that monster? In this episode, you’ll learn how expression trees control translation, how EF Core’s query provider decides what becomes SQL and what falls back to client‑side evaluation, and how caching quietly shapes performance and memory use. We also dig into null semantics and why queries that behave in LINQ to Objects can suddenly blow up—or slow down—once EF Core gets involved.https://www.spreaker.com/cms/episodes/67810642/edit/info?filter=NETWORK&network=18613266 WHAT REALLY HAPPENS WHEN YOU RUN A LINQ QUERY https://www.spreaker.com/cms/episodes/67810642/edit/info?filter=NETWORK&network=18613266LINQ itself doesn’t know anything about SQL; it’s just C# calling methods. EF Core captures those calls as expression trees—object graphs that describe your query before anything is sent to the database—so nothing executes at the moment you type \Where\\ or \Select\\. We walk through how EF turns each clause into nodes (method calls, properties, constants), why that structure matters for translation, and how helper methods and complex expressions can make parts of your query “not SQL‑legal.” That’s the first place where behavior diverges from LINQ to Objects: in memory everything runs, but in EF Core unsupported patterns trigger errors or expensive client‑side evaluation. THE QUERY PROVIDER: GATEKEEPER BETWEEN LINQ AND SQL https://www.spreaker.com/cms/episodes/67810642/edit/info?filter=NETWORK&network=18613266EF Core’s query provider acts like a gatekeeper, walking the expression tree and pattern‑matching which nodes it can translate into SQL and which it can’t. We explain why common patterns (Where, Select, OrderBy) map cleanly, while others (certain GroupBy scenarios, custom methods) either fail or fall back to in‑memory processing that silently pulls far too many rows. You’ll learn how to recognize when a query is being evaluated client‑side, why that often only shows up as performance pain in production, and why it’s better to get a hard error than a “working” query that drags your app under load. CACHING: EF CORE’S HIDDEN PERFORMANCE LEVER https://www.spreaker.com/cms/episodes/67810642/edit/info?filter=NETWORK&network=18613266Every time EF Core translates a query shape from an expression tree into an executable plan, it does real work—parsing, validating, and preparing SQL and materialization logic. We look at how EF Core caches these decisions so repeated queries don’t rebuild the pipeline every time, why parameterized shapes benefit most from this, and how small changes to your LINQ can accidentally defeat caching and hurt throughput. Combined with null‑handling rules and translation limits, this caching behavior explains why two queries that look almost identical in C# can feel very different in SQL Server under load. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67810642/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67810642/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that EF Core isn’t a black box—it follows a predictable pipeline of expression trees, provider decisions, and cached plans. Once you understand that structure, “weird” SQL, sudden performance drops, and confusing null behavior stop looking like magic and start looking like architecture issues you can actually fix in your queries. https://www.spreaker.com/cms/episodes/67810642/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67810642/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67810642/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and data platform consultant and host of the M365.FM podcast, helping organizations treat .NET, SQL Server, and their data layer as one integrated operating system instead of disconnected ORMs and databases. He works with teams running on Microsoft 365, Azure, and modern data stacks to design query, performance, and architecture patterns so LINQ, EF Core, and SQL work together predictably instead of producing surprise slowdowns in production. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Why Dirty Code Always Wins (Until It Doesn’t): Cross‑Cutting Concerns, Middleware, Decorators & How To Keep Business Logic Clean | 18 Sep 2025 | 00:19:25 | |
Ever notice how the fastest way to ship is usually the messiest—logging scattered through controllers, validation copy‑pasted into handlers, authentication bolted on wherever it happens to work? It feels fast in the moment, but every shortcut adds weight until the codebase becomes something nobody wants to touch. In this episode, we look at why dirty code wins the short‑term race, how cross‑cutting concerns quietly smother your business logic, and how to use middleware, decorators and pipelines to keep shipping fast without turning your system into an unmaintainable tangle. WHY MESSY CODE FEELS LIKE THE FASTEST CODE Under deadline pressure, “just make it work” feels rational: log right in the controller, paste the same validation into a few endpoints, wrap everything in try‑catch and move on. The feature ships, the business is happy, and the team gets praised for speed—so the pattern repeats. We unpack how this local optimization turns into global drag: duplicated checks, inconsistent behavior, and controller methods where actual business rules are buried under logging, validation and error‑handling noise. You’ll hear why this isn’t a skill problem but a structural one: without a place to put cross‑cutting concerns, they will always leak into your domain code THE RISE OF CROSS‑CUTTING CONCERNS https://www.spreaker.com/cms/episodes/67803300/edit/info?filter=NETWORK&network=18613266Logging, authentication, validation, telemetry and audit trails don’t belong to any single feature, which is why they end up everywhere. We walk through how these cross‑cutting concerns creep in one “quick fix” at a time, multiplying across endpoints until every change means editing the same patterns in dozens of places. Over time, controllers stop reading like “create order” or “approve invoice” and instead look like “log, check, validate, catch, log again,” hiding intent and making onboarding brutally slow. Once you see this as a systemic concern—not a team discipline issue—you can start solving it with architecture instead of more code reviews. https://www.spreaker.com/cms/episodes/67803300/edit/info?filter=NETWORK&network=18613266WHERE DESIGN PATTERNS ACTUALLY HELP https://www.spreaker.com/cms/episodes/67803300/edit/info?filter=NETWORK&network=18613266Patterns like middleware, decorators, handlers and pipelines aren’t academic buzzwords—they’re how you pull cross‑cutting concerns out of your business code without losing speed. We discuss practical uses: logging decorators that wrap services without touching their methods, validation layers that sit before handlers, middleware pipelines that centralize authentication and error handling so controllers can stay thin. You’ll learn how to start small—wrapping one use case at a time—so you don’t trigger a massive rewrite, and how to use these patterns to keep “boring” domain logic clean even as requirements for observability and compliance grow. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67803300/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67803300/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that “dirty code vs clean code” is not a taste issue—it’s a system design issue. As long as you have nowhere to put cross‑cutting concerns, they will invade your business logic; once you introduce the right patterns, you can ship just as fast while making the next change cheaper instead of more expensive. https://www.spreaker.com/cms/episodes/67803300/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67803300/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67803300/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and backend architecture consultant and host of the M365.FM podcast, helping organizations treat their application code, infrastructure and observability as one integrated operating system instead of disconnected layers. He works with teams running on Microsoft 365, Azure and modern .NET stacks to design patterns, pipelines and governance that keep code shippable and maintainable—even when cross‑cutting demands like logging and compliance keep growing. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| No‑Code vs Pro‑Code Security Showdown: Guardrails, Governance & How To Choose The Right Model For Your Next App | 17 Sep 2025 | 00:21:19 | |
If your Power App exposed sensitive data tomorrow, would you know why—or how to shut it down? No-code feels fast, but every skipped checkpoint quietly adds risk; pro-code gives you control, but only if you deliberately design and maintain security yourself. In this episode, we compare how both models handle speed, guardrails, governance and long‑term ownership so you can decide which approach fits your next project—and where you absolutely cannot afford to cut corners. SPEED VS SECURITY: THE HIDDEN TRADEOFF No-code shines when you need results yesterday: a manager replaces a spreadsheet with a Power App over lunch, or a team automates approvals before the weekend. That speed comes from skipping the natural pauses—documentation, staged testing, structured release gates—that traditional pro‑code projects force you to follow. We walk through real scenarios where this agility backfires, like a region building an app that quietly moves EU customer data into a US tenant, creating GDPR exposure nobody planned. By contrast, Azure‑based pro‑code development feels slower precisely because every layer—networking, identities, access rules—is a gate you must pass. The friction is frustrating, but it acts as a safety net: misconfigurations are more likely to be caught before production instead of during an audit. https://www.spreaker.com/cms/episodes/67797020/edit/info?filter=NETWORK&network=18613266SECURITY MODELS: SHARED GUARDRAILS VS FULL CONTROL https://www.spreaker.com/cms/episodes/67797020/edit/info?filter=NETWORK&network=18613266Low‑code platforms operate on a shared responsibility model: the vendor secures the underlying services, while you decide which data, connectors and environments your apps can touch. That gives you “leased safety features” like global DLP rules that block risky connector combinations across the tenant—but the same broad rules can also block legitimate scenarios you care about. Pro‑code environments flip the equation: you get full control to design identity, logging, encryption and egress control exactly how you want, but no automatic guardrails step in if you forget something. We compare these models with concrete examples, such as blocking data exfiltration via connectors in Power Platform versus hand‑crafting outbound rules and checks in custom APIs. The takeaway: platforms with strong guardrails reduce accidental risk but limit flexibility; code‑first stacks offer deep flexibility but demand sustained security discipline. https://www.spreaker.com/cms/episodes/67797020/edit/info?filter=NETWORK&network=18613266GOVERNANCE BURDEN: WHO ACTUALLY OWNS THE RISK? https://www.spreaker.com/cms/episodes/67797020/edit/info?filter=NETWORK&network=18613266Governance isn’t theory—it’s the answer to “who gets blamed when this goes wrong?” In no‑code platforms, central admins define environments, policies and connector rules, while makers happily build on top without seeing most of that complexity. That split can be powerful—centralized control with distributed creation—but only if the governance layer is real: clear environment strategy, DLP policies that match data classification, and review gates for apps that touch regulated systems. In pro‑code projects, ownership is more obvious and more demanding: engineering teams inherit the full burden for secure design, from auth flows to logging to data residency, and operations must keep those controls current as the system evolves. We discuss how to map this burden explicitly—who approves what, who can change policies, who signs off on risk—so neither makers nor dev teams quietly build shadow systems outside governance. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67797020/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67797020/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that “no-code vs pro-code” is really “guardrails vs responsibility.” Low‑code tools give you built‑in protections but can hide accumulated risk when speed outruns governance; pro‑code gives you full power but demands that you design and own every safeguard. Once you understand where each model’s risks and responsibilities sit, you can choose the right approach intentionally—instead of sliding into it because it happened to be fastest that day. https://www.spreaker.com/cms/episodes/67797020/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67797020/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67797020/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and Power Platform consultant and host of the M365.FM podcast, helping organizations treat low‑code, pro‑code and their cloud governance as one integrated operating system instead of competing islands. He works with teams running on Microsoft 365, Azure and Power Platform to design architecture, security and governance models that let makers move fast without putting regulated data, compliance or critical systems at risk. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| The Hidden AI Engine Inside .NET 10: WebAuthn, Passkeys, Diagnostics & How AI Really Fits Into ASP.NET Core | 17 Sep 2025 | 00:20:45 | |
Most people still think of ASP.NET Core as “just” a web framework, but .NET 10 quietly ships with an AI‑ready engine that shapes how your apps think, react and secure themselves. In this episode, I unpack what that actually means: how AI hooks integrate with the runtime, how WebAuthn passkeys and modern security signals feed into your telemetry, and how improved diagnostics can surface problems earlier instead of burying you in logs. You’ll hear where intelligence is truly baked into the platform, which capabilities are opt‑in, and how to decide what’s safe to adopt now for real projects—not just demos. THE AI ENGINE HIDING IN PLAIN SIGHT https://www.spreaker.com/cms/episodes/67788801/edit/info?filter=NETWORK&network=18613266What stands out in .NET 10 isn’t one flashy “AI feature,” but how the platform makes it easier to plug intelligence into the apps you already build. Instead of wiring ML.NET or external services by hand, you can use familiar patterns—dependency injection, middleware, pipelines—to connect models and AI services directly into your request flow. We walk through how this reduces the scaffolding code and mental overhead that used to make AI feel exotic, and how those hooks turn intelligence into a quiet, supporting layer rather than a separate science project bolted on top.https://www.spreaker.com/cms/episodes/67788801/edit/info?filter=NETWORK&network=18613266 SECURITY THAT TALKS TO YOUR AI .NET 10 doesn’t just add AI‑friendly plumbing; it also strengthens the signals your app can base decisions on. With better support for WebAuthn and passkeys, authentication moves beyond passwords, and the resulting events can be routed into your telemetry and analytics. We explore how sign‑in patterns, device context and timing become inputs for anomaly detection and AI‑driven evaluation—not to replace human judgment, but to surface suspicious combinations earlier. The result is a security layer that does more than lock doors: it tells your monitoring and AI where trust might be shifting in real time. DIAGNOSTICS THAT PREDICT BREAKDOWNS, NOT JUST AUTOPSIES https://www.spreaker.com/cms/episodes/67788801/edit/info?filter=NETWORK&network=18613266Traditional diagnostics in .NET were reactive: you dug through logs after a crash and hoped the right message existed. In the .NET 10 era, diagnostics aim earlier in the cycle, connecting telemetry, traces and AI‑assisted analysis so issues can be highlighted while systems still appear “healthy” on the surface. We talk about how structured signals from runtime behavior, auth flows and performance counters can be fed into smarter tooling that points you at likely root causes instead of leaving you with thousand‑line log files. This doesn’t make debugging magical—but it does tilt the odds toward discovering problems before users feel them.https://www.spreaker.com/cms/episodes/67788801/edit/info?filter=NETWORK&network=18613266 WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67788801/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67788801/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that .NET 10 treats intelligence as part of the foundation, not an afterthought. When AI hooks, security signals and diagnostics all share the same runtime and telemetry, you get a platform where apps can see more, react earlier and stay safer—provided you deliberately choose which pieces to turn on and how to govern them. https://www.spreaker.com/cms/episodes/67788801/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67788801/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67788801/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and backend architecture consultant and host of the M365.FM podcast, helping organizations treat .NET, security, AI and diagnostics as one integrated operating system instead of disconnected stacks. He works with teams running on Microsoft 365, Azure and modern .NET to design architectures where AI, identity and observability reinforce each other—so apps stay fast, secure and explainable under real‑world pressure. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Your SharePoint Content Map Is Lying To You: How To Audit Structure, Usage & Value To Fix Findability In Microsoft 365 | 16 Sep 2025 | 00:20:25 | |
If a new hire joined tomorrow, how long would it take them to find the files they actually need—ten seconds, ten minutes, or never? In this episode, we show why neat site diagrams and folder trees create the illusion of control while people still ask “Where’s the latest version?” or “Should this live in Teams or SharePoint?”. You’ll learn the three layers of content assessment most teams skip—structural, behavioral and contextual—and how to use real usage data, ownership and process fit to separate signal from noise in your Microsoft 365 content. WHY YOUR CONTENT MAP LOOKS PERFECT BUT STILL FAILS https://www.spreaker.com/cms/episodes/67780825/edit/info?filter=NETWORK&network=18613266On paper, your SharePoint environment looks great: sites are tidy, libraries clearly separated, folders labeled for audits. In practice, staff still duplicate files, rebuild documents from scratch and argue about which version is “official,” because the map describes where content should live—not how findable or useful it is in daily work. We unpack the gap between architecture and reality, using the “polished ghost town” pattern: highly structured archives full of content nobody opens, searches or trusts anymore. You’ll see why mapping alone only catalogs assets, while assessment reveals which content still supports real processes, compliance and decisions—and which is just labeled clutter. THE THREE LAYERS OF CONTENT ASSESSMENT EVERYONE MISSES https://www.spreaker.com/cms/episodes/67780825/edit/info?filter=NETWORK&network=18613266Real content health needs three lenses working together. Structural is the “where”: sites, libraries, folders, last‑modified dates and storage footprint. Behavioral is the “what”: which files people open, edit, share or fail to find, using telemetry and search logs as evidence. Contextual is the “why”: ownership, legal or compliance requirements, and the business processes each library actually supports. We show how to gather proof for each layer in Microsoft 365 and how combining them exposes dormant libraries, critical but rarely accessed records, and areas where governance is managing material that no longer matters.https://www.spreaker.com/cms/episodes/67780825/edit/info?filter=NETWORK&network=18613266 SEPARATING SIGNAL FROM NOISE IN YOUR TENANT https://www.spreaker.com/cms/episodes/67780825/edit/info?filter=NETWORK&network=18613266Once you see all three layers, you can finally separate high‑value content from background noise. We outline a practical workflow: inventory one site, pull usage and activity data, interview owners about process relevance, then classify each area as keep, fix or archive. You’ll learn which metrics actually matter (access frequency, failed searches, age vs usage) and how to present findings to leadership in a way that links clutter to real cost: slower search, decision delays and higher risk when outdated docs masquerade as current. The goal is not to police every file, but to identify where cleanup and redesign will have the biggest impact on findability and Copilot readiness. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67780825/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67780825/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that a clean content map doesn’t prove your system works—it only proves someone drew a neat picture. Once you layer structure, behavior and context, you stop managing SharePoint as a static archive and start treating it as a living ecosystem where only the content that supports real work, compliance and search should survive. https://www.spreaker.com/cms/episodes/67780825/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67780825/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67780825/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and information architecture consultant and host of the M365.FM podcast, helping organizations treat SharePoint, Teams and Purview as one integrated operating system instead of a pile of pretty diagrams and forgotten libraries. He works with teams running on Microsoft 365 and Azure to design content assessments, governance and clean‑up programs that improve findability, reduce noise and give Copilot a high‑quality signal to work with. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Build Azure Apps Without Writing Boilerplate: GitHub Copilot for Azure, azd & Faster IaC‑Driven Deployments | 16 Sep 2025 | 00:18:56 | |
How many hours have you lost wrestling with configs, auth wiring and deployment scripts before writing a single useful line of code? In this episode, we start from that pain and then flip the script: you’ll see how GitHub Copilot for Azure knocks down the blank‑page problem by scaffolding infrastructure‑as‑code from a simple prompt, and how the Azure Developer CLI (azd) turns that scaffolding into a running app with a predictable “init → provision → deploy” flow. Instead of spending your first sprint chasing YAML errors and resource names, you shift your time back to product logic—while still keeping control over what actually ships to Azure. WHY BOILERPLATE HOLDS TEAMS BACK https://www.spreaker.com/cms/episodes/67774564/edit/info?filter=NETWORK&network=18613266Most projects don’t stall because of hard algorithms—they stall in the setup swamp. New repos start with enthusiasm and quickly sink into configuration work: resource groups, service principals, connection strings, CI pipelines, DNS and networking decisions that eat days before any feature exists. We walk through how this repetitive scaffolding work quietly burns budget and morale, why it’s especially toxic in early sprints and startups, and how treating boilerplate as “inevitable” leads to teams demoing folder structures instead of working features. That’s the exact bottleneck Copilot and azd are designed to attack. COPILOT AS YOUR CLOUD PAIR PROGRAMMER https://www.spreaker.com/cms/episodes/67774564/edit/info?filter=NETWORK&network=18613266GitHub Copilot for Azure acts like a cloud pair programmer that understands Azure resource patterns. Instead of hunting templates, you describe what you want—“Python web app with Functions and SQL backend”—and Copilot generates Bicep/ARM templates, parameters and wiring that would normally take hours. In the episode, we walk through a live‑style flow: prompting Copilot, inspecting the generated files, and showing how it wires Function App, SQL Database, Key Vault and connection strings together. We’re clear about the boundaries: this is scaffolding, not a finished architecture—you still review for security, naming and org standards—but you start three steps ahead instead of staring at a blank main.bicep. FROM SCAFFOLDING TO DEPLOYMENT WITH AZD https://www.spreaker.com/cms/episodes/67774564/edit/info?filter=NETWORK&network=18613266Once the templates exist, azd becomes your deployment backbone. We show how azd uses config files plus a simple command flow—azd init, azd provision, azd deploy—to create environments, provision resources and push app code without juggling ten separate CLI commands. You’ll hear why azd doesn’t hide anything: you can always inspect the environment files to see exactly what’s being created, which keeps this usable in enterprise scenarios where transparency matters. The result is a predictable path from repo to running app: resources, secrets and code are wired together consistently across dev, test and prod instead of reinvented each project. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67774564/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67774564/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that setup shouldn’t be where your best engineers spend their energy. By letting Copilot handle scaffolding and azd handle deployment, you move boilerplate back to where it belongs—generated, reviewed and automated—while your team focuses on the parts of the Azure app that actually differentiate your product. https://www.spreaker.com/cms/episodes/67774564/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67774564/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67774564/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365, Azure and developer productivity consultant and host of the M365.FM podcast, helping organizations treat GitHub, Azure and their app stack as one integrated operating system instead of a mess of one‑off scripts and hand‑built pipelines. He works with teams running on Microsoft 365, Azure and modern DevOps toolchains to design scaffolding, deployment and governance patterns so new apps go from idea to running in the cloud without burning weeks on boilerplate. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Quantum Code Isn’t Magic – It’s Debuggable: Q#, Azure Quantum & How To Run Your First Quantum Program From .NET | 15 Sep 2025 | 00:19:42 | |
Quantum computing sounds like lab‑coat physics, but today you can write Q# on your laptop and send it to a real quantum computer in the cloud. In this episode, you see the full path: from installing the Quantum Development Kit and Q# tools, to running a simple program locally, to submitting the same job to Azure Quantum hardware. We focus on what feels familiar to .NET and cloud developers—projects, tooling, CI‑style workflows—and where your mental model must shift from deterministic code to probabilistic states and measurement. WHY QUANTUM CODE FEELS MORE FAMILIAR THAN YOU THINK https://www.spreaker.com/cms/episodes/67768620/edit/info?filter=NETWORK&network=18613266Most people expect quantum programming to look like a wall of equations; then they open Q# and find namespaces, operations and types that read like any other modern language. We walk through how Q# leans on structures you already know—functions, parameters, loops—so the barrier isn’t syntax but meaning: qubits instead of integers, operations that move probabilities instead of flipping bits. Using the “dimmer switch” metaphor, you’ll see how superposition and measurement differ from classic one‑and‑zero thinking, and why debugging quantum programs is less about printing values and more about reasoning which operations you applied and when you chose to measure.https://www.spreaker.com/cms/episodes/67768620/edit/info?filter=NETWORK&network=18613266 SETTING UP YOUR QUANTUM PLAYGROUND WITH Q# AND AZURE QUANTUM https://www.spreaker.com/cms/episodes/67768620/edit/info?filter=NETWORK&network=18613266Before any of this matters, your tools have to cooperate. We outline the practical setup: keep .NET SDK current, install the Quantum Development Kit, add the Q# extension to Visual Studio Code, and provision an Azure Quantum workspace in your subscription. You’ll hear the real‑world gotchas—VS Code needing a restart, projects not linking to the right workspace, CLI authentication steps—and how to fix them without chasing “mystical quantum errors” that are really just normal environment problems. With that in place, you have a playground where the same Q# project runs locally on a simulator and remotely on quantum hardware. WRITING AND RUNNING YOUR FIRST Q# PROGRAM https://www.spreaker.com/cms/episodes/67768620/edit/info?filter=NETWORK&network=18613266With the environment ready, we build a tiny but complete quantum program: allocate a qubit, apply a Hadamard gate, then measure it. You’ll see the code structure for that “Hello World” of quantum computing, how the operations correspond to the dimmer‑switch idea, and what the measurement results look like on the local simulator: repeated runs converging on the expected probability split. From there, we show how the same operation can be submitted as a job to Azure Quantum, what changes in the workflow, and how to interpret results that now come from real devices rather than a local simulator. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67768620/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67768620/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that the hardest part of quantum development isn’t magic math—it’s shifting your mental model while using tools you already know. Once Q#, VS Code and Azure Quantum are wired up, quantum programming feels less like an unreachable lab experiment and more like another target in your existing cloud toolchain—just with code that manipulates probabilities instead of plain bits. https://www.spreaker.com/cms/episodes/67768620/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67768620/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67768620/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365, Azure and developer productivity consultant and host of the M365.FM podcast, helping organizations treat .NET, cloud infrastructure and new runtimes like quantum as one integrated operating system instead of isolated experiments. He works with teams running on Microsoft 365 and Azure to design toolchains and architectures that make even advanced platforms like Azure Quantum approachable, testable and ready to plug into existing development workflows. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| The Cloud Promise Is Broken: Why Migrations Never End, Dashboards Don’t Change Anything & How To Fix Azure Responsibility Gaps | 15 Sep 2025 | 00:20:57 | |
You were promised speed, savings and security in one move to the cloud—and got half‑finished migrations, surprise bills and endless “stabilization” instead. In this episode, I explain why cloud migrations never really end, how the data you collect turns into busywork instead of decisions, and where responsibility for fixing things quietly evaporates between teams. You’ll get concrete targets you can set this quarter so Azure stops feeling like a moving target and starts behaving like a platform you can actually steer. WHY CLOUD MIGRATIONS NEVER REALLY END https://www.spreaker.com/cms/episodes/67760699/edit/info?filter=NETWORK&network=18613266Most teams treat “we’re in Azure now” as a finish line, but the platform keeps changing under your feet. Services evolve, pricing shifts, security baselines update and suddenly yesterday’s “done” architecture looks outdated or too expensive. We walk through the pattern: migration projects celebrate landing workloads, then drift into constant reconfigurations, cost firefighting and compliance fixes because the cloud behaves like a living ecosystem—not a static destination. The key shift is moving from “Are we done?” to “How fast can we adjust?” and measuring resilience instead of pretending you’ll ever reach a final state.https://www.spreaker.com/cms/episodes/67760699/edit/info?filter=NETWORK&network=18613266 THE DATA TRAP: DASHBOARDS WITHOUT DECISIONS https://www.spreaker.com/cms/episodes/67760699/edit/info?filter=NETWORK&network=18613266Collecting metrics is easy; acting on them is where most organizations fail. Dashboards show utilization, latency, cost and security alerts, but too often they’re produced, emailed and forgotten—creating the illusion of control without any actual changes in the environment. I break down why reports become background noise, how that lulls leadership into thinking risks are handled, and how to flip one metric this month into a real intervention (for example, shutting down underused VMs at night and tracking the savings). Monitoring only creates value when someone has both the mandate and the habit to turn numbers into adjustments. THE RESPONSIBILITY MIRAGE https://www.spreaker.com/cms/episodes/67760699/edit/info?filter=NETWORK&network=18613266On paper, ownership looks clear: security owns security, finance owns cost, ops owns uptime. In reality, the teams who see the problems often don’t control the budgets, permissions or tools needed to fix them—so issues get logged, escalated and slowly forgotten. We explore this “responsibility mirage” with examples like security teams who can see missing encryption but can’t enable the feature, or FinOps teams who spot waste but can’t change application design. You’ll learn how to redraw the responsibility map so every key signal (cost, risk, performance) has a clearly named owner with authority to change configurations, not just write slide decks.https://www.spreaker.com/cms/episodes/67760699/edit/info?filter=NETWORK&network=18613266 WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67760699/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67760699/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that the cloud promise isn’t wrong—you just don’t get cost, speed and security automatically by landing workloads. When you accept that Azure never stops moving, tie monitoring to real decisions and fix who actually owns which levers, the platform stops feeling like a broken promise and starts behaving like a controllable system you can improve month by month. https://www.spreaker.com/cms/episodes/67760699/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67760699/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67760699/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and Azure governance consultant and host of the M365.FM podcast, helping organizations treat Azure, Microsoft 365 and their operating model as one integrated system instead of disconnected projects and reports. He works with teams running on Microsoft 365 and Azure to design ownership, metrics and improvement loops so cloud platforms deliver measurable gains in cost, risk and speed—instead of becoming permanent “stabilization” projects. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Stop Using Entity Framework Like This: DTO Factories, Micro‑ORM Mirage & How To Model Real Domain Logic With EF Core | 14 Sep 2025 | 00:18:24 | |
If you’re using Entity Framework only to mirror your database tables into DTOs, you’re missing most of what it can actually do. That’s like buying an electric car and never driving it—just plugging your phone into the charger. No wonder so many developers end up frustrated, or decide EF is too heavy and switch to a micro‑ORM. In this episode, I walk through a concrete before‑and‑after refactor, the EF Core features that matter—navigation properties, owned types, fluent API—and the code smells that tell you your EF layer has quietly turned into a DTO factory WHEN EF BECOMES A DTO FACTORY https://www.spreaker.com/cms/episodes/67754723/edit/info?filter=NETWORK&network=18613266Scaffolding tables straight into EF entity classes feels fast: \Customer\\ table becomes \Customer\\ class, one row becomes one object, and at first everything looks clean. But when entities only hold properties and all business rules—totals, discounts, eligibility—get pushed into controllers and services, your “model” stops modeling anything. I explain the red flags: entities with no behavior, duplicated rules across services, controller methods full of business logic and queries that drag back every column because the entity shape is locked to the table. Over time, EF starts to feel like bloat, because you’re carrying a full ORM to do a job a micro‑ORM could handle—while still missing the benefits EF was built to provide. THE MICRO‑ORM MIRAGE https://www.spreaker.com/cms/episodes/67754723/edit/info?filter=NETWORK&network=18613266When EF feels heavy, micro‑ORMs look like salvation: lean, SQL‑first, and transparent. For narrow, read‑heavy endpoints that’s often true, and I explain where tools like Dapper shine—simple queries, tight control of SQL, easy performance tuning. But as soon as your domain needs relationship management, change tracking, concurrency handling or consistent mapping conventions, the work you “saved” comes back as custom plumbing and boilerplate. I outline a simple rule of thumb: reach for a micro‑ORM when you truly need hand‑crafted SQL for slices of your system; default to EF Core when you’re persisting a domain model with real behavior and relationships. HOW TO USE EF CORE THE WAY IT WAS DESIGNED https://www.spreaker.com/cms/episodes/67754723/edit/info?filter=NETWORK&network=18613266EF stops feeling like friction when you let it do the job it was built for: persisting meaningful objects, not table‑shaped shells. I show how to move behavior back into entities, use navigation properties to express relationships, model value objects with owned types and let the fluent API describe database details instead of polluting your domain with attributes. We also talk about where to draw the line between domain models and read models (CQRS), so you don’t bend one set of types into doing everything. Used this way, EF’s features remove code instead of adding it—and the ORM stops being the villain for architectural problems it didn’t create. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67754723/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67754723/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that EF Core isn’t “too heavy” by default—it becomes heavy when you force it to behave like a table copier. Once you treat it as a persistence layer for a real domain model and reserve micro‑ORMs for targeted scenarios, you get the best of both worlds: expressive code and predictable performance without reinventing the plumbing EF already solved. https://www.spreaker.com/cms/episodes/67754723/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67754723/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67754723/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365, Azure and backend architecture consultant and host of the M365.FM podcast, helping organizations treat data access, domain models and infrastructure as one integrated operating system instead of disconnected layers. He works with teams running on Microsoft 365, Azure and modern .NET stacks to design persistence and domain patterns so Entity Framework, micro‑ORMs and SQL all play to their strengths instead of fighting each other. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Power Apps Vibe Code vs Low Code: when to move from Canvas Apps to Code Apps with GitHub Copilot | 28 Oct 2025 | 00:21:10 | |
Power Apps Vibe Code vs Low Code: in this episode of M365.fm, Mirko Peters tears down the fairy tale that Power Apps is just “drag, drop, publish” and shows how Vibe Code—Code Apps with React, VS Code, and GitHub Copilot—changes who should really be building serious apps. He explains how the “low‑code for everyone” story worked too well, leaving enterprises with dozens of fragile Canvas Apps built by well‑meaning citizen devs, all hiding complex Power Fx formulas, delegation warnings, and maintenance nightmares behind pastel buttons and cheerful UI. Mirko starts with the low‑code illusion. Canvas and model‑driven apps made it feel like anyone could be a developer, but the reality was IKEA‑style software: fast to assemble, terrifying to move or upgrade. He walks through how Power Fx creates opaque dependency webs only the original maker understands, how slightly different “Task Tracker” apps proliferate across environments, and why serious integrations—SQL, CI/CD, reusable components—push teams into painful “rewrite moments” where low‑code’s early speed turns into long‑term techdebt. He then introduces Vibe Code (Power Apps Code Apps) as the grown‑up counterweight. You work in Visual Studio Code with TypeScript, React, pac CLI, and proper Git repositories, but still live inside the Power Platform’s governed world of connectors, environments, and Microsoft Entra authentication. Mirko shows how Code Apps let pro devs scaffold real web apps—initialized via CLI, tested locally with npm, and deployed back into Power Apps with pac code push—so you get modern engineering practices (source control, pull requests, CI/CD) without abandoning the platform. The episode also explores GitHub Copilot as the “vibe partner” for this new model. Mirko explains how Copilot turns comments and intent into full React components, connector calls, and data services, handling the boilerplate while humans design architecture and behavior. You’ll hear how this transforms productivity: developers focus on domain logic and patterns while Copilot writes imports, JSX, and repetitive glue, making Code Apps feel as fast as low‑code prototypes but with code that can be tested, refactored, and reviewed like any other serious project. Finally, he lays out a decision framework for when to stay in low‑code and when to move to Vibe Code. Small departmental tools and quick workflows remain a Canvas strength; anything with scale, longevity, complex logic, or heavy integration belongs in Code Apps backed by Git and pipelines. Mirko gives you language to explain this split to stakeholders—low‑code as IKEA, Vibe Code as custom carpentry in a governed workshop—and shows how GitHub Copilot glues the two worlds together instead of forcing a false either/or choice. WHAT YOU WILL LEARN
Low‑code made building apps easy; Vibe Code makes keeping them alive possible. Once you reserve Canvas for small, tactical tools and use Code Apps plus GitHub Copilot for long‑lived, integrated systems, Power Apps stops being a playground of fragile experiments and becomes a real application platform with both speed and discipline. https://www.spreaker.com/cms/episodes/68307416/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FOR This episode is ideal for Power Apps makers, pro devs, fusion teams, COE leaders, and architects who are deciding how to split work between Canvas Apps and Code Apps. It is especially valuable if your organization is hitting the limits of low‑code, seeing Canvas rewrites, or looking for a credible way to bring professional development practices—React, Git, CI/CD—into the Power Platform without losing the productivity that made it attractive in the first place. https://www.spreaker.com/cms/episodes/68307416/edit/info?filter=NETWORK&network=18613266ABOUT THE HOST Mirko Peters is a Microsoft 365 and Power Platform consultant focused on building governed, scalable solutions with Power Apps, Dataverse, GitHub Copilot, and modern low‑code/“vibe code” architectures. Through M365.fm, he shares practical fusion‑dev stories, governance models, and engineering patterns that help organizations balance low‑code speed with pro‑code reliability.https://www.spreaker.com/cms/episodes/68307416/edit/info?filter=NETWORK&network=18613266 Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Unit vs Integration vs Front-End Testing: Which Bugs Each Layer Catches (And Why Your Azure Apps Need All Three) | 14 Sep 2025 | 00:19:52 | |
You fix a tiny function, all unit tests go green, the pipeline smiles—and production still breaks in three different places. That’s not bad luck, it’s a missing test strategy: each layer (unit, integration, front‑end) catches a different class of failure, but most teams over‑invest in one and under‑invest in the others. In this episode, we use a real Azure Functions bug as the running example: how a harmless‑looking change in a helper method broke not just one endpoint, but also queue processing and UI flows. You’ll see exactly how unit tests could have protected the logic, how integration tests would have validated the chain between Function, queue and database, and how front‑end tests would have caught the broken user journey before go‑live.https://www.spreaker.com/cms/episodes/67750560/edit/info?filter=NETWORK&network=18613266The goal isn’t “more tests”, it’s the right mix: a thin, fast unit‑test layer, focused integration tests at risky boundaries, and a handful of sharp end‑to‑end flows. That’s how you stop using production as your test environment and turn CI/CD from a “hope it’s fine” signal into a real quality gate. WHAT UNIT TESTS REALLY COVER (AND WHAT THEY DON’T) https://www.spreaker.com/cms/episodes/67750560/edit/info?filter=NETWORK&network=18613266Unit tests are your first line of defense: they validate pure logic and small units with no external dependencies. They’re fast, cheap and perfect for calculations, decision rules, mappings and any function that deterministically turns input into output. We walk through typical patterns in Azure/backend apps—services with injected dependencies, pure helper functions, domain logic—and show where unit tests, in our Azure Functions example, would have caught the real bug (changed null handling, different default values, altered time logic) right at the source.https://www.spreaker.com/cms/episodes/67750560/edit/info?filter=NETWORK&network=18613266The limits appear as soon as external systems show up: databases, queues, HTTP APIs, storage, feature flags. Unit tests never see missing connection strings, wrong auth headers, broken serialization or timeouts that kill your function. If you only rely on unit tests, you validate your code—but not whether your app actually works in the real Azure setup. WHAT INTEGRATION TESTS CATCH THAT UNIT TESTS CAN’T https://www.spreaker.com/cms/episodes/67750560/edit/info?filter=NETWORK&network=18613266Integration tests don’t care if each function is “theoretically” correct; they check whether services and infrastructure work together. In our Azure Functions scenario, that means: a function calls an API, writes to a queue, a consumer reads the message, writes to a database and sets a status that another service or the UI reads. A good integration test for this chain would have shown that after the code change, certain inputs no longer hit the queue correctly or records never make it into the database—even though every unit test was green.https://www.spreaker.com/cms/episodes/67750560/edit/info?filter=NETWORK&network=18613266We outline practical patterns: local test containers (SQL, storage emulators), small Azure test environments, pre‑provisioned resources, and how to keep integration tests reliable without slowing your pipeline to a crawl. Instead of “integrate everything or nothing”, you focus on a few business‑critical flows (orders, payments, registrations) where failure really hurts. WHY FRONT-END / E2E TESTS ARE YOUR LAST LINE OF DEFENSE https://www.spreaker.com/cms/episodes/67750560/edit/info?filter=NETWORK&network=18613266Front‑end or end‑to‑end tests simulate what users actually do: open a page, fill a form, click a button, expect a result. They can’t see your service layer or queues—they only see “page doesn’t load”, “button does nothing” or “wrong error message shows up”. In the Azure Functions example, a simple E2E flow (for example with Playwright or Cypress) would have exposed the regression: user sends a request, the UI hangs or errors out, even though your unit tests were happy.https://www.spreaker.com/cms/episodes/67750560/edit/info?filter=NETWORK&network=18613266We explain why E2E tests must be used sparingly: they’re slower and more fragile, but unbeatable as the final quality barrier before release. The trick is to pick 5–10 truly critical user journeys and automate those—not every tiny UI branch. Used this way, they keep obviously broken releases away from customers without turning your pipeline into a bottleneck.https://www.spreaker.com/cms/episodes/67750560/edit/info?filter=NETWORK&network=18613266 WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67750560/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67750560/edit/info?filter=NETWORK&network=18613266The core insight is that this isn’t about whether unit, integration or front‑end tests are “best”—it’s about which risk you catch where. Unit tests protect your logic, integration tests protect your critical connections, and front‑end tests protect the real user experience; only together do they stop your customers from becoming your monitoring system. https://www.spreaker.com/cms/episodes/67750560/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67750560/edit/info?filter=NETWORK&network=18613266
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Why ARM Templates Are Holding You Back (And How Bicep Fixes Azure Deployments) | 13 Sep 2025 | 00:17:55 | |
ARM templates look powerful on paper—but in real projects they grow into giant JSON blobs that are hard to read, harder to debug, and almost impossible to keep in sync with what’s actually running in Azure. One missing comma or brace can block a whole deployment, error messages are vague, and teams under pressure quietly “fix it in the portal,” leaving templates and reality out of sync. In this episode, we unpack why ARM collapses under its own weight as soon as you go beyond trivial examples, how configuration drift slowly destroys your “infrastructure as code,” and why so many ARM files end up as untrusted skeletons instead of a real source of truth.https://www.spreaker.com/cms/episodes/67746475/edit/info?filter=NETWORK&network=18613266Bicep flips that experience: it gives you a cleaner, more readable language on top of the same ARM engine, with proper modules, reuse, and tooling support so you stop copy‑pasting JSON and start composing infrastructure like code. We walk through the same deployment written once in classic ARM and once in Bicep so you can see the difference side by side, then show how Bicep makes refactors, reviews, and DRY patterns realistic instead of painful.https://www.spreaker.com/cms/episodes/67746475/edit/info?filter=NETWORK&network=18613266 WHY ARM TEMPLATES BREAK MORE THAN THEY BUILD https://www.spreaker.com/cms/episodes/67746475/edit/info?filter=NETWORK&network=18613266ARM was supposed to make deployments predictable: declare the end state, let Azure handle the rest. In practice, the declarative model gets buried under verbose JSON syntax, deeply nested structures, and duplicated parameter boilerplate, so even a “simple” VM or app service template quickly runs into hundreds of lines. We look at what that does to real teams: error messages that point to the wrong place, hours spent hunting for a missing brace, and pipelines blocked by templates nobody feels confident editing. The result is a familiar pattern: people start bypassing templates with quick portal changes “just this once,” and the more painful the JSON gets, the more often those one‑offs happen. THE SILENT KILLER: CONFIGURATION DRIFT https://www.spreaker.com/cms/episodes/67746475/edit/info?filter=NETWORK&network=18613266Once you start fixing things directly in Azure instead of in code, configuration drift begins. Your template says one thing, your running environment says another, and over time the gap widens until the file you committed isn’t a reliable description of production anymore. We break down how that drift shows up: dev and prod no longer behaving the same even though they “came from the same template,” firewalls and access rules that exist only in the portal, and audits where nobody can explain why a live environment doesn’t match the code in Git. ARM’s bulk and friction make this worse—because editing templates is so painful, small fixes almost never make it back into JSON, so drift becomes the default instead of the exception. WHERE ARM TEMPLATES COLLAPSE UNDER THEIR OWN WEIGHT https://www.spreaker.com/cms/episodes/67746475/edit/info?filter=NETWORK&network=18613266The real breaking point comes when you try to scale. ARM doesn’t give you clean, first‑class ways to build abstractions or reuse building blocks, so teams fall back to copy‑paste as soon as they need similar patterns across environments or stacks. Every copy increases size and complexity, introduces subtle differences, and makes future changes risky, because you’re now editing the same logic in five places instead of one. We talk through how this hits larger deployments—multi‑resource apps, shared components, cross‑region patterns—and why ARM’s design nudges you toward sprawling templates that nobody really owns. HOW BICEP FIXES THE WORST ARM PAIN POINTS https://www.spreaker.com/cms/episodes/67746475/edit/info?filter=NETWORK&network=18613266Bicep keeps the underlying ARM engine but replaces unwieldy JSON with a concise, purpose‑built language for Azure infrastructure. You get readable syntax, proper modules for reuse, parameters and variables that don’t drown in quotes and commas, and tooling that can decompile existing ARM templates so you can migrate instead of starting from scratch. In the episode, we walk a real example: the same VM or app deployment first in ARM, then in Bicep, highlighting how many lines disappear, how much easier it is to spot logic errors, and how review comments suddenly become about architecture instead of bracket placement.https://www.spreaker.com/cms/episodes/67746475/edit/info?filter=NETWORK&network=18613266 WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67746475/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67746475/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that ARM’s problem isn’t what it promises, it’s how it forces you to express those promises. As long as your infrastructure is trapped in giant JSON templates, drift and duplication are almost guaranteed; once you switch to Bicep and treat infrastructure like real code—with modules, reuse and reviews—you finally get the predictable, repeatable deployments ARM was supposed to deliver in the first place. https://www.spreaker.com/cms/episodes/67746475/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67746475/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67746475/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365, Azure and infrastructure‑as‑code consultant and host of the M365.FM podcast, helping organizations treat Azure, DevOps and IaC as one integrated operating system instead of a pile of ad‑hoc scripts and portal changes. He works with teams running on Microsoft 365, Azure and modern DevOps toolchains to replace brittle ARM templates with Bicep‑based deployments that are easier to read, review and keep in sync with reality. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| These New Vulnerabilities Could Break Your .NET Code: OWASP 2025, NuGet Supply Chain Risks & Hidden Traps in Existing Apps | 13 Sep 2025 | 00:21:05 | |
If you think your .NET app is “secure enough” just because you’re on the latest framework, this episode is your uncomfortable reality check. OWASP’s upcoming 2025 update shifts focus away from the usual suspects and toward architectural and ecosystem risks that can compromise your app even when your controllers and queries look clean. We unpack which new categories hit .NET teams hardest—supply chain exposure through NuGet, container and image visibility gaps, and insecure serialization and validation patterns that quietly survived every migration so far. WHY THE NEW OWASP CATEGORIES MATTER FOR .NET https://www.spreaker.com/cms/episodes/67742556/edit/info?filter=NETWORK&network=18613266The most dangerous categories are the ones you don’t expect, because they sit above individual functions. We start with the supply chain angle: how transitive NuGet dependencies three or four levels deep can smuggle in compromised code, even when your own packages and runtimes are fully patched. Then we look at asset visibility in containerized .NET deployments—dozens of images, base layers and registries—where you can’t secure what you can’t even inventory. You’ll see why the updated OWASP view cares less about a single bad query and more about how your architecture, dependencies and deployment choices combine into an attack surface you don’t fully see.https://www.spreaker.com/cms/episodes/67742556/edit/info?filter=NETWORK&network=18613266 WHAT’S MISSING (AND WHY YOU’RE NOT SAFE) https://www.spreaker.com/cms/episodes/67742556/edit/info?filter=NETWORK&network=18613266Some familiar categories drop down or disappear from the headline list—but that doesn’t mean the risks are gone. We explain why classic issues like injection, legacy components and insecure deserialization are still very much alive in real .NET systems, even if they no longer top the charts. Lower visibility simply means newer attacks (like supply chain and asset exposure) are growing faster, not that old flaws stopped working for attackers. For .NET specifically, we highlight insecure serializers and XML/JSON handling that still show up in older code, and why attackers love the moment when teams stop scanning or patching “because it’s not in the Top 10 anymore.” THE HIDDEN TRAPS IN .NET CODE YOU ALREADY SHIPPED https://www.spreaker.com/cms/episodes/67742556/edit/info?filter=NETWORK&network=18613266The most worrying vulnerabilities aren’t in fancy new features; they’re in everyday patterns you wrote long ago and still ship today. We walk through weak input validation that relies on client‑side checks and fragile regex, outdated base images in containerized .NET apps that nobody has rebuilt in months, and nested NuGet dependencies your team never explicitly chose. You’ll see how these ordinary choices now map directly into the newer OWASP categories and how they can be exploited even when your controllers look fine and your framework is up‑to‑date. From there, we translate the theory into action: three concrete checks you can add to your pipelines this week, and one common code pattern you should plan to refactor before the next audit. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67742556/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67742556/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that modern .NET security isn’t just about writing safe controllers—it’s about owning your dependencies, images and deployment paths. As OWASP shifts toward ecosystem and architecture risks, you need to zoom out: secure defaults and patches are necessary, but they won’t save you from a poisoned NuGet package, an outdated base image or a forgotten serializer still running in production. https://www.spreaker.com/cms/episodes/67742556/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67742556/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67742556/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365, Azure and application security consultant and host of the M365.FM podcast, helping organizations treat .NET, NuGet, containers and pipelines as one integrated security surface instead of separate concerns. He works with teams running on Microsoft 365, Azure and modern .NET to design threat models, dependency policies and scanning strategies so new OWASP risks are caught in CI/CD—not in production. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| The Power Platform Hits Its Limit Here: When Apps Outgrow Flows & How Azure Functions Can Save Your Solution | 12 Sep 2025 | 00:21:08 | |
The Power Platform will take you a long way—but not all the way. When workloads get heavy, logic gets complex, or integrations become high‑throughput, flows that looked great in testing start to stall, time out, or buckle under throttling. In this episode, we walk through where Power Apps and Power Automate quietly run out of steam, how to spot the warning signs early in your run histories, and how a single Azure Function can replace layers of brittle nested flows without ripping out your existing app.https://www.spreaker.com/cms/episodes/67736930/edit/info?filter=NETWORK&network=18613266 We start with real‑world patterns you’ve probably seen: approval flows that slow from seconds to hours as volume grows, connectors that silently enforce limits once you cross certain thresholds, and “quick win” apps that become mission‑critical without ever getting the architecture they deserve. From there, we talk about the breaking points—growing run durations, repeated retries, nested flows used as band‑aids—and how to read those signals before your users lose trust and turn to shadow IT. Then we introduce Azure Functions as the invisible bridge: small, targeted bits of code that handle the hard parts—batch processing, complex rules, high‑volume API calls—while your makers keep the Power Platform experience they know. You’ll hear how to carve out the right slice of logic, when to call a function instead of adding “just one more” action, and how to keep ownership clear between low‑code makers and pro‑code developers. Finally, we give you a practical next step you can try this week: open the run history of one important flow, look for rising durations, retries, and failures, and use that evidence to decide whether it’s time to extend with Azure instead of endlessly patching inside Power Automate. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67736930/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67736930/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that the Power Platform isn’t “broken” when it slows down—it’s just doing the job it was designed for. Once your app becomes business‑critical and high‑volume, the right move isn’t more flows, it’s adding a lightweight Azure backend so the platform can focus on orchestration and experience instead of brute‑force processing. https://www.spreaker.com/cms/episodes/67736930/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67736930/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67736930/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and Power Platform consultant and host of the M365.FM podcast, helping organizations treat Power Platform and Azure as one integrated operating system instead of separate low‑code and pro‑code islands. He works with teams running on Microsoft 365, Azure and Power Platform to design extension patterns where heavy logic moves into Azure while makers keep building fast on the front end—without hitting hard limits in silence. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Passwords Are Broken: How Passkeys & WebAuthn Fix Authentication in ASP.NET Core and Microsoft 365 | 12 Sep 2025 | 00:22:45 | |
Passwords aren’t failing because users are careless—they’re failing because the model is fundamentally outdated. Phishing, credential stuffing and endless resets show how fragile a system is that still depends on humans remembering secrets at internet scale. In this episode, you’ll see why tightening password policies barely moves the needle, how much breaches and resets really cost your organization, and why it’s finally realistic to remove passwords altogether instead of patching them.https://www.spreaker.com/cms/episodes/67730942/edit/info?filter=NETWORK&network=18613266 We start with the true cost of “just one” stolen credential: how a single compromised Microsoft 365 admin account can lead to Teams data exposure, mailbox abuse and weeks of recovery work—without any zero-day exploit. Then we look at the hidden tax of password resets and rotation policies that burn IT time, frustrate employees and still don’t stop attackers from reusing old patterns. You’ll walk away with a clear picture of why passwords can’t scale to today’s threat landscape, no matter how many special characters you add. From there, we introduce passkeys and WebAuthn as the realistic alternative, not science fiction. You’ll learn how public‑key cryptography flips the model—private keys stay safely on the device, servers only store public keys, and there’s nothing usable for attackers to steal from your database. We break down what this feels like for users (Face ID, Windows Hello, security keys), how WebAuthn lets browsers and platforms talk the same language, and why phishing pages simply stop working when there’s no password to type.https://www.spreaker.com/cms/episodes/67730942/edit/info?filter=NETWORK&network=18613266 Finally, we get practical for ASP.NET Core teams and decision‑makers. Developers get a high‑level implementation checklist: where to plug passkeys into existing auth flows, which parts of your app change, and what to watch out for in rollout. Leaders get the adoption view: how to position passkeys as both a security and productivity upgrade, what to measure (reset volume, phishing exposure), and how to decide if you’re the one implementing the change or the one sponsoring it. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67730942/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67730942/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that passwords aren’t a behavior problem, they’re an architecture problem. Once you stop trying to train users into impossible habits and instead move to passkeys and WebAuthn, you remove the single point of failure attackers depend on—without making sign‑in more painful for the people you’re trying to protect. https://www.spreaker.com/cms/episodes/67730942/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67730942/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67730942/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365, security and identity consultant and host of the M365.FM podcast, helping organizations treat authentication, devices and cloud apps as one integrated operating system instead of scattered login screens. He works with teams running on Microsoft 365, Azure and modern .NET to design passwordless strategies—using passkeys, WebAuthn and strong device identity—so “just one bad password” stops being the root cause of their biggest incidents. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Microsoft Fabric Changes Everything for BI Pros: Power BI, OneLake, Lakehouse & Real-Time Analytics Explaine | 11 Sep 2025 | 00:20:34 | |
If you’ve been comfortable living inside Power BI, Fabric quietly moved the ground under your feet. Power BI alone is no longer the full story—it’s now just one surface on top of OneLake, pipelines, warehouses, KQL and real‑time analytics. In this episode, we start from the “classic” BI workflow (scheduled refresh, static snapshots, report‑only mindset) and show how Fabric turns you from a visual builder at the end of someone else’s pipeline into someone who can shape data, storage and streaming inside the same ecosystem.https://www.spreaker.com/cms/episodes/67722917/edit/info?filter=NETWORK&network=18613266 We begin with the hidden limits of traditional Power BI: daily refreshes masquerading as “live data,” brittle reports tied to isolated models, and a career path that boxes BI pros into being the last step in the chain. You’ll see how this breaks down once business leaders expect sub‑hourly or real‑time insight, compare you against lakehouse‑centric competitors, and stop accepting “we’ll see it tomorrow morning” as an answer. That pressure is exactly why Microsoft built Fabric—not as a checkbox in Power BI Desktop, but as a unified data platform that pulls lakehouse, warehouse, pipelines, KQL and reporting under one roof.https://www.spreaker.com/cms/episodes/67722917/edit/info?filter=NETWORK&network=18613266 From there, we reframe Fabric: not “one more tool,” but the table Power BI now sits on. We walk through core concepts—OneLake as a single storage foundation, lakehouses and warehouses living next to your reports, dataflows and pipelines replacing scattered ETL, and real‑time analytics that let you query streams instead of waiting for the next refresh. You’ll hear what this looks like in practice for a BI pro: spinning up a Fabric workspace, exploring OneLake, connecting a report directly to a warehouse, and testing your first streaming query without becoming a full‑time data engineer. Finally, we talk career strategy. Staying “just” a report builder risks getting sidelined as others take over architecture and pipeline decisions; learning a handful of Fabric skills—storage concepts, basic pipelines, lakehouse vs warehouse trade‑offs—positions you as the person who can explain to leadership how Microsoft’s new analytics stack actually fits together. You’ll leave with a concrete starting path: how to get Fabric access, which features to test first, and how to talk about those experiments with your stakeholders so they see your role evolving with the platform instead of being left behind by it. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67722917/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67722917/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Fabric turns Power BI from the end of the pipeline into part of a full data platform. If you keep playing only the old report‑builder role, your skills will feel incomplete; if you learn how Fabric’s storage, pipelines and real‑time pieces work, you become the person who connects executive expectations to what the new Microsoft analytics stack can actually deliver. https://www.spreaker.com/cms/episodes/67722917/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67722917/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67722917/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365, Power BI and Fabric consultant and host of the M365.FM podcast, helping organizations treat Power BI, Fabric and OneLake as one integrated analytics operating system instead of isolated tools. He works with teams running on Microsoft 365 and Azure to modernize their BI platforms—bringing reporting, data engineering and governance together so dashboards aren’t just pretty, but built on a Fabric foundation that can scale and handle real‑time demands. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| The Hidden Risks Lurking in Your Cloud: SLAs, Microsoft 365 Outages & How to Build Real Resilience on Your Side | 11 Sep 2025 | 00:18:38 | |
What happens when the software you rely on simply doesn’t show up for work—on the last day of the month, during a critical reporting cycle, or right before a client deadline? A single failed Power App submission or broken Intune policy can leave entire teams locked out, while your service agreements quietly state that the time, money and stress you lose are still your problem. In this episode, we unpack what your cloud SLA really promises (and what it doesn’t), how “bad days” in Microsoft 365 ripple through Outlook, Teams, Intune and Power Apps, and why a few well‑placed mitigations on your side matter more than any status page when things go wrong. We start with the fine print nobody reads. Major cloud platforms position themselves as essential utilities, but their contracts describe them like optional software—best‑effort uptime, limited compensation and almost no responsibility for downstream business impact. You’ll see why that mismatch matters the moment a tenant‑wide issue hits your calendars, mailboxes or app access, and why the question “Who pays for this downtime?” usually has the same uncomfortable answer: you do. Then we zoom in on what it feels like when software has a bad day. We walk through concrete scenarios from the episode text: Power Apps that suddenly stop saving data during end‑of‑month reporting, Intune policies that misfire overnight and lock out devices, approvals that freeze mid‑workflow, and Teams authentication glitches that block entire departments. You’ll recognize the pattern: employees are ready to work, but invisible dependencies—identity, policy, automation—quietly fail and strand them. From there, we map the hidden web of dependencies under Microsoft 365: identity services like Entra handling sign‑ins, shared infrastructure behind Exchange and Teams, and downstream workflows in SharePoint, Power Apps and Intune that all assume the same backbone is healthy. We explain why a failure in one core service can cascade into others, why status dashboards only tell part of the story, and how to identify your few “domino” services that deserve extra resilience planning. Finally, we move to practical mitigation. Instead of relying solely on vendor recovery, we outline steps you can control: lightweight fallbacks for critical processes (like exports or parallel capture paths), clarity on which services are allowed single points of failure, and simple checklists that help leaders react faster when outages hit. The goal isn’t to eliminate risk—that’s impossible—but to make sure one bad day in the cloud doesn’t automatically become a crisis for your business.https://www.spreaker.com/cms/episodes/67714774/edit/info?filter=NETWORK&network=18613266 WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67714774/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67714774/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that cloud outages are not a question of if but when—and the contracts almost always place the real impact on you, not the provider. Once you accept that shared‑responsibility model and design your own safety nets around the few services everything else depends on, you stop treating incidents as pure bad luck and start treating them as scenarios you’ve already planned for. WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67714774/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67714774/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and cloud governance consultant and host of the M365.FM podcast, helping organizations treat Microsoft 365, identity, devices and line‑of‑business apps as one integrated operating system instead of disconnected services. He works with teams running on Microsoft 365 and Azure to design resilience, continuity and incident‑response playbooks so that when critical cloud services have a bad day, the business doesn’t have to stop with them. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Azure CLI vs PowerShell: Which Tool Should You Use for Reliable Azure Automation? | 10 Sep 2025 | 00:20:07 | |
Clicking through the Azure portal works for one‑off fixes, but it falls apart when you need repeatable, reliable changes across multiple environments. In this episode, we take your real‑world pain—late‑night portal tweaks, configuration drift, and “it worked in staging” moments—and turn it into a practical automation strategy with Azure CLI and PowerShell.https://www.spreaker.com/cms/episodes/67704978/edit/info?filter=NETWORK&network=18613266 We start with the trap of the portal: why manual changes are slow, hard to undo, and a major source of outages once dev, test and prod begin to drift. From there, we look at Azure CLI and Azure PowerShell side by side so you can see where each shines: CLI for concise, JSON‑driven commands that drop neatly into pipelines; PowerShell for rich object handling when you need to filter, transform and report across many resources. Then we tackle the “either/or” question. You’ll learn how to choose the right tool for the job without locking yourself into a single camp, and how to wrap az commands inside PowerShell to get the best of both worlds—fast, scriptable actions with powerful post‑processing. Along the way, we walk through examples like replacing a common portal task with a two‑minute script, and show how combining CLI and PowerShell helps you avoid configuration drift altogether. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67704978/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67704978/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that the real “winner” isn’t Azure CLI or PowerShell in isolation—it’s the combination that replaces fragile portal clicks with scripts you can run, review and repeat. Once you treat the portal as a learning and inspection tool, and CLI/PowerShell as your default way of changing Azure, you dramatically cut down on outages caused by human error and configuration drift. https://www.spreaker.com/cms/episodes/67704978/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67704978/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67704978/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and Azure automation consultant and host of the M365.FM podcast, helping organizations trade fragile portal clicks for scripted, repeatable infrastructure. He works with teams running on Azure and Microsoft 365 to design governance, scripting and automation strategies so critical environments can be changed—and recovered—with confidence instead of guesswork. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Agentic AI Is Rewriting DevOps: How AI Agents Transform .NET, Azure Pipelines and Developer Productivity | 10 Sep 2025 | 00:22:24 | |
What if your DevOps team gained a tireless new teammate who understands your entire stack, remembers every decision, and quietly handles the grunt work in the background? That’s what Agentic AI promises: a shift from simple autocomplete to coordinated AI agents that plan, adapt and collaborate across code, infrastructure and pipelines. In this episode, we unpack what makes Agentic AI different from today’s tools, how it reshapes .NET and Azure workflows, and one realistic experiment you can run in your own pipeline this week.https://www.spreaker.com/cms/episodes/67697666/edit/info?filter=NETWORK&network=18613266 We start with what truly sets Agentic AI apart: persistent context, memory and goal‑orientation. Unlike autocomplete that forgets each suggestion, agents keep track of your project’s structure, past attempts and current objectives, acting more like a junior developer who learns over time. Then we look at how multiple agents collaborate like a real team—one focused on architecture, another on code review, a third on test coverage—so the heavy, repetitive work stops landing on human shoulders alone. From there, we draw a clear line between traditional automation and adaptive autonomy. Scripts and CI/CD pipelines follow rigid steps and break when conditions change; agents can re‑plan when dependencies shift, costs change or constraints appear mid‑flight. The outcome isn’t fully hands‑off deployments, but fewer tedious interventions and earlier warnings about risky decisions, long before they reach production. Next, we zoom into a concrete .NET scenario. You’ll hear how agents transform the earliest phases of a project: suggesting architecture patterns for your specific use case, wiring authentication, logging and pipelines, and offering ongoing critique as code evolves. We walk through a simple experiment—using Copilot‑style agents on a small ASP.NET Core service—to compare how fast you reach “first meaningful endpoint” with and without AI support. Finally, we connect Agentic AI to DevOps and infrastructure. Once agents can see beyond code into Azure resources and pipelines, they stop being just coding helpers and become collaborators in provisioning, monitoring and operations. You’ll learn how to frame these tools inside your team: as always‑on partners that handle scaffolding, checks and repetitive tasks, while humans stay in charge of guardrails, strategy and the decisions that really shape your systems. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67697666/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67697666/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Agentic AI doesn’t just speed up snippets—it adds a new kind of teammate that remembers context, coordinates work and adapts when conditions change. Once you treat agents as part of your DevOps team, not just a coding plugin, you unlock a different kind of productivity: fewer manual setups, earlier detection of problems and more time for the creative parts of engineering. https://www.spreaker.com/cms/episodes/67697666/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67697666/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67697666/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365, Azure and DevOps consultant and host of the M365.FM podcast, helping organizations treat AI agents, infrastructure and applications as one integrated delivery system instead of disconnected tools. He works with teams running on .NET and Azure to design practical, guardrail‑first Agentic AI strategies so that automation boosts reliability and developer focus instead of adding opaque complexity to their pipelines.https://www.spreaker.com/cms/episodes/67697666/edit/info?filter=NETWORK&network=18613266 Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Did Mainframes Just Win? How Altair, Terminals and Shared Compute Explain Azure and Modern Cloud Design | 09 Sep 2025 | 00:20:22 | |
In 1975 you programmed an Altair 8800 by flipping switches and watching LEDs; in 2025 you click once and Azure spins up global infrastructure, AI models and multi‑tenant services in seconds. The surface looks completely different, but the underlying ideas—shared resources, programmable access, centralized capacity—never really went away. In this episode, we use the story of the Altair and classic mainframes to show how those same patterns now shape Microsoft 365, Power Platform and Azure, and how understanding them makes you better at cost optimization, automation and architecture today.https://www.spreaker.com/cms/episodes/67692646/edit/info?filter=NETWORK&network=18613266 We start with the Altair box of switches, because it forces you to see computing without any abstractions. With only a tiny amount of memory and a row of toggles, every bit mattered and every instruction was deliberate, creating a discipline that today shows up in how you size cloud resources, design flows and avoid waste. The Altair also represented a power shift: for the first time, individuals could own a computer instead of begging for time on a centralized mainframe, even if that “computer” was brutally limited by modern standards. You’ll hear how that mindset of control and transparency—seeing state directly, tracing output back to exact inputs—maps onto modern tools like APIs, CLIs and low‑code platforms, where the most effective builders still think like architects working under constraints. Then we zoom out to the patterns that refused to die. Classic mainframes ran as shared pools of compute in locked rooms; your terminal was just a window into that one precious resource. Today, Azure looks like the opposite—frictionless, on‑demand scale—but the model is strikingly familiar: multi‑tenant capacity, centralized orchestration and workload scheduling behind the scenes. We explore why the industry keeps returning to centralization (cost, efficiency, flexibility), how this shapes everything from Microsoft 365 throttling to Azure resource limits, and what it means for the way you design solutions that live inside a shared cloud rather than on “your” hardware.https://www.spreaker.com/cms/episodes/67692646/edit/info?filter=NETWORK&network=18613266 From there, we talk about the quiet renaissance of the terminal and text‑based interfaces. Even with rich portals and AI copilots everywhere, serious work in Azure and Microsoft 365 keeps falling back to CLIs, shells and APIs—because they offer speed, repeatability and automation that visual tools can’t match. You’ll see how a terminal window in 2025 has more in common with a 1970s terminal than with a modern dashboard: clear commands in, precise responses out, no distraction. We connect that to practical workflows in your own environment: replacing fragile portal clicks with scripts, using APIs as the “toggle switches” of today, and treating automation as the default instead of the upgrade.https://www.spreaker.com/cms/episodes/67692646/edit/info?filter=NETWORK&network=18613266 Finally, we bring it back to your day‑to‑day decisions in Microsoft 365, Power Platform and Azure. Once you see that the same old patterns—centralized capacity, shared infrastructure, constrained resources—are still with us, it becomes much easier to reason about cost, resilience and performance. You’ll walk away with a set of questions and mental models that help you design tenant governance, app architectures and automations that respect the realities of the shared cloud you’re actually running on, instead of the illusion of infinite, isolated power. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67692646/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67692646/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that cloud computing didn’t kill the mainframe; it generalized it. The sooner you think in terms of shared pools, constraints and programmable access—like the early Altair and mainframe pioneers did—the easier it becomes to build cloud systems that are efficient, resilient and understandable instead of magical black boxes. https://www.spreaker.com/cms/episodes/67692646/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67692646/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67692646/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and Azure architecture consultant and host of the M365.FM podcast, helping organizations treat history’s computing patterns as practical design tools for modern cloud systems. He works with teams on Microsoft 365, Power Platform and Azure to turn vague “cloud is just someone else’s computer” jokes into concrete strategies for optimization, resilience and automation they can explain to both engineers and business leaders.https://www.spreaker.com/cms/episodes/67692646/edit/info?filter=NETWORK&network=18613266 Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Agents vs workflows in Copilot: how to use Power Automate and Copilot Studio agents without losing governance | 27 Oct 2025 | 00:23:49 | |
Agents vs workflows in Copilot: in this episode of M365.fm, Mirko Peters explains why you cannot lump a Copilot Studio agent and a Power Automate workflow into the same “AI automation” bucket—and why that confusion creates chaos once money, compliance, and customers are involved. He draws a clear line between deterministic flows that follow fixed steps and probabilistic agents that pursue goals, use tools, and keep acting as long as their charter allows. Mirko starts by defining the autonomous agent in Copilot Studio: a goal‑seeking system with its own reasoning layer (“generative orchestration”), a toolbox of connectors and actions, and the ability to choose which tool to use next based on context, not just hard‑coded order. You’ll learn how agents interpret messy instructions, decompose them into sub‑tasks, and decide whether they can safely complete an action—behaving more like a junior analyst who needs supervision than like a script that needs configuration. He shows why this autonomy demands ongoing oversight, correction, and monitoring, not just initial design.https://www.spreaker.com/cms/episodes/68293509/edit/info?filter=NETWORK&network=18613266 He then contrasts that with traditional Power Automate workflows as obedient but narrow state machines. Workflows wake up when a trigger fires, execute a predefined sequence of conditions and actions, and then go back to sleep with zero curiosity or memory. Mirko explains how their strength is predictability: you can read the designer and know exactly what will happen, which makes them highly auditable and COE‑friendly—but also brittle when reality deviates from the original decision tree or multiple flows collide on the same data.https://www.spreaker.com/cms/episodes/68293509/edit/info?filter=NETWORK&network=18613266 The episode dives into the first core difference: dynamic decision‑making vs static sequencing. Agents adjust their plans based on current data and tools, like navigation that reroutes around traffic; workflows follow the same “route” every time, even if a metaphorical truck is blocking the road. Mirko shows how this plays out in real scenarios—claims processing, approvals, or customer operations—where an agent might refuse or adapt a task, while a flow charges ahead into failure unless every edge case was anticipated in advance.https://www.spreaker.com/cms/episodes/68293509/edit/info?filter=NETWORK&network=18613266 Throughout the conversation, Mirko argues that you do not choose between agents and workflows—you combine them. Workflows handle strict, repeatable orchestration; agents interpret intent, orchestrate tools, and handle ambiguity. The real maturity step in Power Platform is learning when you need rule execution and when you need supervised reasoning, and designing architectures, governance, and monitoring that treat agents less like flows with prompts and more like digital coworkers with real power.https://www.spreaker.com/cms/episodes/68293509/edit/info?filter=NETWORK&network=18613266 WHAT YOU WILL LEARN
A workflow is a vending machine; an agent is a junior employee. Treating them as the same thing turns Copilot from a controlled automation platform into a playground of unsupervised digital toddlers—use workflows for rule execution, agents for goal‑driven reasoning, and design your governance around that split. https://www.spreaker.com/cms/episodes/68293509/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FOR This episode is ideal for Power Platform architects, COE teams, automation leads, and Copilot Studio builders who are deciding where to use agents, where to use workflows, and how to combine them safely. It is especially valuable if your organization is starting to give agents access to real data and actions and you need a clear mental model to avoid turning “AI automation” into an ungoverned mess. https://www.spreaker.com/cms/episodes/68293509/edit/info?filter=NETWORK&network=18613266ABOUT THE HOST Mirko Peters is a Microsoft 365 and Power Platform consultant focused on building governed, scalable automation platforms with Power Automate, Copilot Studio, Dataverse, and Microsoft 365. Through M365.fm, he shares practical agent‑and‑workflow patterns, governance stories, and architecture models that help organizations use autonomous agents without losing control of behavior, risk, and compliance. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Azure Solutions Break Under Pressure: How to Design Resilient, Highly Available Workloads That Survive Real‑World Load | 09 Sep 2025 | 00:18:38 | |
Ever had Azure look healthy in the portal while your most important workload quietly fails during payroll, end‑of‑month reporting or Monday‑morning logins? In this episode, we unpack why so many Azure solutions only collapse under real‑world pressure: design shortcuts, weak scaling rules, hidden dependencies and architectures that were never truly tested at production load. You’ll see how incidents that get blamed on “Azure being down” are often rooted in fragile foundations—single points of failure, misconfigured autoscale, or untested failover paths—and why backups and DR can’t save you from the damage that happens in the live moment users need your service most. From there, we follow the money to the real cost of downtime. We talk about more than error graphs: lost transactions that never come back, customers who don’t retry after a failed experience, and leadership pulled into crisis mode while engineers juggle firefighting and status updates. You’ll learn why even short outages create lasting reputational and revenue damage, how recovery plans protect infrastructure but not trust, and why “it was only 15 minutes” is rarely the full story when your busiest hour of the year is the one that broke.https://www.spreaker.com/cms/episodes/67684642/edit/info?filter=NETWORK&network=18613266 Then we get practical and walk through the five foundational principles of resilient Azure design: Availability, Redundancy, Elasticity, Observability and Security. We translate them into concrete patterns—zones and regions, cross‑region workloads, correctly tuned autoscale, real observability instead of just pretty dashboards, and guardrails that prevent small misconfigurations from turning into major incidents. By the end, you’ll know one simple ten‑minute check you can run against your own environment to see whether you’ve built on solid ground or are one traffic spike away from your next “mysterious” outage.https://www.spreaker.com/cms/episodes/67684642/edit/info?filter=NETWORK&network=18613266 WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67684642/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67684642/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Azure doesn’t magically make systems resilient—you do. Once you treat resilience as a design responsibility, not a recovery script, you stop being surprised when traffic spikes or Monday‑morning usage hits, because your Azure solutions are built to stay up exactly when the business needs them most. https://www.spreaker.com/cms/episodes/67684642/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67684642/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67684642/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and Azure resilience consultant and host of the M365.FM podcast, helping organizations turn fragile cloud workloads into dependable services that hold up under real business pressure. He works with teams running on Azure and Microsoft 365 to design availability, scaling and observability into their solutions from day one—so incidents become rare edge cases instead of regular Monday‑morning surprises.https://www.spreaker.com/cms/episodes/67684642/edit/info?filter=NETWORK&network=18613266 Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Full‑Stack Skills in Microsoft Teams: How React and Node Developers Build Personal Tabs with Teams Toolkit and Dev Portal | 08 Sep 2025 | 00:19:18 | |
You’ve been building full‑stack apps for years—React frontends, Express backends, APIs, auth flows—but those same skills often stop at the browser tab. In this episode, we look at why so many developers assume “Teams development” means a brand‑new stack, and show you how little you actually need to change to make your existing web app feel native as a personal tab in Microsoft Teams. You’ll learn how to treat Teams as a host, not a parallel universe: keep your React or Node app as‑is, then layer on just enough manifest, auth and routing configuration so it runs smoothly inside the Teams client instead of being abandoned in a side repo. We start with the real blocker: perception. Teams docs talk about manifests, app registrations, sideloading and the Developer Portal, which makes everything sound like a separate, complex platform—even though underneath it’s still your familiar stack serving HTML, JS and JSON. You’ll hear why developers walk in confident, hit those setup screens, and quietly back away—not because they lack skills, but because onboarding friction is high and the mental model is unclear. Once you reframe Teams as “just another host” for your existing React/Express project, those intimidating steps shrink down to what they really are: config, metadata and a slightly different way of pointing to the app you’ve already built.https://www.spreaker.com/cms/episodes/67677986/edit/info?filter=NETWORK&network=18613266 Then we move into concrete setup. With VS Code, Node/npm and your usual React or Express project in place, we show how the Teams Toolkit and Developer Portal take over the repetitive work: scaffolding the manifest, configuring local tunneling and wiring your localhost URL into a personal tab definition. You’ll understand what actually happens when your app appears in Teams—a running web server, an iframe, and a manifest that ties them together—and why you don’t need to swap out React Router, refactor your APIs or adopt a special “Teams framework” to get there. Instead, you keep your development loop exactly the same (npm start, edit components, hit your endpoints) and simply view the result inside the Teams sidebar instead of a standalone browser tab.https://www.spreaker.com/cms/episodes/67677986/edit/info?filter=NETWORK&network=18613266 Finally, we zoom in on the personal tab use case and how it connects to the rest of Microsoft 365. You’ll see when a personal tab is the right first step (dashboards, personal productivity tools, single‑user utilities), where Power Platform might be a better fit, and how to think about permissions, OAuth and Entra ID so sign‑in works cleanly for your users. By the end, you’ll have a clear, minimal checklist for turning “just another web app” into a Teams app your users can pin, open and rely on daily—without changing the way you build full‑stack solutions today. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67677986/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67677986/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Microsoft Teams isn’t asking you to become a different kind of developer—it’s asking you to point the full‑stack skills you already have at a new surface. Once you see Teams as a host for your existing React and Node apps, not a parallel stack, the barrier to shipping useful personal tabs drops from “learn a new platform” to “add a bit of config and keep coding the way you always have.” https://www.spreaker.com/cms/episodes/67677986/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67677986/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67677986/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and Teams development consultant and host of the M365.FM podcast, helping organizations bring their existing full‑stack skills into the Microsoft 365 ecosystem instead of treating Teams as a separate, harder platform. He works with teams using React, Node and Power Platform to design practical Teams apps—from personal tabs to deeper integrations—so they can meet users where they already work without rewriting their architecture from scratch.https://www.spreaker.com/cms/episodes/67677986/edit/info?filter=NETWORK&network=18613266 Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Why Disabling Power Platform Backfires: Shadow IT, Data Leakage and How to Build Secure Governance Instead | 08 Sep 2025 | 00:17:51 | |
If your first instinct when you hear “Power Platform” is to hit the disable switch in the admin center, you’re not alone—but that move usually backfires. Turning the platform off creates a false sense of security: dashboards look clean, usage drops, but business demand for apps, automation and quick data workflows doesn’t disappear, it just goes off the grid. In this episode, we unpack why hard blocking Power Platform almost always drives shadow IT, unmanaged data flows and compliance blind spots—and what a secure‑enablement model looks like instead. We start with the illusion of safety that comes from seeing “Power Apps: 0 users” in your reports. When official tools are blocked, people simply move to spreadsheets, personal cloud accounts and third‑party automation like Zapier, Airtable or free SaaS trials to get their work done. You’ll hear real‑world scenarios where invoice approvals, HR tracking or compliance workflows quietly moved into personal Google Sheets and Dropbox folders after Power Platform was restricted—solving the business problem while completely bypassing retention, auditing and DLP. What looked like risk reduction inside the tenant was actually risk relocation into places IT couldn’t see or govern.https://www.spreaker.com/cms/episodes/67670592/edit/info?filter=NETWORK&network=18613266 Then we dig into the governance gaps this creates. Each time data leaves your managed platforms, you lose the ability to enforce lifecycle, apply sensitivity labels, or prove what happened to that information when auditors or regulators start asking questions. We break down how aggressive blocking and license removal drive exactly this pattern, why “no license” doesn’t equal “no exposure,” and how mixed signals in Microsoft 365 (buttons and entry points still visible, but blocked at runtime) frustrate users into routing around IT. By the time a security team notices, critical records may have lived for months in personal accounts outside your control. Finally, we outline what to do instead of disabling the platform. You’ll learn the core elements of a secure‑enablement approach: clear guardrails and environments, DLP and connector policies, approved templates, and a simple intake path for business‑critical apps that need extra care. We walk through how to combine controlled access, licensing strategy and visibility so you steer makers into safe lanes rather than blocking the road entirely. The goal isn’t to unleash everything; it’s to channel Power Platform usage into governed spaces where you can monitor, protect and support it—before shadow IT and data leakage become your default. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67670592/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67670592/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that you don’t control risk by turning Power Platform off—you control it by giving people a governed place to build. Once you stop equating “no usage” with safety and instead focus on keeping apps and automations inside your tenant, you trade invisible exposure for visible, manageable activity that security and compliance can actually support. https://www.spreaker.com/cms/episodes/67670592/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67670592/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67670592/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 and Power Platform governance consultant and host of the M365.FM podcast, helping organizations move from “block by default” to secure enablement across low‑code, automation and citizen development. He works with teams on Microsoft 365 and Azure to design environments, policies and guardrails that keep business apps inside the tenant—so innovation happens where security, compliance and IT still have the visibility they need. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Purview vs. Rogue AI: How to Keep Copilot, Compliance and Sensitive Microsoft 365 Data Under Control | 08 Sep 2025 | 00:20:58 | |
Purview vs. Rogue AI: Who’s Really in Control? Imagine rolling out Copilot across your entire workforce—only to discover later that junior staff can surface highly sensitive contracts and financial forecasts with a single prompt. That isn’t a theoretical edge case, it’s one of the most common Copilot risks organizations are facing right now, and the biggest problem is that most leadership teams don’t even realize it’s happening. This episode explores how Copilot quietly flattens old boundaries between documents, mailboxes and sites, why permissions and DLP alone can’t keep up, and how Microsoft Purview becomes the missing control plane that lets you capture AI’s productivity upside without losing oversight. We start with the hidden risk behind “it’s just another button in Word or Teams.” Copilot doesn’t think in terms of single files; it pulls from every SharePoint library, OneDrive folder and mailbox a user can technically access, blending that context into answers that feel natural but may contain details from HR, legal or finance content that person never knew existed. You’ll hear how this breaks the old audit model where you could see exactly which file was opened, and why AI‑generated summaries make it harder to prove to regulators, auditors and security teams what was actually used. That’s where Purview’s content‑level governance comes in: classification, sensitivity labels and policies that travel with the data itself instead of relying only on perimeter controls.https://www.spreaker.com/cms/episodes/67670602/edit/info?filter=NETWORK&network=18613266 From there, we show what oversight really looks like in a Copilot world. Purview gives you the tools to define which kinds of content can influence AI responses, how sensitive documents should be labeled and protected, and where encryption, access restrictions or watermarks must apply before Copilot ever sees the data. Rather than trying to retrofit old DLP rules onto AI traffic, you learn how to embed rules into the files—finance forecasts, HR records, contracts—so that Microsoft 365 services, including Copilot, treat them differently by design. We walk through a pragmatic rollout: starting with your highest‑risk libraries, validating label behavior, and progressively expanding coverage so you can prove your guardrails work instead of trusting blind configuration. Finally, we tackle the accountability question: can you reconstruct what Copilot actually touched when something goes wrong? We discuss how today’s logging and auditing gaps make it hard to answer that confidently, why “Copilot operated within permissions” isn’t enough for regulated industries, and which Purview capabilities help you regain traceability over sensitive data as AI enters everyday workflows. The goal isn’t to slow Copilot down or turn it off—it’s to make sure that when AI accelerates your organization, it does so with transparent, governed access to information instead of hidden shortcuts that only show up during an incident review. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67670602/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67670602/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Copilot without Purview doesn’t just increase risk—it hides it. Once you treat content classification and AI oversight as part of your core compliance strategy, not an afterthought, you can let Copilot accelerate everyday work while still proving to auditors, regulators and leadership where sensitive data lives, how it’s used and who is really in control. https://www.spreaker.com/cms/episodes/67670602/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67670602/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67670602/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 security and governance consultant and host of the M365.FM podcast, helping organizations bring AI assistants like Copilot under the same disciplined oversight they expect for email, documents and collaboration. He works with teams running on Microsoft 365, Purview and Entra ID to design classification, labeling and monitoring strategies so “rogue AI” behavior turns into governed AI that compliance and security teams can actually support. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Your MIP Rollout Is Broken: How to Fix Microsoft Information Protection Labels, Governance and User Adoption in Microsoft 365 | 07 Sep 2025 | 00:19:03 | |
You rolled out Microsoft Information Protection, the labels are live, and the policies tick every compliance box—but day‑to‑day behavior hasn’t changed. Files are still overshared, people ignore labels, and the only ones who understand the setup are the admins who built it. In this episode, we break down why so many MIP projects only look secure in the portal and give you five practical checks to see whether your rollout will quietly fail or finally stick. We start with the most common trap: MIP as a label catalog with no clear purpose. If you can’t explain in one sentence which concrete business risk your labels are supposed to reduce—privacy exposure, IP leakage, accidental external sharing—your rollout is already off course. You’ll hear why long, beautifully color‑coded taxonomies collapse the moment real users have to choose between twenty similar options, and how organizations that succeed start from risk and keep their first set of labels brutally simple: a handful of categories tied directly to privacy, internal‑only information and sensitive IP. From there, we dive into the technical rabbit hole that derails even well‑intentioned projects. It’s easy to treat MIP like an engineering playground: complex sub‑labels, department‑specific encryption, every integration switch turned on. That setup looks impressive in the compliance portal but leaves employees stuck in endless drop‑downs, blocked from their own documents or tempted to strip labels just to get work done. We show why over‑engineering your taxonomy creates more risk than it removes, and share a practical rule of thumb: if a user needs more than a couple of clicks or a long explanation to pick the right label, you’ve designed for admins, not for real work. Then we tackle the human resistance factor. Most rollouts underestimate how disruptive “just one more prompt” can feel in Outlook, Teams or Office when people are under time pressure. If users experience MIP as friction with no clear upside, they default to the easiest option, fight the controls, or route around them entirely—moving files to unmanaged locations where no labels or policies apply. You’ll learn how to flip that script: anchor labels in everyday scenarios, link them to real consequences (good and bad), and design training that feels like help, not extra bureaucracy. Finally, we connect all of this to pilots, training and long‑term ownership. Weak pilots that only involve IT create false confidence; you need business teams, skeptics and real workloads in the test to see where labels break. Terrible training—slide decks about features instead of risk‑based stories—finishes the job of disconnecting MIP from reality. We walk through a better pattern: start with risk and purpose, design a minimal label set, pilot with real teams, iterate based on feedback, then roll out with training that shows people how MIP actually protects their work, not just the organization’s compliance posture. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67664577/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67664577/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Microsoft Information Protection doesn’t fail because the technology is weak—it fails when labels, policies and training are built in isolation from real risk and real users. Once you start from business risk, keep the design simple and treat adoption as a behavior change project, MIP shifts from being window dressing for auditors to a living system people actually use to protect what matters. https://www.spreaker.com/cms/episodes/67664577/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67664577/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67664577/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 security and governance consultant and host of the M365.FM podcast, helping organizations turn Microsoft Information Protection from a checkbox project into a practical, behavior‑driven protection layer across documents, email and collaboration. He works with teams on Microsoft 365, Purview and Entra ID to design label taxonomies, policies and training that start with business risk and end with real‑world adoption—so “we rolled out MIP” actually means data is safer, not just more colorful. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Teams Admins Are Missing This Hidden Layer: Microsoft 365 Groups, SharePoint Sites & The Real Impact Of Creating A Team | 07 Sep 2025 | 00:20:35 | |
Most Teams admins think they’re just managing channels and permissions, but every “create Team” click quietly provisions a full Microsoft 365 collaboration stack behind the scenes—group object, SharePoint site, mailbox, calendar, Planner, and more. In this episode, we unpack that hidden layer and show how a single Team triggers a chain reaction across Entra ID, Groups, SharePoint, and Exchange, which is why tiny changes often cause “random” side effects somewhere else in Microsoft 365. You’ll learn how to visualize this ripple effect, how to audit what gets created alongside a Team, and how to adjust roles and policies without accidentally breaking storage, access, or compliance. THE RIPPLE EFFECT OF CREATING A TEAM https://www.spreaker.com/cms/episodes/67664576/edit/info?filter=NETWORK&network=18613266When you click “create a Team,” you’re not just opening a chat space—you’re kicking off a domino effect across Microsoft 365. Behind that one action, a Microsoft 365 Group is created, a SharePoint site is provisioned, membership is written into Entra ID, an Exchange mailbox and calendar appear, and private channels can even spin up additional SharePoint sites. We walk through real examples of how simple changes—like adding private channels or tweaking membership—turn into new sites, folders, and storage locations that admins later discover as “mystery” objects in their tenant. Once you see Teams as a façade on top of this connected stack, permission shifts, storage sprawl, and strange behavior stop looking random and start making architectural sense. GROUPS: THE HIDDEN PUPPET MASTER https://www.spreaker.com/cms/episodes/67664576/edit/info?filter=NETWORK&network=18613266Under the hood, Microsoft 365 Groups are the puppet masters tying Teams, SharePoint, Exchange, and Entra ID together. We explain how each Team is anchored to a Group that controls membership, ownership, and access across linked services, and why ignoring Group lifecycle quickly leads to ghost owners, ex‑employees with access, and inconsistent permissions. You’ll learn three essential Group hygiene checks: ensuring every Group has active owners, regularly reviewing membership (especially externals), and enforcing expiry/lifecycle policies so Groups—and their connected Teams and sites—don’t live forever without oversight. Treating Groups as the backbone instead of noise gives you a stable foundation for Teams governance. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67664576/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67664576/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that creating a Team is never “just” adding a workspace—it’s deploying an entire collaboration stack in one move. If you treat Teams as a standalone app, you’ll constantly chase “random” issues; once you see the hidden Group, SharePoint, Exchange, and Entra layers, you can design roles, policies, and cleanup routines that keep the whole system predictable. https://www.spreaker.com/cms/episodes/67664576/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67664576/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67664576/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 consultant and host of the M365.FM podcast, helping organizations treat Teams, Groups, SharePoint, and Entra ID as one integrated operating system instead of disconnected admin centers. He works with teams running on Microsoft 365 and Azure to design governance, provisioning, and lifecycle models so that every new Team comes with intentional ownership, storage, and access—rather than surprise sprawl six months later. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Why Copilot Fails Most Businesses: Data, Adoption and Use Cases You Need for Real Productivity in Microsoft 365 | 07 Sep 2025 | 00:17:47 | |
Copilot didn’t fail you—your environment, data and rollout plan did. Most organizations flip the switch, expect instant productivity, and then quietly conclude “it doesn’t work here” when nothing meaningful changes. In this episode, we unpack why Copilot stalls after the initial excitement, how messy data and weak use cases destroy trust, and what a grounded, four‑phase adoption model looks like when you actually want measurable ROI instead of a flashy demo.https://www.spreaker.com/cms/episodes/67659452/edit/info?filter=NETWORK&network=18613266 We start with the Instant Productivity Myth: the belief that adding Copilot to Word, Outlook or Teams will automatically double output. In reality, week one looks almost identical to the week before—emails still take time, reports still rely on manual hunting, and staff revert to old habits after a few playful prompts. You’ll hear why this happens in almost every rollout: Copilot gets launched like a feature, not onboarded like a new colleague with clear responsibilities, training and access to the right information. The core message: without structure and expectations, Copilot becomes optional, and optional tools never drive organization‑wide productivity. From there, we go to the forgotten prerequisite: data. Copilot can’t produce reliable answers if it’s swimming in outdated documents, duplicate versions and scattered storage across SharePoint, Teams, email and file shares. We walk through how this plays out in practice—conflicting numbers in summaries, out‑of‑date project status in recaps, and confident‑sounding but wrong outputs that quietly erode trust. Rather than blaming the AI, you’ll learn how to treat data cleanup, sources of truth, taxonomy and lifecycle rules as the foundation that makes Copilot worth using. Once those basics are in place, answers stop feeling like guesses and start feeling like real acceleration.https://www.spreaker.com/cms/episodes/67659452/edit/info?filter=NETWORK&network=18613266 Next, we tackle use cases that miss the mark. Many pilots focus on low‑impact scenarios—nicer email drafts, slightly faster meeting notes—that are impressive on screen but irrelevant when you look at cost and time saved. We show why you need to aim Copilot at processes with real weight: recurring reports, compliance documents, repetitive intake, documentation nobody has time to maintain. You’ll get a practical way to rank potential use cases by impact and feasibility, so you can identify the first three that will actually move the needle instead of producing yet another “cool demo” with no follow‑through. Finally, we outline a four‑phase model you can reuse: Prepare, Pilot, Prove, Scale. Prepare focuses on data readiness, basic guardrails and clear success metrics; Pilot means targeted teams and specific workflows, not a vague “everyone, try it.” Prove is where you measure outcomes against baseline and refine prompts, processes and training; Scale is when you expand to new groups with patterns that already worked, instead of reinventing the rollout every time. By the end, you’ll have a concrete playbook to rescue a stalled Copilot deployment—or design your first one so it delivers visible value instead of quietly fading into the toolbar.https://www.spreaker.com/cms/episodes/67659452/edit/info?filter=NETWORK&network=18613266 WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67659452/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67659452/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Copilot isn’t a magic productivity button—it’s a force multiplier for organizations that prepare their data, processes and people. Once you treat Copilot like a new team member that needs clean inputs, clear responsibilities and measurable goals, you move from “nice feature” to a practical engine for better work across your Microsoft 365 environment. https://www.spreaker.com/cms/episodes/67659452/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67659452/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67659452/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365, Copilot and digital workplace consultant and host of the M365.FM podcast, helping organizations turn AI assistants from shiny experiments into measurable productivity tools. He works with teams on Microsoft 365, Power Platform and Azure to design Copilot strategies that start with data readiness and real use cases—so AI augments existing work instead of becoming another unused icon in the ribbon. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Copilot Connectors: The Missing Link That Turns Microsoft 365 BizChat into a Real Business Copilot | 06 Sep 2025 | 00:19:17 | |
Most teams expect Microsoft 365 BizChat to act like a strategic copilot—but without connectors into your core systems, it’s effectively working half‑blind. Out of the box, BizChat can only see what lives in Outlook, Teams, OneDrive and SharePoint, so every time someone asks about pipeline, invoices or project status, it has to guess based on emails and files instead of real CRM, ERP or project data. In this episode, we walk through why that gap quietly kills trust and adoption, and how building the right Copilot connectors turns BizChat from a nice assistant into a decision‑grade copilot that actually knows your business. We start with what “half‑blind” really looks like. A sales manager asks about current pipeline, but without CRM access BizChat returns vague summaries instead of accurate numbers. A finance lead asks about outstanding invoices, but without ERP integration the answer is empty or incomplete. A project manager asks for upcoming deadlines, but without a connection to the project system, BizChat shrugs. Each time, someone has to jump into the real app, copy figures back into the chat and explain the discrepancy—slowly teaching the whole organization that BizChat can talk, but not truly see. Then we draw a clear line between “assistant mode” and “copilot mode.” In assistant mode, BizChat only rephrases what’s already visible in Microsoft 365: emails, documents, chat logs. In copilot mode, it can reach into systems of record—CRM, ERP, ticketing, project tools—under strict permissions and return answers that are grounded in live transactional data. We give you a simple test: does BizChat have controlled access to your key business systems, respect role‑based security when it queries them, and return responses that directly drive decisions instead of sending people elsewhere to double‑check? If the answer is no, you’re not using a copilot yet—you’re using a clever assistant. From there, we focus on integration strategy: choosing the right systems to connect first, and deciding whether to go no‑code, low‑code or full pro‑code. You’ll learn how to identify the few data sources that will change day‑to‑day work the most—often CRM for revenue, ERP for cash and inventory, and one project or ticket system for delivery. We walk through how Copilot connectors, APIs and Teams Toolkit fit together so you can start small: one high‑value integration that proves the concept, then a pattern you can repeat without turning everything into a massive engineering project. The goal is impact, not a wall of connectors nobody uses.https://www.spreaker.com/cms/episodes/67656260/edit/info?filter=NETWORK&network=18613266 Finally, we show what “BizChat with connectors” actually feels like for your users and leaders. Instead of bouncing between BizChat and dashboards, staff can ask a question once and get answers that match the numbers in your source systems. Conversations include live metrics, approvals and trends, not just summaries of old PPTs and email threads. Over time, that reliability changes behavior: people start with BizChat because it saves them real time and context‑switching, and leadership sees faster, better‑supported decisions instead of AI‑generated noise. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67656260/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67656260/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that BizChat doesn’t become a real copilot by getting smarter prompts—it becomes one when you give it secure, structured access to the systems where your business actually lives. Once you treat connectors as the missing link between conversation and source of truth, BizChat stops producing generic commentary and starts delivering answers you can act on without leaving the chat. https://www.spreaker.com/cms/episodes/67656260/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67656260/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67656260/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365, Copilot and integration consultant and host of the M365.FM podcast, helping organizations turn BizChat from a generic chat interface into a connected copilot that understands their actual systems. He works with teams on Microsoft 365, Power Platform and Azure to design connector strategies and app extensions so AI can see the same data people use for real decisions—without compromising permissions, security or governance.https://www.spreaker.com/cms/episodes/67656260/edit/info?filter=NETWORK&network=18613266 Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Your Team‑Building Is Broken: How Minecraft Missions Create Real Collaboration, Engagement and Better Team Events | 06 Sep 2025 | 00:20:19 | |
What if your next team‑building session didn’t feel like forced small talk or awkward trust falls, but like a real mission everyone actually wants to join? In this episode, we show why most classic workshops fail to change anything after the catering is cleared away—and how a simple Minecraft challenge can create genuine collaboration, shared problem‑solving and lasting team stories instead of eye‑rolling.https://www.spreaker.com/cms/episodes/67655533/edit/info?filter=NETWORK&network=18613266 We start with the uncomfortable truth: many corporate team‑building days are activity for activity’s sake. People answer shallow icebreakers, shuffle through scripted games and walk away wondering what, if anything, changed about how they work together. There’s no progression, no real stakes and no sense of achievement, so the brain never switches into engagement mode. In contrast, a well‑designed Minecraft scenario—like a treasure hunt, base defense or puzzle mission—automatically adds progression, feedback loops and authentic challenges that teams must tackle together to succeed. Then we explain what’s happening inside the game that traditional exercises miss. Roles emerge organically as some teammates explore, others build and others puzzle‑solve; nobody has to assign responsibilities from a flip chart. The environment makes experimentation safe—failure just means you regroup and try again—so people take risks, iterate and communicate more naturally. Immediate feedback (blocks placed, puzzles unlocked, goals reached) keeps motivation high and makes collaboration feel meaningful instead of artificial. Those patterns—self‑organization, rapid iteration, real‑time communication—map directly back to everyday project work.https://www.spreaker.com/cms/episodes/67655533/edit/info?filter=NETWORK&network=18613266 Finally, we walk through how to run your first Minecraft team challenge without needing a dev team or weeks of preparation. You’ll learn how to pick a simple scenario, set clear goals, and frame the exercise so participants instantly understand why they’re there and what “success” looks like. We also cover how to debrief in a way that doesn’t kill the fun: connect in‑game moments to real collaboration habits, highlight positive behaviors and pull out insights teams can apply at their desks the next day. The result is a modern team‑building format where people don’t just talk about teamwork—they live it, remember it, and actually want to do it again. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Copilot Settings Microsoft Won’t Explain: Hidden Web Access, Licensing Pitfalls and Governance Controls in Microsoft 365 | 06 Sep 2025 | 00:21:16 | |
Copilot isn’t just a shiny toggle—it’s a constantly changing mix of permissions, plugins and licenses that can quietly open gaps in control if you don’t stay on top of the settings Microsoft barely mentions. In this episode, we walk through the hidden switches that decide what Copilot can see, which users get real value, and where your governance story silently breaks: web access controls, licensing landmines, browser limitations, Loop and DLP blind spots, and the early foundations you need for future Copilot agents. We start with the web access switch, the small setting that has an outsized impact on how Copilot behaves. Out of the box, many tenants allow Copilot to blend public web content with internal knowledge, which looks great in demos but blurs the line between company‑vetted information and whatever it finds on the internet. You’ll learn how to actually locate and test this control in your own admin center, how to see what external content looks like in Outlook and Word prompts, and how to make an intentional decision—enable, disable or restrict—based on your risk profile instead of just inheriting Microsoft’s default. Then we dive into licensing, where most Copilot rollouts quietly leak money and adoption. We cover how seats often get assigned by hierarchy instead of workflow, why utilization is frequently far below what you’ve purchased, and how to treat licenses as a flexible pool instead of a one‑time allocation. You’ll see how regular reviews of your admin reports let you reclaim idle seats, move them to power users who live in Word, Excel and Teams, and keep up with Microsoft’s evolving plans without ripping Copilot away from people mid‑project. The goal is to turn licensing from a hidden landmine into a controlled lever you can adjust as adoption and features change. Finally, we connect these hidden settings to a broader governance checklist. We talk about Edge and browser limitations that confuse users, Loop and DLP gaps that can surprise compliance teams, and what you should prepare now so Copilot agents don’t arrive in an environment with unclear ownership. By the end, you’ll have a concrete action list: which Copilot switches to find and test this week, which reports to check monthly, and how to communicate changes so users understand not just that Copilot behaves differently, but why you made those choices. WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67652145/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67652145/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Copilot risk and value aren’t determined by magic—they’re determined by a handful of settings and license decisions that most admins only see once. Once you treat those controls as living levers you revisit on purpose, not one‑time setup screens, Copilot becomes something you can actually govern, optimize and explain to your leadership team. https://www.spreaker.com/cms/episodes/67652145/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67652145/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67652145/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365, Copilot and governance consultant and host of the M365.FM podcast, helping organizations turn Copilot from a black box into a controllable, optimizable part of their digital workplace. He works with teams on Microsoft 365, Purview and Entra ID to design Copilot settings, licensing and oversight strategies so admins stay ahead of Microsoft’s changes instead of discovering risks and wasted seats months after rollout. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| AI flows RFI governance: why your Copilot Studio flows need a human firewall to stop bad data | 27 Oct 2025 | 00:20:24 | |
AI flows RFI governance: in this episode of M365.fm, Mirko Peters explains why your “smart” Copilot Studio and Power Automate flows don’t fail because of AI—but because they trust whatever half‑baked data humans throw at them. He shows how missing fields, vague free‑text answers, and unchecked assumptions quietly corrupt Dataverse, dashboards, and downstream automations, turning elegant flows into high‑speed error amplifiers instead of reliable systems. Mirko starts by naming the real problem: governance, not logic. Flows consume form submissions, emails, and chat inputs as if they were facts, when they’re really guesses, typos, and Friday‑afternoon shortcuts. You’ll hear how this “data reliability gap” shows up in practice—facility access approvals with “meeting” as the purpose, visitor records without safety details, and access passes created from incomplete or ambiguous context that auditors later flag as compliance risks. Automation isn’t wrong; it’s just obedient to bad input. He then introduces the Request for Information (RFI) action as the missing human firewall in AI‑driven flows. RFI pauses an Agent Flow mid‑execution, sends an Outlook actionable message to the right person, and refuses to continue until required fields are reviewed and completed. Unlike a prompt that “thinks” data looks okay, RFI demands confirmation: someone with a name, mailbox, and timestamp must explicitly validate or correct the information before the flow moves forward. That pause is not inefficiency—it’s governance discipline. The episode walks through concrete scenarios where RFI changes everything. In a visitor access flow, AI validation may detect that safety details are missing; RFI then sends the requester a focused Outlook card asking for exact work type, protective gear, and clearance. The flow waits synchronously, resumes only after a valid response, and logs who signed off, when, and with which values. Mirko shows how first responder wins logic, redundant attempts, and full history together create an auditable trail that security and compliance teams can trust. Finally, Mirko connects RFI to broader governance frameworks. He explains how RFI checkpoints map to preventive controls in ISO, SOC, and GDPR audits, why they turn “the system did it” into accountable human decisions, and how they prevent silent data failure—bad records slipping in unnoticed. You’ll get a practical mental model: use AI to interpret, RFI to confirm, and flows to execute, so automation becomes both fast and defensible instead of a glossy policy violation engine. WHAT YOU WILL LEARN
Your AI flows don’t need more prompts—they need a brake pedal. Once you treat RFI as a built‑in human firewall, flows stop blindly trusting every form field and start requiring explicit, logged confirmation before doing anything risky, turning automation from fast chaos into governed orchestration. WHO THIS EPISODE IS FOR This episode is ideal for Power Automate and Copilot Studio makers, COE teams, security and compliance leaders, and operations owners who rely on workflows for approvals, access, or sensitive updates. It is especially valuable if you’ve seen “smart” flows produce dumb outcomes and need a concrete, human‑in‑the‑loop pattern to make AI automation defensible in audits and real‑world production. ABOUT THE HOST Mirko Peters is a Microsoft 365 and Power Platform consultant focused on building governed, scalable automation with Power Automate, Copilot Studio, Dataverse, and Microsoft 365. Through M365.fm, he shares practical governance patterns, RFI‑driven flow designs, and real‑world stories that help organizations keep automation fast while keeping accountability, data integrity, and compliance firmly in place. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Defender Alone vs. Sentinel: When Microsoft 365 XDR Isn’t Enough for Security, Forensics and Complian | 05 Sep 2025 | 00:21:29 | |
Here’s the truth many IT teams only discover during an incident: Microsoft Defender protects more than you think, but much less than you assume. Its cross‑signal visibility inside Microsoft 365 is strong for day‑to‑day threats, yet the short retention windows and Microsoft‑only focus mean long‑running attacks and non‑M365 activity can unfold completely outside your investigative view. In this episode, we break down where Defender shines, where its memory and scope fall short, and when relying on it alone quietly sets you up for trouble with both attackers and auditors. We start in the Defender comfort zone. Defender for Office, Endpoint and Identity work together to catch phishing, malware and suspicious sign‑ins, correlating signals across mailboxes, devices and accounts in ways that feel like full coverage. But we show why that picture is incomplete: key logs roll off after 30–90 days, multi‑cloud and network activity stay outside the story, and “we didn’t see anything” often just means “we no longer have the data.” You’ll hear a relatable example of a privileged account breach that lies low for months—exactly the kind of slow burn modern attacks use—and how, by the time damage is visible, much of the early evidence Defender once had is already gone. Then we look at the moment when “good enough” fails: compliance. Auditors don’t care how slick your real‑time detections look; they ask for six, twelve or more months of consistent, tamper‑resistant logs that can reconstruct incidents from the very first suspicious event. We walk through what happens when they request a one‑year trail and Defender can only show the last 30–90 days, why advanced auditing alone still doesn’t equal a SIEM, and how this gap turns into both regulatory risk and painful conversations with customers who expect stronger proof of monitoring.https://www.spreaker.com/cms/episodes/67646241/edit/info?filter=NETWORK&network=18613266 Finally, we explain where Microsoft Sentinel fits and how to decide if it’s worth it for you. Sentinel doesn’t replace Defender’s protections; it extends them with long‑term storage, cross‑platform correlation and serious investigation tools that reach beyond Microsoft 365. You’ll learn when a SIEM becomes non‑negotiable (compliance obligations, complex environments, higher‑tier threat hunting) and when a tuned Defender‑only setup can still be a reasonable starting point—plus one simple question to ask yourself: “If someone breached us six months ago, could we prove what happened?” WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67646241/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67646241/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that Defender isn’t failing you—your expectations are, if you treat it like a full SIEM and compliance archive. Once you see Defender as a powerful but short‑memory shield, and Sentinel as the system that stores and connects the longer story, you can finally design a monitoring strategy that matches both modern threats and the questions auditors will ask later. https://www.spreaker.com/cms/episodes/67646241/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67646241/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67646241/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365 security and monitoring consultant and host of the M365.FM podcast, helping organizations turn scattered Defender alerts into a coherent security strategy with the right mix of XDR, SIEM and compliance logging. He works with teams on Microsoft 365, Sentinel and Azure to design monitoring architectures that balance cost, retention and visibility—so you’re not discovering gaps for the first time in the middle of an incident or an audit. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| M365 Is Not Ready for KRITIS… Or Is It? How to Make Microsoft 365 Compliant with BSI Requirements in Critical Infrastructure | 05 Sep 2025 | 00:22:39 | |
Here’s the uncomfortable truth: moving KRITIS or government workloads to Microsoft 365 is rarely a technical problem—it’s an organizational survival test. One overlooked decision around identity, baselines or governance can quietly undermine BSI compliance before the first user even logs in, turning what looked like a smooth cloud migration into an audit liability. In this episode, we use real‑world patterns to show why many regulated M365 projects are already non‑compliant in their first 90 days, and how you can design your rollout so auditors see a controlled, documented environment instead of screenshots and explanations after the fact. We start with the illusion of safety that comes from Microsoft’s long list of certifications. Platform compliance is often mistaken for customer compliance: leaders assume “Microsoft is certified, so we’re covered,” and rush into licensing and enablement. You’ll hear how that shared‑responsibility gap plays out when a public body rolls out Exchange Online, Teams and SharePoint at speed—only to fail an early audit because identity design, privileged access controls, logging and documentation were never aligned with BSI expectations from day one. The services worked; the evidence didn’t. From there, we unpack why most failures are decided long before migration cut‑over. If you skip a clear strategy phase—mapping which workloads fall under KRITIS, which BSI controls apply, and what auditors will want to see—you build on guesswork, not requirements. Weak identity architecture and rushed directory sync, inconsistent conditional access, and documentation written after the rollout are exactly the “bathroom window” auditors spot first, no matter how many other controls you’ve implemented correctly. We show how these early blind spots create a domino effect: once the foundation is misaligned, every later configuration inherits the same compliance cracks.https://www.spreaker.com/cms/episodes/67640587/edit/info?filter=NETWORK&network=18613266 Then we walk through the three planning phases that actually decide whether your M365 KRITIS rollout will pass or fail: strategy, architecture and governance. Strategy means writing down in plain language what you must protect, which laws and BSI modules apply, and how success will be measured. Architecture means making hard choices about which services are in scope, which must be restricted or technically compensated, and how identities, logs and data residency are designed to meet local requirements. Governance means setting rules and roles before the first user signs in: who creates Teams, how external access is controlled, how changes and exceptions are documented, and how you’ll prove ongoing control instead of one‑time setup. Finally, we tie everything together with practical guidance for your first 90 days. You’ll learn which artifacts auditors ask for first (not last), which identity and logging decisions you must lock in before rollout, and how to avoid the trap of “we’ll fix compliance later” once users are already in production. Think of this episode as a checklist to stress‑test your current or planned project: if you can’t show clear answers for strategy, architecture and governance, your M365 environment may already be out of alignment with KRITIS and BSI expectations—whether anyone has told you yet or not.https://www.spreaker.com/cms/episodes/67640587/edit/info?filter=NETWORK&network=18613266 WHAT YOU’LL LEARNhttps://www.spreaker.com/cms/episodes/67640587/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67640587/edit/info?filter=NETWORK&network=18613266The core insight of this episode is that you don’t “fail compliance” years later in a surprise audit—you fail it in the first months if your M365 rollout is treated like a normal IT project instead of a regulated transformation. Once you plan Microsoft 365 for KRITIS with strategy, architecture and governance at the center, you can move fast on modern work without leaving auditors, regulators and your own accountability behind. https://www.spreaker.com/cms/episodes/67640587/edit/info?filter=NETWORK&network=18613266WHO THIS EPISODE IS FORhttps://www.spreaker.com/cms/episodes/67640587/edit/info?filter=NETWORK&network=18613266
https://www.spreaker.com/cms/episodes/67640587/edit/info?filter=NETWORK&network=18613266Mirko Peters is a Microsoft 365, security and governance consultant and host of the M365.FM podcast, helping KRITIS operators and public authorities design cloud environments that satisfy both modern work demands and strict BSI expectations. He works with teams in regulated sectors to align identity, architecture and governance so that Microsoft 365 rollouts don’t just function technically—but stand up to audits without last‑minute scrambling. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
| Microsoft Copilot top prompts: the exact prompts that cut meeting prep, email, and report time in Microsoft 365 | 04 Sep 2025 | 00:20:08 | |
Microsoft Copilot top prompts: in this episode of M365.fm, Mirko Peters stops talking about prompting theory and shows his actual, battle-tested prompts that he uses every day across Microsoft 365—the ones that cut meeting prep from thirty minutes to five, turn email threads into structured decisions, and make weekly reports write themselves. No filler, no vague advice: just prompts that work, with the context behind why they work. Mirko starts by explaining what separates a useful prompt from a mediocre one in his daily practice. The key is specificity about role, output format, and constraints—not length. He shows how "summarize this" produces generic noise, while "act as a project manager, extract the three open decisions from this thread, list them as bullet points with the owner and due date" produces something you can actually send to your team. The difference is not prompt length; it is structural clarity. He then walks through his top prompts category by category. In Outlook, he uses Copilot to triage long email chains, draft responses that match the sender's tone, and pre-write follow-ups based on conversation history. In Teams, he extracts action items mid-meeting, generates a decision log before the call ends, and creates a one-paragraph executive summary that goes straight into the meeting notes. In Word and PowerPoint, he builds first drafts from a bullet-point outline and refines them with targeted editing prompts rather than regenerating the whole document. The episode also covers context injection—the technique of pasting your own templates, past examples, or company vocabulary directly into the prompt so Copilot imitates your actual style instead of producing generic corporate output. Mirko shares prompts for strategy documents, status reports, and leadership updates that use this technique to produce outputs he barely needs to edit, because the AI already knows the structure, the tone, and the audience. Throughout, he emphasizes iteration over perfection. None of these prompts were written perfectly the first time; they were refined through dozens of tries, small adjustments, and learning what Copilot does well versus what it consistently gets wrong. The real takeaway is not the prompts themselves but the habit of treating Copilot as a collaborator you coach rather than a machine you command with a magic phrase. WHAT YOU WILL LEARN
The best Copilot prompts are not clever—they are specific. Once you stop asking Copilot to "help" and start giving it a role, a format, and a constraint, you stop getting generic summaries and start getting outputs you can actually use without rewriting them from scratch. WHO THIS EPISODE IS FOR This episode is ideal for Microsoft 365 Copilot users who already have access but feel like they are not getting the value they expected. It is especially useful if you are still using generic prompts, getting inconsistent results, or spending as much time editing AI output as you would have writing it yourself. ABOUT THE HOST Mirko Peters is a Microsoft 365 and productivity consultant who uses Copilot daily across Teams, Outlook, Word, and PowerPoint. Through M365.fm, he shares the prompts, patterns, and iteration habits that turn Copilot from a novelty into a reliable productivity multiplier for knowledge workers and enterprise teams. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. | |||
© My Podcast Data