Could Adaptive, Capacity-Aware Recovery Orchestration Improve Exchange Online Resilience?
Sentinel AI – Adaptive Infrastructure Recovery & Traffic Intelligence Hello Microsoft Exchange Community, Following the publicly communicated Microsoft 365 and Exchange Online service disruptions in November 2026, I began examining the reliability challenges associated with large-scale cloud service recovery, traffic redistribution, infrastructure capacity, and secure connection establishment. Based on this technical analysis, I have developed an independent engineering proposal titled Sentinel AI – Adaptive Infrastructure Recovery & Traffic Intelligence. 1. Problem Context Large-scale cloud service disruptions can create complex recovery challenges, particularly when service availability decreases, traffic shifts toward remaining infrastructure, and recovery activities need to be coordinated under changing capacity conditions. Some key engineering challenges worth exploring include: Infrastructure overload during traffic redistribution. Uneven capacity utilization across available service instances. Retry amplification and uncontrolled request concurrency. Health-check signals that may not accurately represent service readiness. Recovery operations that risk introducing additional instability. Limited correlation of operational signals during complex incidents. These are general distributed-systems reliability challenges and are not assertions about Microsoft's internal implementation or the confirmed root cause of any particular incident. 2. Proposed Solution: Sentinel AI Sentinel AI is a proposed adaptive infrastructure recovery and traffic intelligence architecture designed to support cloud service resilience. Its objective is to combine intelligent monitoring, capacity-aware traffic management, controlled recovery orchestration, and evidence-based AI recommendations. The proposed architecture explores the following capabilities: A. Capacity-Aware Adaptive Traffic Management Continuously evaluate available infrastructure capacity. Distribute traffic according to service health and resource availability. Reduce the risk of overwhelming already-constrained infrastructure. Support controlled traffic redistribution during degraded conditions. B. Intelligent Health-Check and Readiness Evaluation Distinguish basic process availability from actual service readiness. Evaluate multiple operational signals before considering an instance healthy. Reduce the possibility of routing traffic toward services that are technically running but unable to handle requests reliably. C. Retry and Concurrency Intelligence Apply bounded concurrency and queue management. Introduce retry budgets and exponential backoff with jitter. Prevent uncontrolled retry amplification. Maintain predictable request handling under elevated load. D. Controlled Recovery Orchestration Gradually restore traffic using canary-based recovery. Monitor service health and capacity during each recovery stage. Define automatic rollback conditions. Require appropriate safeguards before expanding traffic to additional infrastructure. E. AI-Powered Incident Intelligence Correlate monitoring signals, logs, and service metrics. Identify abnormal patterns and potential cascading failure indicators. Generate evidence-linked diagnostic recommendations. Provide human operators with contextual incident insights. F. Human Oversight and Operational Governance Maintain human approval for high-impact recovery decisions. Record operational decisions and recovery actions. Provide auditability, rollback controls, and policy-based execution safeguards. 3. Proposed Architectural Objective The proposed Sentinel AI architecture follows a continuous operational feedback loop: Observe → Analyze → Decide → Validate → Recover → Learn The system is intended to help infrastructure teams make more informed recovery decisions while maintaining capacity constraints, service stability, and operational control. Importantly, AI recommendations would support engineering teams rather than independently control critical production infrastructure without authorization and safeguards. 4. Expected Engineering Benefits If implemented and validated successfully, the proposed approach could help explore improvements in: More controlled traffic redistribution. Reduced retry amplification during degraded conditions. Better visibility into service readiness. Safer and more gradual infrastructure recovery. Faster correlation of operational signals. Improved incident decision support. More predictable recovery behavior under changing capacity conditions. These are proposed outcomes, not measured or demonstrated results. 5. Validation and Implementation Approach The proposal recommends validating the architecture through an isolated test environment using synthetic services, simulated infrastructure constraints, and controlled fault-injection scenarios. Potential evaluation metrics include: Service recovery time. Request success and error rates. Queue depth and request latency. Infrastructure utilization. Retry amplification. Traffic distribution stability. Rollback effectiveness. The architecture has not been implemented or validated in Microsoft's production environment. Any practical evaluation involving Microsoft infrastructure would require explicit authorization. 6. Full Technical Proposal I have prepared a detailed technical document covering the problem analysis, proposed architecture, component-level design, decision logic, recovery workflows, security considerations, validation strategy, risks, and implementation roadmap. Read the complete technical proposal (PDF): https://drive.google.com/file/d/1y-A2rRdasBRpObSpSuW_6iU2miftkkL-/view?usp=sharing 7. Feedback and Technical Discussion I would genuinely appreciate feedback from Microsoft Exchange administrators, cloud infrastructure engineers, SRE professionals, and distributed-systems specialists. In particular, I would welcome technical perspectives on: The feasibility of capacity-aware recovery orchestration in large-scale cloud environments. Approaches to preventing retry amplification during infrastructure degradation. The effectiveness of readiness-based health checks and gradual traffic restoration. The practical role of AI-assisted incident intelligence in production reliability workflows. My intention is to contribute an independent engineering perspective and encourage constructive technical discussion around cloud infrastructure resilience. 8. Author Information Anurag Rajak AI Developer | Independent Engineering Research B.Tech in Information Technology Bansal Institute of Science and Technology (BIST) , Bhopal GitHub: https://github.com/anuragraja LinkedIn: https://www.linkedin.com/in/anurag-rajak-it/ Thank you for your time and consideration. Best regards, Anurag RajakMicrosoft Revamps Exchange Online Admin API Permissions
The Exchange Online Admin API is a REST API to help app developers move from their code from Exchange Web Services before the final deprecation of EWS in April 2027. The permissions originally defined for the API are changing to become less confusing. The change must happen before November 30, 2026. The change shouldn’t impact Microsoft 365 tenants too much as it’s likely that Microsoft posted it to make tenants aware when they discuss apps with developers. https://office365itpros.com/2026/11/13/exchange-admin-api-changes/Mail delviery blocked
Hi we are using exchange online for our e-mail. Microsoft has blocked the tenant from sending any e-mails after an account had been detected sending spam. The microsoft engineer had connected and checked and also set limits to outbound delivery. Now for 2 weeks they are not responding. Any action which can be done or what I need to do.
