Problems with Azure Automation Afflict Microsoft 365 PowerShell Modules

The recent problems with the Microsoft Graph PowerShell SDK are well documented. Suffice to say that the Graph PowerShell SDK hasn’t been very stable since V2.25. V2.26 and V2.27 just didn’t work, and although Microsoft delivered a much-improved update in V2.28 in May 2025, the Graph PowerShell SDK still has problems with Azure Automation.

In the Azure Automation environment, runbooks are configured to use a runtime version of PowerShell. When a runbook starts, Azure Automation loads the dependent modules (which must be a version that matches the runtime version) on the target server where the runbook executes. Currently, Azure Automation supports runtime versions for PowerShell V5.1, V7.1, and V7.2.

A Question of .NET

PowerShell V5.1 is the “classic” version. V7-based PowerShell is “PowerShell Core.” The V7.1 and V7.2 runtimes support .NET 6 while the latest versions of PowerShell use .NET 8. Software engineering groups don’t like supporting what they consider to be outdated software, so a decision was taken to drop support for .NET 6. The net effect was that V7.1 and V7.2 runbooks couldn’t use the Graph PowerShell SDK. The workaround was to use the PowerShell V5.1 runtime or revert to V2.25 of the Graph PowerShell SDK, which still supports .NET6.

Microsoft says that the solution will come when Azure Automation supports the PowerShell V7.4 runtime. That update was supposed to arrive by June 15, 2025. It’s late, so I cannot confirm or deny if Graph PowerShell SDK V2.28 code supports PowerShell V7.4 runbooks.

The .NET Versioning Problem Strikes Exchange

A week or so ago, a reader complained that the latest version of the Exchange Online management module (now V3.8.0) didn’t run with PowerShell V7.2 runbooks. A previous comment for the article where the issue was raised said that V3.5 was required to support PowerShell V7.2 runbooks as long ago as February 13, 2025. At the time, apart from finding a relevant Stack Overflow discussion, I didn’t pay too much attention to the problem. I guess I became accustomed to the Exchange module just working while the Graph PowerShell SDK was the problem child of the Microsoft 365 PowerShell modules.

As it turns out, the Exchange Online management module shares the same problem as the Microsoft Graph PowerShell SDK. Engineering decided to remove support for .NET 6 in V3.5.1 of the Exchange module and screwed up Azure Automation V7 runbooks. The release notes for V3.5.1 are brief and concise:

Version 3.5.1

• Bug fixes in Get-EXOMailboxPermission and Get-EXOMailbox.
• The module has been upgraded to run on .NET 8, replacing the previous version based on .NET 6.
• Enhancements in Add-VivaModuleFeaturePolicy.

There’s nothing to raise awareness for tenant administrators that the change in supported .NET version will stop runbooks dead in the water. It’s easy to glance over the release notes and conclude that not much has changed and it’s therefore safe to upgrade to the new version. The problem becomes very evident when the Connect-ExchangeOnline cmdlet can’t run and as a result, every other Exchange cmdlet cannot be found (Figure 1).

The Need for Solid Azure Automation Support

No one denies that Microsoft must prune old software from their cloud services. It’s hard enough to keep a service running smoothly when it carries unnecessary baggage in the form of old code. But in the cases of both the Microsoft Graph PowerShell SDK and the Exchange Online Management module, it seems like the engineering groups never stopped to ask if the change might impact the ability of scripts to run. Running scripts interactively revealed no issues, but running code in an interactive session on a Windows PC (or even a Mac) is not the same as Azure Automation firing up a headless Linux server and configuring it with the software necessary to execute a runbook.

Ensuring that shipped modules support Azure Automation is a problem that can be solved by incorporating Azure Automation runbooks in the test procedures that must succeed before a new version of a module can be released. What’s more upsetting is the lack of awareness within Microsoft about why customers pay for Azure Automation to run scripts.

