Support Engineering Weekly

A server under pressure fails its health checks. Automated traffic management removes it from service, pushing even more load onto the remaining infrastructure. What was designed to protect the system becomes part of the failure itself. In this episode of Support Engineering Weekly, Alex and Maya examine the Microsoft 365 incidents reported between November 9 and 13, 2026, starting with a major multi-service disruption affecting Exchange Online, Teams, SharePoint, Copilot, Defender, and Purview. We unpack the engineering mechanisms behind the cascading failure, including overloaded TLS handshakes, automated health checks, the thundering herd effect, and the decision to extend Exchange Online message timeouts to 48 hours to protect delayed email from unnecessary delivery failures.

Beyond the infrastructure outage, we investigate how distributed-system behaviour creates unexpected problems across Microsoft 365. We explore why Copilot Chat can display outdated conversation history even when the underlying data remains safe, how a latent state-management defect can surface during an infrastructure migration, and why a seemingly minor SMTP header change can trigger duplicate messages and downstream support tickets. We also examine an Exchange Online quarantine failure that raises an important security question: what happens when a system designed to isolate suspicious messages cannot determine where to store them? The discussion then moves to Copilot's integration with Edge for Business, including the interaction between browser-based writing assistance and data loss prevention policies.

Finally, we look at the connection between front-end behaviour and back-end functionality through two unusual incidents: restored Microsoft Teams appearing invisible to users because of a client-side rendering issue, and Word for the web failing to open its audio-file selection dialog under specific Chromium browser window conditions. Across these incidents, one lesson keeps returning: the visible symptom is not necessarily where the failure begins. For support engineers, administrators, and IT professionals, understanding the dependencies between infrastructure, application state, security controls, and user interfaces is essential to troubleshooting modern cloud services.

Chapters

00:00 Introduction: When Recovery Makes It Worse

01:33 The Cascading Infrastructure Outage

06:11 Copilot Caching and Hidden State Bugs

10:14 Copilot in Edge and DLP Boundaries

11:35 Exchange Routing and Quarantine Failures

16:18 Teams and Word: Front-End Failures

20:51 Lessons for Support Engineers

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.

Microsoft Project Online is approaching retirement - or, in this case, its retirement date has already passed. But replacing a project management platform is not as simple as moving tasks from one product to another.

In this episode of Support Engineering Weekly, Alex and Maya examine the architectural differences between Project Online and Planner Premium, and why treating Planner Premium as a one-to-one replacement can put important business processes at risk.

We begin by separating project execution from enterprise project and portfolio management. Planner Premium is well suited to structured collaborative execution, including task dependencies, milestones, timelines, and critical paths. But enterprise workloads may also depend on resource capacity planning, complex timesheets, financial forecasting, and cross-project management capabilities that require a different approach.

The discussion explores Planner Premium’s technical boundaries, including task, resource, custom field, successor link, and project duration limits. We then examine the illusion of equivalence: why workload visibility is not the same as enterprise resource management, and why portfolio views do not automatically unify every project management system.

From there, we look at the hidden dependencies that make migrations difficult: Power Automate flows, custom Power Apps, APIs, reporting, financial systems, governance, and the need to establish an authoritative plan of record.

Alex and Maya then walk through a fit-gap assessment approach, from identifying the business capabilities teams actually use to classifying requirements, validating dependencies, selecting the right destination, and testing complex workloads in a pilot.

Finally, we explore how different workloads may need different destinations—including Planner Basic, Planner Premium, Project Server, Dynamics 365 Project Operations, Project desktop, or archival for inactive projects.

The central lesson: Don't replace the product. Replace the capability.

Disclaimer: This episode discusses the Microsoft Project Online retirement date of September 30, 2026, which has already passed. The episode is being published after that date because an earlier publication slot was not available. The discussion reflects the retirement timeline referenced during the original recording.

Chapters

00:00 — The Retirement Deadline and the Assumption

02:01 — Project Execution vs. Enterprise PPM

04:35 — Planner Premium's Technical Boundaries

