Forum Widgets
Latest Discussions
Exchange 2019 Mailbox Migration Error - Folder conflicts with Exchange Online folder
Hi Exchange Experts, I'm migrating a small Exchange 2019 environment to 365. Been pulling my hair out becuase of just one mailbox giving this error Error description --------------------------- Error: AggregateMailboxFolderConflictPermanentException: The folder 'Files' conflicts with Exchange Online folder 'Files', please move the messages to another folder and restart the job. Data migrated: 0 B (0 bytes) Migration rate: -------------------------------------- Migration user report: 5/14/2025 12:32:05 PM [MEUP300MB0105] Request processing continued, stage CreatingFolderHierarchy. 5/14/2025 12:32:05 PM [MEUP300MB0105] Stage: CreatingFolderHierarchy. Percent complete: 10. 5/14/2025 12:32:12 PM [MEUP300MB0105] Stage: CreatingFolderHierarchy. Percent complete: 10. 5/14/2025 12:32:12 PM [MEUP300MB0105] Fatal error AggregateMailboxFolderConflictPermanentException has occurred. ---------------------- It seems to be a system folder and I've tried to remove files from it (although there're no files in it) using MFCMAPI tool with no success. Renamed the folder and tried to re-run the migration with no luck. Has anyone experience this issue? any thoughts or tips are much appreciated ! Thank you.Exchange Mailbox Migration Errors - Corrupted items
Howdy Folks! I'm getting a lot of errors in one of the last mailboxes we're migrating to 365 from Exchange 2019 Hybrid. Has anyone managed to remediate these type of errors? I've remediated abandoned users from permissions but nothing has worked. The errors still popping up even after creating a new batch. Subject Kind Scoring Classification Folder Name FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Tasks FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Tasks FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Notes FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Notes FolderACL CorruptFolderACL Inbox, FolderACL, SourcePrincipalError Inbox FolderACL CorruptFolderACL Inbox, FolderACL, SourcePrincipalError Inbox FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Investments FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Investments FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Health FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Health FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Eleanor FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Eleanor FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Clover FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Clover FolderACL CorruptFolderACL FolderACL, SourcePrincipalError ACL ASIC FolderACL CorruptFolderACL FolderACL, SourcePrincipalError ACL ASIC FolderACL CorruptFolderACL FolderACL, SourcePrincipalError __Pre 2011 FolderACL CorruptFolderACL FolderACL, SourcePrincipalError __Pre 2011 FolderACL CorruptFolderACL FolderACL, TargetPrincipalError __Pre 2011 FolderACL CorruptFolderACL FolderACL, SourcePrincipalError __2011-2012 FolderACL CorruptFolderACL FolderACL, SourcePrincipalError __2011-2012 FolderACL CorruptFolderACL FolderACL, TargetPrincipalError __2011-2012 FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Contacts FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Contacts FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Recipient Cache FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Recipient Cache FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Recipient Cache FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Recipient Cache FolderACL CorruptFolderACL FolderACL, SourcePrincipalError PeopleCentricConversation Buddies FolderACL CorruptFolderACL FolderACL, SourcePrincipalError PeopleCentricConversation Buddies FolderACL CorruptFolderACL FolderACL, SourcePrincipalError PeopleCentricConversation Buddies FolderACL CorruptFolderACL FolderACL, SourcePrincipalError PeopleCentricConversation Buddies FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Organizational Contacts FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Organizational Contacts FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Organizational Contacts FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Organizational Contacts FolderACL CorruptFolderACL FolderACL, SourcePrincipalError GAL Contacts FolderACL CorruptFolderACL FolderACL, SourcePrincipalError GAL Contacts FolderACL CorruptFolderACL FolderACL, SourcePrincipalError GAL Contacts FolderACL CorruptFolderACL FolderACL, SourcePrincipalError GAL Contacts FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Companies FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Companies FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Companies FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Companies FolderACL CorruptFolderACL FolderACL, SourcePrincipalError {A9E2BC46-B3A0-4243-B315-60D991004455} FolderACL CorruptFolderACL FolderACL, SourcePrincipalError {A9E2BC46-B3A0-4243-B315-60D991004455} FolderACL CorruptFolderACL FolderACL, SourcePrincipalError {06967759-274D-40B2-A3EB-D7F9E73727D7} FolderACL CorruptFolderACL FolderACL, SourcePrincipalError {06967759-274D-40B2-A3EB-D7F9E73727D7} FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar FolderFreeBusyACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar FolderFreeBusyACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar FolderFreeBusyACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar FolderFreeBusyACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar FolderFreeBusyACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar FolderFreeBusyACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar FolderFreeBusyACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar_JFK3F8.ics FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar_JFK3F8.ics FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar_JFK3F8.ics FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar_JFK3F8.ics FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar_JFK3F8.ics FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar_JFK3F8.ics FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar_JFK3F8.ics FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar_JFK3F8.ics FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Calendar_JFK3F8.ics FolderACL CorruptFolderACL FolderACL, TargetPrincipalError Calendar_JFK3F8.ics FolderACL CorruptFolderACL FolderACL, SourcePrincipalError Freebusy Data Model walkthrough with NT CorruptItem Calendar, Item, StartMustExistCalendarCorruption Calendar
Maximum Number of Mail Contacts can we create in a Exchange online
I would like to inquire about the supported limit for creating Mail Contacts in an Exchange Online environment under a Microsoft 365 tenant licensed with the Business Basic plan. Specifically, we need to know: What is the maximum number of Mail Contact objects that can be created in the tenant? 2. Are there any technical or service limitations tied to the Business Basic plan regarding Mail Contact creation? 3. Would creating a large number (e.g., 5,000 to 10,000) of Mail Contacts have any impact on tenant performance or directory synchronization? 4. Do these limits vary based on tenant type, region, or licensing tier?Managing Large Shared Mailboxes in Exchange Online – Performance Strategies and Trade-offs
Hey everyone, We’re managing very large shared mailboxes (>30 GB) in Exchange Online. These mailboxes are accessed by multiple users, with constant activity — dozens of emails being read, moved, flagged or replied to per minute. Now: - If we cache the shared mailbox in Outlook, the .ost file grows massively (10–20+ GB), which leads to local performance issues and even sync glitches. - If we don’t cache, then Outlook has to fetch everything live from Exchange Online, which introduces delays and makes search slower or inconsistent. => So basically, performance sucks either way. What we’ve learned so far: Shared mailboxes are treated like secondary mailboxes in Outlook, meaning: They sync slower than the primary mailbox. Push notifications from Exchange are limited or absent. Outlook often polls instead of getting real-time updates. Microsoft applies throttling policies per mailbox and tenant, which affects shared mailboxes with many concurrent users. OWA (Outlook Web Access), and the new Outlook app (One Outlook), use a persistent connection (WebSockets / streaming), allowing true real-time updates — no polling, no .ost reliance, no lag. The classic Outlook (Win32) client relies on MAPI and old-style caching behavior, which makes it less ideal for fast-paced shared mailbox environments. What we’re now considering: Should we move high-activity shared mailboxes to be accessed via OWA or the new Outlook app, where real-time sync is better? Should we split large shared mailboxes into smaller functional ones (e.g. support@, sales@, escalations@) to reduce contention? Should we still use caching, but limit it to Inbox + Sent Items and 3–6 months, and invest in better client hardware (faster SSDs, 16–32GB RAM)? Is it worth mapping shared mailboxes as full secondary accounts rather than traditional shared folders, to improve sync reliability (with the right licensing)? Or should we just give users personal mailboxes instead, and use distribution groups or automation for collaboration?
Shared Mailbox can have a password and login enabled without license
I'm very much aware of the license requirements for Shared Mailboxes in Exchange Online and for all Shared Mailboxes we always give licensed users access to them. If we need to login to the actual shared mailbox, we assigned them a license. This could be necessary if you also have some 3rd party application that actually need to login to the mailbox and fetch e-mail for some reason. I have recently realized that you CAN actually set a password to a Shared Mailbox. Just go to admin.microsoft.com > Users > Active Users > select the Shared Mailbox > Reset password. After this, you can login with the username/password. Of course, if you access it via portal.office.com you won't see Outlook but if you go directly to outlook.office365.com you will get access to the mailbox. Anyone know anything more about this feature? Limitations? I'm not looking to break the licensing terms, all our physical users for all our customers have their own personal accounts but there are scenarios where you have a 3rd party application accessing the mailbox for some reason.Replacing Litigation Holds with Microsoft 365 Retention Policies
Litigation holds can retain mailbox data, but that’s it. You can swap litigation holds out for a Microsoft 365 retention policy and gain extra functionality, such as retaining OneDrive for Business content for the mailbox owners. It’s easy to script the transition from litigation holds to retention policy using PowerShell and to show how, we include a fully working script. https://office365itpros.com/2025/05/14/microsoft-365-retention-policy/How to Find Active EWS-Based Apps in a Microsoft 365 Tenant
Microsoft will retire Exchange Web Services (EWS) from Exchange Online on October 1, 2026. A new usage report helps tenants understand what apps use EWS. Many of the apps are likely to be first-party (Microsoft) apps, but some might be third-party apps developed externally or internally. Those apps need to be retired or upgraded to use Graph APIs. Time is slipping away to do the work. https://office365itpros.com/2025/04/29/exchange-web-services-apps/
Missing emails
Got a weird one here and hoping someone else has seen this before. Scenario: Internal user sends an email to about 15 other internal users. I see the sent item in message trace, delivering successfully for all recipients. Days later, the sender and recipients can not locate the item in their mailboxes. I spot check one of the recipients and perform as thorough of a search on their mailbox as I can and am unable to locate it. All recipients claim to have not permanently deleted the item. What I've done: I did multiple content searches with scopes of varying depth, none of them have found the item. I checked audit logs for 'move to deleted' and 'delete from deleted', nothing. I checked Defender to see if the item had any post delivery processing performed, nothing. The trace shows successful delivery, Explorer in Defender portal shows the same, yet the item is undetectable. I don't know what I'm missing as far as what system could have snagged that item out of the mailboxes, which I'm assuming happened since the content searches are coming up empty. For the affected users, there are no commonalities regarding delegate access. There are 3 administrative users for the environment - none recall performing any purge for this item. There are no logs of a purge of this item that I can find.Use an OWA Mailbox Policy to Block Attachment Download for the New Outlook for Windows
The ConditionalAccessPolicy setting in an OWA mailbox policy can be configured to work with Entra ID conditional access so that OWA blocks access to attachments on unmanaged devices. Microsoft originally introduced the feature in 2018 and as it turns out, the combination of OWA mailbox policy and CA policy also blocks attachment access for the new Outlook for Windows client. https://office365itpros.com/2025/05/13/owa-mailbox-policy-new-outlook/Microsoft Changes Strategy for High Volume Email
A surprise announcement brings the news that the Exchange Online High Volume Email (HVE) solution will only deliver messages to internal recipients from June 2025. Azure ECS is now the sole offering for sending large volumes of email to external recipients. On the upside, HVE will support basic authentication until September 2028 to give tenants the chance to upgrade devices and apps. https://practical365.com/hve-new-strategy/
