Outlook clients receive error 0x8004010f when downloading the Offline Address Book
EDIT 10/01/2008: To read the updated (and more comprehensive) guidance for troubleshooting errors 0x8004010f, please go here. There are a multiple reasons for why an Outlook client can receive the 0x8004010f sync error. Unfortunately, 0x8004010f is just a generic MAPI error and will show up for a variety of problems. Here is what the error looks like under err.exe (Microsoft Exchange Server Error Code Look-up Tool): C:\WXP\system32>err 0x8004010f # for hex 0x8004010f / decimal -2147221233 ecNotFound ec.h ecAttachNotFound ec.h ecUnknownRecip ec.h ecPropNotExistent ec.h MAPI_E_NOT_FOUND mapicode.h # 5 matches found for "0x8004010f" This is what the error looks like from the sync log from within Outlook: 12:45:53 Synchronizing Mailbox <dgoldman> 12:45:53 Done 12:45:54 Microsoft Exchange offline address book 12:45:54 0x8004010f Some of the most common reasons for Outlook clients to receive the 0x8004010f error with regards to downloading the OAB are listed below. Most of these are documented and I have linked articles to each of these to help everybody out. Please note that these solutions can change a small bit depending on unknown factors in a company's environment. An administrator decommissioned the last Exchange server in a site and never pushes replicas to another Exchange server. A new OAB is created in the active directory and the information store never reads the active directory during its maintenance schedule. This will result in the OAB files never being generated and the Outlook client will fail to download anything. The information store has an invalid EntryID that points to the legacy EX:/ folders. Again there is nothing for the client to download. An outlook client logging in from one domain to another domain and attempting to log in to another users mailbox. The OAB was never generated or some OAB folders are missing from the public folder store. Multiple OAB Version folders exist of the same type. Clients are attempting to download the OAB files from a public folder store that have not received the replicated updates. The offline address book list object has a missing address list. The offline address book list object has an incorrect address list. Send/As changes in the store affect users accounts with no mailbox full rights to another mailbox. If you are seeing this error on an Exchange 2007 server and your OAB is generated by an Exchange 2007 server, please make sure of the following: 1. Make sure that you have added the replicas of OAB to the Exchange 2007 server 2. Make sure public folder replication is working. 3. Make sure the OAB is public folder enabled and you have OAB Version 2, OAB Version 3 and OAB Version 4 checked off so your legacy clients can download the OAB files from the public folder store. 4. Make sure that if you are using an Outlook 2007 client, your OAB is Web Distribution enabled and the OAB files have been replicated over to the Client Access Server. For more information on this process please see this blog: http://blogs.msdn.com/dgoldman/archive/2006/10/23/outlook-client-fails-to-download-the-oab-with-error-0x8004011b.aspx and http://blogs.msdn.com/dgoldman/archive/2006/08/25/How-Exchange-2007-OAB-Files-are-replicated-to-a-Client-Access-Server-for-download.aspx 5. If you are removing your last Exchange 2003 server from the org, please make sure that you follow our documentation on this process. - Dave GoldmanWhy do Apple macOS and Ubuntu clients display Exchange meeting times one hour earlier than scheduled
If a meeting is generated from Apple macOS and Ubuntu clients showing the meeting time as one hour earlier than the actual scheduled time email solution is exchange server 2019, what will be the issue.
Business Standard with Exchange Plan 2 NOW only showing 100GB of email space
FOR THE PAST 3 YEARS, we have 15 users with Microsoft Business Standard with 100GB of email storage space and 11 with Microsoft Business Premium with 100GB of email storage. I have 1 Business Standard with Exchange On-line Plan2, and 1 with Exchange On-line Plan2. Both have always jhad 150GB of usable mailbox storage. Both users for several years, leading up to September 18, 2026 had over 100GB of mail in their mailboxes and had no problems sending or receiving email, ever. THEN ALL OF THE SUDDEN on 9/18/2026, these 2 users with Plan 2 are no longer able to receive any email and it now shows their mailbox is full Even though checking active users details about mail for both of these users shows 150GB storage. In investigating further, in the exchange area of the admin portal, checking mailboxes indeed both of these 2 USERS ONLY SHOW 100GB, which is the exact same as all my other users who are not paying for Exchange PLAN 2. HOW DO I REPORT this to Microsoft?
IMAP Mail Migration
Hello Microsoft Community, We are currently performing a mailbox migration from Google Workspace (Gmail) to Microsoft 365 Exchange Online using the IMAP migration method. The customer's environment is configured for split routing/coexistence, where both Google Workspace and Microsoft 365 are actively being used during the migration process. Mail flow is functioning as expected; however, we are experiencing extremely slow migration performance. For example, a mailbox containing approximately 10 GB of data is taking nearly two weeks to migrate, which is significantly impacting the overall project timeline. We would appreciate guidance on the following: Is this migration speed expected when using the IMAP migration method from Google Workspace to Exchange Online? Does Exchange Online enforce any throttling limits that can affect IMAP migration throughput? Can split routing or coexistence between Google Workspace and Microsoft 365 impact IMAP migration performance? Is there a recommended number of concurrent mailbox migrations or migration batch size for optimal performance? Are there any Google Workspace-side limitations, API restrictions, or throttling settings that should be reviewed? What Microsoft-recommended configurations or best practices can help improve IMAP migration speed? If higher migration throughput is required, does Microsoft recommend an alternative migration approach instead of IMAP? If split routing/coexistence must remain active throughout the migration project, what is the recommended Microsoft-supported migration method? We are trying to identify whether the bottleneck is on the Exchange Online side, Google Workspace side, or related to the coexistence configuration. Any troubleshooting guidance, performance recommendations, or Microsoft documentation references would be greatly appreciated.
Outlook Desktop users continually prompted for credentials On-Prem Exchange SE
Battling ongoing issues with users being continually prompted for password using Outlook 2024 LTSC with on-prem Exchange 2019 SE. Removed Windows credentials, turned off cache mode, removed shared calendar(s), outlook connection status seems fine. Only (temp) workaround seems to be removing mail profile and recreating it. All other network resources on domain are fine. Any input appreciated. Thanks
