Tout ce que je voulais faire, c’était transmettre à un serveur certaines exceptions d’antivirus relatives aux extensions et aux chemins d’accès aux fichiers.
Le client est un petit cabinet comptable utilisant Sage 50, rien d’inhabituel. Il s’agissait d’un serveur autonome Windows Server 2019 exécutant Microsoft RDS, hébergé par un fournisseur DaaS. Les utilisateurs se connectent à distance au serveur et exécutent Sage sur le serveur, où se trouvent également les données. Ainsi, tout – application ET données – est local sur le serveur.
Après plusieurs tentatives infructueuses avec le support technique de Sage, j’ai trouvé un document sur leur site qui parlait de la mise en place d’exceptions antivirus. Je gère ce client à l’aide de Microsoft XDR (Defender + Intune), et j’ai donc créé une politique AV distincte pour le serveur avec les exceptions en place.
Sauf qu’ils n’ont jamais atteint le serveur.
J’ai cherché dans de nombreux documents et forums, mais je n’ai pas trouvé de solution. J’ai donc ouvert un ticket avec Microsoft. C’était en juin 2023.
J’ai été transféré d’un ingénieur à l’autre, d’un groupe à l’autre (j’ai parlé à des gens formidables en cours de route !), mais personne n’a pu mettre le doigt sur le problème. Au cours de l’été (en août, je crois), j’ai migré le serveur vers une nouvelle VM Windows Server 2022, pour d’autres raisons (le désormais célèbre problème “erreur 1001”, qui n’a toujours pas été résolu – si vous le savez, vous le savez). Je pensais que le fait de tout rafraîchir résoudrait le problème des exceptions, mais non.
Qu’est-ce que j’essayais d’exclure ?
Tout d’abord, deux extensions de fichiers : sai et saj.
Comme indiqué dans l’astuce pop-up et sur la page correspondante, j’ai ajouté les deux extensions séparées par un “|” :
Ensuite, j’ai dû ajouter quelques chemins :
- c:\data\Simply Accounting
C:\Program Files (x86)\Sage 50 Édition Experts Version 2023
C:\ProgramData\Sage
C:\ProgramData\Sage 50 Canadian
C:\Program Files (x86)\winsim
J’ai donc ajouté une entrée en utilisant la même syntaxe :
“c:\data\Simply Accounting”|”C:\Program Files (x86)\Sage 50 Édition Experts Version 2023″|”C:\Data\Sage”|”C:\Data\Sage 50 Canadian”|”C:\Data\Sage 50 Canadian”|”C:\Data\Program Files (x86)\Winsim”
J’ai attendu que le serveur communique avec Defender/Intune, puis j’ai vérifié sur le serveur : les exceptions n’avaient PAS été transmises au serveur.
Lorsque l’on consulte le rapport sur la politique dans Intune, l’état est toujours Pending ; il n’a jamais atteint le stade de la Success.
C’était il y a quelques mois déjà, mais je suis presque certain d’avoir essayé de nombreuses autres combinaisons, en plaçant chaque extension et chaque chemin dans une entrée séparée, avec ou sans guillemets. Rien n’a fonctionné.
D’où l’appel à Microsoft, car je pensais qu’il s’agissait d’autre chose.
Alors, qu’est-ce que c’était ?
Après des mois de diagnostic et de collecte de données, l’un des ingénieurs m’a contacté et m’a dit : “C’est lié aux extensions”. Elle allait me recontacter. Cependant, par une journée d’hiver de janvier (Canada, les amis !) où il faisait trop froid pour aller jouer dehors, j’ai recommencé à travailler sur cet aspect de la politique.
J’ai commencé par supprimer toutes les exceptions, les types de fichiers ET les chemins d’accès. J’ai attendu que le serveur communique et se synchronise, et la politique est passée de “Pending” à “Succes” !
Ensuite, j’ai rajouté les extensions de fichiers, mais au lieu d’ajouter la liste des extensions comme décrit ICI, je les ai ajoutées sur des lignes séparées :
Si vous vous souvenez, ma politique initiale ne comportait qu’une seule entrée avec sai|saj
Après une synchronisation, TA-DAAAA !
Les exceptions se trouvaient sur le serveur !
J’ai ensuite ajouté une seule exception de chemin :
“c:\data\Simply Accounting”
Il s’est synchronisé avec le serveur !
J’en ai ajouté un deuxième :
“C:\ProgramData\Sage”
Toujours un succès !
On continu – j’ai ensuite ajouté :
“C:\Program Files (x86)\Sage 50 Édition Experts Version 2023”
Et c’est là que le tout a arrêté de fonctionner !
J’ai même attendu le lendemain matin pour m’assurer que le serveur avait bien récupéré les réglages, mais toujours rien.
Puis j’ai pensé : “Peut-être qu’il y a quelque chose dans le chemin qu’il n’aime pas, ou qu’il est trop long”.
Je suis donc allé sur le serveur et j’ai utilisé la commande “dir /x” pour afficher les noms courts 8.3 des répertoires, et j’ai obtenu ceci :
Et…:
Cela a fonctionné !!!
Je dois supposer que Defender exclut le répertoire de l’analyse même si j’utilise le nom abrégé…
Ensuite, j’ai ajouté les deux dernières exceptions :
J’étais certain que “C:\ProgramData\Sage 50 Canadian” fonctionnerait, mais je me demandais si les parenthèses dans “C:\Program Files (x86)\winsim” n’étaient pas à l’origine du problème. J’ai enregistré la stratégie et synchronisé le serveur, puis j’ai attendu.
Mais j’avais tort : toutes les exceptions ont été transmises au serveur !
Ainsi, à la manière de Sherlock Holmes, nous devons considérer que “lorsque vous avez éliminé l’impossible, tout ce qui reste, aussi improbable soit-il, doit être la vérité”, ce qui ne laisse comme seule différence que l’accent français dans le chemin encombrant, “Édition”.
J’ai fait un autre test, en mettant le même chemin mais sans l’accent, juste pour voir s’il était transmis au serveur :
Même si le chemin n’existe pas vraiment (à moins que Windows n’interprète “Édition” et “Edition” comme la même chose !), il s’agissait juste d’un test pour voir si l’exception parviendrait au serveur.
Et c’est le cas !
CONCLUSION : il y a un problème avec Defender ou Intune en ce qui concerne les caractères accentués.
C’est un peu incroyable en 2024, alors que ces produits sont utilisés dans le monde entier, mais c’est ainsi.
Et comme je suis la première personne au monde à essayer et à comprendre cela, je vais m’attendre à une énorme reconnaissance de la part de Microsoft !