Le calendrier publié (.ics) renvoie HTTP 500 pour les applications de calendrier

Symptômes

Après avoir installé le correctif de sécurité d’août 2026 (Exchange Server SE, build 15.2.2562.46), les abonnements à un calendrier Exchange publié anonymement cessent de s’actualiser. L’application abonnée signale une erreur serveur et l’URL renvoie HTTP 500.

Résolution

Pour résoudre ce problème, installez la mise à jour de sécurité suivante ou des mises à jour ultérieures :

• Description du correctif de sécurité pour Microsoft Exchange Server Édition d'abonnement RTM : 13 octobre 2026 (KB5128895)
• Description du correctif de sécurité pour Microsoft Exchange Server 2019 CU15 : 13 octobre 2026 (KB5128896)
• Description du correctif de sécurité pour Microsoft Exchange Server 2019 CU14 : 13 octobre 2026 (KB5128897)
• Description de la mise à jour de sécurité pour Microsoft Exchange Server 2016 CU23 : 13 octobre 2026 (KB5128898)

Solution de contournement

Ajoutez une règle de réécriture d’URL au site Exchange Back End dans IIS. La règle s’ajoute layout=premium aux demandes .ics sous /owa/calendar/. Cette action sélectionne le chemin d’accès au code pris en charge et restaure le flux.

Méthode A : Gestionnaire IIS

1. Ouvrez le Gestionnaire des services Internet (IIS). Développez le serveur, développez Sites, sélectionnez Exchange Back End, puis double-cliquez sur Réécriture d’URL.

   

2. Dans le volet Actions à droite, sélectionnez Ajouter une ou plusieurs règles..., sélectionnez Règle vide sous Règles de trafic entrant, puis sélectionnez OK.

   

3. Entrez le nom et renseignez la section Faire correspondre l’URL avec les valeurs suivantes.

   Champ	Valeur
   Name (Nom)	calendrier publié dans OWA Forcer la disposition Premium
   URL demandée	Correspond au modèle
   Using	Expressions régulières
   Modèle	^owa/calendar/.+\.ics$
   Ignorer la casse	sélectionné

   

4. Développez Conditions, cliquez sur Ajouter... et complétez la boîte de dialogue avec les valeurs suivantes. Cette condition laisse les requêtes telles quelles si elles comportent déjà un paramètre de disposition.

   Champ	Valeur
   Entrée de condition	{QUERY_STRING}
   Vérifier si la chaîne d’entrée	Ne correspond pas au modèle
   Modèle	(^|&)layout=

   

   Une fois que vous avez cliqué sur OK, la condition apparaît dans la liste, avec le regroupement logique restant dans le champ Correspondre tout.

   

5. Développez Action et terminez-la avec les valeurs suivantes.

   Champ	Valeur
   Type d’action	Réécrire
   URL de réécriture	{R:0}?layout=premium&{QUERY_STRING}
   Ajouter une chaîne de requête	Désactivé
   Arrêter le traitement des règles suivantes	sélectionné

   

   Important

   Désactivez la case à cocher Ajouter une chaîne de requête . Si vous laissez la case à cocher sélectionnée, IIS ajoute la chaîne de requête d’origine une deuxième fois. Cela entraîne des paramètres en double dans la demande.

   Dans le volet Actions , sélectionnez Appliquer pour enregistrer la règle.

6. Vérifiez que la règle est répertoriée dans la liste Réécriture d’URL . Développez-la pour afficher la condition.

   

Aucun recyclage de pool d’applications n’est requis. IIS recharge automatiquement la configuration.

Méthode B : Modifier applicationHost.config

Utilisez cette méthode si vous préférez déployer la configuration en tant que modification de fichier, par exemple via un outil de gestion de la configuration. Fichier :C:\Windows\System32\inetsrv\config\applicationHost.config

1. Sauvegardez le fichier.

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

2. Localisez l’élément <location path="Exchange Back End"> . S’il n’existe pas, créez-le à la racine du fichier, avec les autres <location> éléments. Ajoutez le <rewrite> bloc à l’intérieur <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>
   

Vérification

Exécutez la commande suivante à partir d’un ordinateur extérieur à l’organisation, sur le même chemin réseau que celui utilisé par les abonnés. Remplacez l’URL par l’adresse de votre calendrier publié. Le -A paramètre présente la demande sous la forme d’une application de calendrier plutôt que d’un navigateur, ce qui reproduit le problème.

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"

Avant la modification :

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

La demande est redirigée vers une page d’erreur et aucune donnée de calendrier n’est renvoyée. Après la modification :

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

Vérifiez les valeurs HTTP/1.1 200 OK et Content-Type: text/calendar. L’en-tête Set-Cookie: OwaLight= est présent uniquement lorsque la demande échoue. Par conséquent, son absence confirme que la règle est en vigueur. Pour afficher le contenu du calendrier, supprimez -o NUL -D - de la commande. Une réponse de travail commence par BEGIN:VCALENDAR.

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

Pour vérifier que IIS lui-même voit la règle et pour déterminer le fichier qui la contient, exécutez les commandes suivantes sur le serveur :

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

Vérifiez également que le calendrier publié s’ouvre toujours dans un navigateur et que la connexion normale /owa/ n’est pas affectée.

Restauration

Pour supprimer la solution de contournement, supprimez la règle dans le Gestionnaire des services Internet (IIS) ou supprimez le <rewrite> bloc du fichier qui la contient. Cette modification ne nécessite pas de redémarrage. Vérifiez les deux emplacements, car la règle peut être stockée dans l’un ou l’autre :

• C:\Windows\System32\inetsrv\config\applicationHost.config
• %ExchangeInstallPath%\ClientAccess\web.config Si vous supprimez la règle d’un fichier alors qu’une copie reste dans l’autre, la réécriture reste active.

Informations connexes

• Appliquer la règle sur chaque serveur qui gère le calendrier publié. Cette règle s’applique à chaque serveur IIS et non à l’échelle de l’organisation. Un équilibreur de charge distribue les demandes d’abonnement à tous les membres du tableau. Par conséquent, un serveur que vous manquez continue à renvoyer un message « HTTP 500 ». L’échec intermittent qui en résulte est considérablement plus difficile à diagnostiquer qu’un échec constant. Vérifiez la règle sur chaque serveur. Ne présumez pas qu’il s’applique partout.
• Revérifiez après chaque mise à jour cumulative et de sécurité. La configuration IIS au niveau du site survit normalement aux mises à jour Exchange, mais cette condition n’est pas garantie. Incluez un case activée de cette règle dans votre procédure de mise à jour Exchange afin que la solution de contournement ne disparaisse pas lors d’une prochaine mise à jour.