Skip to content
Sign in
Artwork for Support Engineering Weekly
TechnologyEducationHow To

Support Engineering Weekly

Support Engineering Blog

Support Engineering Weekly is the podcast from the Support Engineering Blog, featuring technical conversations about Microsoft technologies, support engineering, troubleshooting, administration, architecture, operations, and modernization. Each week, we explore practical engineering challenges, technical decisions, and the deeper considerations behind keeping enterprise technology working.

Visit Support Engineering Blog at https://blog.sadhan.ch/

Play
Open in
  • 14 episodes
  • Avg 24 min
  • English

Episodes 14

NewestOldestLongest
All14Unplayed14In progress0Played0
  • S1 · E14
    Sunday · 22 min

    Power Apps: What Actually Happens Behind the Screen?

    Power Apps can make application development look simple - but what actually happens behind the screen when an enterprise application runs? In this episode of Support Engineering Weekly, Alex and Maya look beyond the app interface to examine the engineering layers that make Power Apps work in an enterprise environment. The discussion begins with choosing the right application model, including Canvas apps, model-driven apps, Power Pages, and Power Automate. From there, we follow the Power Apps runtime journey—from a user's action and Microsoft Entra authentication through Power FX, connectors, APIs, gateways, data sources, and the response that ultimately reaches the user. We then examine delegation and why a query that works perfectly during development can become a serious scale problem when it encounters production-sized datasets. The conversation moves into security, where application access is separated from actual data access. We explore the layers involved, including identity, environments, application permissions, connectors, roles, records, and column-level controls. The episode also covers auditing, application lifecycle management, Data Loss Prevention, solutions, and managed deployment, showing why production readiness involves much more than getting an application to work. Finally, Alex and Maya examine common enterprise anti-patterns—from non-delegable queries and unsuitable systems of record to excessive privileges, default-environment dependencies, and single-owner production workloads. The discussion also considers service principals, managed identities, licensing, and cost as part of the architecture itself. The central lesson is simple: the app is not finished when it works. It is ready when it can be changed safely. Chapters 00:00 — Power Apps: Behind the Screen 02:14 — Choosing the Right App Model 04:44 — The Power Apps Runtime Journey 07:24 — Delegation, Security, and Scale 12:10 — Auditing, ALM, and DLP 14:48 — Solutions and Safe Deployment 16:17 — Enterprise Architecture Anti-Patterns Learn more: The full technical article, references, and supporting resources are available through the Support Engineering Blog at https://blog.sadhan.ch/.

    • Transcript
    • Chapters
  • S1 · E13
    Friday · 24 min

    Microsoft Weekly — October 5–9, 2026

    A resilience update designed to make a service stronger can end up taking it offline. A routine cleanup can break a critical feature. And a small increase in response time can trigger a traffic surge that overwhelms an entire system. In this episode of Support Engineering Weekly, Alex and Maya examine Microsoft 365 service incidents from October 5–9, 2026. They explore Outlook calendar caching failures and unwanted add-ins, cascading failures affecting Teams meetings and Copilot voice, request queuing and retry storms, and silent failures involving Teams contacts and PowerPoint Live recordings. The discussion also examines security and compliance issues involving Defender Conditional Access App Control, emergency calling, and legitimate DocuSign links being quarantined. The episode concludes with a practical operational change: Microsoft’s migration of Teams Rooms on Android, Teams phones, and Teams panels management from the legacy Teams admin center to the Teams Rooms Pro Management Portal. Alex and Maya also consider a broader reliability challenge: how should engineers load-test generative AI workloads when prompt complexity and processing times are unpredictable? Chapters 02:04 - Outlook Caching and Unwanted Add-ins 06:35 - Teams and Copilot Resilience Failures 09:01 - Cascading Traffic and Request Queues 12:47 - Silent Failures in Contacts and Recordings 16:31 - Security and Compliance Failures 21:01 - Teams Rooms Android Management Migration 22:51 - AI Load Testing and Cloud Reliability Learn more: Visit the Support Engineering Blog at https://blog.sadhan.ch/ for the full articles, technical references, and additional support-engineering resources behind the discussion.

    • Transcript
    • Chapters
  • S1 · E12
    October 4 · 24 min

    Dataverse Isn't Just a Database

    Why is Microsoft Dataverse so much more than a database? In this episode, Alex and Maya examine Dataverse as a managed application data platform and explore how metadata, security, APIs, storage, capacity, integration, analytics, governance, and application lifecycle management work together to support enterprise workloads. The discussion follows what happens when a request reaches Dataverse and explains why the platform's layered architecture changes how engineers should think about schema changes, metadata, standard versus custom tables, storage models, capacity planning, and security. The episode also examines the difference between operational and analytical workloads, API service protection limits, HTTP 429 responses, backoff, bounded concurrency, idempotency, and the performance implications of synchronous plugins. The conversation then moves into governance and ALM, including solutions, managed versus unmanaged changes, deployment discipline, and why direct production customization can undermine the integrity of the deployment pipeline. Finally, Alex and Maya look at the growing role of AI agents and why clean metadata, well-defined security, lifecycle repeatability, predictable capacity, and resilient integrations become even more important as Dataverse becomes an operational data foundation for AI-enabled workloads. The central lesson is straightforward: Dataverse should be engineered as a governed application platform, not treated as an isolated database. This episode is based on the Support Engineering Blog article “Dataverse Isn't Just a Database”, including its layered architecture, metadata model, storage and capacity guidance, security model, integration patterns, ALM principles, and supporting diagrams. Chapters 00:00 - Dataverse Isn't Just a Database 02:00 - The Six-Layer Dataverse Architecture 04:28 - Metadata as the Platform Contract 07:00 - Storage Engines and Capacity 11:12 - The Seven-Layer Security Gauntlet 14:48 - APIs, Analytics, and Throttling 18:09 - Plugins, Governance, and ALM 20:50 - Dataverse Anti-Patterns 22:12 - AI and the Platform Contract Learn more: The full technical article, references and supporting resources are available through the Support Engineering Blog at https://blog.sadhan.ch/.

    • Transcript
    • Chapters
  • S1 · E11
    October 2 · 21 min

    Microsoft Weekly — September 28–October 2, 2026

    This week on Support Engineering Weekly, Alex and Maya examine a series of Microsoft 365 incidents that reveal a common engineering pattern: as cloud services become more deeply connected, failures increasingly occur in the connective tissue between systems rather than in the systems themselves. The episode begins with Microsoft’s transition from SharePoint One-Time Passcodes to Microsoft Entra B2B for external sharing, and what that means for legacy sharing links, guest identities, Conditional Access, and help-desk preparation. From there, the discussion moves into Teams device-management consolidation, iOS enrollment failures, and a Windows Autopilot routing issue where an internal network change caused seemingly unrelated device-management operations to fail. The deeper dive focuses on Microsoft 365 Copilot, including licensing failures, agent deployment problems, traffic-related capacity issues, and a particularly significant semantic-indexing gap that left Exchange Online email available in storage but absent from Copilot's semantic understanding. The episode then turns to traditional Office clients, examining a Word PDF-save failure that redirected files into a hidden legacy cache location, an Exchange Online add-in synchronization issue, and a Teams workflow regression involving run-only permissions. The common thread is silent and indirect failure: systems can appear healthy while an underlying dependency, routing path, synchronization pipeline, or indexing process is no longer behaving as expected. For support engineers, that raises a difficult question for the AI era: how do you troubleshoot a system that is functioning normally while quietly operating on incomplete information? Chapters 00:00 - Cloud Dependencies Under Stress 01:47 - SharePoint External Access Changes 05:43 - Teams Device Management Consolidation 06:43 - Intune Routing and Autopilot Failure 10:03 - Copilot Licensing and AI Index Gaps 13:02 - Copilot Scale and Agent Failures 14:05 - Office Clients and Cloud Dependencies 16:44 - Exchange Add-ins and Teams Workflows 19:28 - The Enterprise AI Monitoring Challenge Learn more: Visit the Support Engineering Blog at https://blog.sadhan.ch/ for the full articles, technical references, and additional support-engineering resources behind the discussion.

    • Transcript
    • Chapters
  • S1 · E10
    September 27 · 21 min

    When a Power Automate Flow Becomes Production Software

    A Power Automate flow can start as a simple productivity shortcut and quietly become business-critical production software. In this episode, Alex and Maya examine what changes when automation has to operate reliably at scale, including workload management, concurrency, downstream limits, retries, error handling, observability, ownership, application lifecycle management, and architectural boundaries. The discussion begins by reframing a production flow as a small distributed system rather than a simple sequence of actions. Alex and Maya explore the multiplication problem, why broad triggers and loops can generate far more work than the flow designer suggests, and why increasing concurrency can simply move a bottleneck downstream. They then examine throttling, HTTP 429 responses, service protection limits, dynamic backoff, safe retries, stable business keys, and idempotent operations. The episode then moves into production engineering practices: explicit failure paths using scopes and run-after conditions, actionable observability with Application Insights and KQL, service-principal ownership, managed solutions, environment variables, connection references, and modular flow design. The conversation also examines when Power Automate should hand work off to Azure Functions, desktop flows, or message queues instead of trying to perform every task itself. Finally, Alex and Maya distinguish deterministic workflows from agentic workflows and explore how AI agents can complement governed automation when reasoning is required without replacing the predictable execution boundaries of production systems. The central lesson is straightforward: a production flow should be engineered for failure, observability, scale, and change—not simply designed to work when everything goes right. This episode is based on the Support Engineering Blog article “When a Power Automate Flow Becomes Production Software”, including its production architecture model, runtime and performance guidance, resilience patterns, observability practices, ALM approach, modularity principles, and supporting diagrams. Chapters 00:00 - From Simple Flow to Production Software 02:00 - The Three Planes of Production 03:43 - The Multiplication Problem 05:35 - Concurrency, Throttling, and Safe Retries 09:08 - Failure Handling and Observability 12:09 - Production Ownership, ALM, and Modularity 16:00 - Choosing the Right Architecture 18:00 - Deterministic Workflows and AI 20:08 - Engineer for Failure, Not Luck Learn more: The full technical article, references and supporting resources are available through the Support Engineering Blog at https://blog.sadhan.ch/.

    • Transcript
    • Chapters
  • S1 · E9
    September 25 · 25 min

    Microsoft Weekly — September 21–25, 2026

    This week on Support Engineering Weekly, we look beneath the surface of Microsoft 365 incidents and the hidden dependencies that make apparently simple failures difficult to diagnose. The discussion begins with Microsoft 365 Copilot licensing and routing failures, then moves into Purview policy behavior and audit-log issues that show how problems in administrative and compliance layers can affect the support experience. From there, we examine regressions across Office clients and their cloud-connected services, including the interaction between Word, SharePoint, and Exchange state. The episode also looks at rollbacks as diagnostic evidence and at API routing and infrastructure migration, highlighting how changes beneath the visible product layer can produce symptoms that initially appear unrelated. The broader theme this week is the changing role of the support engineer: understanding dependencies, distinguishing client symptoms from service-side causes, and using operational evidence to reconstruct what actually changed. This episode is based on the Microsoft Service Health updates included in the weekly coverage window for September 21–25, 2026. Chapters 00:00 - Hidden Cloud Dependencies 02:01 - Copilot Licensing and Routing Failures 06:45 - Purview Policy and Audit Logs 11:05 - Office Clients and Cloud Dependencies 15:53 - Word, SharePoint, and Exchange State 19:57 - Rollbacks as Diagnostic Evidence 20:25 - API Routing and Infrastructure Migration 23:59 - The Modern Support Engineering Mindset 24:48 - Final Thought: The Future of Offline Learn more: Read the full technical articles, references, and supporting resources on the Support Engineering Blog at https://blog.sadhan.ch/.

    • Transcript
    • Chapters
  • S1 · E8
    September 20 · 21 min

    The Power Platform Isn't Three Products: It's an Architecture

    Why does the Microsoft Power Platform become difficult to support when Power Apps, Dataverse, and Power Automate are treated as isolated products? In this episode, Alex and Maya examine the Power Platform as an architecture, with clear responsibility boundaries between the user experience, governed business data, orchestration, integration, compute, analytics, and the control plane. The discussion explores deliberate handoffs between Power Apps, Dataverse, and Power Automate, the event-driven pattern that connects them, why Dataverse should be treated as shared business context rather than simple storage, and why specialized compute and analytics belong in the appropriate services instead of inside apps or flows. The episode then examines enterprise control through environments, application lifecycle management, data loss prevention, and workload-level security. The conversation also looks at the 2026 direction of the platform, including Copilot, autonomous AI agents, and agentic low-code development, and explains why AI does not replace architecture. Instead, AI makes clear identity structures, governed data, security boundaries, integration controls, and proper ALM even more important. The central lesson is straightforward: start with the workload, define clear responsibility boundaries, use deliberate handoffs, and treat the Power Platform as an integrated architecture rather than three separate products. This episode is based on the Support Engineering Blog article “The Power Platform Isn't Three Products: It's an Architecture”, including its architectural model, responsibility boundaries, deliberate handoff pattern, Dataverse business context, integration and compute guidance, control-plane principles, security model, and supporting diagrams. Chapters 00:00 - Three Products or One Architecture? 02:07 - Responsibility Boundaries 04:51 - Deliberate Handoffs and Events 07:57 - Dataverse as Business Context 10:28 - Integration, Compute, and Analytics 13:16 - The Control Plane and ALM 15:53 - Security Across the Workload 17:00 - AI Doesn't Replace Architecture 19:19 - The Workload-First Architecture Model Learn more: The full technical article, references and supporting resources are available through the Support Engineering Blog at https://blog.sadhan.ch.

    • Transcript
    • Chapters
  • S1 · E7
    September 18 · 22 min

    Microsoft Weekly — September 14–18, 2026

    This week on Support Engineering Weekly, Alex and Maya examine the Microsoft 365 Service Health events from September 14–18, 2026 through the lens of hidden dependencies and architectural complexity. The discussion begins with Microsoft 365 Copilot incidents, including retrieval failures caused by problems in semantic indexing and request-processing changes that affected multiple Copilot experiences. The episode then moves into the administrative side of the stack, where telemetry and reporting failures created misleading data, audit logging problems removed critical user identity information, and seemingly simple desktop actions were affected by cloud-connected state. Excel copy-and-paste failures, Teams shared-channel links, and Outlook add-ins all demonstrate how tightly coupled modern clients have become with cloud services. The final section looks at Defender XDR Conditional Access App Control and the security implications of infrastructure performance problems, including the trade-off between maintaining availability and maintaining security controls. The broader lesson is that support engineers can no longer look only at the visible symptom: accurate state, healthy data pipelines, dependency behavior, and security-layer performance are all part of understanding what a cloud service is actually doing. This episode is based on the Microsoft Service Health updates for September 14–18, 2026 and the supporting technical material used for the episode. Chapters 00:00 - Microsoft 365 Under Architectural Stress 02:24 - Copilot Search and AI Retrieval Failures 07:19 - Admin Reporting and Telemetry Blindness 10:17 - Audit Logs and the Non-Repudiation Gap 12:17 - Excel, Teams, and Outlook Regressions 16:52 - Defender XDR and Fail-Open Security 20:25 - The Invisible Foundations of Cloud Systems 21:23 - Final Thought: When AI Plays Dumb Learn more: The full technical source material, references, and supporting information are available through the Support Engineering Blog at https://blog.sadhan.ch.

    • Transcript
    • Chapters
  • S1 · E6
    September 12 · 25 min

    Why Conditional Access Blocks Users — and How to Find Out Why

    Why can a user be blocked even when one Conditional Access policy shows a successful result? In this episode, Alex and Maya examine how Microsoft Entra evaluates Conditional Access and why a successful policy does not necessarily mean that access will be granted. The discussion explores the difference between a policy that did not apply and one that actually failed, how multiple applicable policies can combine requirements, and why troubleshooting requires finding the requirement that remained unsatisfied. The episode then moves from the evaluation model into practical troubleshooting. Alex and Maya explore authentication strength, session controls, Authentication Context, the roles of What If, Report-only mode, and sign-in logs, and a six-step method for tracing an access failure from the exact sign-in event to its root cause. The goal is to replace guesswork and emergency policy changes with an evidence-first approach that fixes the actual cause while preserving the security posture. The central lesson is straightforward: Conditional Access is a parallel evaluation, not a sequential checklist. Do not look for the policy that blocked the user; find the requirement that remained unsatisfied. This episode is based on the Support Engineering Blog article “Why Is Conditional Access Blocking My User? A Systematic Troubleshooting Method”, including its troubleshooting method, policy evaluation model, root-cause guidance, investigation tools, and supporting diagrams. Chapters 00:00 - Why a Successful Policy Can Still Mean Blocked 02:08 - Why Conditional Access Isn't a Firewall 05:15 - Applicability: Which Policies Actually Apply 11:04 - When Multiple Policies Stack Requirements 14:16 - Authentication Strength and Session Controls 17:26 - Authentication Context and Step-Up Access 19:12 - The Tools and Evidence That Matter 20:40 - The Six-Step Troubleshooting Method 23:07 - From Static Logs to Continuous Access Learn more: The full technical article, references and supporting resources are available through the Support Engineering Blog on the URL https://blog.sadhan.ch/,

    • Transcript
    • Chapters
  • S1 · E5
    September 11 · 24 min

    Microsoft Weekly — September 7–11, 2026

    This week on Support Engineering Weekly, Alex and Maya examine a set of Microsoft 365 incidents and updates that reveal just how deeply connected modern cloud services really are. A shared access configuration created a cross-service blast radius, while telemetry failures produced misleading reporting and downstream service behavior that turned incomplete data into real operational impact. The discussion then moves into several targeted regressions across Outlook and Microsoft Teams, including unwanted Outlook add-ins, malformed shared-channel links, and failures affecting run-only workflows. The episode also looks at two very different forms of intentional disruption: an internal Microsoft resiliency drill that affected Copilot Chat suggestion pills, and TLS interception by network infrastructure that can make a customer-side security appliance look like a Microsoft cloud outage. The episode closes with two Message Center updates administrators should prepare for: more granular Microsoft 365 Copilot usage exports and the upcoming Rewrite with Copilot feature in Edge for Business. Together, these changes highlight a broader support-engineering lesson: authentication, telemetry, network controls, and data-governance policies can all determine how cloud services behave at the user interface. This episode is based on the Microsoft Message Center and Service Health updates for September 7–11, 2026, together with the supporting technical source material used for the episode. Chapters 00:00 - Hidden Microsoft 365 Dependencies 02:03 - When the Access Layer Fails 05:37 - Telemetry Failures and Bad Data 11:04 - Outlook and Teams Code Regressions 15:17 - Copilot Drills and TLS Interception 18:26 - Copilot Analytics and Edge Rewrite 22:25 - Three Key Support Engineering Lessons 23:43 - Resilience in AI-Driven Interfaces Learn more: The full technical source material, references, and supporting information are available through the Support Engineering Blog at https://blog.sadhan.ch.

    • Transcript
    • Chapters
  • S1 · E4
    September 6 · 23 min

    How to read a Microsoft Entra Sign-In Like an Investigator

    A Microsoft Entra sign-in log is more than a simple success or failure. In this episode, Alex and Maya examine how to read a sign-in event as an evidence trail, connecting identity, authentication, client and protocol, device, location, application, resource, Conditional Access, risk, status, error information, and correlation identifiers. The discussion focuses on an evidence-first investigation approach: start with the exact sign-in event, understand what actually happened during authentication, identify the policies and requirements that applied, and connect the available evidence before reaching a conclusion. The episode also examines how the same sign-in data can be used proactively to identify patterns such as legacy authentication, repeated failures, Conditional Access anomalies, unusual device activity, and suspicious risk signals. The central lesson is straightforward: don't just ask whether the sign-in succeeded. Ask what story the sign-in event tells you. This episode is based on the Support Engineering Blog article “Microsoft Entra Sign-In Logs Explained: A Field Guide for Administrators and SOC Teams”, including its sign-in event model, investigation guidance, worked example, and supporting diagrams. Chapters 00:00 - Read the Sign-In Differently 02:16 - Status, Errors, and Authentication 06:20 - Client, Device, and Location 08:40 - Application, Resource, and Policy 11:56 - Conditional Access and Session Controls 13:01 - Case Study: MFA Succeeded, Access Failed 15:24 - The Evidence-First Investigation 19:24 - From Troubleshooting to Threat Hunting Learn more: The full technical article, references and supporting resources are available through the Support Engineering Blog.

    • Transcript
    • Chapters
  • S1 · E3
    September 5 · 23 min

    When MFA Succeeds but Access Is Still Denied

    Why can a user successfully complete MFA and still receive an access-denied result? In this episode, Alex and Maya examine what happens after MFA succeeds and explain how Conditional Access, authentication strength, grant controls, device requirements, Authentication Context, and session controls can influence the final access decision. The discussion focuses on an evidence-first troubleshooting approach: start with the exact sign-in event, identify which policies and requirements applied, determine what remained unsatisfied, and remediate the actual cause rather than weakening an unrelated security control. The central lesson is straightforward: MFA success is evidence that one authentication requirement was satisfied. It is not evidence that the overall access decision must succeed. This episode is based on the Support Engineering Blog article “Why MFA Success Can Still Result in Access Denied”, including its troubleshooting decision path, administrator checklist, and supporting diagrams. Chapters 00:00 - Why MFA Can Succeed Yet Access Is Denied 04:28 - MFA vs. Authentication Strength 08:10 - The Multi-Requirement Minefield 10:14 - Finding the Failed Conditional Access Policy 11:31 - Authentication Context and Step-Up 13:40 - When Access Is Granted but Restricted 15:55 - The Evidence-First Troubleshooting Model 18:00 - The Conditional Access Troubleshooting Funnel 19:52 - Remediation Without Creating an Outage 20:45 - What If vs. Report-Only Mode 22:00 - Remediate the Requirement That Failed 23:01 - The Question Every Admin Should Ask Learn more: The full technical article, references and supporting resources are available through the Support Engineering Blog.

    • Transcript
    • Chapters
  • S1 · E2
    August 30 · 21 min

    Microsoft Weekly — August 24–28, 2026

    This week on Support Engineering Weekly, Alex and Maya review the latest Microsoft Service Health and Message Center updates from August 24 through August 28, 2026. The episode looks at incidents and changes across Microsoft Teams, Microsoft 365 Copilot, Power Automate, SharePoint Online, Microsoft Purview, Microsoft 365 administration, and other Microsoft services. We discuss what happened, who was affected, how Microsoft investigated and mitigated the incidents, and what the underlying causes reveal about operating large-scale cloud services. The episode also covers the latest Microsoft Purview Compliance Manager update for AI Powered Regulatory Templates and what administrators should know about upcoming changes. This is the first edition of our weekly Microsoft Service Health and Message Center review, published every Sunday at 9:00 AM IST.

    • Transcript
    • Chapters
  • S1 · E1
    August 29 · 42 min

    Surviving the Microsoft Project Online Shutdown

    Microsoft Project Online is approaching its September 30, 2026 end-of-service date—but what comes next isn't as simple as clicking an upgrade button. In the first episode of Support Engineering Weekly, we take a deep technical look at what the retirement means for organizations that have spent years building projects, workflows, reporting, integrations, governance and operational processes around Project Online. We begin with the retirement timeline and clarify what is—and isn't—being retired. From there, we examine one of the biggest misconceptions surrounding the transition: the assumption that Planner Premium is simply a modernized version of Project Online. The discussion then goes beneath the user interface to explore the architectural differences between basic Planner and Planner Premium, including the role of Microsoft Dataverse, data organization, governance, dependencies and scale. We then examine the major transition paths available to organizations: Planner Premium for collaborative project execution and modern work management. Project Server Subscription Edition for organizations that continue to require enterprise PPM, on-premises control and deep customization. Dynamics 365 Project Operations for project-centric organizations that need broader project, resource, time, expense and financial capabilities. The conversation also looks at migration as a modernization exercise rather than a simple lift-and-shift operation, including environment assessment, legacy workflows, reporting, OData integrations, APIs, permissions, governance and technical debt. Finally, we explore what increasingly structured and governed project data could mean for AI-assisted work management—and how the role of the project manager may evolve as more mechanical project-management activities become automated. Chapters 00:00 — The Project Online Retirement: Why This Is Not a Simple Upgrade 02:51 — The Retirement Timeline: October 2025, April 2026, September 2026 05:36 — What Is Actually Retiring? 06:29 — The Planner Premium 1:1 Replacement Myth 09:12 — Basic Planner vs. Planner Premium: The Architecture Beneath the UI 13:10 — The Scale Paradox: Why 9,000 Tasks Isn't the Whole Story 16:00 — Legacy Workflows, Dataverse, and the Automation Shift 18:55 — Choosing the Right Transition Path 28:08 — Migration Is Modernization, Not Lift-and-Shift 35:15 — AI, Data Governance, and the Future of Work Management Learn more: The full technical article, references and supporting resources are available through the Support Engineering Blog.

    • Transcript
    • Chapters
Showing 1–14 of 14 episodes