The Sad State of Microsoft Graph and Other APIs

MVPs Express Annoyance and Frustration at the Sad State of the Microsoft Graph

An appeal by several MVPs in the Microsoft Graph feedback forum highlights the fragmented and incoherent state of APIs used across the Microsoft 365 ecosystem. The original promise that the Microsoft Graph would deliver a consistent method to access data distributed across many different data stores has never transpired, and developers and administrators for tenants, CSPs, and ISVs are frustrated by the seeming inability of Microsoft to bring order to the chaos created by Redmond.

Among the complaints made are:

Missing or inconsistent coverage of workloads by Graph APIs. Exchange Online has an Admin API, but that’s a sticking plaster to get past the need to remove EWS. SharePoint Online introduced a Graph API to manage tenant settings in 2022 and hasn’t done much since. At least SharePoint Online has an API to create sites (albeit limited): Exchange Online is limited to PowerShell when it comes to creating mailboxes. Many of the Teams administrative policies are based on the old Skype for Business framework and don’t have Graph APIs.

Widespread use of Undocumented APIs: Behind the scenes of many workloads are features inaccessible through PowerShell or a Microsoft Graph API. It’s understandable that engineering groups need time to complete the work to create a fully supported API, but it would also be nice if the major administrative portals used documented APIs whenever possible. For example, no interfaces are available for the critical Microsoft XDR solution.

Graph APIs remaining in beta for extended periods: Tenants understand that APIs need to meet performance and quality goals before they attain production status. Many tenants don’t like using beta APIs because they also understand that Microsoft can remove or drastically change functionality while APIs are in beta. It’s therefore unacceptable when APIs remain in beta for years. The AuditLogQuery API is an example. Microsoft has struggled to deliver a stable service for the synchronous audit search feature in PowerShell. They don’t seem to be able to get the asynchronous Graph API to run well either, even though it seems to be the one used by the Purview audit search solution. Tenants would like clarity about plans for moving beta APIs to production to help them plan their use of these APIs.

Lack of Resource for the Microsoft Graph PowerShell SDK: Many automated processes developed in tenants use PowerShell. The Microsoft Graph PowerShell SDK is an incredibly important tool. Each new version gets over 700,000 downloads. Despite the evidence of obvious customer interest and usage, instead of devoting sufficient engineering resources to maintain the Microsoft Graph PowerShell SDK properly so that reported bugs are fixed in a reasonable timeframe, the SDK is supported by a very small team. The result is poor quality and a large bug count.

It would also be nice for Microsoft to fix the ongoing problem of assembly clashes that affects major Microsoft 365 PowerShell modules. For example, I can load Exchange Online (V3.9.2) and then the Microsoft Graph PowerShell SDK (V2.35.1). but I can’t load the SDK followed by Exchange. How frustrating do you think this is to the average developer?

It is unacceptable for Microsoft to speak out of one side of its mouth by endorsing the Graph APIs as the route for external developers to interact with Microsoft 365 while at the same time declining to support the development and enhancement of the APIs.

Copilot Sucks Resources

Many long-time observers see only one cause to blame. Microsoft’s focus on artificial intelligence and integrating Copilot into literally every piece of software they produce has stolen engineering budget and resources from other tasks. Developers working on projects not aligned with Copilot tell of budget and headcount cuts with small teams given new responsibilities without extra resources. Over coffees and beers, I’ve heard about teams being cut in half while also being asked to take on new projects. Allied to cuts in writers, the net effect is declining quality in both code and documentation.

Customers aren’t stupid. We see the lack of responsiveness to software bugs. We see the lack of consistency across APIs and the holes that appear in APIs. We look at the documentation and wonder how anyone could create such horrible examples. We cope with poor support that isn’t getting any better despite the fact that understanding Office 365 and cloud-based services are no longer like searching for a hidden secret. And we see contacts in Microsoft who used to work on Graph-related topics being moved to other areas with no replacement.

The Real State of Microsoft 365

Microsoft obviously believes all is well within Microsoft 365. The service meets its financially backed SLA every quarter, so everything must be OK. The quarterly results for the Microsoft Cloud are applauded by Wall Street analysts because of high profitability and growing numbers. It’s nice for CFO Amy Hood to see her much-loved Average Revenue Per User (ARPU) increase as the result of efforts to upsell licenses and add-ons, and those numbers will get a nice uptick in July 2026 when Microsoft increases monthly license fees. Not that the increases will come close to offsetting the investment Microsoft has made to build out datacenter capacity for AI services.

The profitability of the Microsoft Cloud brings no joy for customers, especially those who eschew the notion of spending $360/year/user on Microsoft 365 Copilot (or $1,188 for the new Microsoft 365 E7 license). The 3.3% or so of the Microsoft 365 installed base who pay for Copilot must be happy because of the rapid pace of development to deliver new features. The rest of the user base is paying for that development without benefiting from the enormous software engineering effort.

We know Microsoft can do great things when the company sets a target. The ability to take on and solve technical challenges is engrained into Microsoft history. All that is being asked here is to help the Microsoft 365 community by bringing stability to and predictability to the Microsoft Graph APIs and associated tools.

The Way Forward

It wouldn’t take much to solve the issues reported here. The world’s largest software engineering company has the resources, talent, and funding to make rapid improvements in the Microsoft Graph and associated tools.

Microsoft management should make it a priority to restore consistency and robustness to the Microsoft Graph, to ensure that sufficient resources are in place to improve quality and close the gaps in current coverage, and to make the Microsoft Graph APIs deliver on the vision laid out years ago. When that happens, customers can get on with the task of building automated processes to fill in the gaps left by Microsoft.

Help Microsoft make the right decision by expressing your opinions and voting for the requests expressed in the Microsoft Graph feedback forum. Your opinion counts!

---

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365. Only humans contribute to our work!