When a script moves from running interactively on an administrator workstation to become an Azure Automation runbook, it’s probably because the script is deemed to be important enough to run on a stable, robust, and secure environment, often on a schedule (the Windows Task Schedule should not be relied upon to run important scripts). In other words, Azure Automation is an important platform that deserves the respect and solid support of the Microsoft engineers that build PowerShell modules that can run within Azure Automation. That doesn’t seem to be the case today.

Too Much Disruption

Microsoft 365 tenants have suffered far too much disruption with PowerShell modules over the last few years. The retirement of the old Azure AD and MSOL modules was a necessary evil, but Microsoft didn’t handle the situation as well as they should. Many sins might be forgiven if the Microsoft 365 PowerShell modules were rock solid. They’re not currently. Let’s hope that Microsoft does a better job in their testing and pre-release verification processes for PowerShell modules in the future.

Need some assistance to write and manage PowerShell scripts for Microsoft 365? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.

Update #12 Available to Help People Figure Out Microsoft 365 PowerShell

As is our norm, we have released the monthly update for the Automating Microsoft 365 with PowerShell eBook some days before the end of the month to allow us to concentrate on working on the Office 365 for IT Pros eBook. The current version number is 12.2 and the updated PDF and EPUB files are available for subscribers to download from Gumroad.com. Please use the link in your receipt (which always fetches the latest files) or go to your Gumroad account, See our FAQ for more information about downloading book updates.

The Automating Microsoft 365 with PowerShell eBook is available separately and as part of the Office 365 for IT Pros eBook bundle. The same update is available to all subscribers.

We also have a paperback version of the book available from Amazon.com. This version is proving to be more popular than we anticipated. I guess some people still like the tactile experience of reading a real book, and we are happy to oblige. Regretfully, we cannot provide monthly updates to the paperback edition as there’s no way to paste (literally) updated text into paper copies.

Focus Areas for Update #12

Most of the work in Update #12 focused on adding extra detail to the sections covering retrieving calendar information, messages, group-based license assignments, and sensitivity labels. Like always, a bunch of other changes were made to clarify thoughts or correct possible misinterpretations.

It’s the nature of a book like this that developments in Microsoft’s tools affect our content, so some Graph API requests that were used because of problems with Microsoft Graph PowerShell SDK cmdlets are now replaced by cmdlets following the release of V2.28 of the SDK on May 10, 2025.

Should I Upgrade to V2.28 of the Graph PowerShell SDK?

So far, the experience with V2.28 is positive. However, this isn’t a massive endorsement because the previous versions were so buggy and poorly tested prior to release. I think it’s safe to say that V2.28 is at least as good as V2.25, which was the last good release.

This does not mean that V2.28 is bug free. I think it would be impossible to release even a 99% bug-free Graph PowerShell SDK. The number of dependencies on many different product groups, the complex interactions with other PowerShell modules and products like Azure Automation, and the errors and omissions in the Open API documents that describe the different Graph APIs all create the potential for problems like missing parameters or failure to process parameters properly. Throw in some Entra ID authentication problems, like the current bug that sometimes requires double authentication after running the Connect-MgGraph cmdlet to create an interactive session, and it’s easy to understand why there’s over 160 reported issues for the SDK.

Bugs are a fact of IT life, and the presence of some known bugs is no reason to avoid using the Graph PowerShell SDK. In fact, the SDK is more popular now than ever before because of the retirement of the AzureAD and MSOL modules (some people still ask why they can’t run Connect-MSOLService or Connect-AzureAD like they used to…). It does mean that you should:

• Pay attention to the known bugs reported to Microsoft.
• Report any bugs that you find that aren’t on the known issues list.
• Be prepared to use the underlying Graph API if a Graph PowerShell SDK cmdlet doesn’t work as expected (alternatively, if a parameter doesn’t work, try passing values in a hash table using the BodyParameter parameter).

Overall, I think it’s safe to upgrade to V2.28. Remember to upgrade modules used as resources by Azure Automation accounts too.

On to Update #13

Work has now started on update #13, which is planned for July 1. This version of the book will be part of Office 365 for IT Pros (2026 edition), which we plan to release on the same day. Happy coding!

