Exchange Online administrators across multiple tenants are reporting a troubling and repeatable symptom: attempts to change
Public Folder permissions are being rejected with access-denied or “permission change is denied” errors, and the problem appears to have affected multiple tenants over the past several days. The situation was first called out in the German blogosphere and has since been confirmed by administrators in community forums and help channels. This feature article examines what is known, what is not verifiable, how Exchange Online’s public-folder permission model works, likely root causes, and practical steps administrators should take now to diagnose, mitigate, and plan for longer-term migration away from fragile public-folder dependencies.
Background / Overview
Public Folders in Exchange have been a core collaboration primitive for two decades. In Exchange Online they remain supported, but they bring a complex set of behaviors and operational dependencies that make them more fragile than mailbox-based permissions or modern Microsoft 365 collaboration primitives.
- Public Folder permissions are stored and replicated in the public folder hierarchy and the public-folder mailboxes that host that hierarchy.
- Administrative changes can be made through the Exchange Admin Center (EAC), Outlook (client UI), or Exchange Online PowerShell using cmdlets such as Get-PublicFolderClientPermission, Add-PublicFolderClientPermission, Set-PublicFolderClientPermission, and Update-PublicFolderMailbox / Update-PublicFolderPermissions automation scripts.
- Changes to permissions may take minutes to replicate to all public folder mailboxes. In hybrid or complex environments, permissions that look like they were applied may not have been propagated to the specific public-folder mailbox assigned to a user.
These design characteristics mean permission changes sometimes fail for benign replication reasons—but a recent pattern of universal rejections points to something more systemic.
What triggered this story (summary of initial reports)
A German blog reported on March 13 that an Exchange Online tenant administrator could not change permissions on public folders in his tenant and later found the same behavior in several client tenants. After the blog post circulated, other tenant admins in the community confirmed they had been experiencing the same inability to set or update public-folder permissions for “the past few days.”
Multiple community threads and anecdotal reports from administrators corroborate this timing: attempts to use the GUI or PowerShell to update permission entries either fail with a “permission change denied / access denied” message, or appear to succeed locally but do not propagate (users continue to see old permissions). Administrators describe both EAC and PowerShell methods failing and note that the issue affected tenants independently of size or licensing tier.
A few reports include alarming but unverified claims (detailed below) about vendor or support interactions. Those claims are sourced to anonymous accounts and should be treated cautiously; they cannot be independently corroborated.
Why this matters: impact for tenant admins and users
Public Folders are often used for shared calendars, team inboxes, archival collaboration, and integration with third-party tools. When permissions cannot be changed:
- End users lose crucial access or inherit overly broad access rights.
- On-call rotations, calendar visibility, and automated processes can break.
- Third-party integrations that manage or rely on public-folder ACLs fail to enforce policy.
- Administrators cannot remediate security incidents or lockdown access quickly.
- Organizations may find themselves exposed by stale access entries or forced into emergency, manual interventions.
Because public-folder permission changes are often part of regular security and governance workflows, a tenant-wide inability to modify them is an operational and security risk.
Technical primer: how public-folder permissions work in Exchange Online
Understanding where things can break helps diagnose this class of issue.
Permission storage and replication
- Public-folder permissions are stored as Access Control Lists associated with the public-folder objects and are hosted in the public-folder mailboxes that contain the hierarchy.
- Permission changes are supposed to replicate to every public-folder mailbox that contains that folder or subtree. If folders are hosted across multiple public-folder mailboxes, propagation can fail or lag.
Administrative surfaces
- GUI: Exchange Admin Center (Public Folders) offers limited capabilities and is often slower or less reliable for deep permission updates.
- Client: Outlook (desktop) can set permissions, but that requires client-side propagation and proper mailbox targeting.
- PowerShell: Recommended for precision and automation. Common cmdlets include:
- Get-PublicFolderClientPermission -Identity "\Path\To\Folder"
- Add-PublicFolderClientPermission -Identity "\Path\To\Folder" -User user@domain -AccessRights Reviewer
- Set-PublicFolderClientPermission -Identity "\Path\To\Folder" -User user@domain -AccessRights Owner
- Replication helpers: Microsoft provides scripts such as Update-PublicFolderPermissions.ps1 to apply or propagate permissions recursively, and Update-PublicFolderMailbox / InvokeSynchronizer are used to invoke replication to a specific public-folder mailbox.
Known limitations (relevant to the current reports)
- The EAC sometimes does not offer "apply to all subfolders" reliably for folders that span multiple public-folder mailboxes.
- Permission changes may not appear immediately to users; replication windows exist.
- Hybrid deployments and incorrect PublicFoldersEnabled configuration may lead to inconsistent behavior.
- Historical issues show that mail-enabled or stale public-folder entries in the NON_IPM_SUBTREE can create unexpected errors or blocking conditions when administrative operations are attempted.
These are normal operational caveats—however, the recent reports indicate something outside ordinary replication timing.
What the community reports show (pattern recognition)
Several features of the incident pattern stand out from administrator reports:
- Attempts to change public-folder permissions are failing across multiple tenants and using different administrative interfaces (EAC and PowerShell).
- In some cases, the admin UI returns an immediate denial; in others, PowerShell cmdlets return permission-related exceptions or appear to succeed locally but never propagate to the folder mailbox that serves end-users.
- The problem surfaced to multiple independent administrators within a few days—consistent with either a rolling platform change, a service regression, or a wide-scale replication fault on Microsoft’s side.
- Community discussions include references to other Exchange Online oddities in the weeks/months prior (mailbox anomalies, replication events, and EWS-related enforcement), suggesting a period of elevated instability in Exchange Online.
Taken together, this pattern points to a
platform-level problem (service-side) or an orchestration/configuration change rather than isolated tenant misconfiguration—though tenant-side misconfigurations can produce similar symptoms.
Plausible technical causes (ranked and explained)
The available evidence suggests several plausible root causes. I rank them by likelihood based on what is publicly observable and typical failure modes.
- Service-side regression or configuration change (most likely)
- A backend change at the Exchange Online service that affects how public-folder ACL updates are accepted or replicated could produce tenant-wide permission change denials.
- Platform deployments occasionally introduce validation or enforcement rules that reject changes previously accepted; such a change would explain the simultaneous reports across tenants.
- Replication or synchronizer outage
- If the public-folder replication subsystem (the synchronizer responsible for propagating ACLs to each public-folder mailbox) is degraded or blocked, local changes will not reach the mailbox that serves the user—resulting in perceived denial or no-effect behavior.
- API or protocol enforcement change (including EWS / API hardening)
- Microsoft has been actively hardening legacy protocols and APIs (for example, EWS hardenings and planned retires). If an internal change affected the authentication or permissions model for the service used by the EAC or PowerShell endpoints, permissions updates could be rejected.
- Certain tenant-level controls (like stricter EWSEnabled semantics or tenant-level allow lists) have previously caused broad functional impacts; similar controls could cause permission update failures.
- Tenant configuration mismatch (less likely but possible)
- Incorrect PublicFoldersEnabled values (Local/Remote/None) or hybrid misconfigurations can cause administrators to create or modify permissions in the wrong context—leading to apparent failures.
- Stale or mail-enabled objects in non‑standard subtrees can also create edge-case errors when performing bulk permission operations.
- A malicious or accidental cross-tenant control event (low probability, high impact)
- Some unverified accounts have recounted dramatic scenarios where tenant-local actions allegedly affected other tenants. These claims lack corroborating technical evidence and would indicate a catastrophic platform vulnerability if true. They are technically plausible only if there were a severe multi-tenant isolation failure—but such a failure would be broadly detectable and would likely trigger a formal incident response and public statement.
Verifiable facts and where to be cautious
What we can verify:
- Microsoft documents the PowerShell cmdlets used to view and change public-folder permissions and provides scripts to help propagate and update permissions. These cmdlets and scripts are the supported tools administrators should use.
- Microsoft has made service-level changes and hardenings to legacy Exchange APIs in 2025–2026 (including staged EWS disablement and stricter EWSEnabled semantics) and has published a staged retirement plan for Exchange Web Services. These changes can and have affected integrations.
- Community administrators are reporting the problem across multiple tenants and platforms (GUI and PowerShell), consistent with the BornCity article’s timeline.
What is not verified or remains suspect:
- Allegations that a tenant admin’s PowerShell sequence “deleted mailboxes worldwide” or that Microsoft support escalated to threats and NDAs are unverified third-party claims. Treat these as anecdote until Microsoft provides official confirmation or incident details.
- The exact underlying code change or service incident causing the permission denials has not been publicly documented (as of this writing). Administrators should expect official Microsoft communications if this is a service-side regression.
Immediate troubleshooting steps for admins (practical checklist)
If you are an Exchange Online administrator seeing “permission change denied” on public folders, follow this structured triage. Use PowerShell where possible for repeatable checks.
- Confirm the symptom and scope
- Try the change in the Exchange Admin Center (EAC) and note the exact error.
- Try the same operation in Exchange Online PowerShell and capture the full error message and request ID.
- Test on multiple public folders and on multiple public-folder mailboxes (if you have more than one) to determine whether the failure is global or specific to a mailbox.
- Verify service health
- Check your organization’s Microsoft 365 Service Health Dashboard / Message Center for any active incidents affecting Exchange Online or Public Folders.
- Check public community channels (peer forums, but treat as anecdotal) to see if others report simultaneous failures.
- Use diagnostic cmdlets and replication helpers
- Get-PublicFolderClientPermission -Identity "\Top\Folder" to read current ACL entries.
- Add-PublicFolderClientPermission and Set-PublicFolderClientPermission to attempt an update and record the exact PowerShell error output (copy the FullyQualifiedErrorId and RequestId if present).
- Run Update-PublicFolderMailbox <PublicFolderMailbox> -InvokeSynchronizer to force replication to a specific public-folder mailbox.
- If propagation fails, run the Update-PublicFolderPermissions.ps1 script to propagate ACLs recursively from a trusted parent folder to children—this is a Microsoft-provided helper for replication-related permission issues.
- Check public-folder mailbox health and assignment
- Verify that public-folder mailboxes are provisioned and online.
- Confirm that the public-folder mailbox assigned to a user is the one that should receive replicated permissions; mismatched assignments can mean permissions are applied to a mailbox not used by the client.
- Reproduce in another tenant / test tenant
- If possible, attempt the same PowerShell commands in an alternate tenant or a dedicated test tenant. If the operation succeeds elsewhere, the issue is likely tenant-specific or a targeted problem; if it fails everywhere, platform-level causes are likelier.
- Collect artifacts before escalation
- Save detailed logs: exact PowerShell command lines, full error messages (including RequestId, Server, TimeStamp), screenshots from EAC, and timestamps.
- If escalation to Microsoft support is required, these artifacts materially speed analysis.
- Engage Microsoft Support with full details
- Open a support ticket with a clear problem statement, steps to reproduce, captured error IDs, and the list of tenants affected (if you manage multiple).
- If you observe service-wide failures, ask Microsoft to check the public-folder replication subsystems and to search backend logs using the RequestId values you captured.
Short-term mitigations and workarounds
If permission changes are urgent and the normal tools are failing, consider these temporary measures:
- Use Outlook desktop to apply permissions (where feasible). The client path sometimes succeeds when EAC or PowerShell fails because it uses a different surface for ACL changes.
- Create a new public-folder mailbox and move the affected folder(s) into it (only with care). In some replication edge cases, moving to a fresh mailbox can restore correct ACL behavior.
- Use delegated mailbox-based sharing (shared mailboxes, shared calendars, or Microsoft 365 Groups) as an interim alternative for collaboration scenarios that do not strictly require public-folders.
- Apply access controls at the application or transport layer (for mail-enabled public folders) to limit risk while the ACL problem is resolved.
These are stopgaps; avoid heavy-handed changes to production hierarchies unless absolutely necessary and tested.
Medium- and long-term recommendations (operational hygiene and strategy)
Public Folders are legacy and require extra operational attention. The recent incident is a timely reminder to reduce dependence on fragile legacy constructs.
- Inventory and document all public-folder usage.
- Identify all business-critical workloads that depend on public-folder ACLs.
- Catalog third-party products and scripts that read or write public-folder ACLs or use EWS to access public folders.
- Reduce or eliminate dependencies on public folders where practical.
- For shared mailboxes, calendars, or team collaboration, evaluate Microsoft 365 Groups, SharePoint document libraries, Teams channels, and shared mailboxes as modern replacements.
- Convert public-folder calendars and mailboxes into shared mailboxes or Group calendars where functionality and integrations permit.
- Plan for API changes and EWS retirement
- Microsoft’s staged retirement of Exchange Web Services (EWS) and ongoing hardenings mean vendors and scripts depending on EWS must migrate to Microsoft Graph or supported alternatives. EWS disablement and stricter EWSEnabled semantics have already produced functional impacts in some tenants.
- Inventory EWS dependencies and engage vendors about migration schedules and supported APIs.
- Harden administrative procedures
- Add change control and monitoring for bulk ACL updates.
- Use test tenants for any complex scripts, and avoid running large unknown PowerShell sequences copied from unverified sources without dry-run verification.
- Maintain a runbook for public-folder ACL troubleshooting, including the Update-PublicFolderPermissions script and replication commands.
Risk assessment and the “unknown” behaviors: caution and transparency
Several community accounts include dramatic anecdotes—claims of large-scale mailbox deletions triggered by a tenant-local PowerShell sequence, allegations of support escalating to legal threats, and assertions that a single cmdlet sequence could bypass tenant isolation. These claims are important to note because of their severity, but they are not corroborated by public incident reports or official Microsoft disclosures. Until Microsoft publishes a post-incident report or the vendor confirms a cross-tenant isolation defect, treat those claims as unverified. Responsible incident response requires documented evidence: RequestId logs, backend trace, and service-side incident summaries.
Administrators should do two things when confronted with such claims:
- Collect precise, verifiable artifacts (PowerShell output, timestamps, RequestId values) and preserve them.
- Escalate promptly to Microsoft Support with the artifacts and request a formal investigation and, if warranted, a post-incident summary.
What Microsoft communications and recent platform changes mean for this problem
Microsoft has publicly communicated several platform hardenings and a migration path away from legacy APIs. The key operational items for admins are:
- The EWS retirement and phased disablement plan: administrators must inventory EWS-dependent apps and prepare migration efforts. The platform-level changes around EWS have already affected how external apps and some administrative surfaces interact with Exchange Online.
- Message Center and TechCommunity announcements have emphasized migration to Microsoft Graph and the need to use supported APIs for integrations.
- For public-folder operations, Microsoft provides guidance and PowerShell scripts to propagate and repair permissions—indicating that replication and mailbox-assignment issues are recognized, recurring operational problems.
Taken together, these communications indicate a platform in transition: Microsoft is deprecating legacy surfaces and making security- and scale-driven changes that can, during rollout windows, produce functional regressions or require immediate admin action.
Practical next steps for WindowsForum readers (concise checklist)
- If you cannot change public-folder permissions:
- Record the full PowerShell error output, including RequestId and TimeStamp.
- Attempt the same change in Outlook desktop (if available) and note results.
- Run Update-PublicFolderMailbox <MailboxName> -InvokeSynchronizer and attempt propagation.
- Run Update-PublicFolderPermissions.ps1 as a remediation for recursive propagation.
- Check the Microsoft 365 Service Health and Message Center for active incidents.
- Escalate to Microsoft Support with collected artifacts if the issue persists.
- Inventory EWS usage and public-folder reliance as a priority item in your migration plan.
- Prepare a migration plan away from public folders for critical workloads as a medium-term project.
Conclusion
The recent wave of “permission change denied” errors on Exchange Online public folders is a serious operational pain point for administrators. Evidence from a regional blog and independent administrator reports suggests the issue is not isolated to a single tenant, and the failure modes are consistent with backend replication or validation changes at service scale. Microsoft provides supported PowerShell cmdlets and replication scripts that are the recommended first line of diagnosis, but platform-level fixes may be required if replication or a backend validation rule has regressed.
Administrators should document and preserve error artifacts, use the documented replication and permission-propagation scripts, and escalate to Microsoft Support in parallel with short-term mitigations. Most importantly, this incident underscores the strategic need to re-evaluate public-folder dependence and accelerate migration to modern Microsoft 365 collaboration constructs and supported APIs—both to reduce operational fragility and to stay ahead of planned platform retirements and hardenings.
Finally, while anecdotal and alarming claims have circulated, they remain unverified. Administrators should demand documented evidence for any cross-tenant isolation failures and rely on official incident reports for conclusive assessments. In the meantime, treat permission failures as high-priority operational incidents: collect evidence, apply Microsoft-recommended remediation steps, and prepare for the long-term work of moving critical workloads off legacy public-folder constructs.
Source: BornCity
Exchange Online: Permission change on “Public Folders” is denied