M365 Show Podcast

Mirko Peters

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. Autonomous Agents & Dynamics 365 Customer Service: The Night the Emails Died

    7 GIỜ TRƯỚC

    Autonomous Agents & Dynamics 365 Customer Service: The Night the Emails Died

    The night the emails died, the city got quiet. In this noir-soaked episode, we walk the alleys of shared inbox hell—rotting cases, dead letters, heroic agents burning out one thread at a time. Then the city changes. Three autonomous operators roll in and take over the work humans keep dropping: The Case Scanner – reads every email, pulls every clue, creates every case before it hits the floorThe Traffic Controller – routes like traffic, not vibes; skills, capacity, and SLA heat instead of “who likes billing?”The Shadow Operator – drafts replies, pulls knowledge, and speaks only when it has receiptsYou’ll hear real “case files” from three different “cities” (Retail, Insurance, HR/BPO), a noir-style demo that walks through a three-second end-to-end flow, and a practical blueprint to turn your inbox from a crime scene into a quiet, governed, self-watching city. If your support@ inbox still runs the city, this episode is your map out. Episode Outline Opening — The Night the Emails Died Shared inboxes as crime scenes: dead letters, unread neon, weekend dead zonesEmail isn’t the villain—it’s the witness“Dead letters” as the core metaphor: every minute a message sits, it dies a littleThe real pattern: slow replies → sharp follow-ups → manager CCs → churn threatsThe Crime Scene: Email Ticketing Gone Rotten How shared inbox operations really break:Misfiled threads and fragmented storiesAttachments buried in “Re:” / “Fwd:” chainsOwnership roulette—everyone reads, nobody ownsWhy inbox ≠ queue: it’s just a street corner you hope someone walks pastRouting by vibe: “she likes billing,” “he knows Product A”Time wasted on copying, pasting, re-asking for info that’s already attachedThe myth of the heroic agent and the danger of knowledge walking out the doorCore diagnosis: you’re asking humans to do what machines do better—remember, classify, route, recallEnter the Autonomous Agents: Three Operators Clean House 1. The Case Scanner (Email-to-Case with real teeth) Watches support@, info@, intake@ and never blinksReads subject, body, attachments; extracts IDs, tags products, stitches threadsTurns chaos into structured fields (customer, product, priority) on arrivalOCR on PDFs and screenshots; “one story, not three”2. The Traffic Controller (Unified Routing as the grid) Routes by skills, capacity, customer tier, and SLA heatNo more “I like billing, so I’ll take it”—rules, queues, workstreamsRouting diagnostics act as a flight recorder: what rule fired and whyMisroutes become rule fixes, not witch hunts3. The Shadow Operator (Copilot + knowledge) Reads the case + archive and drafts responses before agents finish sighingSummaries with sources, replies with receipts, asks for only the missing infoMulti-language and tone-aware; always cites where it pulled fromHuman still owns the send; every move is logged and governedStacked together: Scanner → Controller → Shadow turns minutes into seconds and dead letters into live cases. The Case Files: Three Cities, Same Cleanup Crew Case #0147 — Retail: The Inbox That Never Slept 2,500 emails/day, 48–72 hour first responsesScanner extracts product codes, order IDs, OCRs receiptsController routes by reason (returns, damage, exchange) and tierShadow Operator replies with the right KB reference and clean next stepsResult: auto-triage takes most volume; first response time drops sharplyCase #0228 — Insurance: Claims Dripping Through Cracks Agents playing archaeologist with forms and photosScanner detects severity language (fracture, total loss, water ingress)Controller routes to the right adjusters with urgency and tierShadow Operator drafts clear, specific asks and cites policy clausesResult: backlog drops, agents stop triaging and start decidingCase #0316 — HR/BPO: The Black Hole Where Tickets Vanished 1,000 tickets/day, no case creation, ~30% lost in the gapScanner watches intake@ and tags “benefits,” “onboarding,” “contract”Controller routes by client, region, and SLA heatShadow Operator builds onboarding replies with the exact next three stepsResult: capture and assignment climb into the 90%+ range, black hole closesPatterns across all three: same spine, different stories. The Noir Demo: Three Seconds, Faster Than Regret A beat-by-beat demo of the ideal flow: 00:00 — Email lands in support@; Scanner reads motive, extracts IDs, opens case, pins attachments with OCR tags00:01 — Controller applies rules (intent, tier, skills, capacity, SLA heat) and assigns to the right agent00:02–00:03 — Shadow Operator drafts a reply with empathy, the right policy or article, and minimal, precise asksSame pattern repeated for Retail, Insurance, HR/BPO—different words, same heartbeat. The Blueprint: Build a City That Doesn’t Bleed Practical steps to recreate the “clean city”: Ingest at the edgeTurn on Email-to-Case on every relevant mailboxOne portal intake, one chat lane if neededOne drawer (case) per clue sourceIntent without ceremonyStart with simple rules: “refund,” “damage,” “reset password”Gradually teach it the phrases that matter in your domainAim for good coverage over perfectionArchives that answer (not a morgue)Curate 10–20 high-impact articles that close most ticketsClean titles, dated facts, one quotable line per articleWire Copilot/Shadow Operator to pull from these, not folkloreCase creation on impactAuto-create cases on intake; extract customer, product, priorityAttach everything, start SLA timers from the system, not humansKeep required fields lean and meaningfulRouting like traffic, not vibesThree queues: Tier 1, Specialists, VIPReal skill tags, capacity profiles, workstreams per channelUse diagnostics to fix rules instead of blaming peopleEscalation as law, not panicStart with one SLA (first response) and enforce with automationOptional second SLA for VIP resolutionEscalation rules as policy, not emotional reactionShadow Operator on the wireLimit it to safe prompts (“first reply,” “ask for missing info,” “close case summary”)Require sources and human approval Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    30 phút
  2. The Dynamics 365 Lie That Kills Your Business Impact

    19 GIỜ TRƯỚC

    The Dynamics 365 Lie That Kills Your Business Impact

    Most teams use Dynamics as a filing cabinet. The real question is simple: Does your system turn work into progress—or just store activity? In this episode, you’ll see how tiny structural changes inside Dynamics collapse cycle time, improve every downstream metric, and finally make progress the default. I start with a two-minute, visual micro-demo and then walk through real stories where small adjustments delivered big movement. Episode Summary “We implemented Dynamics” is not the finish line. It’s a milestone. The true outcome is speed—how fast your system turns work into progress. In this episode, you’ll learn: Why most orgs build ceremony instead of accelerationHow to run Dynamics like a product, not a projectA tiny BPF redesign that changes behavior the same day you ship itHow to align Dynamics to one real business goal per monthThe three levers that scale: process, data, peopleThe patterns that actually work at scale—product mindset, nearshore capacity, and real agileHow to avoid the classic failure patterns that quietly wreck throughputWhat a 90-day transformation really looks like when you reduce friction deliberatelyBy the end, you’ll know how to create a Dynamics environment where movement is inevitable and stalling is impossible. Episode Segments 1. Why “We Implemented Dynamics” Isn’t the Finish Line Most teams treat Dynamics as a project with a launch date—then habits revert, routing becomes tribal knowledge, and people flee to email where progress is easier. You’ll hear why: “Launch” is not an outcome—speed isReducing friction improves all critical metricsCeremonial process design creates beautiful thickets, not throughputA single mindset shift (“What friction did we remove this month?”) changes everythingNew rituals—not new tech—unlock the engine2. Micro-Demo: The Smallest Change with the Biggest Return A two-minute walkthrough of the simplest upgrade you can ship today: Before: Six vague stages, zero required fields, endless limbo. After: Three stages (Qualify → Commit → Deliver), two required fields each, and a tiny automation that routes records automatically. This shift forces clarity, eliminates purgatory, and turns the ribbon from decoration into governance. 3. Align Dynamics to Real Business Goals Dynamics should guide what happens next—not archive what already happened. You’ll learn: Why dashboards rarely change behaviorWhy you must pick one goal per 30 daysHow to turn that goal into architecture: views, guardrails, and tiny automationsThe subtractive craft: removing decisions that slow motionThe three mechanics that make change visible within daysA weekly triage ritual that finds root causes fast4. The Three Levers of Scaling: Process, Data, People Scaling isn’t louder—it’s cleaner. We break down: Process: Subtraction beats addition. Clear exit criteria beat documentation. Data: Capture less, require smarter, surface risk—not reports. People: Adoption is rhythm, not training. Release cadence creates trust. Real examples include cutting a 21-step approval chain to four and deleting 32 fields to slash user errors. 5. Patterns That Actually Scale: Product, Nearshore, Agile The three patterns that remove bottlenecks without creating ceremony: Product mindset: friction → behavior → metricNearshore capacity: brains in-house, hands nearshoreReal agile: tiny shippable changes tied to two-week metricsYou’ll hear a case where lead qualification fell from six days to two in under two sprints. 6. Classic Failure Patterns (and How to Fix Them) The traps you’ve probably seen: Legacy system recreated with nicer colorsRibbons with infinite stages and zero rulesWork happening in email while Dynamics becomes a museumCommittees that “align” but don’t decideDashboards as theatreBig-bang releases that land with a thudEach one has a practical, tiny fix you can ship this month. 7. Tools That Give You Rhythm: RACI, Backlog, 30-Day Release The three alignment tools that keep your Dynamics ecosystem healthy: A real RACI with a single accountable product ownerA backlog template based on friction, behavior change, and metric impactA 30-day release cadence with clear acceptance criteria and short, in-app release notesThese aren’t ceremonies—they’re how you make momentum predictable. 8. What Scaling with Dynamics Actually Looks Like (90-Day View) A clear, three-month roadmap: Month 1: Rhythm + rails Month 2: Subtraction + surfacing Month 3: Compounding + confidence What it feels like on the floor: No more ownership debates, no more email-based handoffs, no more slide-based reviews. Just work → progress, by design. Key Takeaways Dynamics should be a guidance engine, not an archive.Reduce friction and every metric improves—automatically.Progress comes from rails, clarity, and cadence, not complex features.Small, shippable changes beat giant projects every time.Treat Dynamics like a product and progress becomes the default state. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    28 phút
  3. Dynamics 365 Sales Is Not CRM (It's Your Membership Hub)

    1 NGÀY TRƯỚC

    Dynamics 365 Sales Is Not CRM (It's Your Membership Hub)

    🔥 What This Episode Is About Most people think Dynamics 365 Sales is only for leads, pipelines, and opportunities. The truth? It’s a relationship engine wearing a sales costume. In this episode, we strip off that costume and repurpose the platform for:Membership managementCommittee & governance structuresPartner & association networksAll without custom software. You’ll see how to turn Accounts → Organizations, Contacts → Members, and Opportunities → Assignments using the relational backbone already in Dataverse. By the end, you’ll walk away with a blueprint: data model, lifecycle, and a working prototype layout you can build immediately. 💡 Why This Matters Teams rebuild systems they already own—spreadsheets, shadow databases, hacky SharePoint lists—because they assume “Sales” means “pipeline only.” You’ll learn why that’s backwards:Dataverse already gives you relationships, security, timelines, activities, and automation.Outlook, Teams, SharePoint, and Purview governance all work out of the box.Copilot can summarize threads and keep your users out of email archaeology.Microsoft updates won’t break your world when you stay inside the platform’s guardrails.Stop reinventing membership systems. Start bending the platform you already pay for. 🔧 What You’ll Learn 1. Core Scenarios You Can Run Today We walk through three zero-pipeline use cases: • Membership Management Rename Accounts → Organizations, Contacts → Members, and create a Membership table with Term Start/End, Plan, Status, and Roles. Automate renewals with Power Automate and use timeline activities instead of email chaos. • Committees & Governance Model Committees, Positions, and Assignments. Track terms, voting rights, conflicts, expirations, nominations, and approvals—no custom UI. • Partner & Association Networks Use Programs + Participations to track tiers, benefits, SLAs, and onboarding sequences. Build a Partner Health dashboard powered by Dataverse + Power BI. Pattern: You're remapping nouns, not writing software. 🧱 Data Model Blueprint We reframe Sales as a membership graph, not a pipeline. Key StructuresContact → MemberAccount → OrganizationMembership (bridge): Term Start/End, Status, Plan, Role associationsCommittee / Position / Assignment (governance)Partner Program / Participation (networks)PrinciplesIdentity stays in Contact.Context lives in bridge tables.Roles are related entities, not picklists.Documents live in SharePoint, not scattered across file fields.Payment plans & schedules are modular tables, not custom engines.Security flows from ownership, not custom rules.Model relationships—not checkboxes. 🔄 Membership Lifecycle (Process Flow) Replace sales stages with a deterministic membership lifecycle: Registration → Validation → Active → Renewal → Archive You’ll see:Required steps for documents, payment, eligibilityAutomated renewal triggers (30/60/90)Clear entitlement creation during ActiveGrace/Lapsed handlingMandatory reason codes during ArchiveA calm, predictable conveyor belt that replaces ad-hoc chaos. 🖥️ UI/UX Remodeling We reshape the experience to feel purpose-built:Rename labels (not schema): Member, Organization, MembershipRemove sales clutter: revenue, probability, pipeline fieldsHero layout: Timeline center, Related right, Lifecycle topRole-based forms for staff, volunteers, executivesDashboards for renewals, expirations, missing documents, committee seatsClean views: Renewals Due, Assignments Ending, Memberships Missing DocsEverything users need. Nothing they don’t. 🎬 Demo Highlights In the episode, you’ll see:Members list (former Contacts)Organizations list (former Accounts)A Membership record with lifecycle stagesA Committee → Position → Assignment chainTimeline doing 80% of the storytellingRenewals Due views & a clean operational dashboardIt’s simple, correct, and immediately usable. ⚠️ Pitfalls to AvoidDuplicating Contacts into “Member” tablesOver-customizing with plugins & JavaScriptShoving membership logic into OpportunitiesIgnoring security, ownership, DLP, and ALMBuilding a wide, 200-field monster formTreating mobile as an afterthoughtModel first. Automate second. Code only when truly necessary. 🏛️ Governance & Scalability We cover:Dev/Test/Prod environmentsManaged solutions + proper ALMBusiness units & team ownershipField-level security & auditingDLP policies & data boundariesUTC storage, localized displayComposable flows instead of branching monstersEnterprise-safe, but admin-friendly. 🎯 Real Value for Organizations This approach delivers:One identity across memberships, committees, partnersTrue activity history in one placeFaster onboarding (Timeline + BPF clarity)Cleaner collaboration (Outlook + Teams integrated)Accurate reporting from modeled relationshipsScalable architecture you can extend without rebuildsUse the platform. Don’t fight it. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    36 phút
  4. Stop Customer Service Chaos: The Dynamics 365 AI Fix

    1 NGÀY TRƯỚC

    Stop Customer Service Chaos: The Dynamics 365 AI Fix

    🔧 What You’ll Learn in This Episode Your inbox isn’t broken — your access path is. In this episode, we break down how autonomous agents inside Dynamics 365 fix the chaos of email-to-case by standardizing intake, eliminating misroutes, and turning every message into clean, governed, SLA-accurate tickets. You’ll see the real mechanics behind: Email parsing & AI-driven intent extractionEntity capture (customer, product, entitlement, order IDs, attachments)Unified Routing with skills, capacity, performance & SLA mathCopilot drafting + agent review loopsHuman escalation paths with Teams context injectionGovernance: audit logs, PII redaction, DLP, identity bindingAnd one silent SLA mistake that drains teams without anyone noticing. 🚨 The Problem Today Modern service inboxes aren’t inboxes — they’re attack surfaces. We dig into the core fractures: Slow, inconsistent ticket creationHuman parsing fatigue → wrong categories → bad routingEscalations that depend on tribal knowledgeHigh cost per ticket hidden in tiny repetitive actionsUnbounded access paths with no identity, taxonomy, or intake controlSilent SLA breaches from delayed case creationYour backlog isn’t a volume issue. It’s a design issue. 🤖 What Autonomous Agents Actually Do No hype — just mechanics. We walk through the full agent pipeline: 1. Read & Understand Email structure, threads, attachments, sentiment, urgency, identity binding. 2. Extract with Discipline Entities mapped to fields — not notes. OCR for PDFs, table extraction, product → entitlement mapping. 3. Decide Deflect with verified self-service, or create a case with full accuracy. 4. Auto-Create All required fields, correct SLA, duplicate detection, channel tracking. 5. Categorize with Signal Stacking Subject + body + attachment + history → topic models, not keyword roulette. 6. Route Skills, capacity, performance history, SLA viability — math, not politics. 7. Draft Responses Copilot generates context-aware replies agents review in seconds. 8. Escalate Low confidence, negative sentiment, VIP → human with summary + labeled attachments. 9. Follow Up SLA-based nudges, reopen logic, clean closeout notes. 10. Learn Topic clusters, stale knowledge, new error patterns → continuous improvement. 11. Protect PII redaction, DLP, RBAC, retention — compliant from intake to resolution. Agents don’t replace humans. They clear the noise so humans can handle judgment, empathy, and exceptions. 🏢 Why Dynamics 365 Is the Right Home Place matters. Dynamics brings: Native identity + customer context in DataverseUnified inbox + omnichannel routingSeamless escalation into TeamsSkill-based routing with SLA mathBuilt-in governance: audit logs, retention, PII controlsKnowledge tied to live case patternsAnalytics that show real trends, not noiseAzure AD & Conditional Access securing the intake pathYou get context, control, continuity — all in one system. 🎯 Three Value Areas Where Friction Falls 1. Self-Service Empowerment Not chatbot fluff: verified, identity-bound steps that resolve without touching queues. 2. Automated Ticket Creation No guessing. No half-cases. No silent SLA breaches. Honest dashboards. 3. Human Escalation AI clears repetitive work; humans handle nuance with perfect context. Resulting in: 25–40% lower AHT15–30% higher first-contact resolution~30% fewer reopeningsReal, compounding cost-per-ticket reductionThis is how capacity scales without headcount. 📦 Real-World Example (Retail Ops) Hundreds of daily emails. Baseline: long AHT, weak routing, rising ticket cost, agent burnout. After autonomous agents: Accurate intent extraction & identity bindingTopic-model categorizationSLA-bound case creationCopilot drafting saving minutes per caseClean escalation into Teams30% AHT reduction20% FCR increase~30% fewer reopeningsManagers forecast using real arrival times, not guessesThe queue didn’t empty — it became quiet. Predictable. Sanely scalable. ⚠️ Pitfalls to Avoid Dirty taxonomy or data → poisoned routingMissing escalation paths → silent SLA breaksOver-automation without controls → shadow workflowsNo human feedback → stale modelsPII leakage through drafts/screenshotsIdentity ambiguity → wrong customer, wrong caseFix the foundation before scaling speed. 🧭 What You Need to Implement Clear intent taxonomy + confidence thresholdsClean intake queues with normalized subjectsCRM schema with required fields & validationUnified routing rules tuned to SLA mathCopilot licensing + role-based accessHuman override & escalation controlsWeekly feedback loops + monthly retrainingA 30–60–90 rollout plan focused on stability → accuracy → speedControls first. Speed second. Scale third. 🏁 Final Takeaway AI isn’t replacing your agents. It’s deleting the backlog, standardizing intake, and giving humans the context to make the real calls. 📣 CTA Want the full deployment checklist, SLA templates, and benchmark metrics? Subscribe and watch the next episode, where I walk through the 30–60–90 rollout, the exact thresholds to use, and the governance templates you can copy. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    27 phút
  5. Your Optimization Problems Are Already Solved: The Azure Quantum Hybrid Fix

    2 NGÀY TRƯỚC

    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 phút
  6. No Modules. No Dependencies. No Limits: PowerShell + Graph API the Modern Way

    2 NGÀY TRƯỚC

    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 phút
  7. Planning, Collaboration, Tooling: Building Multi-Agent Systems with Azure Foundry + Semantic Kernel

    3 NGÀY TRƯỚC

    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 phút
  8. Your Endpoints Are Lying to You: Why Intune Alone Isn’t Enough

    3 NGÀY TRƯỚC

    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 phút

Giới Thiệu

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.

Có Thể Bạn Cũng Thích