Questions about New-PnPPersonalSite / Request-PnPPersonalSite

[TobiasAT]

Hello, I want to ask if there are plans to update New-PnPPersonalSite or Request-PnPPersonalSite.

1. From my understanding the method for appregnew.aspx creates Azure ACS principals. There is now a note they will be deprecated in April 2026, as described at https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins/retirement-announcement-for-azure-acs.

2. The method for Connect-PnPOnline without an Azure ACS principal is not working, also not with a secret key. Neither Graph or SharePoint API permissions (Sites.FullControl.All) are working, always no permissions. Are there alternative permissions to the Azure ACS principal?

3. In general I don't know why there are two commands with similar results. What is the difference between the two commands? Same question like New-PnPPersonalSite vs Request-PnPPersonalSite #3851.

I try to find a method to pre-provision OneDrive site collections via an Azure app but without the Azure ACS principals.

Thanks for an input.

Tobias

[NorwegianTacoIsNrOne]

I’m encountering a similar issue while automating OneDrive pre-provisioning at scale for multiple customer tenants using PnP.PowerShell. Specifically, I’m running into challenges with the Request-PnPPersonalSite cmdlet due to its reliance on legacy authentication mechanisms, which are blocked on most modern tenants. This seems to be the root cause of the access issues (despite the app having Sites.FullControl.All permissions).

Here are the key challenges I'm facing:

- Certificate-based authentication, which is the preferred modern security method, doesn’t work with Request-PnPPersonalSite. The cmdlet still requires ClientId and ClientSecret, which forces the use of legacy authentication.

- Graph API permissions such as Sites.FullControl.All also don't seem to apply, leading to permission errors. My objective is to move away entirely from the outdated appregnew.aspx method and adopt modern Azure AD App registrations with API permissions.

This is a critical issue because I need to automate this provisioning process on a daily or weekly basis across different customer tenants. Switching to Microsoft.Online.SharePoint.PowerShell isn’t an option either, as it lacks support for modern API permissions like PnP.PowerShell. While we can temporarily rely on service accounts using Microsoft.Online.SharePoint.PowerShell, this will no longer be viable once Microsoft enforces MFA on service accounts in 2025 (unless there’s a workaround for that?).