Veröffentlichter Kalender (.ics) gibt HTTP 500 für Kalenderanwendungen zurück

Nachdem Sie das Sicherheitsupdate vom August 2026 (Exchange Server SE, Build 15.2.2562.46) installiert haben, werden Abonnements für einen anonym veröffentlichten Exchange-Kalender nicht mehr aktualisiert. Die abonnierende Anwendung meldet einen Serverfehler, und die URL gibt HTTP 500 zurück.

Weitere Informationen

Das Öffnen derselben veröffentlichten Kalender-URL in einem Webbrowser funktioniert normal und gibt den Kalender zurück. Der Server klassifiziert den Client anhand seines User-Agent Headers. Calendar-Anwendungen sind keine Webbrowser. Daher erkennt der Server sie nicht und leitet die Anforderung an einen Codepfad weiter, den das August-Update deaktiviert hat. Die Anforderung schlägt dann fehl und gibt eine "HTTP 500"-Nachricht zurück.

Die folgenden Clients sind betroffen.

Client	Result
Microsoft Outlook, Internetkalenderabonnement	HTTP 500
Apple Calendar unter iOS und macOS	HTTP 500
Google Calendar, Kalender aus URL hinzufügen	HTTP 500
Mozilla Thunderbird	HTTP 500
Jeder Skript- oder automatisierte Consumer des Feeds	HTTP 500
Chrome, Edge, Firefox, Safari, Android Chrome, iOS, Safari	HTTP 200, Kalender zurückgegeben

Problemumgehung

Fügen Sie der Exchange-Back-End-Website in IIS eine URL-Rewrite-Regel hinzu. Die Regel hängt layout=premium an .ics Anforderungen unterhalb von /owa/calendar/ an. Durch diese Aktion wird der unterstützte Codepfad ausgewählt und der Feed wiederhergestellt.

Das Regelmuster stimmt mit jeder .ics Anforderung unterhalb von /owa/calendar/ überein. Daher deckt es auch die und veröffentlichten reachcalendar.ics Zeitplanfeeds ab, die auf die gleiche Weise fehlschlagen.

Verwenden Sie eine der beiden Methoden in den folgenden Abschnitten. Da beide Methoden dieselbe Regel im gleichen Bereich konfigurieren, wählen Sie die für Ihren Änderungsprozess geeignete Option aus.

Methode A: IIS-Manager

1. Öffnen Sie den IIS-Manager. Erweitern Sie den Server, erweitern Sie "Websites", wählen Sie "Exchange-Back-End" aus, und doppelklicken Sie dann auf "URL umschreiben".

   

2. Wählen Sie im Bereich Aktionen auf der rechten Seite die Option Regel(n) hinzufügen... aus, wählen Sie unter Eingehende Regelndie Option Leere Regel aus, und wählen Sie dann OK aus.

   

3. Geben Sie den Namen ein, und füllen Sie den Abschnitt "URL abgleichen " mit den folgenden Werten aus.

   Feld	Wert
   Name	OWA veröffentlichter Kalender Premium-Layout erzwingen
   Angeforderte URL	Entspricht dem Muster
   Verwenden:	Reguläre Ausdrücke
   Muster	^owa/calendar/.+\.ics$
   Groß-/Kleinschreibung ignorieren	berechnet.

   

4. Erweitern Sie Bedingungen, klicken Sie auf Hinzufügen... und füllen Sie das Dialogfeld mit den folgenden Werten aus. Bei dieser Bedingung bleiben Anforderungen unverändert, wenn sie bereits einen Layoutparameter enthalten.

   Feld	Wert
   Bedingungseingabe	{QUERY_STRING}
   Überprüfen, ob Eingabezeichenfolge	Stimmt nicht mit dem Muster überein
   Muster	(^|&)layout=

   

   Nachdem Sie auf OK geklickt haben, wird die Bedingung in der Liste angezeigt, wobei die logische Gruppierung bei "Alle übereinstimmen" verbleibt.

   

5. Erweitern Sie Aktion und schließen Sie sie mit den folgenden Werten ab.

   Feld	Wert
   Action type	Umschreiben
   URL umschreiben	{R:0}?layout=premium&{QUERY_STRING}
   Abfragezeichenfolge anfügen	gelöscht werden
   Verarbeitung nachfolgender Regeln beenden	berechnet.

   

   Wichtig

   Deaktivieren Sie das Kontrollkästchen Abfragezeichenfolge anfügen . Wenn Sie das Kontrollkästchen aktiviert lassen, fügt IIS die ursprüngliche Abfragezeichenfolge ein zweites Mal an. Dies führt dazu, dass die Anforderung über doppelte Parameter verfügt.

   Wählen Sie im Bereich "Aktionen " die Option "Anwenden " aus, um die Regel zu speichern.

