Gepubliceerde agenda (.ics) retourneert HTTP 500 voor agendatoepassingen

Nadat u de beveiligingsupdate van augustus 2026 (Exchange Server SE, build 15.2.2562.46) hebt geïnstalleerd, worden abonnementen op een anoniem gepubliceerde Exchange-agenda niet meer vernieuwd. De geabonneerde toepassing meldt een serverfout en de URL retourneert HTTP 500.

Meer informatie

Het openen van dezelfde gepubliceerde agenda-URL in een webbrowser werkt normaal en geeft de agenda als resultaat. De server classificeert de client vanaf de header van de User-Agent. Calendar-toepassingen zijn geen webbrowsers. Daarom worden ze niet herkend en wordt de aanvraag doorgestuurd naar een codepad dat door de update van augustus is uitgeschakeld. De aanvraag mislukt vervolgens en retourneert een 'HTTP 500'-bericht.

De volgende clients worden beïnvloed.

Client	Resultaat
Microsoft Outlook, abonnement op internetagenda	HTTP 500
Apple Calendar op iOS en macOS	HTTP 500
Google Calendar, agenda toevoegen van URL	HTTP 500
Mozilla Thunderbird	HTTP 500
Elke gescripte of geautomatiseerde gebruiker van de feed	HTTP 500
Chrome, Edge, Firefox, Safari, Android Chrome, iOS Safari	HTTP 200, agenda geretourneerd

Tijdelijke oplossing

Eén regel voor het herschrijven van URL's toevoegen aan de back-endsite van Exchange in IIS. De regel wordt layout=premium toegevoegd aan .ics aanvragen onder /owa/calendar/. Met deze actie wordt het ondersteunde codepad geselecteerd en wordt de feed hersteld.

Het regelpatroon komt overeen met alle .ics aanvragen onder /owa/calendar/. Daarom worden ook de reachcalendar.ics en gepubliceerde schemafeeds behandeld, die op dezelfde manier mislukken.

Gebruik een van de methoden in de volgende secties. Omdat bij beide methoden dezelfde regel wordt geconfigureerd met hetzelfde bereik, moet u de regel kiezen die het beste bij het wijzigingsproces past.

Methode A: IIS-beheer

1. Open IIS-beheer. Vouw de server uit, vouw Sites uit, selecteer Exchange-backend en dubbelklik vervolgens op URL herschrijven.

   

2. Selecteer in het deelvenster Acties aan de rechterkant de optie Regel(s)..., selecteer Lege regel onder Binnenkomende regels en selecteer vervolgens OK.

   

3. Voer de naam in en vul het gedeelte URL vergelijken aan met de volgende waarden.

   Veld	Waarde
   Name	OWA published calendar force premium layout
   Aangevraagde URL	Komt overeen met het patroon
   Met behulp van	Reguliere expressies
   Patroon	^owa/calendar/.+\.ics$
   Hoofdlettergebruik negeren	geselecteerd

   

4. Vouw Voorwaarden uit, klik op Toevoegen... en voltooi het dialoogvenster met de volgende waarden. Deze voorwaarde laat aanvragen met rust als ze al een indelingsparameter hebben.

   Veld	Waarde
   Input voor voorwaarde	{QUERY_STRING}
   Controleer of de invoertekenreeks	Komt niet overeen met het patroon
   Patroon	(^|&)layout=

   

   Nadat u op OK hebt geklikt, wordt de voorwaarde weergegeven in de lijst, met Logische groepering over bij Alles overeenkomen.

   

5. Vouw actie uit en voltooi deze met de volgende waarden.

   Veld	Waarde
   Actietype	Herschrijven
   URL herschrijven	{R:0}?layout=premium&{QUERY_STRING}
   Queryreeks toevoegen	Uitgeschakeld
   De verwerking van volgende regels stoppen	geselecteerd

   

   Belangrijk

   Schakel het selectievakje Queryreeks toevoegen uit. Als u het selectievakje ingeschakeld laat, wordt de oorspronkelijke querytekenreeks nog een keer toegevoegd. Dit zorgt ervoor dat de aanvraag dubbele parameters heeft.

   Selecteer in het deelvenster Acties de optie Toepassen om de regel op te slaan.

