I’ve done a few articles about the new PnP.PowerShell module. One of the biggest changes from its ancestor, SharePointPnPPowerShellOnline, is that it requires the registration of an Azure Application before you can connect with it. In this blog post I’m going to explain how to get that Azure App registered if you’re not a Tenant Admin in your tenant.
You don’t need to be a Tenant Admin to use the PnP.PowerShell cmdlets. You don’t even need to be a SharePoint Admin or a site collection admin. There are plenty of cmdlets you can run, like Add-PnPFile if you’re only a Member of the site. However, before you can run the most import PnP cmdlet of all, Connect-PnPOnline, the PnP Azure Application has to be registered in your tenant by a tenant admin. If it’s not, you’ll get a sad message that looks like this:
Here’s the text:
Connect-PnPOnline: AADSTS65001: The user or administrator has not consented to use the application with ID '31359c7f-bd7e-475c-86db-fdb8c937548e' named 'PnP Management Shell'. Send an interactive authorization request for this user and resource.
In most cases the person introducing the PnP.PowerShell module is a tenant admin, so it’s not an issue. They run Register-PnPManagementShellAccess and Bob’s your uncle. But it’s not uncommon for an organization to be large enough that the SharePoint or Microsoft 365 Admin team is not a tenant admin. In that case the Tenant Admin, who likely doesn’t know what a PnP.PowerShell is, has to register the Azure App before the SharePoint Admin can enjoy the bliss that is PnP.PowerShell. Fortunately, there’s an easy enough solution, the Consent URL.
The Consent URL is the URL to a web page your Tenant Admin can go to to consent the PnP.PowerShell Azure App without needing to install anything, or really know anything about the PnP.PowerShell. There are a few ways to get the Consent URL. It doesn’t matter how you do it, they all get you to the same place.
The easiest way to remember is to run Register-PnPManagementShellAccess –ShowConsentUrl after installing the PnP.PowerShell. You’ll be asked to log in, but you don’t need to be an sort of admin. It’s only logging in so it knows when tenant you’re in. Then it will give you the Consent URL. It looks like this:
The part in the red box is your tenant’s ID.You had to log so the cmdlet could get that number. The Client_id refers to the PnP.PowerShell, so it’s the same everywhere.
You can also specify your tenant’s name instead of its ID. This works as well:
Whether you get the URL from running Register-PnPManagementShellAccess –ShowConsentUrl or by copying it out of this blog post and putting your tenant’s information, send that URL to your Tenant Admin. When they browse to the page it will look like this:
All they need to do is click Accept and you’re ready to go.
That’s a pretty long, scary list of permissions, and it might spook some admins. Accepting this does not give everyone in your tenant all of those permissions. The PnP.PowerShell Azure App uses Delegation, which means any user using it to access objects in Microsoft 365 has to have permission to access it. The PnP.PowerShell does not allow anyone access to anything they don’t otherwise have access to. If they don’t believe you, have them try. Have someone that cannot open up a SharePoint site in the browser try to connect to it with Connect-PnPOnline. They won’t be able to.
If they want to check out what the Azure App has permission to, or heaven forbid, remove it, you can browse to the Azure AD Portal and find it in the Enterprise Applications.
The Permissions blade will show you all delegated permissions the app has. Feel free to poke around, but resist the urge to change any, even if you’re positive you’ll never use them. I promise it’ll only hurt you in the future.
After your tenant admin has done all of that you should be able to get back to all that PowerShell and PnP goodness.