M365 Show Podcast

Mirko Peters
  • 5.0 (1)
  • NOTICIAS TECNOLÓGICAS
  • CADA DÍA

Welcome to the M365 Show — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365 Show brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.

  1. Your Optimization Problems Are Already Solved: The Azure Quantum Hybrid Fix

    HACE 4 H

    Your Optimization Problems Are Already Solved: The Azure Quantum Hybrid Fix

    It started with a warning. Then… silence. Your classical optimization pipeline didn’t get murdered — it bled out from combinatoric wounds while everyone argued about budget. Now someone wants you to “manage qubits” and all you can think is: I barely trust my VM agents to reboot on schedule. Here’s the truth: Optimization is everywhere.Classical stalls exactly where costs start leaking.Azure’s hybrid quantum tools already live in your tenant.We’re going to dissect one algorithm — QAOA — one Azure pattern, and the one part of quantum that breaks everyone’s brain. Bits were clean: 0/1. Now they’re “maybe.” Fantastic. Let’s autopsy before the coffee oxidizes. The Autopsy Begins — Why Quantum Exists (Forensic Cause of Death) The corpse on the table is an enterprise optimization problem. The tag says: NP-hard complications. Time of death? The moment the solution space exploded. Classical hardware hit the physics wall: clock scaling stalled, core counts gave diminishing returns, and GPUs said, “I accelerate arithmetic, not your exponential grief.” Look at the chart. What killed it? Every new variable doubled the search space.Local heuristics got trapped in pretty but useless local minima.Global structure mattered, but the search couldn’t see the whole board.Classical didn’t fail everywhere. It failed precisely where you needed global coordination under pressure. Enter qubits. Not magic — different physics. A bit is 0 or 1.A qubit lives in superposition — “many maybes at once” — and you only pay the measurement bill at the end.Superposition is like cracking every door open at once instead of checking one room at a time. You still commit to one door when you measure, but the system sampled drafts from all of them. Then comes entanglement — variables whispering behind your back. Classically, coordinating constraints across a graph means message passing, shared state, pain. Entanglement bakes correlations into the state itself. Constraints are knitted into the system. No emails sent. No tickets filed. Interference is the knife. Good paths reinforce. Bad paths cancel. It’s code review with phase kicks — your circuit amplifies feasible configurations and suppresses nonsense. The machine doesn’t brute-force; it steers. Reality check though: Today’s QPUs are small and noisy.This is not the fault-tolerant future yet.That’s why Azure’s approach is hybrid: Quantum proposes. Classical disposes. You run a parameterized quantum circuit. A classical optimizer tweaks the knobs. Rinse, repeat. You’re not “solving” on the chip; you’re shaping a probability landscape and harvesting better answers earlier. Azure Quantum makes this painfully practical: A workspace in your subscriptionSimulators for developmentSelective access to real QPUs for samplingTooling in Q# and Python for orchestrationJobs with metrics, logs, and cost control like any other Azure workloadAnti-hype clause: This is not “crack RSA tomorrow.”We’re here for better routing, scheduling, portfolio choices, and workforce plans — where wasted compute becomes wasted cash.Business translation: logistics, finance, energy, workforce planning — same NP-hard skeleton in different uniforms. Classical gets tired. Hybrid methods tilt the odds and cut time-to-decision. There’s exactly one thing that breaks everyone’s brain: These circuits are not deterministic programs — they are statistical experiments. You don’t read “the answer.” You read a histogram and map bitstrings back to the world. Once you accept that, the rest is plumbing. So how does QAOA actually cut into this problem without summoning demons? The Core Pattern — Hybrid QAOA on Azure (Mechanism of Death + Reconstruction) Cause of death was combinatorics, not a single bug. QAOA is the reconstruction. Why Hybrid? Think of the quantum device as a very smart, very noisy intern — brilliant instincts, shaky hands. The classical host is the grizzled attending — skeptical, methodical, slower but steady. Alone, the QPU drowns in noise.Alone, the CPU drowns in search space.Together, they trade: fast intuition plus measured correction.Quantum explores many maybes at once. Classical decides which maybes deserve another look. What Is QAOA, Clinically? You define two operators: Cost Hamiltonian — encodes the thing you hate:ConflictsOveragesViolationsLost profitMixer — lets the state move through the search space without getting stuck.You stack them in p layers: Apply cost operator with angle γApply mixer with angle βRepeat p timesThose angles (β, γ) are the knobs. The Loop Pick angles (β, γ).Run the quantum circuit for many shots.Measure bitstrings (00…0101, 11…0010, …).Score each bitstring with your classical cost function.A classical optimizer proposes better angles.Repeat until improvement plateaus or budget ends.The QPU never says, “This is the optimal answer.” It says, “Here’s a probability distribution over candidates.” The CPU reads the histogram and says, “These few look promising. Again.” Where QAOA Fits Anywhere you can encode your problem as: Binary decisions (0/1)A cost function that punishes bad combosThink: MAX-CUT: conflict-heavy graphs (network design, clustering, some portfolios)Scheduling: assign people to shifts while respecting hard rulesRouting: choose edges under capacity and time windowsIf your constraints argue with each other, QAOA enjoys the drama. How Azure Wires It Azure Quantum Workspace is your sterile room: Target = simulator (dev) or QPU (sampling)Circuits in Q# or an SDKLoop in PythonJobs tracked with metrics, logs, and artifactsYou submit a hybrid job; Azure coordinates: Classical host runs the optimizerQuantum backend runs the circuitAll the evidence lands in storageTooling: Q# expresses cost & mixer clearly.Python orchestrates optimizers (COBYLA, Nelder–Mead, SPSA, etc.).Azure Functions + Logic Apps automate runs, backoff, retries.Azure Monitor + Log Analytics record every incision.Common mistakes: Expecting miracles on tiny toy problems a greedy heuristic already crushesCranking depth p too high so noise turns your state into soupMeasuring too aggressively and killing interference before it helpsUsing quantum as marketing glitter instead of putting it at real bottlenecks Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    30 min
  2. No Modules. No Dependencies. No Limits: PowerShell + Graph API the Modern Way

    HACE 16 H

    No Modules. No Dependencies. No Limits: PowerShell + Graph API the Modern Way

    If your PowerShell scripts still Import-Module MSOnline or AzureAD, they’re already legacy. And if you just thought “That’s not me,” this episode is exactly for you. The cloud moved on. Your modules didn’t. They break on Linux runners, containers, CI/CD. REST doesn’t. PowerShell isn’t dead — but the “old module era” is. We’re going API-first with Microsoft Graph, and in this session you’ll see the pattern and walk away with scripts that run anywhere. You’ll learn: The API-first, module-free PowerShell pattern for Microsoft GraphThree auth flows (device code, cert-based, Managed Identity) and when to use eachThree enterprise demos: Intune cleanup, identity onboarding, and compliance drift remediationThe stupidly simple Graph gotcha that breaks most scripts (and how to never hit it again)If you’re still loading legacy modules in 2025, you’re basically heating the office with old Exchange servers. 🔥 Why PowerShell Without Modules Is the Future We start by ripping off the band-aid: Everything that matters is in Microsoft Graph nowUsers, groups, devices, Intune, Teams, SharePoint, licenses, app regs, and moreThe portal rides Graph. Your scripts should too.REST beats modules in 2025:No module load timesNo dependency roulette or weird version driftNo “works on my laptop” when your CI/CD runner is LinuxTokens beat credentials. Full stop.OAuth2 + certificates or Managed IdentityShort-lived tokens, clean audit trailsNo passwords in scripts, no sticky notes, no “who owns this account?” dramaCloud-native, cross-platform reality:PowerShell Core works on Windows, Linux, containers, GitHub Actions, FunctionsGraph is the constant behind all of themInvoke-RestMethod + Graph works everywhereWhy security and leadership like this:Least-privilege scopes per job / app registrationAdmin consent reviewed on scheduleEvery call has request IDs & correlation IDs for auditsYou don’t depend on a third-party module maintainer’s calendarKey idea: Modules lag. Graph is always first. If a feature exists, it lands in Graph before it shows up in a PowerShell module—if it ever does. 🧩 The Core Pattern: PowerShell + REST + Graph We walk through the one pattern you’ll reuse for everything: Token → Headers → REST call → Paging/Retry → Done 1. Get a Token (Three Real-World Flows) Device Code (local dev & testing)Great for: interactive console devFlow: request code → browser prompt → token for https://graph.microsoft.com with scopesNot for production (humans are flaky)Client Credentials + Certificate (headless automation)For: CI/CD, scheduled jobs, back-end servicesApp registration with only required Graph app rolesJWT signed with cert → token for https://graph.microsoft.com/.defaultNo client secrets in scripts. Ever.Managed Identity (cloud-native, best option)For: Azure Automation, Functions, VMs, containers in AzureCall local identity endpoint → get Graph tokenNo secrets. No Key Vault lookups in the script. Just proper RBAC.2. Build the Headers Simple but critical: Authorization: BearerContent-Type: application/json for requests with bodiesConsistencyLevel: eventual + Prefer: ... when needed (advanced queries, $count, search)Most people miss ConsistencyLevel and then wonder why advanced queries feel drunk. 3. Call Graph with Invoke-RestMethod Invoke-RestMethod -Method GET/POST/PATCH/DELETE -Uri $uri -Headers $headers -Body ($body | ConvertTo-Json)You handle:Paging via @odata.nextLinkThrottling via status 429/503 and Retry-AfterRetries with exponential backoff + jitterCommon failure modes we call out: Wrong audience (token for management.azure.com but calling Graph 👉 401 all day)Ignoring @odata.nextLink and thinking Graph “only returns 100 rows”Hammering endpoints with tight loops and no delay → throttle hellGranting Directory.ReadWrite.All “just to test” and failing your audit in advancePro tip: Write one retry helper and one pagination helper and reuse them everywhere. Your scripts shrink. Your failure rate drops. 🛠 Enterprise Demo 1 — Intune Device Cleanup (No Modules) Problem: Intune tenants rot. Ghost devices. Old laptops. Duplicate entries. Reports lie. Compliance looks better than reality. Goal: Use Graph-only PowerShell to find, classify, and clean stale devices—safely and on a schedule. What we do: Query Intune devices via Graph:GET https://graph.microsoft.com/beta/deviceManagement/managedDevicesUse $select to trim payload (e.g., id,deviceName,operatingSystem,lastCheckInDateTime,managedDeviceOwnerType,azureADDeviceId)Apply server-side $filter where possible (e.g., stale lastCheckInDateTime)Follow paging until no @odata.nextLink remainsClassify devices by:Age thresholds (e.g., 30/60/120+ days)Ownership (corporate vs personal)Tags for exclusions (lab, loaner, break-glass)Take actions via Graph:Retire: POST /managedDevices/{id}/retireDelete: DELETE /managedDevices/{id}“Disable” via tags or policy triggers, if applicableAll actions log to Log Analytics with runId, deviceId, action, reason, resultAutomation setup:Azure Automation with Managed IdentityGraph app roles: only what’s needed for read + device actionsNon-secret config in variables (thresholds, tags, dry-run flag)We explicitly stress: Dry-run mode first (log-only)Respect Retry-After and throttlingNever run this with god-mode Directory.ReadWrite.All “just to get started.” Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    23 min
  3. Planning, Collaboration, Tooling: Building Multi-Agent Systems with Azure Foundry + Semantic Kernel

    HACE 1 DÍA

    Planning, Collaboration, Tooling: Building Multi-Agent Systems with Azure Foundry + Semantic Kernel

    You already know the meme: chatbots talk, agents act, multi-agent systems actually get stuff done. If you’ve ever begged a bot to fix Intune and got a poem instead, this one’s for you. In this episode, we go full Netflix hands-on: you watch, you snack, I poke the dangerous Service Principal things so nobody nukes prod. We build a mini self-healing, governed multi-agent system using Azure AI Foundry + Semantic Kernel, wired into real enterprise surfaces: IntuneEntra IDMicrosoft GraphAzure AutomationLog AnalyticsWe run one-agent vs multi-agent head-to-head on a real workflow: 12 minutes vs 3 minutes time-to-fix — with only my subscription credit on the line. You’ll see why one agent stalls while teams fly, and how to ship this pattern safely in your own tenant. 🔥 What You’ll Learn 1. Why a Single Agent Isn’t Enough in the Enterprise We start by tearing apart the “one giant agent” fantasy: Single agents are like gas-station Swiss Army knives: technically they have tools, practically they bend on the first real job.You stuff planning, reasoning, execution, approvals, and reporting into one prompt → context explodes, latency spikes, hallucinations creep in.One agent trying to:Plan a changeCall Graph and IntuneWrite remediation scriptsRequest approvalsVerify resultsDocument everything…is basically a help desk, change board, and postmortem crammed into one very tired intern. We break down what actually goes wrong: Context windows flooded with logs, policies, and MDM miscellanyImportant details get truncated or inventedToken usage and costs balloon“Fix” attempts that quietly break other things (like deleting the resource instead of rotating a secret 😬)Then we introduce the fix: Multi-agent = roles + boundaries + parallelism Planner focuses on intent & constraintsOperator focuses on tools & executionReviewer focuses on guardrails & approvalsEach agent gets a tight instruction set, minimal memory, and a focused toolset, passing around small structured messages, not a 50-page policy doc. 2. Multi-Agent Systems 101 (No Hype, Just The Pattern) We map out a clear, shippable mental model: think digital team, not one big brain. Roles: Planner — understands the goal, constraints, environment; outputs a stepwise plan with tool callsOperator — executes the plan via tools: Graph, Azure Automation, Functions, Logic Apps, etc.Reviewer — checks groundedness, scope, compliance, and safety before risky changesMessenger/Concierge — interacts with humans: approvals, status updates, and audit summariesCore concepts: Tools = handsREST APIs (Graph, internal services)Azure Automation runbooks (device scripts, remediation)Azure Functions & Logic Apps (glue & approvals)RAG via Azure AI Search (curated knowledge, not random web junk)Memory = budget, not magicMinimize per-agent contextUse external state (Search, state store, thread metadata)Only pass what’s needed for the next decisionPlanning vs ExecutionPlanner decomposes → Operator calls tools → Reviewer checks → Messenger tells humansThis is where Semantic Kernel shines: planners, skills, function catalogs, retries, cancellationSafety by designManaged Identities per agentRBAC split into read vs managePIM for destructive operationsTool calls logged to Log AnalyticsContent Safety + prompt shields to block jailbreaks & indirect injection3. How Azure AI Foundry Powers Multi-Agent Workflows We then show how Azure AI Foundry becomes the control room: You’ll see how to define agents with: Instructions — short, role-specific promptsDeployments — different models per role (GPT-4-class for planning, SLMs for extraction)Knowledge — Azure AI Search indexes, uploaded docs, optional web groundingActions — OpenAPI tools, Graph, Logic Apps, Functions, Azure Automation, Code InterpreterConnected agents — yes, one agent can call another like a toolWhy this matters: Foundry handles threads, safety, tracing, and evaluationsSemantic Kernel orchestrates the planner → operator → reviewer loop in codeYou keep prompts short and put power in tools with strict schemasModel strategy: Reasoning models for planning and complex decisionsSmall models (SLMs) for extraction, classification, parameter shapingMix serverless endpoints and managed compute depending on cost & residency needsSafety & observability: Content Safety on inputs and outputsPrompt shields against jailbreak and indirect injectionFull tracing of tool calls (who, what, where, how long)Application Insights + Log Analytics for performance & auditBuilt-in evaluation flows for groundedness, relevance, and fluency Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    25 min
  4. Your Endpoints Are Lying to You: Why Intune Alone Isn’t Enough

    HACE 1 DÍA

    Your Endpoints Are Lying to You: Why Intune Alone Isn’t Enough

    Watcher, heed this record. Most teams believe Intune is “handled”—until they try to run it across tens of thousands of laptops, phones, kiosks, and shared devices. Then the logs fill with noise, drift creeps in, and humans become the bottleneck. In this episode, we show you how to treat Intune as the control plane and Azure as the engine—binding Managed Identities, Automation, Functions, and Microsoft Graph into a self-healing device estate that repairs itself before dawn. By the end, you’ll know how to: Use Intune for declarative policy, not manual cleanupLet Azure Automation & Functions close the loops humans forgetBuild keyless, least-privilege control with Managed IdentitiesTurn Graph + Log Analytics into a single source of truth for posture, drift, and MTTRDesign a device platform that corrects, cleans, and reconciles itself at scale🔥 Part I — Why Intune Alone Doesn’t Scale We start with the uncomfortable truth: Intune is necessary, but not sufficient. You’ll hear the seven wounds that appear when Intune is left to carry everything: Manual Process HellExports, blade-clicking, chasing single devicesWorks at 100 endpoints; collapses at 10,000MTTR grows; humans become the queueConfiguration DriftSame policy, different actual statesDeferred reboots, half-applied scripts, missed check-insNo automatic reconciliation = drift piles upOverpowered HumansGlobal Admin summoned “just this once”Broad roles, shared secrets, one-off fixes that never dieLeast privilege becomes theory, not practiceConditional Access ChaosSprawling policies, cryptic names, inconsistent user promptsNo single ledger tying access failures to device posture & policy evaluationScattered OwnershipCerts, scripts, patching, onboarding all owned by different teamsNo one owns the end-to-end flow from enroll → secure → retireNever-Cleaned Device GraveyardsStale, lost, and loaner devices still reported as “active” or “compliant”Metrics lie, policies target corpsesPatching Without OrchestrationRings exist, but no workflow logic:Patch only when Defender is healthyOnly reboot in real maintenance windowsEscalate when a device ignores multiple summonsWe reframe the core idea: Intune declares. Azure enforces. Intune shouldn’t remember, reconcile, and repair without Azure at its side. 🧩 Part II — What Happens When You Combine Intune with Azure Then we show what changes when you let Azure carry the heavy execution: Azure Automation — The Clock That Never Forgets Nightly jobs to:Sweep stale devices and disable/retire themRenew certificates before expiryCheck for configuration drift and trigger remediationAdds nuance Intune alone can’t: time zones, retry logic, health checks, grace periodsManaged Identities — Keyless, Least-Privilege Hands No more secrets in scripts or pipelinesSystem-Assigned Managed Identities on Automation / FunctionsNarrow Graph permissions:Device.Read.All for inventoryDeviceManagementConfiguration.Read.All for policy viewMinimal write scopes for specific actionsIdentity dies with the workload; power is explicit and auditableEntra ID Governance — Least Privilege as Law Role separation: device managers, policy authors, security readers, break-glassPIM for just-in-time elevation, approvals, and auto-expiryConditional Access that actually respects device posture & risk signalsAzure Functions — The Nerves That React in Seconds Event-driven responses to:Device enrollmentCompliance state changesWebhooks & alertsExamples:Tag devices on enrollment and push them into the right dynamic groupsQuarantine non-compliant devices via group-based Conditional AccessLog every decision into Log AnalyticsMicrosoft Graph & Log Analytics — The Road & The Ledger Graph as the single API to devices, users, groups, and policiesLog Analytics as the ledger of record:Drift variance by policyMTTR by device typeCleanup rates for stale devicesKQL turns hunches into charts instead of arguments📜 Part III — Real Enterprise Scenarios (With Numbers) We walk through three real-world patterns: 1. The Device Graveyard Cleanup Nightly Runbook under Managed Identity:Find devices unseen for 60 daysExclude tagged loaners/lab/break-glassDisable, notify owners, log to Log AnalyticsResults:~9% cleanup in week one~42% reduction in stale devices by day 30Conditional Access stops treating ghosts as compliant2. Zero-Touch Onboarding That Actually Works Enrollment event triggers Function:Read hardware & purchasing detailsStamp tags: region, role, security baselineAuto-add device to dynamic groups & policy setsAutomation jobs follow up with cert checks & early health checksResults:Onboarding time cut from 9 business days → ~90 minutes60%+ drop in “new device not ready” tickets Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    29 min
  5. The Backup Operator from Hell: Why Your Azure Backups Aren’t as Safe as You Think

    HACE 2 DÍAS

    The Backup Operator from Hell: Why Your Azure Backups Aren’t as Safe as You Think

    Administrator… do you hear that? The silence is lying to you. Your Azure backups look healthy. Vaults are green. Jobs say Completed. No alerts. No smoke. But one overpowered identity, one leaked token, or one panicked admin can quietly erase every recovery point you’re betting the company on. In this episode, we dissect what really happens when Azure Backup runs on defaults—and how the “Backup Operator from Hell” (rogue admin, stolen automation, careless consultant, or insider threat) can destroy your recovery story in a handful of clicks. You’ll watch: Soft delete fail to comfort youThe purge attemptThe “undead” backup returnThe vault that even you can’t override once it’s lockedThen you’ll get the cure: vault protections, clean identity lines, and monitoring that never sleeps. One rule to remember in the dark: if one person can kill your backups, you don’t have backups. 🔥 What You’ll Learn 1. Backups: The Most Dangerous False Sense of Security We start by breaking the comfortable lie: Why “all green” backup blades are not proof of safetyHow “Completed” jobs hide over-scoped roles, trimmed retention, and silent policy changesThe real villain: the Backup Operator from HellLong-lived Owner at subscription scopeStolen service principal/token from CI/CDOverpowered automation accountsConsultants and temp admins who left fingerprints but no documentationYou’ll see how one identity can: Delete backup itemsSlash retention down so time quietly erases historyDisable protection so new points stop formingPurge soft-deleted recovery points if the vault isn’t lockedBackups don’t fail when you configure them. They fail when you need them—and discover what your IAM and defaults actually allowed. 2. Why Azure Backup Is Not Secure by Default Azure feels “official” and safe. But Azure Backup is only as hardened as you make it. We unpack three big myths: “Backups are immutable by default.” Reality: Immutability is a configuration, not a word. You need:Soft delete for forced delayMulti-User Authorization (MUA) so one human can’t pull all the leversVault Lock so even Owners can’t weaken protection later“Only backup admins can delete backups.” Reality:Contributor can delete backup itemsOwner can purge soft-deleted pointsMis-scoped roles and DataActions can lower retention so backups “die of natural causes”“More subscriptions = more safety.” Reality:If the same identities span them, you just gave one key to more doorsManagement group assignments and wide service principals become cross-subscription attack pathsYou’ll leave with a clear picture of what secure actually looks like: Soft delete on every vaultMUA on destructive actionsVault lock after you’ve tested restoreIAM that prevents any single identity from destroying recovery3. The Common Attack Paths That Kill Backups We map the creature’s favorite routes: Compromised automation (Terraform / pipelines / DevOps)Service principals with Contributor on vaults “for convenience”“Cleanup” jobs that silently rewrite retention and policies at 03:12Logs that look like “normal” deploy operations while history is being erasedOverprivileged vault rolesContributors and Owners on backup vaults who can deploy, delete, and purgeStress-driven clicks during an incident (“just shut it down!”) that wipe protectionSide-door kills: retention cut too low, protection disabled “temporarily,” backups stopped at the policy levelShadow admins and nested groupsCustom roles with hidden Backup DataActionsGroups inside groups that grant purge rights no one remembers“Reader” labels that hide the true effective permissionsYou’ll learn how to spot these paths quickly: Identities that can both deploy and purgeAutomation that can modify backup policyRole assignments that quietly span vaults, subscriptions, and management groups4. The 3-Step Azure Backup Hardening Strategy Then we lay out a practical, operator-ready hardening plan: Step 1 — Lock the Vault Enable soft delete everywhere and actually test delete → restoreConfigure Multi-User Authorization for:DeleteDisable protectionRetention reduction below your minimumApply Vault Lock after you’ve proven restore works and accepted the cost trade-offsStep 2 — Separate Identities and Duties Kill “God-Mode” rolesSplit responsibilities into:Backup Admin (configure & restore, no purge)Security Reader (see everything, change nothing)Vault Purge Admin (rarely used, PIM-gated, MUA-protected)Minimal automation identities (deploy & register only)Use PIM for just-in-time elevation and no permanent OwnersStep 3 — Isolate and Monitor Separate subscription or resource groups for backup vaultsNarrow scopes for managed identities (no subscription-wide everything)Log and alert on:BackupItemDeleteRetentionPolicyChangeRecoveryPointPurgeCorrelate with PIM activations, role assignments, and off-hours activity using Sentinel or similar Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    22 min
  6. Why Microsoft Fabric Is Becoming the New Operating System for Enterprise Data

    HACE 2 DÍAS

    Why Microsoft Fabric Is Becoming the New Operating System for Enterprise Data

    You don’t have a data platform. You have a staged illusion. Power BI pretending to be glue. Pipelines hiding drift. Access you can’t explain. Lineage you can’t prove. You call it analytics. It’s chaos. In this episode, we rip the mask off “modern data” and walk through what a real end-to-end platform looks like with Microsoft Fabric, OneLake, and Medallion—and why most teams quietly sabotage it by smuggling business logic into the wrong layers. By the end, you’ll know how to: Stop using Power BI as duct tapeDesign a single access path from raw → insightEnforce Bronze / Silver / Gold contracts for real (not just in slides)Use Fabric, OneLake, Purview, and workspaces to kill copy storms, shadow truth, and governance theaterStand in front of an exec and prove where a number came fromNo vibes. No “modern stack” buzzwords. Just the architecture and discipline that keep your platform from rotting. 🧨 Part 1 — The Problem You’re Pretending Isn’t There We start by naming the thing nobody wants to say out loud: Power BI is acting as glue code, not as a BI layerPipelines are masking schema drift instead of surfacing itYou have 15 places that claim to be “truth” and none are authoritativeAccess, lineage, and logic live in people’s heads and buried notebooksYou blame “slow BI.” It’s not BI. It’s entropy. We walk through: How copy storms happen: each team spins up their own warehouse, mart, or lakeWhy “just one more semantic model” creates seven conflicting truthsHow schema drift silently kills metrics at 2 a.m. while dashboards still “refresh”Why security is a split-brain mess of service principals, tokens, and made-up “access matrices”Then we drop the uncomfortable line: If you can’t name your access path and your contracts, you don’t have a platform. You have sprawl. 🧩 Part 2 — Why Fabric Exists (The Autopsy Version) This isn’t a product pitch. It’s an autopsy. We break down why Fabric exists in brutally simple terms: to attack fragmentation. You’ll hear how Fabric compresses surface area: One identity: Entra — the same identity that hits your inbox hits your lakeOne storage layer: OneLake — open Delta tables, shortcuts instead of copiesOne governance plane: Purview + workspaces — lineage, sensitivity, and roles in one placeOne monitoring view: capacities, pipelines, warehouses, notebooks, and reports on a single heartbeatWe connect this to the real cost you’re already paying: Cognitive load: every engineer keeping a mental map of “which thing runs where”Delay-as-a-habit: nobody wants to touch the mess, so fixes lagShadow truth: users stop trusting dashboards, export to Excel, and build their own numbersFabric is not “more.” It’s less: fewer places to lie, fewer tools to misconfigure, fewer excuses. 🥇 Part 3 — What Fabric Actually Is: The One Platform Moment We walk through what Fabric actually gives you when you stop treating it as another logo: OneLake as the single organizational lake, backed by Delta/ParquetExperiences on top of that same storage:Data Factory for ingest & orchestrationData Engineering for Spark & lakehousesData Science, Warehouse, Real-Time Analytics, Power BI, Data ActivatorAll sharing the same:Identity (Entra)Security boundary (workspaces)Governance (Purview)Monitoring & capacityKey ideas we break down: Tables, not pipelines, are the real contractShortcuts instead of copies to connect external stores without duplicationHow Direct Lake changes Power BI:Semantic models read Delta in OneLake directlyNo import bloat, no DirectQuery latency taxFreshness and performance without copy stormsYou’ll hear how Fabric takes Medallion from slideware to actual structure you can point at. 🪙 Part 4 — Medallion for Grown-Ups: Bronze, Silver, Gold as Contracts We reframe Medallion from “nice diagram” into enforceable contracts: Bronze — Evidence Immutable, append-only, source-granularNo business rules. No deduping. No joins.You keep schema drift and bad data visible.In Fabric: Lakehouse Files (Bronze folders, Delta logs, arrival metadata)Silver — Truth Validated schema, types, deduplication, conformanceLate-arriving logic, SCDs, and reference joins properly encodedTests for row counts, uniqueness, referential integrity, driftIn Fabric: Lakehouse Tables (Delta), notebooks/Dataflows Gen2, idempotent transformsGold — Meaning Consumption-specific dimensional models and measuresClean star schemas, conformed dimensions, fact tables at stable grainBusiness logic in DAX measures, not buried upstreamIn Fabric: Gold Delta tables surfaced as Direct Lake semantic modelsWe hammer one rule home: Bronze answers what happened. Silver answers what is true. Gold answers what it means. Mix them, and you lose the plot. 🧱 Part 5 — Multi-Workspace Architecture (The Nordwand Approach) We introduce the Nordwand approach: multiple workspaces with boring, consistent names and sharp boundaries: Platform workspaces (Dev/Test/Prod):Core LakehouseCore WarehouseShared dimensionsMedallion pipelinesMonitoring artifactsDomain workspaces (Finance, Sales, Ops, HR, Supply Chain):Dev/Test/Prod per domainShortcuts into Platform SilverDomain-specific Gold models onlyShared Analytics workspace:Certified semantic modelsOfficial cross-domain metricsWe show how this solves: Clear ownership (Platform owns Silver, domains own Gold)Reuse instead of copying (Shortcuts vs. shadow tables)Certified truth (one place for “official” metrics)Controlled promotion (Dev → Test → Prod via deployment pipelines and Git)The result: fixed anchors, clear lanes, and less room for quiet corruption. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    43 min
  7. MCP & Semantic Kernel: Building AI Agents That Take Action, Not Just Chat

    HACE 3 DÍAS

    MCP & Semantic Kernel: Building AI Agents That Take Action, Not Just Chat

    Ah! You’re wasting AI on small talk. Pure power trapped in chit-chat. In this episode, we break open the containment field and show you how to turn AI from a polite conversationalist into a fully-acting IT Operations agent—one that plans, executes, verifies, and stays inside governance at all times. You’ll learn exactly how modern enterprise teams are using Semantic Kernel, MCP, and Azure OpenAI tool-calling with Managed Identity to auto-remediate incidents, reduce MTTR, eliminate hundreds of service desk tickets, and create predictable, auditable workflows. This isn’t theory—it’s the blueprint. 🎯 Episode Focus — From Answering to Acting Traditional chatbots whisper advice. Acting agents do the work. We explore the shift from static Q&A loops to a closed-loop cycle: Intention → Plan → Tool Use → Result → Self-Check → Next Step Learn why this pattern unlocks automation in Microsoft environments without sacrificing safety, compliance, or observability. Micro-Story: A real SRE team wired an agent to monitor high CPU alerts, correlate with deployments, drain faulty nodes, roll back the slot, and post an incident summary—all before the human even rolled out of bed. Not magic. Orchestration. 🔌 Why Microsoft Shops Win Big: MCP + SK + Managed Identity Three components snap together and give you enterprise-grade capability: 🔧 MCP (Model Context Protocol): The WiringTools describe themselves with standards and schemasMicrosoft Graph, Intune, Service Health, internal APIs become discoverableNo brittle plugins or secret adaptersAdd new capabilities without redeploying anythingMCP makes your tools visible. 🧠 Semantic Kernel: The Orchestration LayerTurns MCP tools into callable kernel functionsHandles planning: sequential, parallel, or graph-shaped tasksAuto-builds JSON schemas models expectRemoves the need for hand-crafted payloadsSK shapes the plan and the calls. 🔐 Azure OpenAI + Managed Identity: The Containment FieldModel decides what, identity decides what’s allowedTokens are never exposedEach action is access-controlled at the tool boundaryHigh-risk actions require approval tokensIdentity contains the blast radius. 🧬 The Six-Part Agent Molecule: Build Stable, Reliable Agents A high-functioning IT Ops agent is built from a six-part molecule:Persona — SRE temperament encoded (cautious, concise, safety-first).Memory — Short-term context + durable environmental facts.Planner — Decomposes tasks into safe, verifiable steps.Tools — MCP-exposed actuators and sensors.Policy — Identity controls, approvals, guardrails.Verifier — Post-action checks: metrics, probes, risk state.Miss one of these parts and your agent becomes unpredictable. ⚙ Blueprint 1 — SK Planner + Graph via MCP (IT Ops) We walk through a concrete pattern for post-deployment error spikes: Goal: Recover from elevated 5xx while minimizing blast radius. Tools (via MCP):AppInsightsQueryGraphServiceHealthGraphChangeLogDrainSubsetByBuildRollbackSlotPostIncidentNotePlan:Assess: Query metrics, deployments, health advisories (parallel).Decide: Pick the narrowest safe fix—e.g., drain a bad build subset.Act: Perform drainage or rollback with identity-scoped tools.Verify: Require P95 + 5xx improvement before declaring success.Report: Summaries, graphs, dashboards, change IDs.Key win: Narrow-first fixes prevent unnecessary rollbacks. 🔧 Blueprint 2 — Azure OpenAI Tool-Calling with Managed Identity This blueprint shows how to let the model act without ever handing out credentials. Example: Password Reset AutomationAgent validates user status via GraphChecks MFA, riskState, and role assignmentsPerforms compliant reset (MI scopes enforce safety)Notifies user and closes ITSM ticketVerifies sign-in status or risk flag after resetPolicy encoded in tools ensures governance is non-negotiable. 🛠 Blueprint 3 — Closed-Loop Auto-Remediation The crown jewel: a fully contained remediation loop. Flow:Triggered by telemetry or incidentMulti-branch assessment for root-cause hintsNarrow corrective action first (drain, isolate, scale)Approval-gated high-risk actions (rollback, redeploy)Continuous verification with App InsightsAuto-reporting with evidenceClosed-loop means no guessing—an agent proves the outcome. 📈 Business Outcomes: Why This Actually Matters Beyond the tech, we break down real business impacts:40–70% reduction in MTTR for repeatable failure modes60–90% ticket deflection for onboarding and identity issues50% faster change cycles with Parallel Assess → Safe ActionLower burnout and attrition in SRE/on-call teamsAudit-ready logs for every action—no mystery behaviorRisk compression thanks to identity-scoped tools and approvalsAutomation stops being magic—it becomes measurable. 🛡 Guardrails & Responsibility: Safety as Physics We detail the guardrails that prevent chaos:Split Managed Identities (read vs. write vs. high-risk)Hard-coded schema constraints for dangerous operationsApproval tokens enforced by the tool, not the promptImmutable audit envelopes for every tool callRed-team testing for bypass attempts and prompt injectionsScope-drift monitoring on tools and identitiesPrivacy guarantees for sensitive dataFailure choreography: safe fallback → escalate → contextual summaryModel rotation behind stable tool contractsGovernance isn’t vibes—it’s encoded in the tool boundary. 🏁 Conclusion — The Agent Era Starts Now If you remember nothing else: SK orchestrates. MCP connects. Foundry governs. Managed Identity contains. Verification proves. Start with one narrow flow—like drain-then-verify for post-deploy spikes—and scale safely outward. Subscribe for next week’s episode: The Minimal Viable RAG Pipeline for Enterprise Truth: Chunking, Guardrails, Evaluations, and Cost Control. Delicious security awaits. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    42 min
  8. RAG vs Copilot: When You Need Your Own AI — and When You Don’t

    HACE 3 DÍAS

    RAG vs Copilot: When You Need Your Own AI — and When You Don’t

    Your tenant is humming. Your files are stacked like rusted steel. You need answers — fast. But not guesses. This episode tears into one of the most misunderstood decisions in modern enterprise AI: Should you rely on Microsoft Copilot, or build a Retrieval-Augmented Generation (RAG) pipeline that cites from your own knowledge? Most teams get this wrong. They assume Copilot “knows everything.” They assume RAG is “too hard.” They assume accuracy magically appears on its own. And then they pay for it — in rework, bad decisions, broken trust, and a service desk drowning under repeat questions. We’re here to stop that. What You’ll Learn in This Deep-Dive Episode 🚀 Copilot: Powerful, Fast… and Bounded We break down how Copilot actually works — an M365-native assistant that walks Outlook alleys, Teams threads, SharePoint sites, and OneDrive folders you already have rights to. Perfect for: Drafting emails, briefs, and meeting notesSummaries and rewrites in your voiceSurfacing documents inside your permissionsFast context on work already in your laneCopilot saves minutes per move — but we expose the moment it falls apart: when the truth you need lives outside the M365 glow. 🛑 Where Copilot Quietly Fails (and Why It’s Not Its Fault) Organizations destroy their own trust when they ask Copilot questions it was never designed to answer: Outdated PDFs on a file shareDevice baselines split across three contradictory versionsSOPs buried across wikis, Word docs, and tribal knowledgeERP/CRM fields living in systems Copilot can’t seeWhen Copilot can’t reach the right source, it doesn’t tell you it’s blind — it gives its best guess. Good tone. Bad facts. Big risk. 📚 RAG: Your AI Librarian With Receipts The RAG Breakdown (No Hype, Just Reality): Retrieval: Clean, chunk, tag, and index your docs with metadata and vector embeddingsAugmentation: Find only the most relevant chunks at query timeGeneration: Have the model answer only from those cites, with “don’t know” when blindIt’s not a model trick. It’s a discipline — an information supply chain built for accuracy. With RAG: Every answer is grounded in your sourcesCitations are mandatoryContradictions surface instead of hidingPolicies and SOPs are always up-to-date after reindexingTrust skyrockets because nothing is inventedIf Copilot is speed, RAG is truth. 🏭 Case Study: The Global Manufacturer That Turned Chaos Into Clarity We walk through a real (anonymized) transformation: Before RAG: 4,800+ policy files scattered everywhereConflicting versions, duplicated PDFs, outdated baselines12–15 repeat questions hitting the service desk dailyCopilot helping only on shallow tasksEmployees guessing because finding the right doc was too slowAfter RAG on Azure: Unified index across SharePoint + file serversEvery clause chunked, dated, tagged, ownedHybrid semantic search for precisionTeams agent returning answers with citations in secondsService desk load dropped by a thirdContradictions surfaced and fixed in days, not monthsLeadership finally trusted the documentation againNot because the model was smarter — but because the library was. 💡 Credibility Boosters: Why RAG Wins Enterprise Trust You’ll hear the key lines from real teams: “The biggest win wasn’t speed — it was accuracy.”“Users trusted the answers because citations were mandatory.”“We didn’t retrain anything. We just fixed our data.”RAG is the only approach where: Every answer is auditableEvery source is traceableEvery contradiction is fixableEvery update is immediate after reindexingIn enterprise, this isn’t optional — it’s survival. 🧭 How to Actually Choose Between Copilot and RAG We give you the simple, crystal-clear filter: Use Copilot when: ✔ You’re working inside M365 ✔ You need a draft, summary, rewrite, or quick info ✔ Governance + simplicity outweigh precision ✔ You don’t need strict citations or cross-system truth Use RAG when: ✔ Correctness beats speed ✔ Answers must cite specific clauses ✔ Knowledge lives outside M365 ✔ Policies, SOPs, or baselines shift often ✔ You depend on ERP/CRM/LOB data ✔ Repeatability matters — same question, same answer, same source Copilot is your runner. RAG is your librarian. Know which city you’re operating in. 🔥 Up Next: The RAG Blueprint Episode Subscribe now — the next episode breaks down the minimal viable RAG pipeline, costs, architecture, chunking strategy, evaluation techniques, and guardrails you must implement to avoid hallucinations and blowback. Make the call. Pick the lane. Build the truth. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    26 min
Ver todo (389)

Acerca de

Welcome to the M365 Show — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365 Show brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.

Información

  • Creador
    Mirko Peters
  • Años de actividad
    2 k
  • Episodios
    389
  • Clasificación
    Apto
  • Copyright
    © Copyright Mirko Peters / m365.Show
  • Mostrar sitio web
    M365 Show Podcast

También te podría interesar