La fin annoncée des Exchange Web Services
L'annonce de Microsoft le 5 octobre de retirer 25 API Exchange Web Services (EWS) d'ici le 31 mars 2022 contient des signes clairs que EWS touche à sa fin. Microsoft précise que l'ensemble des 25 API sélectionnées pour passer en premier sont les moins utilisées avec Exchange Online. Microsoft indique également qu'il 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 pour faciliter la suppression d'EWS de Microsoft 365, et Microsoft note qu'EWS est une surface d'API héritée. qui a bien servi, mais ne répond plus aux besoins de sécurité et de gérabilité du développement d'applications modernes.
Définition des conséquences
Microsoft a créé EWS en tant que protocole basé sur SOAP pour permettre aux ISV d'accéder au contenu d'Exchange Server. En fait, lorsqu'il est apparu pour la première fois dans Exchange 2007, EWS était la première API réussie pour Exchange que Microsoft a livrée à partir de MAPI. Depuis lors, les clients Microsoft, Entourage et Outlook pour Mac et les ISV ont utilisé EWS à des fins très diverses, notamment la migration des boîtes aux lettres et des données PST vers Exchange Online, mais également comme base pour les produits de sauvegarde. L'introduction des API Microsoft Graph comme méthode préférée d'accès aux données via Microsoft 365 a marqué le début de la fin pour EWS. Le premier signe a été l'annonce de 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, en particulier 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 à utiliser les API Microsoft Graph en ce moment. Les API Graph sont plus récentes, utilisées dans Microsoft 365, prennent en charge des normes telles que OAuth et OData, leur modèle basé sur REST est familier à de nombreux développeurs. La large gamme d'outils tels que Graph Explorer et 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 était l'inclusion d'EWS dans la suite de protocoles de connectivité que Microsoft prévoit de désactiver l'authentification de base.
La dernière date de démantèlement est le 1er octobre 2022
Tout cela conduit à la nécessité pour les organisations de déterminer comment EWS est utilisé au sein de leurs locataires et de planifier son remplacement. Les domaines d'intérêt pour la recherche SAP comprennent :
– programmes personnalisés internes et scripts PowerShell ; – clients tiers et plug-ins clients ; – produits tiers.
Chaque organisation est différente et EWS existe depuis longtemps. Ces deux facteurs rendent difficile la perception d'un ensemble définitif de lignes directrices sur ce qu'il faut voir. Trois domaines évidents sont : la migration, les connecteurs et la sauvegarde. Tout produit qui transmet des informations vers ou depuis Exchange Online doit être interrogé pour déterminer quelle API est utilisée. La plupart des produits de sauvegarde Exchange Online utilisent EWS. Le protocole n'a jamais été conçu comme une base pour la sauvegarde, mais rien d'autre n'est disponible, donc les ISV ont utilisé ce qu'ils pouvaient.
Recherche un remplaçant graphique
Alors qu'ils assimilent la nouvelle selon laquelle EWS est en déclin terminal, les ISV chercheront naturellement un remplaçant. Les API graphiques de Microsoft couvrent actuellement Outlook et d'autres objets stockés dans les boîtes aux lettres, tels que les tâches, les notes et les contacts. Cependant, il n'existe aucune API graphique destinée à prendre en charge la transmission à grande échelle du contenu de la boîte aux lettres du type que l'on trouve généralement dans les opérations de sauvegarde et de restauration.
Les API Microsoft Graph sont des outils de gestion de contenu
Microsoft vient de publier une API d'exportation graphique pour Teams considérée comme adaptée aux scénarios de sauvegarde et de restauration. Cependant, cette API est livrée avec des compteurs de consommation et un modèle de facturation par message qui crée un tout nouveau modèle commercial 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 aux lettres Exchange Online est plus grande (même avec la nouvelle limite de 1,5 To pour les fichiers à expansion automatique). Si Microsoft décide d'imposer le même modèle de tarification grand public sur une API d'exportation/importation pour Exchange Online, cela pourrait créer de nombreux maux de tête tant pour les clients que pour les ISV, qui devront faire face aux coûts associés à des scénarios tels que :
– déplacer les données des anciennes solutions d'archivage vers Exchange Online ; – importer des données de systèmes tiers vers Exchange Online (connecteurs) ; – migrations locataire à locataire des boîtes aux lettres et des archives Exchange ; – le traitement des copies de sauvegarde des boîtes aux lettres Exchange Online (utilisateur, partagée, groupe, dossier public et autres) dans des centres de données externes tiers.
Bien que tout indique que EWS sera bientôt parti, Microsoft n'a pas fixé de date finale (publique) pour la suppression d'EWS d'Exchange Online. Nous pourrions nous cacher la tête dans le sable, en espérant que le tollé des clients et des ISV suffira à forcer Microsoft à conserver EWS plus longtemps. Cette stratégie ne semble pas la plus judicieuse. Il est préférable d'accepter que les jours d'EWS sont comptés et de commencer à travailler sur des composants de remplacement pour votre infrastructure informatique.
