Le passage à la nouvelle année est loin de bien se passer pour tout le monde. Dans le domaine de l'IT, ce changement peut déboucher sur de gros soucis comme cela a été le cas avec Microsoft lors du passage à l'an 2000. Cependant, pas besoin de changer de millénaire pour connaitre des problèmes comme vient de l'apprendre encore à ses dépens la firme de Redmond. Et en particulier ses clients utilisant Exchange sur site dont des e-mails sont restés bloqués en file d'attente Exchange suite au passage en 2022. « Une file d’attente est un emplacement d’hébergement temporaire réservé aux messages qui attendent de passer à l’étape suivante de traitement ou de remise à destination. Chaque file d'attente représente un ensemble logique de messages traités par un serveur Exchange dans un ordre spécifique. Dans Exchange 2016 et 2019, les files d’attente peuvent contenir des messages avant, pendant et après la remise. Il en existe dans le service de transport sur les serveurs de boîtes aux lettres et les serveurs de transport Edge », peut-on lire dans la documentation de l'éditeur
« Nous avons résolu le problème provoquant le blocage des messages dans les files d'attente de transport d'Exchange Server 2016 et 2019. Le problème est lié à un échec de la vérification de la date avec le changement de nouvelle année et non à une défaillance du moteur anti-virus lui-même », a expliqué l'éditeur dans un billet. « Ce n'est pas un problème avec l'analyse des malwares ou le moteur de sécurité, et ce n'est pas un problème lié à la sécurité. La vérification de version effectuée par rapport au fichier de signature provoque le blocage du moteur de logiciels malveillants, ce qui entraîne le blocage des messages dans les files d'attente de transport ». Si des entreprises ont pu désactiver temporairement leur analyse de scan Exchange pensant que le problème venait de là elles doivent donc immédiatement le réactiver. Nombre d'entre elles se sont plaintes de soucis liés à ce bug.
Un script exécutable sur plusieurs serveurs en parallèle
Il n'a pas fallu attendre longtemps pour voir se multiplier les réactions suite à ce défaut bloquant avec rapidement de premières explications sur la toile. Sur Reddit, un utilisateur appelé /u/FST-LANE a publié vers 1h du matin le 1er janvier 2022 a ainsi suggéré que Microsoft avait publié un correctif « 220101001 » pour assurer le passage sans encombre de date mais qui ne s'est pas passé comme prévu : « Je vois un tas d'erreurs du service FIPFS qui disent : Impossible de convertir 220101001 "en long " », a écrit /u/FST-LANE. Même son de cloche du côté de Marius Sandbu, évangéliste cloud chez Sopra Steria, qui a publié un synopsis détaillé de la cause relatant que les serveurs Microsoft Exchange ont complètement cessé de traiter le courrier parce qu'ils n'ont pas été prêts à gérer la date du 1er janvier 2022. « La raison en est que Microsoft utilise un int32 signé pour la date et avec la nouvelle valeur de 2.201.010.001 est supérieure à la valeur maximale de l'int "long" étant 2.147.483.647 ».
Pour palier ce souci très gênant, Microsoft a publié une solution de contournement nécessitant toutefois une intervention manuelle de l'utilisateur. « Nous avons maintenant créé une solution pour résoudre le problème des messages bloqués dans les files d'attente de transport sur Exchange Server 2016 et 2019 en raison d'un problème de date latente dans un fichier de signature utilisé par le moteur d'analyse des logiciels malveillants au sein d'Exchange Server. Une action du client est requise pour mettre en œuvre cette solution. Lorsque le problème se produit, vous verrez des erreurs dans le journal des événements d'application sur le serveur Exchange, en particulier les événements 5300 et 1106 (FIPFS) », indique l'éditeur.
Deux méthodes de remédiation existent, la première est de télécharger ce script. « Avant d'exécuter le script, modifiez la stratégie d'exécution des scripts PowerShell en exécutant Set-ExecutionPolicy -ExecutionPolicy RemoteSigned », précise Microsoft. « Exécutez le script sur chaque serveur de boîtes aux lettres Exchange qui télécharge les mises à jour anti-programme malveillant dans votre organisation (utilisez Exchange Management Shell avec élévation de privilèges) ». A noter que les les serveurs de transport Edge ne sont pas affectés par ce problème et qu'il est possible d'exécuter ce script sur plusieurs serveurs en parallèle. Une deuxième méthode de contournement manuelle peut aussi être utilisée pour corriger ce problème de messagerie sans recourir au script : « pour résoudre manuellement ce problème, vous devez effectuer les étapes suivantes sur chaque serveur de boîtes aux lettres Exchange de votre organisation qui télécharge les mises à jour anti-programme malveillant. Les serveurs de transport Edge ne sont pas affectés par ce problème ».
Résoudre manuellement le problème d'envoi de messages Exchange
Supprimer le moteur anti-malware et les métadonnées existantes
1. Arrêtez le service Microsoft Filtering Management. Lorsque vous êtes invité à arrêter également le service de transport Microsoft Exchange, cliquez sur Oui ;
2. Utilisez le Gestionnaire des tâches pour vous assurer que updateservice.exe n'est pas en cours d'exécution ;
3. Supprimez le dossier suivant : %ProgramFiles%\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\amd64\Microsoft ;
4. Supprimez tous les fichiers du dossier suivant : %ProgramFiles%\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\metadata.
Mettre à jour vers le dernier moteur anti-malware
1. Démarrez le service Microsoft Filtering Management et le service de transport Microsoft Exchange.
2. Ouvrez Exchange Management Shell, accédez au dossier Scripts (%ProgramFiles%\Microsoft\Exchange Server\V15\Scripts) et exécutez Update-MalwareFilteringServer.ps1 .
Vérifier les informations de mise à jour du moteur anti-malware
1. Dans Exchange Management Shell, exécutez Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell.
2. Exécutez Get-EngineUpdateInformation et vérifiez que les informations UpdateVersion sont 2112330001.
« Après la mise à jour du moteur, nous vous recommandons également de vérifier que le flux de messagerie fonctionne et que les événements d'erreur FIPFS ne sont pas présents dans le journal des événements d'application », précise Microsoft.