6. Controleer of de regel wordt vermeld in de lijst URL herschrijven . Vouw het uit om de voorwaarde te zien.

   

Prullenbak van een toepassingsgroep is niet vereist. IIS laadt de configuratie automatisch opnieuw.

Methode B: applicationHost.config bewerken

Gebruik deze methode als u configuratie liever als een bestandswijziging wilt implementeren, bijvoorbeeld via een hulpprogramma voor configuratiebeheer.

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

1. Maak een back-up van het bestand.

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

2. Zoek het <location path="Exchange Back End"> element. Als het bestand nog niet bestaat, maakt u het in de hoofdmap van het bestand, naast de andere <location> elementen. Voeg het <rewrite> blok erin <system.webServer>toe:

   <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>
   

Slaat het bestand op. De wijziging wordt automatisch toegepast door IIS.

Verificatie

Voer de volgende opdracht uit vanaf een computer buiten de organisatie, via hetzelfde netwerkpad dat door abonnees wordt gebruikt. Vervang de URL door uw eigen gepubliceerde agendaadres. Met de -A parameter wordt het verzoek gepresenteerd als een agendatoepassing in plaats van een browser, waardoor het probleem wordt gereproduceerd.

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"

Vóór de wijziging:

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

Het verzoek wordt omgeleid naar een foutpagina en er worden geen agendagegevens geretourneerd.

Na de wijziging:

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

Controleer op de waarden HTTP/1.1 200 OK en .Content-Type: text/calendar De Set-Cookie: OwaLight= header is alleen aanwezig wanneer de aanvraag mislukt. Daarom bevestigt het ontbreken ervan dat de regel van kracht is.

Als u de agenda-inhoud wilt zien, verwijdert u uit -o NUL -D - de opdracht. Een werkantwoord begint met BEGIN:VCALENDAR.

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

Voer de volgende opdrachten uit op de server om te controleren of IIS de regel zelf ziet en om te bepalen welk bestand de regel bevat:

& "$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

Controleer ook of de gepubliceerde agenda nog steeds wordt geopend in een browser en of dit niet van invloed is op de normale /owa/ aanmelding.

Terugdraaien

Als u deze tijdelijke oplossing wilt verwijderen, verwijdert u de regel uit IIS-beheer of verwijdert u het <rewrite> blok uit het bestand waarin de regel zich bevindt. Na deze wijziging hoeft u niet opnieuw op te starten.

Controleer beide locaties, want de regel kan op beide locaties worden opgeslagen:

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

Als u de regel uit het ene bestand verwijdert terwijl een kopie in het andere bestand blijft staan, blijft het herschrijven actief.

Gerelateerde informatie

• Pas de regel toe op elke server die de gepubliceerde agenda bedient. Deze regel is een IIS-instelling per server en niet voor de hele organisatie. Een load balancer verdeelt abonnementsaanvragen over alle leden van de matrix. Een server die u over het hoofd ziet, blijft dus een HTTP 500-bericht retourneren. De resulterende intermitterende storing is aanzienlijk moeilijker te diagnosticeren dan een consistente. Controleer de regel op elke server. Ga er niet vanuit dat het overal wordt toegepast.

• Controleer opnieuw na elke cumulatieve update en beveiligingsupdate. De IIS-configuratie op siteniveau overleeft normaal gesproken Exchange-updates, maar het is niet gegarandeerd aan deze voorwaarde. Controleer deze regel in de Exchange-updateprocedure zodat deze tijdelijke oplossing niet verdwijnt tijdens een latere update.

• Dit is een tijdelijke oplossing. Microsoft heeft bevestigd dat dit een bekend probleem is. Het productteam is op de hoogte van het gedrag en evalueert mogelijke verbeteringen in een toekomstige update. Momenteel is er geen geschatte tijdsperiode beschikbaar voor een oplossing. De regel moet worden verwijderd nadat een build met de oplossing is geïmplementeerd.