Published calendar (.ics) returns HTTP 500 for calendar applications

After you install the August 2026 security update (Exchange Server SE, build 15.2.2562.46), subscriptions to an anonymously published Exchange calendar stop refreshing. The subscribing application reports a server error, and the URL returns HTTP 500.

More information

Opening the same published calendar URL in a web browser works normally and returns the calendar. The server classifies the client from its User-Agent header. Calendar applications aren't web browsers. Therefore, the server doesn't recognize them, and routes the request to a code path that the August update disabled. The request then fails and returns an "HTTP 500" message.

The following clients are affected.

Client	Result
Microsoft Outlook, internet calendar subscription	HTTP 500
Apple Calendar on iOS and macOS	HTTP 500
Google Calendar, add calendar from URL	HTTP 500
Mozilla Thunderbird	HTTP 500
Any scripted or automated consumer of the feed	HTTP 500
Chrome, Edge, Firefox, Safari, Android Chrome, iOS Safari	HTTP 200, calendar returned

Workaround

Add one URL Rewrite rule to the Exchange Back End site in IIS. The rule appends layout=premium to .ics requests below /owa/calendar/. This action selects the supported code path, and restores the feed.

The rule pattern matches any .ics request below /owa/calendar/. Therefore, it also covers the reachcalendar.ics and published schedule feeds, which fail in the same way.

Use either method in the following sections. Because, both methods configure the same rule at the same scope, choose whichever suits your change process.

Method A: IIS Manager

1. Open IIS Manager. Expand the server, expand Sites, select Exchange Back End, and then double-click URL Rewrite.

   

2. In the Actions pane on the right, select Add Rule(s)..., select Blank rule under Inbound rules, and then select OK.

   

3. Enter the name and complete the Match URL section with the following values.

   Field	Value
   Name	OWA published calendar force premium layout
   Requested URL	Matches the Pattern
   Using	Regular Expressions
   Pattern	^owa/calendar/.+\.ics$
   Ignore case	selected

   

4. Expand Conditions, click Add... and complete the dialog with the following values. This condition leaves requests alone if they already carry a layout parameter.

   Field	Value
   Condition input	{QUERY_STRING}
   Check if input string	Does Not Match the Pattern
   Pattern	(^|&)layout=

   

   After you click OK, the condition appears in the list, with Logical grouping left at Match All.

   

5. Expand Action and complete it with the following values.

   Field	Value
   Action type	Rewrite
   Rewrite URL	{R:0}?layout=premium&{QUERY_STRING}
   Append query string	cleared
   Stop processing of subsequent rules	selected

   

   Important

   Clear the Append query string checkbox. If you leave the checkbox selected, IIS appends the original query string a second time. This causes the request to have duplicated parameters.

   In the Actions pane, select Apply to save the rule.

6. Verify that the rule is listed in the URL Rewrite list. Expand it to see the condition.

   

No application pool recycle is required. IIS reloads the configuration automatically.

Method B: Edit applicationHost.config

Use this method if you prefer to deploy configuration as a file change, for example through a configuration management tool.

File: C:\Windows\System32\inetsrv\config\applicationHost.config

1. Back up the file.

   Copy-Item C:\Windows\System32\inetsrv\config\applicationHost.config "C:\Windows\System32\inetsrv\config\applicationHost.config.bak-$(Get-Date -f yyyyMMdd-HHmmss)"
   

2. Locate the <location path="Exchange Back End"> element. If it doesn't exist, create it at the root of the file, alongside the other <location> elements. Add the <rewrite> block inside <system.webServer>:

   <location path="Exchange Back End">
     <system.webServer>
       <rewrite>
         <rules>
           <rule name="OWA published calendar force premium layout" stopProcessing="true">
             <match url="^owa/calendar/.+\.ics$" />
             <conditions>
               <add input="{QUERY_STRING}" pattern="(^|&amp;)layout=" negate="true" />
             </conditions>
             <action type="Rewrite" url="{R:0}?layout=premium&amp;{QUERY_STRING}" appendQueryString="false" />
           </rule>
         </rules>
       </rewrite>
     </system.webServer>
   </location>
   

Save the file. IIS applies the change automatically.

Verification

Run the following command from a machine outside the organization, over the same network path that subscribers use. Replace the URL with your own published calendar address. The -A parameter presents the request as a calendar application rather than a browser, which is what reproduces the problem.

curl.exe -s -o NUL -D - -A "iOS/26.6.1 (23G83) dataaccessd/1.0" "https://mail.contoso.com/owa/calendar/{id}/{token}/calendar.ics"

Before the change:

HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: /owa/calendar/auth/errorFE.aspx?httpCode=500
Set-Cookie: OwaLight=; expires=Mon, 24-Aug-2026 13:47:06 GMT; path=/
Content-Length: 161

The request is redirected to an error page, and no calendar data is returned.

After the change:

HTTP/1.1 200 OK
Content-Type: text/calendar; charset=utf-8
Content-Length: 1780

Check for the values, HTTP/1.1 200 OK and Content-Type: text/calendar. The Set-Cookie: OwaLight= header is present only when the request fails. Therefore, its absence confirms that the rule is in effect.

To see the calendar content, remove -o NUL -D - from the command. A working response begins with BEGIN:VCALENDAR.

curl.exe -s -A "iOS/26.6.1 (23G83) dataaccessd/1.0" "https://mail.contoso.com/owa/calendar/{id}/{token}/calendar.ics"

To verify that IIS itself sees the rule, and to determine which file holds it, run the following commands on the server:

& "$env:windir\System32\inetsrv\appcmd.exe" list config "Exchange Back End" -section:system.webServer/rewrite/rules
Select-String -Path "$env:windir\System32\inetsrv\config\applicationHost.config" -Pattern 'OWA published calendar'
Select-String -Path "$env:ExchangeInstallPath\ClientAccess\web.config" -Pattern 'OWA published calendar' -ErrorAction SilentlyContinue

Also, verify that the published calendar still opens in a browser, and that normal /owa/ sign-in is unaffected.

Rollback

To remove the workaround, delete the rule in IIS Manager, or remove the <rewrite> block from the file that holds it. This change doesn't require a restart.

Check both locations, because the rule can be stored in either one:

• C:\Windows\System32\inetsrv\config\applicationHost.config
• %ExchangeInstallPath%\ClientAccess\web.config

If you remove the rule from one file while a copy remains in the other, the rewrite stays active.

Related information

• Apply the rule on every server that serves the published calendar. This rule is a per-server IIS setting, not an organization-wide one. A load balancer distributes subscription requests across all members of the array. Therefore, a server that you miss continues to return an "HTTP 500" message. The resulting intermittent failure is considerably harder to diagnose than a consistent one. Verify the rule on each server. Don't assume that it's applied everywhere.

• Recheck after each cumulative update and security update. Site-level IIS configuration normally survives Exchange updates, but this condition isn't guaranteed. Include a check of this rule in your Exchange updating procedure so that the workaround doesn't disappear during a future update.

• This is a temporary workaround. Microsoft has confirmed this as a known issue. The product team is aware of the behavior and is evaluating potential improvements in a future update. Currently, no estimated timeframe for a resolution is available. The rule should be removed after a build that contains the fix is deployed.