Exchange online error HTTP status 403 only on one account but not the other account

Young Park 0 Reputation points
2026-09-30T00:59:43.82+00:00

It was confirmed for both email address "EWS" enabled via Powershell script. One connect successfully but the other is still failing for about 8 hours since we updated policy. Is it possible that one could take longer to clear? I just don't want to wait for nothing if there is other thing to check to get connected.

Exchange Online
Exchange Online

A cloud-based service included in Microsoft 365, delivering scalable messaging and collaboration features with simplified management and automatic updates.

0 comments

4 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Young Park 0 Reputation points
    2026-09-30T16:29:33.03+00:00

    It is now connected with Exchange Online. Time is what I needed. It took closed to 24 hrs since the EWS enable update.

    Was this answer helpful?

    0 comments
  2. Vasil Michev 128.2K Reputation points MVP Volunteer Moderator
    2026-09-30T05:50:14.77+00:00

    Functionalities such as Application access policies and RBAC for applications can block access regardless of other controls, so check for these.

    Other than that, consider replacing EWS-based code, as EWS is on its deprecation journey. Part of this involves Microsoft doing "scream tests", with the relevant controls being switched off, in order to highlight any dependencies on EWS code. This blog post has the details: https://techcommunity.microsoft.com/blog/exchange/exchange-online-ews-your-time-is-almost-up/4492361

    Was this answer helpful?

    0 comments
  3. BabybooHN 3,290 Reputation points Independent Advisor
    2026-09-30T02:01:37.52+00:00

    Dear @Young Park

    Thank you for the additional details.

    Since EWS has already been enabled for both accounts, I would like to narrow down whether the 403 response is specific to the affected account or related to the client/request being used.

    Could you please confirm the following:

    • Does the affected account return HTTP 403 consistently, or only when using a specific application/client?
    • Have you tested the affected account from a different device or network? If so, does the same 403 error occur?
    • Are the Exchange Online/EWS settings and permissions for both accounts otherwise identical?
    • Could you provide the exact 403 error message or response, if available?

    If the affected account still fails after 8 hours while the other account works successfully under the same configuration, I would not recommend simply waiting longer without checking these factors. The above information should help identify where the difference lies and determine the next troubleshooting step.

    I look forward to your response.

    Was this answer helpful?

    0 comments

  4. AI answer

    2026-09-30T00:59:57.5433333+00:00

    If the issue is a 403 for Exchange Online connectivity and one account started working after a policy change while the other still fails, the supported guidance in the available documentation is:

    1. Wait and retest if the change was recent. For 403 errors in Exchange hybrid configuration, a timing issue can prevent completion, and the documented resolution is to wait approximately 30 minutes and rerun the operation.
    2. If this is related to mailbox moves or remote connectivity through EWS/MRSProxy, verify the hybrid server EWS virtual directory configuration. In Exchange Management Shell, run: 
         Get-WebServicesVirtualDirectory "ServerName\EWS (Default Web Site)" | FL Server,MRSProxyEnabled
      • If MRSProxyEnabled : False is returned, that is a documented cause of 403 errors.
      • If MRSProxyEnabled : True is returned, check Event Viewer > Application log for event 1309 with MRS proxy service is disabled.
    3. If MRSProxy is disabled, enable it: 
         Set-WebServicesVirtualDirectory "<ServerName>\EWS (Default Web Site)" -MRSProxyEnabled $true
      Then restart IIS with iisreset.
    4. If MRSProxy appears enabled but is still effectively disabled, disable and re-enable it: 
         Set-WebServicesVirtualDirectory "<ServerName>\EWS (Default Web Site)" -MRSProxyEnabled $false
      Wait a few minutes, then run: 
         Set-WebServicesVirtualDirectory "<ServerName>\EWS (Default Web Site)" -MRSProxyEnabled $true
      Then restart IIS with iisreset.
    5. Test Exchange Online to on-premises EWS connectivity: 
         Test-MigrationServerAvailability -RemoteServer <on-premises mail server FQDN> -ExchangeRemoteMove -Credentials (Get-Credential)
      When prompted, use credentials in domain\administrator format.

    Based on the documented guidance, waiting can be valid for some 403 scenarios, but 8 hours is already well beyond the documented 30-minute timing case. The next supported checks are the EWS/MRSProxy state and connectivity test above.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.