07:44 — Visibility vs. Resource Management

11:29 — Dependencies, Governance, and Migration Risk

17:12 — Routing Workloads to the Right Platform

20:01 — Archive What No Longer Needs a Home

Learn more:

The full technical article, references, and supporting resources are available through the Support Engineering Blog at https://blog.sadhan.ch/.

Microsoft 365’s latest updates are reshaping how users communicate and collaborate—but beneath the cleaner interfaces, this week’s incidents reveal just how fragile cloud routing and data pipelines can be. Alex and Maya examine changes across Microsoft Teams, Teams Rooms, and Viva Engage, including minimized meeting controls, new chat sections, private event chat, and dynamic audiences.

Then, they connect the user-facing symptoms to the infrastructure behind them: Exchange Online quarantine failures caused by a missing tenant identifier, duplicate emails triggered by abnormal SMTP headers, Copilot chat histories that appeared to vanish because of regional synchronization issues, and Copilot Cowork traffic throttled by an internal API loop. They also explore delayed usage reports, stale Copilot health data, and Microsoft Purview audit-log backlogs—and why reporting delays do not necessarily mean data loss.

The episode closes with three practical lessons for support engineers: communicate UI changes before users are surprised by them, understand the fragility of backend routing and automated defenses, and distinguish telemetry pipeline problems from service or data loss. As Microsoft 365 services become more interconnected, dependency mapping and blast-radius analysis will matter more than ever.

This episode is based on the Microsoft Message Center and Service Health updates covered for November 2–6, 2026.

Chapters

00:00 Introduction: When Cloud Services Break

02:38 Microsoft 365 Collaboration Changes

08:18 Exchange Quarantine and Secure Failure

10:10 SMTP Forwarding and Duplicate Emails

12:05 Copilot Routing and API Loops

16:30 Telemetry Pipelines and Admin Visibility

20:30 Three Lessons for Support Engineers

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.

When does a simple task list stop being enough to manage a project?

A team can coordinate everyday work perfectly well with a basic task board. But when activities become interconnected, dependencies start affecting delivery dates, and leadership needs visibility into project risks, tracking individual tasks is no longer enough.

In this episode of Support Engineering Weekly, Alex and Maya explore how Microsoft Planner Premium moves work management beyond basic task coordination into structured project delivery.

The discussion begins with the four-stage Work Management Journey, from individual tasks and team coordination to structured projects and enterprise portfolio management. We examine the differences between Planner Basic and Planner Premium and explain why project complexity is driven by relationships between tasks rather than simply the number of items on a board.

From there, we explore dependencies, milestones, timeline views, and critical path analysis. We look at how these capabilities help project managers understand cascading delays, identify delivery bottlenecks, and manage the actual constraints of a project rather than simply tracking incomplete tasks.

The conversation then turns to licensing. Using a practical implementation example, Alex and Maya explain why organizations should assign licenses according to individual responsibilities rather than automatically licensing every project participant for premium capabilities. The discussion also examines how separating task execution from strategic schedule management can support better project governance.

We then address the retirement of Project Online and what it means for organizations planning their next work management platform. Planner Premium is not an automatic replacement for every Project Online workload. We explore the enterprise decision framework and the different paths involving Planner Premium, Project Server Subscription Edition, and Dynamics 365 Project Operations.

The episode also examines the four-stage adoption approach: assess, pilot, govern, and scale. We discuss why successful adoption requires measurable behavioral evidence, why the organization must provide the project management method, and how administrators can evaluate whether teams are genuinely using structured planning capabilities.

Finally, Alex and Maya explore the evolving AI experiences in Planner, distinguishing Planner Agent from Copilot in Planner. We examine how AI can accelerate project creation and reporting while also introducing the risk of generating poorly governed plans at greater speed.

The central lesson is simple: Planner provides the mechanics, but the organization must provide the method. Technology can make structured project delivery possible, but human governance, accountability, and sound project practices remain essential.

Chapters