Updated EPUB and PDF Files Available for Download

The Automating Microsoft 365 with PowerShell eBook is now at update #9. This is the March 2025 update. We release monthly updates for the PowerShell eBook around the middle of the preceding month to allow us the time to concentrate on preparing the monthly update for Office 365 for IT Pros.

The updated EPUB and PDF files are available to:

• People who bought Automating Microsoft 365 with PowerShell on its own.
• Subscribers to the Office 365 for IT Pros (2025 edition) eBook.

Please use the download link in the receipt emailed after your purchase to access the updated files. Alternatively, you can get the updated files through your Gumroad.com account. The update number (and month) is shown at the bottom of each page.

Continual Expansion of Content

The original version of Automating Microsoft 365 with PowerShell spanned about 120 pages. The book is now 300 pages (more in the paperback edition because it includes an index). When we removed the PowerShell chapter from the Office 365 for IT Pros eBook, we always knew that there was much more to say about using PowerShell with Microsoft 365. Over the last eight updates, we’ve added a ton of examples, mostly covering the use of Microsoft Graph PowerShell SDK cmdlets with workloads like Entra ID, Exchange Online, SharePoint Online, and Teams.

Update #9 continues the trend with new content covering topics like using the Sites.Selected Graph permission to control access to SharePoint Online sites, how to upload files to SharePoint Online, sending multiple attachments with Exchange Online, and using an upload session to process very large attachments. There are many other changes, rewrites, and enhancements scattered across the book, including a complete rewrite of our coverage of using Microsoft 365 PowerShell with Azure Automation.

Price, Price, Price

To reflect the increased value of the content included in Automating Microsoft 365 with PowerShell, we’ve increased the price from $12.95 to $14.95. Other books covering the use of PowerShell with Microsoft 365 are priced significantly higher, so we think that even the new price represents incredible value. We’re confident that no other book covers the number and variety of fully-worked out examples of how to use PowerShell to get work done with Microsoft 365.

We also increased the price of the paperback edition to $19.95. This is simply a function of the increased page count driving the cost we pay Amazon to print each copy on an on-demand. There’s nothing to stop anyone printing off the PDF version if you want a paper copy. The only issue you’ll run into is that the many hyperlinks (over 200 at the last count) we include in the book become unusable when printed. To get around the issue, we substitute plain-text links in the content of the paperback edition.

Subscribers of Office 365 for IT Pros don’t have to pay any extra for their copies of Automating Microsoft 365 with PowerShell.

Onto Update #10

Work has already started on update #10. We’re waiting for Microsoft to release a new version of the Microsoft Graph PowerShell SDK. V2.25 has been around for about three months now, which is much longer than the usual monthly release cadence (Figure 1).

I don’t know why Microsoft has delayed the release of V2.26. It’s certainly not to deal with the problem related to plain-text passwords reported last week. No doubt we will hear in time. In the meanwhile, the interesting thing about the information shown in Figure 1 is the dramatic usage growth for the SDK from 1.18 million downloads of V2.24 to 3.49 million downloads for V2.25. That’s probably indicative of an uptick in interest as tenants work to get off the soon-to-retire MSOL and Azure AD modules. Maybe all those folks upgrading scripts to use the Graph SDK could do with a good book?

A Store of PowerShell Scripts for Microsoft 365 Tenant Management in the Office365ITPros GitHub Repository

I’m on record as saying that knowing how to access and interact with Microsoft 365 data with PowerShell is essential knowledge for tenant administrators. Many options are enabled through settings that are only accessible through PowerShell, and it’s possible to extract more data from workloads with PowerShell (including use of Graph API requests) than is exposed through the different Microsoft 365 administrative interfaces.

Microsoft helps by including PowerShell examples in its documentation. The examples are basic and tend to concentrate on performing a single step in what is often a more complex sequence of commands necessary to fully complete a task. Nevertheless, all examples are welcome, and the Microsoft examples receive lots of attention because of their source.

