Exchange Add-ins not loading for some users

Hi @PatKeeley

Since local COM add-ins are working fine and the problem moves with the user, we can safely rule out machine-level configurations, network drops, or basic Outlook profile corruption. The recent UPN change you mentioned is actually a very strong suspect here; UPN changes frequently cause delayed, residual token or identity mismatch issues. It is highly likely that the underlying EWS GetAppManifests call is either silently failing or throwing a background error for these specific identities. Let's dig into the background processes to see exactly where the connection is dropping. Please try the following steps:

We need to see what Outlook is doing the moment it tries to fetch the add-ins. Do this directly on a machine where the affected user is logged in.

Open the Outlook (classic) desktop app as normal > Immediately open Event Viewer > Windows Logs > Application > Filter the log with the Source set to "Microsoft Office 16" (or "Outlook") and look specifically for Event ID 63. This event triggers right after opening Outlook or clicking on an email when it attempts to load web add-ins.

-If there is no Event 63: Outlook is completely failing to query Exchange for this user's add-ins.

-If Event 63 is present but failed: Note the specific error code. It is highly beneficial to compare this side-by-side with the Event 63 logs from a working user (like yourself) on that exact same machine.

If there is no Event 63, or if it shows an error, we need to force a hard rebuild of the Web Extension Framework cache. You mentioned clearing various app data, but this specific folder often leaves behind hidden GUID/hash subfolders if not completely wiped.

Close Outlook completely > Navigate to: %localappdata%\Microsoft\Office\16.0\WEF\> Delete the entire contents of this folder (or delete the WEF folder entirely) > Reopen Outlook. This forces the client to call GetAppManifests fresh and rebuild the cache. Check the Event Log again after doing this to see if the behavior changed.

On the Exchange 2016 side, when comparing the working and non-working users (likely via the Get-App cmdlet), double-check that Enabled = True is actively set for the affected user's identity. For organization-wide add-ins, specifically verify that the ProvidedTo, UserList, and DefaultStateForUser parameters are correctly applying to their current (or previous) UPN state.

Please let me know your results, or if you have any questions

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Gemini said

Since this issue is user-specific (travels with the user to different machines) but client-specific (works in OWA but not Outlook Desktop), you are dealing with a breakdown in how the Outlook Desktop client authenticates or retrieves the "App List" from the Exchange server.

Given that you've already tried new profiles and basic cache clearing, here are all the possible ways to resolve this, categorized by the level of intervention required.

1. The Identity & UPN Mismatch Fixes

Since a UPN change occurred, Outlook Desktop may be confused about which identity to use for its internal "Web Hub."

Reset the Office Global Identity: Even if you signed out, the registry holds onto the old identity.

Navigate to: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity\Identities.

  __**Delete**__ the subkeys here. This forces the Office "Identity Manager" to create a fresh token based on the current UPN/SMTP.
  
  __**Check the `mail` Attribute:**__ Outlook Desktop often relies on the `mail` attribute in Active Directory to map add-ins. Ensure the `mail` attribute matches the new Primary SMTP/UPN exactly. If OWA works, the server knows the user, but the client-side "discovery" might be failing due to this mismatch.
  

2. Deep Mailbox Configuration (MFCMAPI)

Add-in visibility in Outlook Desktop is controlled by a hidden "dictionary" in the mailbox. If this object is corrupted, OWA (which builds the list on the fly) will work, but Desktop (which caches the list) will not.

Reset the Extension Master List:

Open MFCMAPI > Session > Logon.

  Open the Mailbox Store > __**Root Container**__ > __**Top of Information Store**__.
  
     Right-click __**Inbox**__ > __**Open Associated Contents Table**__.
     
        Look for an item with Message Class: `IPM.Configuration.ExtensionMasterList`.
        
           __**Delete it.**__ (Outlook will regenerate it on the next restart).
           
           __**Clear the OWA User Options:**__
           
              Also in the Associated Contents Table, look for `IPM.Configuration.OWA.UserOptions`. Deleting this resets the web-side settings that Outlook Desktop sometimes "checks" during the add-in handshake.
              

3. Connectivity & Endpoint Validation

Outlook Desktop uses Exchange Web Services (EWS) to load add-ins. OWA does not.

Validate EWS for the User: Run this in Exchange Management Shell:

Get-CASMailbox -Identity <user> | Select EwsEnabled, EwsAllowOutlook.

  If `EwsAllowOutlook` is `$false`, add-ins will fail in Desktop but work in OWA.
  
  __**Test the EWS Metadata URL:**__ From an affected machine, logged in as the affected user, try to browse to:
  
     `https://<YourExchangeServer>/ews/exchange.asmx`.
     
        If you get an auth prompt or a certificate error, the WebView2 control inside Outlook is likely failing to authenticate silently.
        

4. Client-Side "Web Extensions" Reset

You mentioned clearing app data, but specifically, the WEF (Web Extension Framework) cache is the most common culprit for the 64-bit Office 365 app.

The "Nuclear" WEF Clear:

