ARC verification fail (40) on specific Exchange Online frontends - recurring issue
Hello, We are observing recurring arc=fail (40) errors on messages forwarded through Exchange Online, caused by specific frontend servers. The same messages pass ARC verification correctly on other providers (Google, etc.). Affected frontends identified so far: CH2PEPF0000013F.namprd02.prod.outlook.com - build 15.20.9700.17 (March 14, 2026) CH3PEPF0000000B.namprd04.prod.outlook.com - build 15.20.9769.17 (April 6, 2026) Both share the same build suffix .17. The signing implementation on our side has been cryptographically verified as correct and RFC 6376 compliant. The issue has also been reported on the IETF ietf-smtp mailing list with full technical analysis. Cryptographic analysis shows the failing servers append a spurious trailing \r\n to the last header before computing the verification hash, violating RFC 6376 Section 3.7. Is there a pattern with .17 frontend builds and ARC verification? Reagards VittorioOAB download fails after hybrid mailbox move.
Hi folks, I'm posting this query here as I doubt anyone in the Outlook forums would have the necessary Exchange hybrid knowledge. I run a classic hybrid Exchange environment where Exchange Server 2019 CU15 is the on-premise platform. Authentication is provided by on-premise AD FS, with the accounts being synchronised from on-premise via AAD Connect. I've just moved my on-premise mailbox to Exchange Online via New-MoveRequest and for the most part, everything is fine. One thing that possibly isn't fine - going off the Bits-Client event log is the regular offline address book downloads, where I'm seeing regular failures in the event log and through double-checking with bitsadmin.exe. The initial address book synchronisation worked as the view in Outlook is fully populated, however, I expect that future changes likely won't come through. bitsadmin output Event log output (There's numerous events to choose from - this is the one I'm most curious about.) The BITS service provided job credentials in response to the UNIDENTIFIED authentication challenge from the outlook.office365.com server for the Microsoft Outlook Offline Address Book <guid> transfer job that is associated with the following URL: /OAB/<guid>/oab.xml. The credentials for the <sid> user were rejected. When the mailbox was on-premise, the OAB came from the Exchange Server - no surprise there, where post migration it can be seen from the bitsadmin output it now comes from outlook.office365.com. Perhaps that's also to be expected - I don't know, but it makes sense given the move. What alerted me to there potentially being an issue is the systray icon frequently gets stuck on the "synchronising" icon, and running a manual full OAB sync from within Outlook fails to complete. After an extended "hang" period, the sync window eventually times out with the error shown above (the protracted UI behaviour would appear to be due to the large number of retries). Dropping the BITS job URL into Edge simply returns a HTTP 503, which doesn't necessarily strike me as a problem. After all, I'm unable to provide a BEARER token using this method. I haven't yet tried via PowerShell as it only occurred to me now but perhaps I'll do so after posting this. Searching on this error and scenario has turned up nothing useful. I have also checked and compared event log entries from an Azure AD-native account, where it's a mixed bag of successful OAB BITS downloads and unsuccessful ones that feature the same symptoms as above, which offers up the possibility this might be a transient service-side error (though I'm not leaning heavily towards this). Has anyone else encountered this issue and resolved it? Is it even an issue to begin with, or is this expected behaviour? I'm unsure what to make of the symptoms. Cheers, Lain
Can we hide default address lists in Outlook Address Book and show only custom ones?
There are existing Custom Address Lists. When users use the MS Outlook App (Office 2019) and open the Address Book, is it possible to hide the other address lists (including domain-sg-GAL, Global Address List, and domain-sg-Rooms), and only display the Custom Address Lists (domain-HK-AL and domain-sg-AL) — the ones shown in green in the photo?Exchange database dismounted due to NTFS file extent limit reached – unexpected outage
Hi everyone, We experienced a serious outage on our Exchange 2016 server recently, and I wanted to share what we found during the root cause analysis – in case it helps someone else avoid the same scenario. Summary: After digging deep, we discovered that the issue was caused by the NTFS file system hitting its internal file extent limit on the .edb file. Once this threshold was reached, the database could no longer grow, and the system dismounted the database unexpectedly. No prior warning, just service interruption. Details: The .edb was around 1.2 TB in size. This isn’t a limit on database size itself — it’s about how fragmented the file is on disk. Once NTFS couldn’t track any more extents, the database stopped working. Microsoft doesn’t publish a clear fix for this; only scattered references to similar behavior in past cases. What we did: Created a fresh, clean database. Manually moved user mailboxes into the new DB. The old database couldn't be mounted anymore, so we brought the system live without historical mail – just to maintain continuity. We're now working on extracting data from the unmounted .edb using third-party tools. Looking for thoughts: Has anyone else hit the NTFS extent wall with Exchange? How do you monitor extent growth proactively? Did switching to ReFS solve this for you long-term? Open to any input or similar experiences – appreciate it in advance. Thanks!
Does Exchange Online have an internal search Index for people ?
Hello everyone, I'm managing users with Office 365 E3 licences. We have an hybrid Exchange Online / Exchange On-Premise architecture. My problem is the following: After I create an user with E3 licence, and after AAD Synchronisation between Azure / AD, the user is created on Azure but also the email mailbox (Exchange Online). But within the "To" input, through the Autocomplete suggestions, this user cannot be found, neither with Outlook Desktop Client nor with OWA Outlook (Web version of Otlook), even several hours later of the creation. I can use the mailbox (can login to OWA Outlook), can send / receive. So the mailbox is created correctly. I can connect to Exchange-Online via PowerShell and get all informations for the target mailbox (like others) with: Get-Recipient -Identity "email address removed for privacy reasons" And also via Get-Recipient -Anr "elon" (this gives me "Elon, Musk" as a suggestion through PowerShell). But why the autocomplete cannot suggest me this user ? Through the GAL (Global Address List) the user is visible (when I click on "To" button within Outlook Desktop Client -> Popup showing the Global Address List). But it's not suggested automatically, like others (old users). I made several hours of searches but I do not found any concluant result. My only question is: does Exchange Online infrastructure have an internal Search Index for People ? And if so, how often it's updated to include newly added users to the tenant? On what is based the autosuggestions within the inputs "To" / "CC" / "CCI". In my case (at least), the search for autosuggestions cannot be based on Global Address List / Offline Address Book from our On-Premise Exchange server, because EVEN the Web based OWA Outlook cannot find the newly created user! Thank you in advance for your precious help! Best Regards, Adam J.
OL client in-app link for getting OL for iOS or Android not working
Hello! Redirected to this forum from here: https://learn.microsoft.com/en-us/answers/questions/5617563/ol-desktop-link-broken-file-get-ol-app-for-ios-and See error description and attempt to solve it by following the link. For some reason, Windows clients in our organization can not follow the Outlook desktop client in-app link for getting Outlook for iOS or Android. (hybrid, no mailboxes in MS-cloud, only on prem) The link for getting the Outlook app for iOS and Android under File when logged into Outlook app does not seem to work. Clicking on it seems to send user to the URL: go.microsoft.com/fwlink/?LinkId=2112779 but quickly redirects and ends up with https://w2.outlook.com/l/mobile?WT.mc_id=Backstage**Win32**All**Hyperlink** https://learn-attachment.microsoft.com/api/attachments/cb7d456f-ac6e-4566-a4ef-ffa912500423?platform=QnAhttps://learn-attachment.microsoft.com/api/attachments/cb7d456f-ac6e-4566-a4ef-ffa912500423?platform=QnA We haven't been able to figure out why, but since the same two different accounts mentioned in the thread above works on a private device on a private home network, is seems like something in our environment is the cause.