What’s in the Office365ITPros Repository

As part of investigating Microsoft 365 technology to report how things work, we write a lot of PowerShell code. Until 2019, we published code in articles. At an Experts Live event in Oslo, Norway in 2019, Ståle Hansen (who wrote the Teams devices chapter for the book at that time) suggested that we establish a GitHub repository and use it to distribute script samples instead. Simple web links allow us to reference scripts in the Office365ITPros GitHub repository as needed in presentations, articles, and the Office 365 for IT Pros and Automating Microsoft 365 with PowerShell eBooks.

The suggestion made a ton of sense. Instead of updating script code in WordPress pages, we could update the script code in GitHub to keep it current, eliminate annoying bugs, and smoothen out problems caused by Microsoft changing the way that cmdlets work. For instance, scripts that call the Search-UnifiedAuditLog cmdlet have needed updates several times since 2018. Looking forward into 2025, Microsoft proposes to make another fundamental (and horrible) change to Search-UnifiedAuditLog that will cause many problems.

Another important change happened when the Microsoft Graph PowerShell SDK went from V1 to V2 and changed the structure of the modules and naming scheme for the beta cmdlets. Looking back, this was a good change, even if it caused disruption at the time by forcing developers to remove the cmdlet that selected beta or production cmdlets together with renaming any beta cmdlets called in scripts.

https://office365itpros.com/2021/01/21/introducing-office-365-for-it-pros-github-repository/The Office 365 for IT Pros GitHub repository (Figure 1) currently contains 304 PowerShell scripts covering different aspects of Microsoft 365 and Entra ID tenant management (the repository held 80 scripts when we first launched it in 2021). We update scripts when we discover issues or when people let us know about bugs or features they would like to see implemented.

The quality of the code has gradually improved over the years. Several reasons exist why this should be so:

• Writing complete scripts rather than snippets forces more attention to elements like error handling and report generation.
• The influence of GitHub Copilot. Everyone involved with Microsoft 365 PowerShell should use GitHub Copilot, especially now that Microsoft offers a free version of GitHub Copilot for Visual Studio Code.
• Learning from other people, including Michel de Rooij’s Practical PowerShell series.

The repository could be better organized into folders for different topics and the naming convention isn’t great at times. We know that things could be better and improving the structure is on our to-do list.

It’s important to understand that Office 365 for IT Pros does not create fully-fledged solutions. The scripts are to explore principles of interacting with Microsoft 365 workloads, to extract and refine data, create objects, manage settings, and so on. Error handling is enough to make sure that everything works, but not sufficient for deployment in a production environment. We take this approach deliberately because every organization has its own coding standards. Our intention is that developers can take the code we create and meld it in their own fashion to solve automation problems within a tenant.

Forking the Office365ITPros GitHub Repository

You can share the scripts in the Office365ITPros repository by forking to create your own copy of the repository. As you can see from Figure 1, 583 forks exist for the Office365ITPros repository, all created by people who want to have their own copy of the scripts to work with. Those with forks can change code to make scripts work better by fixing bugs or adding features and then push the changes for inclusion in our repository. Twenty people have made contributions in this manner since the creation of the repository. It’s a great example of community in action.

Browse the Office365ITPros GitHub Repository – And Maybe Become a Contributor

The Office365ITPros repository exists to share PowerShell code so that we can all learn how to write quality scripts for Microsoft 365. Take the time to browse the scripts to see what might be useful to you. If you find something that could be done better, fork the repository and make the change and push the amended code to us. We’ll have a look at the changes and decide whether to accept them. We always welcome a new contributor!

Need more help to write and manage PowerShell scripts for Microsoft 365? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.

Microsoft 365 PowerShell Automates Management Operations Quickly, Easily, and Cheaply, No Matter What an MVP Says

My strong view that it’s often a bad idea for Microsoft MVPs to endorse ISV products (with or without payment) was reinforced by a recent article titled “6 Reasons Why Identity Admins Should Retire Scripting” written by Sander Berkouwer (described as an Extraordinary Identity Architect in his LinkedIn profile).