00:00 — When Task Lists Stop Being Enough

02:15 — From Tasks to Structured Projects

05:53 — Dependencies and Critical Path

09:11 — Premium Licensing by Role

13:00 — Project Online Retirement and Migration Paths

18:00 — Adoption, Governance, and AI in Planner

22:26 — Choosing the Right Work Management Model

Learn more

The full technical article, references, and supporting resources are available through the Support Engineering Blog.

This week on Support Engineering Weekly, Alex and Maya explore the growing tension between rapid AI innovation and the reliability of the infrastructure supporting it. Microsoft is expanding Copilot capabilities with features such as bilingual consecutive interpretation, while introducing new consumption reporting and billing alerts. But behind these advances, administrators are encountering failures in SharePoint knowledge agents, Copilot file pickers, chat history, and agent experiences. We examine how missing configuration parameters, legacy authentication fallbacks, distributed cache synchronization, and incorrect URL routing can disrupt even the newest AI-powered services.

We then investigate a less visible but equally important challenge: the reliability of Microsoft's reporting and telemetry pipelines. Delayed Microsoft 365 usage reports, stale Copilot health data, and missing Defender for Servers baseline visibility demonstrate why a reporting failure should not automatically be mistaken for data loss. Alex and Maya explain how ETL processing, schema mismatches, infrastructure migrations, and growing backlogs can disconnect dashboards from otherwise healthy services. We also examine mandatory infrastructure changes, including the retirement of Microsoft Defender Advanced Hunting APIs in favor of Microsoft Graph Security API, and the transition of Teams Android device management into the Teams Rooms Pro Management portal.

Finally, we look at how shared dependencies create unexpected user-facing failures. From stalled cross-tenant migrations to Outlook attachment problems caused by an Edge WebView update, blank contact cards, and Teams interface regressions, this week's incidents demonstrate how a change in one component can have consequences across an entire ecosystem. We close with three practical engineering lessons: reassess the blast radius of shared dependencies, treat API migrations as active engineering projects, and distinguish data-storage failures from reporting-pipeline problems. As AI agents become part of critical business workflows, we also consider how troubleshooting itself may need to evolve.

This episode is based on the Microsoft Message Center and Service Health updates covered for October 26–30, 2026.

Chapters

02:04 - Copilot Innovation and Reliability

08:01 - Reporting Pipelines and Telemetry

11:53 - API Retirements and Migrations

15:14 - Migration Infrastructure Failures

16:18 - The Hidden Blast Radius of UI Bugs

20:19 - Engineering Lessons for Cloud Support

21:45 - The Future of AI Troubleshooting

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.

In this episode of Support Engineering Weekly, Alex and Maya examine the architectural differences between human interaction, deterministic execution, and adaptive reasoning. Rather than starting with a technology choice, the discussion starts with the nature of the work and asks which execution model best fits it.

The episode begins with Power Apps and the role of applications in providing structured human experiences. It then moves into Power Automate and deterministic workflows, where triggers, rules, actions, expected outcomes, and auditability can be explicitly defined.

The discussion then explores AI agents and the situations where reasoning, ambiguity, unstructured information, multiple knowledge sources, and dynamic tool selection make agentic execution useful. Alex and Maya examine why an agent should not simply replace a deterministic workflow and why bounded tools, permissions, escalation paths, and observability matter when agents can take action.

The conversation then moves beyond the idea of choosing a single tool. Power Apps, Dataverse, Power Automate, AI agents, enterprise systems, and human decisions can be composed into a governed architecture, with each execution model responsible for the work it is best suited to perform.

Finally, the episode examines business data, governance, security, ALM, monitoring, licensing, AI capacity, and human-review costs.

The central lesson is simple: applications, workflows, and AI agents are not competing replacements for one another. They are different execution models that can coexist when architecture starts with the work.

Chapters

00:00 — Choosing the Right Execution Model

05:09 — Apps for Human Interaction

07:00 — Workflows for Deterministic Execution

10:22 — Agents for Reasoning and Ambiguity

