Connect PnPOnline: Specified Method Is Not Supported
You run a PnP PowerShell script that worked fine for years, and you get this:
Connect PnPOnline: Specified method is not supported.
Or, depending on which version of the module you are on, this one:
AADSTS700016: Application with identifier '31359c7f-bd7e-475c-86db-fdb8c937548e'
was not found in the directory.
Both mean the same thing. Nothing is wrong with your script. The app registration it was quietly relying on does not exist any more.
What happened
PnP PowerShell came with an Entra ID app called “PnP Management Shell” until September 2024 which allowed multi-tenant access, and all tenants were able to utilize it without registering anything. This is the app ID in the error message. The announcement that it will be removed from PnP PowerShell was made on 21 August 2024, and on 9 September 2024 it was removed.
Thus, Connect-PnPOnline -Url…-Interactive without -ClientId authenticates to nowhere. So you have to create your own app registration in your tenant.
This is actually a good thing, despite the fact that it broke everyone’s scripts at once. The shared app was way too permissive for any script.
The fix: register your own app
PnP gives you a cmdlet for this, so you do not have to click through the Entra portal. Run this once per tenant:
Register-PnPEntraIDAppForInteractiveLogin `
-ApplicationName "PnP.PowerShell" `
-Tenant contoso.onmicrosoft.com `
-Interactive
The one to watch here is -Interactive. On PnP.PowerShell 2.x you must include it, or you get this instead:
Register-PnPEntraIDAppForInteractiveLogin: Parameter set cannot be resolved
using the specified named parameters.
Which is not a useful message when you are fixing another error. Run Get-Module PnP.PowerShell -ListAvailable to check what you are using and, should you get confused about your version’s parameters, Get-Command Register-PnPEntraIDAppForInteractiveLogin -Syntax shows you instead of the documentation that talks about whatever version is current.
Then you will get the following warnings that no permissions have been specified, so defaults will be used, a line that the app was registered with its ID, and a wait of 30 seconds until Entra ID registers everything before opening the consent window. Log in and accept.
At the end, it prints a Client ID. Grab it because you will need it every time you log in from now on.
This requires either Global Administrator or Application Administrator permissions because it creates app registration and gives consent to it. If you do not have such permissions, that is the time to go and ask someone who is.
Then connect like this:
Connect-PnPOnline `
-Url "https://contoso.sharepoint.com/sites/Demo" `
-ClientId "11111111-2222-3333-4444-555555555555" `
-Interactive
That is it. Every script you have needs that one extra parameter.
If your script runs unattended
Interactive login is no good for anything scheduled. For that you want app-only with a certificate:
Register-PnPEntraIDApp `
-ApplicationName "PnP.PowerShell.Unattended" `
-Tenant contoso.onmicrosoft.com `
-OutPath C:\certs `
-DeviceLogin
That writes a certificate to C:\certs. Then:
Connect-PnPOnline `
-Url "https://contoso.sharepoint.com/sites/Demo" `
-ClientId "11111111-2222-3333-4444-555555555555" `
-Tenant contoso.onmicrosoft.com `
-CertificatePath "C:\certs\PnP.PowerShell.Unattended.pfx" `
-CertificatePassword (ConvertTo-SecureString -String "yourpassword" -AsPlainText -Force)
Keep that certificate somewhere sensible. Anyone who has the file and the password has whatever permissions you granted the app.
Two things that catch people out
You still receive an error message after registration. In nine out of ten cases, you will either lack a permission or have it but nobody ever tapped the Grant admin consent. You can go to Entra admin center > App registrations > API permissions to see the warning triangle.
Both cmdlets only add a small default set of permissions. If your script does something beyond reading sites, add what you need explicitly:
Register-PnPEntraIDAppForInteractiveLogin `
-ApplicationName "PnP.PowerShell" `
-Tenant contoso.onmicrosoft.com `
-SharePointDelegatePermissions "AllSites.FullControl" `
-GraphDelegatePermissions "User.Read.All"
Register once, put the Client ID somewhere your scripts can read it, and you are back to writing PowerShell instead of fixing it
If you are updating old scripts, my earlier post on copying SharePoint Online web part settings with PnP PowerShell is one of the ones I had to go back and fix. The connection line was the only part that changed.
4 Comments
Comments are closed.