Symptoms
After you install the November 2021 security updates (KB5007409) for Microsoft Exchange Server 2019, 2016, or 2013, Outlook on the web (OWA) redirection in a hybrid environment is broken.
For on-premises deployments, the inter-site OWA redirection might also stop working for environments that are not using the forms-based authentication (FBA) protocol.
Expected behavior
For hybrid environments
When a user who has an Exchange Online mailbox logs in to OWA on-premises, they receive a redirect URL that points them to https://outlook.office.com.
For on-premises environments
In an Exchange deployment that spans multiple Active Directory (AD) sites that use different URLs to access OWA (for example, site 1 = https://site1.contoso.com/owa, and site 2 = https://site2.contoso.com/owa), a user who has a mailbox in site1 and who logs in to OWA by using the "site2" URL will be silently redirected to the "site1" URL.
Actual behavior
In both the expected scenarios, the user can't log in, and receives the following error message in Exchange Server 2019 or 2016:
Something went wrong.
The user receives the following error message in Exchange Server 2013:
External component has thrown an exception.
Resolution
This problem is fixed in January 2022 security update for Microsoft Exchange Server. Install the January security update to resolve the OWA redirection problem that's mentioned in the "Symptoms" section.
If you can't install the January security update, use one of the methods from the next section to work around the OWA redirection problem.
Workaround
Workaround 1
Configure the OWA and ECP virtual directory on all the affected front-end servers to use FBA.
Workaround 2
Ask users from each site to use the appropriate site-specific OWA URL to log in.
Example:
Users who have a mailbox on site 2 should use https://site2.contoso.com/owa.
Workaround 1
Users can use the direct URL for Exchange Online OWA in the browser at https://outlook.office.com/owa.
Workaround 2
Note The following workaround applies to only Exchange Server 2019 and Exchange Server 2016.
Exchange Server admins can use the redirect rule to modify the redirect URL so that the error does not appear to users. The steps for this workaround have to be configured on all servers that handle OWA traffic.
Steps to apply the URL rewrite
-
Open IIS Manager. In the Connections pane, expand <ServerName>, expand Sites, and then select Default Web Site.
Note In this step, replace <ServerName> with the name of your server. -
In the Features (center) pane you should see the URL Rewrite feature in the IIS area. If you do not see it, the feature might not be installed. In this case, you can download the installation package from URL Rewrite: The Official Microsoft IIS Site. This installation does not require a restart. However, it will restart the IIS app pools.
Note Make sure that you install the X64 version.If the URL rewrite module is already installed on the servers, and the servers are configured similarly by using pathing, then you can copy the Web.config file from the Wwwroot folder on the first server to the other servers after you make the change. Notice that you might have to wait a short while for the changes to take effect on the first server.
-
Double-click URL Rewrite.
-
In the Actions pane, select Add Rule(s).
-
In the Add Rule(s) window, under Inbound Rules, select Blank Rule, and then select OK.
-
On the Edit Inbound Rule screen, in the Name box, enter Nov21 OWA redirect fix.
-
Leave Requested URL as Matches the Pattern.
-
Change the value of Using to Wildcards.
-
For Pattern, enter *owa/Auth/errorFE.aspx*.
-
Leave Ignore case selected.
-
Select the Conditions list to expand it, and then select Add.
-
In the Edit Condition dialog box, in the Condition input box, enter {REQUEST_URI}.
-
Leave Check if input string as Matches The Pattern.
-
For Pattern, enter *\u0026*\u0026*\u0026*.
-
Select OK.
-
In the Action dialog box, select Rewrite in the Action type list.
-
Under Action Properties, in the Rewrite URL text box, enter the following code:
{C:1}&{C:2}&{C:3}&{C:4} -
Clear the Append Query String checkbox.
-
Select the Log rewritten URL checkbox.
-
In the Actions pane, select Apply.
-
Select Apply, and then select Back To Rules.
-
In the URL Rewrite window, select the rule that you just created, and then check in the Actions pane under Inbound Rules to verify that the rule is enabled.
This new rule should not require an IIS reset, and it should take effect as soon as you enable it. You can now test it by using OWA (by using the account that reproduced the problem) to verify that you get the expected URL redirection.
Enabling logging to verify the rule action
To verify the expected redirection behavior, you can use failed request tracing. To do this, follow these steps:
-
Open IIS Manager. In the Connections pane, select Default Web Site.
-
In the Actions pane under Configure, select Failed Request Tracing.
-
In the Edit Website Failed Request Tracing Setting dialog box, select Enable.
-
Leave the values unchanged for Directory and Maximum number of trace files.
-
Select OK.
-
In the center pane, double-click Failed Request Tracing.
-
In the Actions pane, select Add.
-
Select Custom, and enter errorFE.aspx.
-
For Status codes, enter 100-900, and then select Finish.
-
Clear the ASP, ASPNET, and ISAPI Extension checkboxes.
-
Select WWW Server. Under Areas, deselect all but the last option (which should be Rewrite).
-
Select Finish.
-
Try again to log in to an Exchange Online mailbox in on-premises OWA.
-
In Windows Explorer on the affected server, navigate to C:\inetpub\logs\FailedReqLogFiles.
-
Double-click the latest .xml file. If you haven’t done tracing earlier, this file will likely be Fr000001.xml.
-
Select the last line, which should be See all events for the request.
-
Look for URL_REWRITE_START and URL_REWRITE_END. Examine the content in-between these events. You should see the following entries:
ULE_EVALUATION_START
PATTERN_MATCH
CONDITION_EVALUATION
REWRITE_ACTION
RULE EVALUATION_END -
Verify the REWRITE_ACTION value. Rewrite should now have all the \0026 patterns changed to an ampersand (&).
Deploying to multiple servers
After you complete these procedures on one server, it can be easily deployed to multiple servers as long as the URL rewrite module that was previously mentioned is already installed on all Exchange Client Access servers.
We recommend that you make a backup of the current Web.config file on all the servers. However, after the changes are made on the server that you created the rule on, you can copy the Web.config file from the C:\inetpub\wwwroot folder on that server to the same location on each of the other servers. Notice that you might have to wait a while for the configuration changes to take effect. To speed up the process, you can run an iisreset command.