14:50 — Composed and Governed Architecture

19:00 — Data, Governance, and Total Cost

22:44 — The Architecture Rule

Learn more:

The full technical article, references, and supporting resources are available through the Support Engineering Blog at https://blog.sadhan.ch/.

This week on Support Engineering Weekly, Alex and Maya explore a growing tension in Microsoft's cloud ecosystem: administrators are gaining new visibility into AI usage, performance, and spending while legacy APIs and authentication methods are being retired. We examine new Agent 365 activity insights, tenant-level adoption metrics, and beta Microsoft Graph APIs for Copilot cost management, including how programmatic spending policies could help organizations monitor consumption and establish financial controls as AI deployments expand.

We then turn to the operational changes that demand preparation. Exchange Web Services (EWS) is entering retirement in Exchange Online, requiring affected archive and compliance integrations to transition to Microsoft Graph APIs. Microsoft Entra's move toward customer-managed telephony providers for SMS and voice authentication also raises important questions about authentication strategy, passkey adoption, user communications, and help-desk readiness. Alongside these changes, new remote repair capabilities for Microsoft 365 Apps and read-only diagnostic checks in Microsoft Purview eDiscovery offer administrators more ways to troubleshoot problems without relying entirely on manual intervention.

Finally, we investigate several Microsoft 365 service-health incidents that reveal the risks of interconnected cloud systems and fragile telemetry pipelines. From Copilot model visibility changes and missing contacts to Global Secure Access disruptions and prolonged delays in Microsoft 365 usage reports, these cases show how backend dependencies, data-processing bottlenecks, and user-interface behavior can affect administration and support. We close with a question for every organization planning its 2027 IT and compliance strategy: is your internal monitoring infrastructure as resilient as the applications you are trying to support?

This episode is based on the Microsoft Message Center and Service Health updates covered for October 19–23, 2026.

Chapters

02:02 - AI Agent Visibility and FinOps

06:03 - Exchange Web Services Retirement

08:12 - Entra SMS and Passkey Transition

11:10 - Remote Repair and Compliance Diagnostics

14:41 - Copilot Visibility and Contact Failures

18:34 - Global Secure Access Outage

19:20 - Usage Reports and Telemetry Backlogs

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.

What happens when a Power Platform app stops being a personal productivity tool and becomes an enterprise system that the business depends on?

In this episode of Support Engineering Weekly, Alex and Maya examine Power Platform governance from the perspective of operating applications safely at enterprise scale. The discussion begins with the transition from lightweight apps to critical business workloads and why governance needs to scale with the importance of the workload.

The conversation explores environments and the risks of allowing the default environment to become a universal development, test, and production boundary. From there, we examine proportional governance using business criticality, data sensitivity, external exposure, and lifecycle stage as dimensions for determining the appropriate governance posture.

The episode then moves into Data Loss Prevention and connector traffic, explaining how DLP policies control which data paths are possible and why DLP is only one part of the broader security model. Identity, environment access, Dataverse permissions, and least privilege are considered together with durable ownership, so critical workloads do not depend on a single individual.

We then examine application lifecycle management as governance in motion, including managed solutions, automated deployment pipelines, solution checks, environment variables, and repeatable production changes. Visibility and inventory are also discussed as prerequisites for governing a growing Power Platform estate.

Finally, Alex and Maya look at governance anti-patterns, time-bounded exception processes, and AI agents as another governed actor within the platform.

The central lesson is simple: governance is not about stopping innovation. It is about creating a safe, repeatable path for innovation to operate at enterprise scale.

Chapters

00:00 — When Apps Become Enterprise Systems

02:59 — Environments and the Default Trap

06:38 — Proportional Governance

09:53 — DLP and Data Path Control

13:26 — Security and Durable Ownership

16:50 — ALM and Automated Deployment

19:24 — Governance, Exceptions, and AI

Learn more:

The full technical article, references, and supporting resources are available through the Support Engineering Blog at https://blog.sadhan.ch/.

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/.

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.