What You’ll Learn, Explore, and Experience at ESPC 2026
From November 30 through December 3 at the RAI Amsterdam, ESPC brings together IT professionals, business leaders, developers, architects, partners, MVPs, community leaders, and Microsoft experts to explore what’s next across Microsoft 365, Copilot, Teams, SharePoint, Power Platform, Security, Fabric, Azure, and AI.
365 tenant blocked for delivery e-mails
Hi Good Day ! Microsoft have blocked our tenant for 2 weeks due spam originating from the domain. Still we cannot send any e-mails and the block is not removed inspite of us contacting microsoft and their engineer connecting to the tenant and checking the tenant for any connectors and updating the outbound delivery settings. The engineer is not responding. How can we contact microsoft as it is a small business and no mails can be delivered. Please can some guide or help. Thank you M Carvalho
Core problem that Tier 1 & Tier 2 could not fix. Needs solution.
"Customize Quick Access Toolbar" updates are blocked by the message "The server drafts location you entered for offline editing is not valid or you do not have permission to access that location. Specify a location on your local computer." The user is also blocked from entering any data into the "Server drafts location" (MS Word/Options/Save/Server drafts location). Microsoft Tier 1 and Microsoft Tier 2 spent about 2 hours on this with registry checks and deletions and even the complete removal of Office 365 and reinstallation. They confirmed and reconfirmed the problem. They could not fix it. I have an electronic file of the chat session, if needed. Tier 2 said that an internal escalation to Tier 3 is not possible though Tier 1 to Tier 2 did happen without fanfare. This input to the Tech Community was the only escalation method. So here it is. Microsoft sold a product that currently does not work as it has in the past. The problem has appeared on Word & Excel (may happen on other applications as well). Please fix this. Thank you.
Microsoft 365 Family - how can there be two products with the same name?
Just spent an hour on live chat/quick assist before the agent worked out that "Microsoft 365 Family" that you pay for (in the UK appx £105 per year) is a different product to the "Microsoft 365 Family" that shows up in the "Family Safety" screens. How can Microsoft have two products with the same name that do different things? Am beyond confused, and pretty annoyed (for those not used to British understatement add three swear words of your own choice to translate into your own 'level of annoyance' language). Would be interested if anyone can explain with more actual rationale than the poor agent had (wouldn't expect them know everything as front line support - maybe someone on here has deeper insight?).OneDrive won't sign in until I log into an external account in Teams
OneDrive gets stuck on "Signing in" after every restart – Sign-in only works when I log into a second organization in Teams I've noticed that OneDrive consistently gets stuck at the "Signing in" stage every time I restart my Mac. I have tried several troubleshooting steps to resolve this issue, including: Quitting OneDrive completely and restarting the Mac. Running the ResetOneDriveApp.command reset procedure. Running the standalone version of the OneDrive reset procedure (ResetOneDriveAppStandalone.command). Removing the "OneDrive Cached Credential" entry from macOS Keychain Access. Testing the sign-in process through a web browser. Testing the connection using a mobile hotspot to rule out potential network-related issues. Updating the standalone OneDrive application to the latest available version. Unfortunately, none of these steps has permanently resolved the issue. Even when OneDrive starts working again, it gets stuck at the sign-in stage after a subsequent restart. However, I have discovered something quite interesting. Recently, while preparing for a Teams meeting, I signed in to one of my two accounts in Microsoft Teams. At that exact moment, I noticed that OneDrive suddenly completed its sign-in process and started working normally, even though it had previously been stuck at the "Signing in" screen. Here is how my account setup is configured: OneDrive is currently syncing folders belonging to my primary organization, as well as one shared folder from an external organization. I have two accounts configured in Microsoft Teams, representing my primary organization and the external organization. Both accounts are essentially associated with the same email address and my primary organization's Exchange account. The external organization's shared access also uses the same email address, but with some additional characters appended to the email address. The interesting part is that OneDrive only manages to complete its sign-in process when I sign in to the external organization's account in Teams. Otherwise, it remains stuck in an endless sign-in loop. This makes me wonder whether there is some kind of authentication dependency or token-sharing mechanism between Teams and OneDrive that is causing this behaviour. What I would like to understand is: Is it possible to make OneDrive authenticate independently, without relying on signing in to the external organization's account in Teams? Is this expected behaviour when using multiple organizational accounts and shared folders across different Microsoft 365 tenants? Could a recent update to OneDrive, Teams, or macOS have introduced a change in how authentication tokens are handled? What's particularly confusing is that I have been using exactly the same account configuration and setup for quite some time without any issues. This behaviour only started appearing after recent updates. I'd really appreciate any insights or suggestions on how to resolve this permanently, rather than having to sign in to the external organization's Teams account every time I restart my Mac just to get OneDrive working. Thank you in advance!Securing the Non-Human Identity Attack Surface
Cybersecurity teams often spend most of their efforts on securing and governing human identities: enforcing Multi-Factor Authentication (MFA), monitoring phishing campaigns, and tightening joiner-mover-leaver processes. Yet, lurking quietly inside every information technology environment is an entirely different population that frequently outnumbers employees: Non-Human Identities (NHI). These workload identities—which encompass applications, service principals, managed identities, CI/CD runners, and automated AI agents—are the connective tissue powering modern IT operations. They run deployment pipelines, automate resource provisioning, and pull data from cloud APIs. Unlike human users, however, they cannot complete an MFA prompt. When an attacker gets their hands on a service principal’s credentials, there is no push notification or phone call standing in the way. The Core Problem: Security & Governance Asymmetry Organizations routinely hold human users to rigorous security standards while letting NHIs operate with sprawling, unmonitored privileges. This disparity turns machine accounts into a high-value attack surface. Once compromised, an identity with broad infrastructure and application permissions grants immediate, high-speed execution capabilities. With AI agents proliferating, automated attacks are evolving. In late 2026, Microsoft published threat intelligence on “Storm-3168: Agentic-driven cloud attacks using compromised service principals” [1]. The immediate danger isn't a science-fiction swarm of sentient rogue AIs. Rather, it is machine-speed execution: scripts and agents performing rapid credential stuffing, instant permission discovery, and automated API reconnaissance through identities that bypass human friction. These modern threats need a modern and comprehensive solution for advanced cyber warfare. The Solution: Microsoft’s multi-layer defense mode: Entra Workload ID Premium + Defender for Cloud (Defender for Resource Manager) + Agent 365 Defending NHIs requires stopping unauthorized access at authentication and monitoring what the identity does once inside. Microsoft tackles this through a multi-layer defense strategy. Layer 1 | Control the Front Door with Microsoft Entra Workload ID Microsoft Entra Workload ID is designed specifically for non-human identities, it focuses on who gets a token and under what conditions: Conditional Access for workload identities — Restricts token issuance to specific public IP ranges and blocks requests when risk thresholds are crossed. Identity Protection for workloads — Detects risky service principals, including leaked credentials, and lets you investigate, confirm compromise, or disable the identity. App Health Recommendations — Flags stale, inactive service principals and expiring secrets before attackers exploit them. Access reviews — Forces scheduled recertification for service principals holding privileged directory roles. Layer 2 | Detect what Non-Human Identities do with Defender for Resource Manager Even with strict front-door checks, a legitimate secret can still be abused. Microsoft Defender for Resource Manager provides a behavioral detection layer for the Azure management plane, analyzing Azure Resource Manager (ARM) operations for suspicious activity that may indicate an identity has been compromised. For Non-Human Identities, Microsoft provides dedicated service-principal behavioral detections that look for suspicious use of high-risk Azure management operations. These detections span the attack lifecycle, including initial access, credential access, execution, persistence, privilege escalation, defense evasion, lateral movement, collection, and impact. This allows Defender to identify scenarios where a service principal may have valid credentials and legitimate Azure RBAC permissions, but begins using those permissions in ways consistent with an attacker. When suspicious behavior is detected, it is surfaced as a Defender for Cloud security alert, providing security teams with information about the detected activity, severity, and associated attack technique. Defender for Resource Manager can also detect surrounding indicators such as activity from suspicious IP addresses or TOR infrastructure, unusual privilege or role changes, abnormal resource creation, persistence activity, and known Azure exploitation techniques. Together, these signals help the SOC move beyond “Was this Non-Human Identity allowed to authenticate?” to the more important question: “After authentication, is this identity behaving like the expected workload or like an attacker?” A full list of the alerts provided by Microsoft Defender for Resource Manager is on the Defender for Cloud alerts reference page. [2] Layer 3 | Give AI agents an identity, governance, and security plane with Microsoft Agent 365 Unlike a traditional application that executes a relatively predictable workflow, an agent can reason, invoke tools, access corporate data, interact with other services, and take actions on behalf of a user or itself. Organizations therefore need controls that extend beyond simply authenticating the underlying application. Microsoft Agent 365 provides a control plane for discovering, governing, and securing agents across the organization: Agent registry and inventory: Establishes centralized visibility into registered agents so security and IT teams can identify agents operating across the environment rather than relying on individual development teams to track them. Connected platforms and the Agent 365 SDK extend visibility and management to agents built outside Microsoft's native agent platforms. Purpose-built agent identity with Microsoft Entra Agent ID: Gives agents a distinct identity foundation instead of treating every agent as an indistinguishable application or service principal. This allows security teams to apply controls to the agent itself and better understand which agent is requesting access. Agent ownership and sponsorship: Associates agents with accountable human sponsors. This creates an ownership model for non-human identities so an agent can be reviewed, governed, and ultimately disabled or removed when its sponsor, business purpose, or lifecycle changes. Lifecycle governance: Applies identity governance controls to agents so access does not have to become permanent simply because an agent was deployed. Organizations can govern the lifecycle from onboarding and access assignment through review and eventual removal. Governed resource access: Microsoft Entra governance capabilities such as access packages can be used to define which resources an agent should receive access to, who can request or approve that access, and how long the entitlement should remain. Conditional Access for agents: Agent-specific Conditional Access gives organizations another policy enforcement point for controlling how agent identities access protected resources. This helps move agent security away from implicit trust toward policy-based access. Agent-aware protection across Microsoft security: Agent 365 integrates the agent into Microsoft's broader security and compliance ecosystem, including Microsoft Defender and Microsoft Purview, so organizations can investigate agent-related threats, apply data security controls, and incorporate agents into existing security operations rather than creating a separate security program for AI. Activity and observability: Centralized agent visibility helps security and operations teams understand which agents exist, who sponsors them, what resources they can reach, and how they are interacting with the enterprise environment. This is critical when autonomous actions occur without a person directly initiating every transaction. Beyond outlining Microsoft's multi-layer defense controls that organizations can implement to protect their NHIs from modern threats, below are practical principles and actionable steps, alongside Microsoft's official mitigation and protection guidance for Storm-3168. Core Principles to Harden Non-Human Identities: Prefer secretless authentication — Use managed identities for Azure workloads, and Workload Identity Federation (OIDC) to swap short-lived tokens instead of storing static credentials. Apply least privilege — Give service principals only the specific roles and scopes they need. Avoid broad Owner or Contributor assignments. Own and review them — Assign clear owners. Regularly review privileged service principals and clean up unused apps and credentials. Watch for risk signals — Use Entra Workload ID Identity Protection features to detect leaked credentials and risky sign-in behavior, and pair that with monitoring of Azure resource operations. Treat them like privileged accounts — Even though they’re not people, high-privilege workload identities deserve the same rigor you apply to admin accounts: inventory, review, and rapid response. Practical Steps to Harden Entra Workload Identities: Secure access with adaptive policies: Apply Conditional Access policies to service principals using Conditional Access for workload identities. Enable real-time enforcement of Conditional Access location and risk policies using Continuous access evaluation for workload identities. Manage custom security attributes for an app Intelligently detect compromised identities: Detect risks (like leaked credentials), contain threats, and reduce risk to workload identities and agents using Microsoft Entra ID Protection. Simplify lifecycle management: Access Microsoft Entra protected resources without needing to manage secrets for workloads that run on Azure using managed identities. Access Microsoft Entra protected resources without needing to manage secrets using workload identity federation for supported scenarios such as GitHub Actions, workloads running on Kubernetes, or workloads running in compute platforms outside of Azure. Review service principals and applications that are assigned to privileged directory roles in Microsoft Entra ID using access reviews for service principals. Mitigation and Protection Guidance for Storm-3168: “Agentic-driven cloud attacks using compromised service principals” Enable appropriate Microsoft Defender for Cloud plans for critical Azure workloads. Consider enabling workload protections relevant to the resources in your environment, including Defender for Resource Manager, Defender for Storage, Defender for Key Vault, Defender for App Service and Defender for Databases. Learn more in the Microsoft Defender for Cloud overview. Protect and continuously assess application credentials and secrets. Avoid storing service principal credentials, storage keys, connection strings, and other secrets in source code, configuration files, public repositories, issues, or other locations where they might be inadvertently exposed. Learn more in the Microsoft Entra Workload ID documentation. Rotate compromised or exposed credentials immediately and establish credential lifecycle practices. Treat credentials that have been publicly exposed as compromised, even if the original location has subsequently been edited or deleted. Removing the content does not invalidate the credential or eliminate copies retained in edit history, caches, archives, logs, or other systems. Immediately revoke or rotate the affected credentials and investigate their historical use. Where supported, organizations should favor mechanisms that reduce reliance on long-lived credentials. Learn more about protecting secrets with Defender for Cloud. Apply least privilege to service principals and other workload identities. Review the Azure RBAC permissions assigned to service principals and restrict their privileges to the resources and operations required by their applications. Learn more about best practices for Azure RBAC. Protect backup and recovery infrastructure as part of ransomware resilience. Restrict access to backup and recovery resources and closely monitor attempts to modify or remove their protection controls. Learn more about Azure Backup security best practices. Scale investigation and response with agentic defenses. Use Project Perception to help defenders deploy AI agents that investigate and respond across large, complex environments at machine speed. Strengthen security posture for AI applications and agentic systems. Use Microsoft Defender for AI Security (codename MDASH) to discover AI assets, identify vulnerabilities and misconfigurations, and reduce exposure to AI-related attack paths. The Bottom Line Non-Human Identities are no longer just “service accounts.” They are first-class identities that attackers actively target. Because they can’t use MFA and often lack strong lifecycle management, a single leaked secret or compromised pipeline can give an attacker lasting, high-impact access. Microsoft provides the multi-layer security controls to inventory, review, risk-assess, and restrict these non-human identities. Combined with least-privilege access, secretless authentication, and monitoring of what NHIs actually do in Azure, organizations can significantly reduce their risk to these identity-based attacks. For additional details or assistance, please reach out to your Microsoft Representative. Learn More: For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog. Review our documentation to learn how to prevent identity attacks, ensure least privilege access, unify access controls, and see how to enable them within your organization. Learn more about securing Copilot Studio agents with Microsoft Defender Evaluate your AI readiness with our latest Zero Trust for AI workshop. Microsoft 365 Copilot AI security documentation How Microsoft discovers and mitigates evolving attacks against AI guardrails Prompt injection protection in Microsoft Defender for Office 365 – official documentation of the prompt injection protection in Microsoft Defender for Office 365. How Microsoft discovers and mitigates evolving attacks against AI guardrails | Microsoft Security Blog Manipulating AI memory for profit: The rise of AI Recommendation Poisoning | Microsoft Security Blog – a related example of an AI-era technique observed in email traffic Defending the inbox against prompt injection attacks | Microsoft Defender for Office 365 Blog – feature announcement introducing prompt injection protection in Microsoft Defender for Office 365. Learn how Microsoft is reimagining the SOC for the agentic era with ISOC in Microsoft Defender Microsoft Entra News and Insights | Microsoft Security Blog Microsoft Entra documentation | Microsoft Learn References: [1] Microsoft Corporation. Storm-3168: Agentic-driven cloud attacks using compromised service principals | Microsoft Security Blog 2 Microsoft Corporation. Alerts for Resource Manager - Microsoft Defender for Cloud | Microsoft LearnExcel and word saving to invalid cloud location
There is a random account that belongs to my wife that keeps showing up randomly in my office 365. Supposedly last year it was "fixed", yet now suddenly it's showing up again when I create a new file in word. It says I need to sign in when I make it so I have to save a copy to my actual cloud to use it. This is driving me nuts, I need an actual solution, tried support and that was a joke. I'm on iPhone 15 pro max with iOS 27.2Powerpoint customizing theme fonts on Mac OS
I'm trying to create a Microsoft Powerpoint Template for my client so they can use it to design slides in future. I've managed to save their colour palette, update the master slides and change the fonts I can see, but when I add text boxes to the slides it still shows the old "theme fonts" and I'm unable to update it. I've tried editing in variants (not available) and in Design > Fonts and it only shows the default font options not a "customization" option outlined in the support documentation. I also don't seem to have access to any them font updates in the Master Slide area as well. Is there a way to change the theme fonts to my default font choices from Powerpoint on a Mac?
