OAB 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