Close Outlook.

  Delete the contents of: `%LocalAppData%\Microsoft\Office\16.0\Wef\`
  
     Delete the contents of: `%LocalAppData%\Microsoft\Office\16.0\Wef\WebView2` (if present).
     
        Restart Outlook and wait 5–10 minutes for the background sync to complete.
        

5. Privacy & Connected Experiences

Microsoft has tied Add-ins to "Optional Connected Experiences."

Go to File > Office Account > Account Privacy > Manage Settings.

Ensure "Enable optional connected experiences" is checked. If this is off, the "Get Add-ins" store and all Exchange-side web add-ins are instantly disabled in the desktop client.

6. Registry "Hard Resets"

If the UPN change left "ghost" accounts in the Office activation layer:

• Disable ADAL/WAM (Temporary Test): * Add DisableADALatopWAMOverride = 1 (DWORD) under HKCU\Software\Microsoft\Office\16.0\Common\Identity.
  • This forces Outlook to use the older, more stable authentication method for Exchange 2016. If add-ins reappear, your issue is a Modern Auth / Token mismatch caused by the UPN change.

    Gemini said

    Since this issue is user-specific (travels with the user to different machines) but client-specific (works in OWA but not Outlook Desktop), you are dealing with a breakdown in how the Outlook Desktop client authenticates or retrieves the "App List" from the Exchange server. Given that you've already tried new profiles and basic cache clearing, here are all the possible ways to resolve this, categorized by the level of intervention required.

    1. The Identity & UPN Mismatch Fixes

    Since a UPN change occurred, Outlook Desktop may be confused about which identity to use for its internal "Web Hub."
    • Reset the Office Global Identity: Even if you signed out, the registry holds onto the old identity.
      • Navigate to: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity\Identities.
      • Delete the subkeys here. This forces the Office "Identity Manager" to create a fresh token based on the current UPN/SMTP.
    • Check the mail Attribute: Outlook Desktop often relies on the mail attribute in Active Directory to map add-ins. Ensure the mail attribute matches the new Primary SMTP/UPN exactly. If OWA works, the server knows the user, but the client-side "discovery" might be failing due to this mismatch.

    2. Deep Mailbox Configuration (MFCMAPI)

    Add-in visibility in Outlook Desktop is controlled by a hidden "dictionary" in the mailbox. If this object is corrupted, OWA (which builds the list on the fly) will work, but Desktop (which caches the list) will not.
    • Reset the Extension Master List:
      1. Open MFCMAPI > Session > Logon.
      2. Open the Mailbox Store > Root Container > Top of Information Store.
      3. Right-click Inbox > Open Associated Contents Table.
      4. Look for an item with Message Class: IPM.Configuration.ExtensionMasterList.
      5. Delete it. (Outlook will regenerate it on the next restart).
    • Clear the OWA User Options:
      • Also in the Associated Contents Table, look for IPM.Configuration.OWA.UserOptions. Deleting this resets the web-side settings that Outlook Desktop sometimes "checks" during the add-in handshake.

    3. Connectivity & Endpoint Validation

    Outlook Desktop uses Exchange Web Services (EWS) to load add-ins. OWA does not.
    • Validate EWS for the User: Run this in Exchange Management Shell:
      • Get-CASMailbox -Identity <user> | Select EwsEnabled, EwsAllowOutlook.
      • If EwsAllowOutlook is $false, add-ins will fail in Desktop but work in OWA.
    • Test the EWS Metadata URL: From an affected machine, logged in as the affected user, try to browse to:
      • https://<YourExchangeServer>/ews/exchange.asmx.
      • If you get an auth prompt or a certificate error, the WebView2 control inside Outlook is likely failing to authenticate silently.

    4. Client-Side "Web Extensions" Reset

    You mentioned clearing app data, but specifically, the WEF (Web Extension Framework) cache is the most common culprit for the 64-bit Office 365 app.
    • The "Nuclear" WEF Clear:
      1. Close Outlook.
      2. Delete the contents of: %LocalAppData%\Microsoft\Office\16.0\Wef\
      3. Delete the contents of: %LocalAppData%\Microsoft\Office\16.0\Wef\WebView2 (if present).
      4. Restart Outlook and wait 5–10 minutes for the background sync to complete.

    5. Privacy & Connected Experiences

    Microsoft has tied Add-ins to "Optional Connected Experiences."
    • Go to File > Office Account > Account Privacy > Manage Settings.
    • Ensure "Enable optional connected experiences" is checked. If this is off, the "Get Add-ins" store and all Exchange-side web add-ins are instantly disabled in the desktop client.

    6. Registry "Hard Resets"

    If the UPN change left "ghost" accounts in the Office activation layer:
    • Disable ADAL/WAM (Temporary Test): * Add DisableADALatopWAMOverride = 1 (DWORD) under HKCU\Software\Microsoft\Office\16.0\Common\Identity.
      • This forces Outlook to use the older, more stable authentication method for Exchange 2016. If add-ins reappear, your issue is a Modern Auth / Token mismatch caused by the UPN change.