Update: The original article is no longer available on the ENow Software site. It seems like they pulled it soon after this article appeared.

Update 2 (March 12): ENow Software republished an amended article. It still contains inaccuracies and demonstrates a lack of knowledge and awareness about the role and function of the Microsoft Graph PowerShell SDK.

The article is a thinly disguised pitch for ENow Software’s App Governance Accelerator product. Basically, Berkouwer says that Entra ID administrators (who are often the same people as Microsoft 365 tenant administrators) should eschew PowerShell and leave management automation to ISVs. It’s a ridiculous position that is insulting to the many IT professionals who work with PowerShell daily.

I’m all for strong ISV participation in the market and have worked with ENow Software and other ISVs during my career. Because the cloud is a more closed environment, it’s more difficult for ISVs to find niches to exploit in the Microsoft 365 ecosystem than in on-premises environments. It’s natural for ISVs to respond by seizing every opportunity to publicize their products. In doing so, many ISVs seek the endorsement of “an expert,” like a Microsoft MVP. In my eyes, these endorsements are close to worthless.

How Microsoft 365 PowerShell Helps Administrators

The major theme developed by Berkouwer is to question whether writing PowerShell scripts is a good use of administrator time and lays out six “reasons to retire this practice.” My perspective is that understanding how to use PowerShell is a fundamental skill for Microsoft 365 administrators to acquire. You don’t have to be proficient, but PowerShell helps administrators to understand how Microsoft 365 works. This is especially true of using Graph APIs, including through the Microsoft Graph PowerShell SDK.

Here are the six reasons advanced for why administrators shouldn’t spend time writing scripts.

Microsoft renamed Azure AD: Including this as a reason to stop writing PowerShell scripts is simply silly and undermines the author’s credibility. Product rebranding happens. The important point is what a product does. Should we stop using the Microsoft Purview solutions simply because Microsoft decided to bring them all under the Purview brand? Or perhaps Yammer customers should have fled when Microsoft renamed it as Viva Engage?

Don’t trust random scripts you find on the internet… “written by everyone’s favorite Microsoft Most Valuable Professional.” This has been the advice given about PowerShell scripts since 2006. It is not a blinding insight into new knowledge. Great care is required with any code downloaded from the internet, including any of the 250-odd scripts available from the Office 365 for IT Pros GitHub repository.

Downloaded code, even written by a favorite MVP, should never be run before it is thoroughly checked and verified. But it’s also true that many scripts are written to demonstrate principles of how to do something instead of being fully worked-out solutions. Before people put PowerShell code into production, it must meet the needs and standards of the organization. For instance, developers might tweak a script to add functionality, improve error handling, or log transactions. Michel de Rooij addresses some of these challenges in his Practical365.com column.

Berkouwer’s assertion ignores the enormous value derived from how the community shares knowledge, especially at a time when tenants are upgrading scripts to use the Graph SDK. Without fully worked out examples, how could people learn? I learned from examples when PowerShell first appeared with Exchange Server 2007 in 2006. I still learn from examining PowerShell scripts written by others today. And many maintain the scripts shared through GitHub repositories.

The greater use of GitHub repositories and their inbuilt facilities to report and resolve issues helps people to share and maintain code. In addition, GitHub Copilot helps developers reuse PowerShell code that’s stored in GitHub to develop new solutions. The net is that it is easier than ever before to develop good PowerShell code to automate tenant operation.

Least Priviliged Principle. It’s true that the changeover from older modules like MSOL and AzureAD to the Graph SDK brings a mindset change. Instead of assuming that you can do anything once you connect to a module with an administrator account, some extra care and thought is needed to ensure that you use the right Graph permissions (delegated or application). Right permission means the lowest privileged permission capable of accessing the data a script works with. Yes, this is a change, but finding out what Graph permissions to use is not a difficult skill to master and I utterly fail to see why Berkouwer considers it to be such a big problem. If anything, adopting the least privileged principle drives better security practice, and that’s goodness.

