Table of Contents
Update 24 for Our PowerShell eBook
The Office 365 for IT Pros eBook team are thrilled to announce the publication of the June 2026 update (#24) for the Automating Microsoft 365 with PowerShell eBook. As is our norm, we release the PowerShell book about ten days ahead of the “big” Office 365 for IT Pros eBook. The PowerShell book is available separately or as part of the Office 365 for IT Pros bundle. It’s also available as a printed paperback through Amazon.com.
Current subscribers can download the updated EPUB and PDF files from their Gumroad.com account. As always, the updates contain a mixture of new information, refinements or expanded coverage of topics, and corrections.
Meantime, two other important issues exist that are of interest to the Microsoft 365 PowerShell community.
Microsoft Graph PowerShell SDK V2.37
Microsoft released V2.37 of the Microsoft Graph PowerShell SDK on May 12, 2026. So far, so good, and the new release seems to be stable. As usual, we recommend that you install the update on a workstation and test some critical scripts before deciding to deploy V2.37 widely.
Be careful with Azure Automation runtime environments. Remember that the other SDK modules have a dependency on the Microsoft.Graph.Authentication module. In effect, this means that all SDK modules installed as resources for a runtime environment must be of the same version. You can’t install V2.37 of the Microsoft.Graph.User.Actions module into a runtime environment where the Microsoft.Graph.Authentication module is at V2.36.1.
V2.36.1 of the SDK was downloaded over 1.04 million times. That figure marks considerable growth over previous versions and is probably the result of increased interest in the SDK after the (eventual) retirement of the old AzureAD and MSOnline modules. The Entra module, which is based on the SDK, has clocked up a further 300K downloads for the current release (1.2.0, released four months ago).
The AutoRest Conundrum
Out of the blue, on February 27, 2026, Microsoft posted a deprecation leading to retirement notice for the AutoRest utility on its GitHub repository (Figure 1). This development was quite shocking for fans of the Microsoft Graph PowerShell SDK because AutoRest is deeply involved in the pipeline used to generate the SDK by reading the OpenAPI documentation for the Graph APIs. The output from that pipeline includes basic REST calls for Graph APIs, parameters and properties, and cmdlet outlines. The output from AutoRest is transformed into cmdlets and modules by further hand-built processing created specifically for PowerShell.
I missed the notification when it first appeared, as I suspected most other people who are interested in the Graph APIs and AutoRest also did. The way that the Azure SDK engineering team posted critical information like this is unpardonable and marks a complete disregard for the consequences of the action.
The issue is simple. There is currently no alternative available today to replace AutoRest in the Microsoft Graph PowerShell SDK generation pipeline. If Microsoft proceeds to retire AutoRest on July 1, 2026, customers might assume that the SDK is suddenly plunged into an unsupported state. A more upbeat reading of the situation would conclude that retiring one component doesn’t mean that the Microsoft Graph PowerShell SDK is kaput. Autorest will continue to work and the SDK will continue to be generated.
It’s important to emphasize that retirement does not mean that AutoRest will stop working on July 1, 2026. However, news of tools entering a maintenance state sends chills down the spine of customer CIOs and CTOs who decide what tools should be used in their production environments.
Suggesting that TypeSpec is the replacement is unrealistic for PowerShell users because of the lack of support. In a nutshell, Microsoft has not presented a credible path forward for a tool that’s used by over a million people to automate real-life operational processes for customer tenants.
To balance some of the negativity, I know that discussions are ongoing within Microsoft to establish what can be done to bring AutoRest back from the dead, My feeling is that steps will be taken to address the issue caused by the retirement. However, it’s deeply unsettling when a Microsoft team could even consider proceeding with such a plan when so much customer production automation is based on a PowerShell SDK that depends on AutoRest. At a minimum, the episode raises concerns about how Microsoft understands the real-world impact about tooling decisions on paying customers. Stay tuned for further developments.
Onwards and Upwards
It’s the nature of the cloud to experience lots of change in a compressed period of time. Our books help because they are constantly updated to track change. At least, we do our best to understand the changes and communicate it as clearly as we can to our readers.