Microsoft Graph PowerShell SDK V2.34 Makes WAM the Default

Web Account Manager Enabled with No Workaround

With the holiday season fully engaged, people like me have blog posts scheduled a few days in advance to allow for some downtime. Which is why I missed Microsoft releasing V2.34 of the Microsoft Graph PowerShell SDK on Saturday, December 20. 2025 and didn’t include a very important change made in that release in V19 of the Automating Microsoft 365 with PowerShell eBook.

Microsoft doesn’t typically push a new version of a major software product over the weekend, especially as they released V2.33 a scant twelve days previously. When something like this happens, people like me become instantly suspicious that Microsoft or customers have discovered something very bad that required patching. The poor quality record of the Microsoft Graph PowerShell SDK earlier this year naturally brings bugs to mind (like those found in V2.26).

Windows Account Manager Becomes the Default

Finding out what happened is problematic because a large number of Microsoft engineering personnel are on vacation. According to the people I reached, the only change in V2.34 is to make use of the Web Account Manager (WAM) mandatory for interactive Graph connections.

WAM is an authentication broker that the Microsoft Graph PowerShell SDK previously supported to enable token protection. However, problems with the previous implementation, such as lack of support for administrator connections and a module clash with the Azure Identity Broker effectively stopped WAM working with SDK connections after V2.25. Microsoft has fixed the problems and WAM is now the default login experience for Graph SDK interactive connections, including sessions that use administrator accounts. After installing V2.34, you will notice a different UI to select the account used to connect (Figure 1).

In addition, you’ll see this text after a successful connection:

NOTE: Sign in by Web Account Manager (WAM) is enabled by default on Windows systems and cannot be disabled. Any setting stating otherwise will be ignored.

Possibly Related to a Security Issue

Fixing a problem that’s been around for a few versions and then suddenly rushing out a new release over a weekend is just strange. Microsoft only ever does something like this when it responds to a security issue. What might have happened is that Microsoft has been made aware of a vulnerability that affects the Microsoft Graph PowerShell SDK and moved to close off the issue as quickly as possible.

The holiday period will likely lead to a lack of communication until everyone returns from vacation. In the interim, my recommendation is that you upgrade non-production systems to V2.34, test scripts to make sure that they work as expected (so far, all my scripts have worked) and then deploy V2.34 into production.

The update does not affect Azure Automation runbooks that use Microsoft Graph PowerShell SDK cmdlets. It is only relevant for interactive delegated sessions. Interactive app-only sessions use a different authentication route and are unaffected by WAM.

If you use Windows PowerShell V5.1 to run Microsoft Graph PowerShell SDK sessions, you might run into the same problem as reported here. Microsoft is aware of the issue and is investigating. The issue does not arise with PowerShell Core (V7; I used V7.5.4 for testing). I recommend that PowerShell Core is used for all production use of the Microsoft Graph PowerShell SDK.

A Popular Component

On a positive note, even if it’s a pain to be forced to upgrade to a new version twelve days after the previous release, it’s good to see Microsoft take action to fix known issues. V2.32 of the Microsoft Graph PowerShell SDK had over 880K downloads, so it’s obviously an important component for many Microsoft 365 tenants. Protecting those kinds of components is obvious important, as is keeping book content updated. Which is why V19.1 of the Automating Microsoft 365 with PowerShell eBook is now available for download.