The only constant in life is change. Yes, change is ongoing all the time across the Microsoft 365 ecosystem, but it is untrue that people can’t keep pace with that change. Microsoft publishes change notifications and although they’re not perfect and don’t include everything that changes (like Entra ID updates), a combination of the message center notifications (perhaps leveraging the synchronization of message center information to Planner) and RSS feeds to track important Microsoft blogs is all that’s needed.

There’s no evidence to suggest that ISVs are any better at tracking change within Microsoft 365. If anything, ISV development cycles, the need for testing, and customer desire for supportable products can hinder their ability to react quickly to changes made by Microsoft.

Maintaining and updating scripts. I’m unsure why the European Cyber Resilience Act is introduced into the discussion. It seems like some FUD thrown into the debate. PowerShell scripts are like any other code used in production. They must have a designated owner/maintainer and they should be checked as new knowledge becomes available, just like programs written using C# or .NET must be checked when Microsoft releases updates. ISVs have the same problems of code maintenance, so handing a task over to an ISV might resolve a tenant of some responsibility without being a magic bullet.

Zero trust. “When you run scripts for monitoring and security reporting purposes, they must provide instantaneous, useful information.“ Well, it would be nice if tenants always had instantaneous data to process but the singular fact is that tenants and ISVs share the same access via public APIs to information like usage reports, audit logs, license data, sign-in logs, workload settings, and so on. For instance, the data used to create a licensing report comes from Entra ID user accounts and a Microsoft web page. The data that the ENow App Governance Accelerator product comes from Entra ID and is easily accessed and reported using PowerShell (here’s an example).

ISVs and PowerShell Access the Same Microsoft 365 Data

ISVs don’t have magic back doors to different information that suddenly throws new light onto the inner functioning of Microsoft 365. ISVs might develop innovative ways of using information and use those methods to create new features, but that’s not the instantaneous, useful information that Berkouwer wants.

If Microsoft 365 tenants want to run PowerShell scripts to check what turns up in audit and other logs, a simple solution exists in the shape of Azure Automation runbooks executed on a schedule. It’s not hard to translate a regular PowerShell script to execute in Azure Automation and the support for managed identities in the major Microsoft 365 modules makes authentication for runbooks easy and highly secure. Here’s an example of using Azure Automation to create a daily risk report for Microsoft 365 tenants.

No Reason to Dump Microsoft 365 PowerShell

The solution is emphatically not to dump PowerShell scripts for an ISV product. Well-written PowerShell is as robust and secure as any ISV product. It’s worth noting here that Microsoft uses tons of PowerShell in its operations.

No single off-the-shelf product can cater for the different aspects of Microsoft 365 tenant management. ISV products have bugs, need to be supported, sometimes do a worse job than tenant-developed scripts, and no guarantee exists that the products will keep up with changes within Microsoft 365. Deploying ISV products also involves additional costs to pay for licenses and support.

On the other hand, ISV products are usually developed and maintained by very experienced professionals who are dedicated to that task (and don’t have to worry about day-to-day tenant management), so they have the time and space to think more deeply about what their product does.

ISVs Should Compete on their Merits, Not with False Arguments

I have the height of respect for Microsoft 365 ISVs and the products they create and support. Those of us who have worked in this space understand the challenges of running ISV operations and how difficult it is to succeed in a very competitive market. Product reviews do help, but only when the review focuses on explaining the strengths and weaknesses of a product after the reviewer spends a reasonable amount of time getting to understand the technology and how it fits into the ecosystem it works in.

Many ISV offerings work extremely well and do a good job of filling gaps left by Microsoft. I applaud the innovation I see in many ISV products and how they add real value to the Microsoft 365 ecosystem. ISVs do not need to be supported by artificial arguments, especially laughable advice to avoid using one of the most valuable tools available in tenant management toolboxes. If Sander would like some help understanding the usefulness of the Microsoft Graph PowerShell SDK, I’ll be delighted to help if he attends my session at the Microsoft 365 Conference in Orlando.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.