6. Stellen Sie sicher, dass die Regel in der Liste URL-Rewrite aufgeführt ist. Erweitern Sie es, um die Bedingung anzuzeigen.

   

Es ist kein Anwendungspool-Recycling erforderlich. IIS lädt die Konfiguration automatisch neu.

Methode B: Bearbeiten applicationHost.config

Verwenden Sie diese Methode, wenn Sie die Konfiguration lieber als Dateiänderung bereitstellen möchten, z. B. über ein Konfigurationsverwaltungstool.

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

1. Sichern Sie die Datei.

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

2. Suchen Sie das <location path="Exchange Back End"> Element. Wenn sie nicht vorhanden ist, erstellen Sie sie zusammen mit den anderen <location> Elementen im Stammverzeichnis der Datei. Fügen Sie den <rewrite> Block darin hinzu <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>
   

Speichern der Datei IIS wendet die Änderung automatisch an.

Überprüfungs-

Führen Sie den folgenden Befehl auf einem Computer außerhalb der organization über denselben Netzwerkpfad aus, den Abonnenten verwenden. Ersetzen Sie die URL durch Ihre eigene veröffentlichte Kalenderadresse. Der -A Parameter stellt die Anforderung als Kalenderanwendung und nicht als Browser dar, wodurch das Problem reproduziert wird.

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"

Vor der Änderung:

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

Die Anforderung wird an eine Fehlerseite umgeleitet, und es werden keine Kalenderdaten zurückgegeben.

Nach der Änderung:

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

Überprüfen Sie die Werte HTTP/1.1 200 OK und Content-Type: text/calendar. Der Set-Cookie: OwaLight= Header ist nur vorhanden, wenn die Anforderung fehlschlägt. Daher bestätigt ihr Fehlen, dass die Regel in Kraft ist.

Um den Kalenderinhalt anzuzeigen, entfernen Sie -o NUL -D - ihn aus dem Befehl. Eine funktionierende Antwort beginnt mit BEGIN:VCALENDAR.

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

Um zu überprüfen, ob die Regel von IIS selbst erkannt wird, und um zu bestimmen, welche Datei sie enthält, führen Sie die folgenden Befehle auf dem Server aus:

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

Überprüfen Sie außerdem, ob der veröffentlichte Kalender weiterhin in einem Browser geöffnet wird und dass die normale /owa/ Anmeldung nicht beeinträchtigt ist.

Rollback

Um die Problemumgehung zu entfernen, löschen Sie die Regel im IIS-Manager, oder entfernen Sie den <rewrite> Block aus der Datei, die ihn enthält. Für diese Änderung ist kein Neustart erforderlich.

Überprüfen Sie beide Speicherorte, da die Regel an einem Speicherort gespeichert werden kann:

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

Wenn Sie die Regel aus einer Datei entfernen, während sich eine Kopie in der anderen befindet, bleibt das Umschreiben aktiv.

Verwandte Informationen

• Wenden Sie die Regel auf jedem Server an, der den veröffentlichten Kalender bereitstellt. Hierbei handelt es sich um eine IIS-Einstellung pro Server und nicht um eine organizationweite. Ein Load Balancer verteilt Abonnementanforderungen auf alle Mitglieder des Arrays. Daher gibt ein Server, den Sie übersehen, weiterhin eine "HTTP 500"-Nachricht zurück. Der daraus resultierende intermittierende Ausfall ist erheblich schwieriger zu diagnostizieren als ein konsistenter. Überprüfen Sie die Regel auf jedem Server. Gehen Sie nicht davon aus, dass sie überall angewendet wird.

• Wiederholen Sie die Überprüfung nach jedem kumulativen Update und Sicherheitsupdate. Die IIS-Konfiguration auf Standortebene übersteht normalerweise Exchange-Updates, dies wird jedoch nicht garantiert. Nehmen Sie eine Überprüfung dieser Regel in Ihr Exchange-Aktualisierungsverfahren auf, damit die Problemumgehung bei einem zukünftigen Update nicht verschwindet.

• Hierbei handelt es sich um eine vorübergehende Problemumgehung. Microsoft hat bestätigt, dass dies ein bekanntes Problem ist. Das Produktteam ist sich des Verhaltens bewusst und evaluiert potenzielle Verbesserungen in einem zukünftigen Update. Derzeit ist kein geschätzter Zeitrahmen für eine Lösung verfügbar. Die Regel sollte entfernt werden, nachdem ein Build bereitgestellt wurde, der den Fix enthält.