La fin annoncée d’Exchange Web Services
L’annonce faite par Microsoft le 5 octobre dernier de la mise hors service de 25 API d’Exchange Web Services (EWS) d’ici au 31 mars 2022 contient quelques signaux clairs indiquant que EWS est proche de la fin. Microsoft précise que l’ensemble des 25 API sélectionnées pour disparaître en premier sont les moins utilisées avec Exchange Online. Microsoft indique également qu’elle supprimera la possibilité de créer de nouvelles applications EWS à partir du 30 septembre 2022. Ces deux étapes font partie du processus de mise hors service visant à faciliter le retrait d’EWS de Microsoft 365, Microsoft notant que EWS est une surface d’API héritée qui a bien servi, mais qui ne répond plus aux besoins de sécurité et de gestion du développement d’applications modernes.
Définir les conséquences
Microsoft a créé EWS comme un protocole basé sur SOAP pour permettre aux ISV d’accéder au contenu d’Exchange Server. En fait, lorsqu’il est apparu dans Exchange 2007, EWS a été la première API réussie pour Exchange que Microsoft a livrée depuis MAPI. Depuis lors, EWS a été utilisé par Microsoft par les clients d’Entourage et Outlook pour Mac et par les ISV à des fins très diverses, notamment pour la migration des boîtes aux lettres et des données PST vers Exchange Online, mais aussi en tant que base pour les produits de sauvegarde. L’introduction des API graphiques de Microsoft comme méthode d’accès privilégiée aux données à travers Microsoft 365 a marqué le début de la fin pour EWS. Le premier signe a été l’annonce faite par Microsoft en juillet 2018 selon laquelle EWS ne recevrait plus de mises à jour de fonctionnalités. Dans de nombreux cas, une API statique est une API morte, surtout lorsque l’attention de son propriétaire est fermement dirigée vers une autre API. Il est difficile de nier que Microsoft a tort de forcer les gens vers les API Microsoft Graph à ce stade. Les API Graph sont plus récentes, utilisées à travers Microsoft 365, prennent en charge des normes comme OAuth et OData, son modèle basé sur REST est familier à de nombreux programmeurs. La large gamme d’outils tels que Graph Explorer et les SDK dans différents langages de programmation facilite la tâche des développeurs. Il est également vrai que les API graphiques ont des politiques de sécurité plus granulaires. Le deuxième signe a été l’inclusion de EWS dans l’ensemble des protocoles de connectivité que Microsoft prévoit de désactiver l’authentification de base.
La dernière date de mise hors service est le 1er octobre 2022
Tout cela nous amène à la nécessité pour les organisations de déterminer comment EWS est utilisé à l’intérieur de leurs locataires et d’établir des plans pour son remplacement. Les domaines d’intérêt à rechercher pour les SAP comprennent :
- les programmes personnalisés maison et les scripts PowerShell ;
- les clients tiers et les modules complémentaires des clients ;
- les produits tiers.
Chaque organisation est différente et EWS existe depuis longtemps. Ces deux facteurs rendent compliqué la perception un ensemble définitif de directives sur ce qu’il faut regarder. Trois domaines évidents sont : la migration, les connecteurs et la sauvegarde. Tout produit qui diffuse des informations vers ou depuis Exchange Online doit être interrogé afin de déterminer quelle API est utilisée. La plupart des produits de sauvegarde pour Exchange Online utilisent EWS. Le protocole n’a jamais été conçu comme la base de la sauvegarde, mais rien d’autre n’est disponible, de sorte que les ISV ont utilisé ce qu’ils pouvaient.
Recherche d’un remplacement du graphique
Alors qu’ils digèrent la nouvelle selon laquelle EWS est en phase terminale de déclin, les ISV vont naturellement chercher un remplacement. À l’heure actuelle, les API graphiques de Microsoft couvrent Outlook et d’autres objets stockés dans les boîtes mail comme les tâches, les notes et les contacts. Cependant, il n’existe aucune API graphique destinée à prendre en charge le streaming à grande échelle du contenu des boîtes mail du type de celui que l’on rencontre habituellement dans les opérations de sauvegarde et de restauration.
Les API graphiques de Microsoft sont des outils de gestion de contenu
Microsoft vient de publier une API d’exportation graphique pour Teams qui est jugée adaptée aux scénarios de sauvegarde et de restauration. Cependant, cette API s’accompagne de compteurs de consommation et d’un modèle de facturation par message qui crée un tout nouveau modèle économique pour la tarification des données de sauvegarde. Le volume des messages Teams est inférieur à celui de la messagerie Exchange Online et la taille des boîtes mail Exchange Online est plus importante (même avec la nouvelle limite de 1,5 To pour les archives à expansion automatique). Si Microsoft décide d’imposer le même modèle de tarification de la consommation à une API d’exportation/importation pour Exchange Online, cela pourrait créer de nombreux maux de tête pour les clients comme pour les ISV qui devront faire face aux coûts associés à des scénarios tels que :
- le déplacement des données des anciennes solutions d’archivage vers Exchange Online ;
- l’importation de données de systèmes tiers dans Exchange Online (connecteurs) ;
- les migrations de locataire à locataire des boîtes mail et des archives Exchange ;
- le traitement des sauvegardes des boîtes aux lettres Exchange Online (utilisateur, partagé, groupe, dossier public et autres) vers des centres de données tiers externes.
Bien que tout indique que EWS va bientôt disparaître, Microsoft n’a pas fixé de date définitive (publique) pour le retrait d’EWS d’Exchange Online. Nous pourrions faire l’autruche, espérer que les protestations des clients et des ISV seront suffisantes pour obliger Microsoft à maintenir EWS plus longtemps. Cette stratégie ne semble pas la plus judicieuse. Il vaut mieux accepter que les jours d’EWS sont comptés et commencer à travailler sur des composants de remplacement pour votre infrastructure informatique.
