2020-07: Upcoming PnP PowerShell developments and recommendations

Upcoming PnP PowerShell developments

At the moment (July 2020), the large variety of Microsoft Services in the Microsoft 365 ecosystem require a lot of separate modules. However, work is ongoing at Microsoft to unify the desired Microsoft 365 and Azure AD operations spanning multiple (if not all?) services in a single Microsoft Graph API. The PnP PowerShell¹ module is using these MS Graph developments to provide a ‘one module solution’ and is already equipped to make use of the Graph API. Recently some interesting Microsoft Graph-based, Teams specific cmdlets were added as well. Great stuff!

As you may have noticed I am a big fan of the PnP PowerShell initiative and some exciting things are happening here, like pending support for PowerShell 7 (which has been built on the platform independent ‘.NET Core’ and has some nice backward compatibility with ‘normal’ PowerShell). As a consequence:

1. Supporting the various Online and On Premises PnP PowerShell modules will will become a little more difficult as the Microsoft’s .NET Standard baseline will drop support for the SharePoint ‘On Premises’ CSOM for .NET Framework implementation², so apps built on .NET Core will not be able to make use of it, without which you can not hope to manage SharePoint ‘On Premises’. Catering to both the Online and On Premises CSOM implementations requirements could prove tough on supportability since their underlying .NET base classes are effectively forked³ and Microsoft has no plans on porting cloud API developments to the ‘On Premises’ products, at the time of writing. Of course the extra dimension (platform independent-ness) .NET Core brings, will surely shift the focus off the ‘On Premises’ product line for both Microsoft and PnP development teams even more than it already has.
2. It seems that support for using SharePoint Online basic ‘user credentials’ (SharePointOnlineCredentials class) to connect to SharePoint through .NET Standard will be dropped as well. This is really not an issue since PnP PowerShell already implements a modern authentication flow so you can keep⁴ using username/password combinations in the Online product as an authentication method (with CA policies applied!)⁵. The PnP-Sites-Core project will probably support this connection method in combination with .NET Standard as well, but we will have to see. That means PnP PowerShell can make use of that. You do need to turn off the ‘LegacyAuthProtocolsEnabled’ switch on your Office 365 tenant to actually make use of the modern authentication flow and make sure your account will not trigger an MFA CA rule if you intend on using your script in an unattended manner.

Recommendations

Considering all this it might be time to change your PnP PowerShell authentication method of choice to Azure AD App-Only just to be sure you remain fully compatible with the new .NET Standard and Core developments in the future. A nice overview of the various ‘Connect options’ is being maintained here. Finally, I would recommend NOT going the ClientId/ClientSecret route and start adopting Certificate/Thumbprint methods as the latter would permit forgoing the somewhat archaic feeling SharePoint App-Only route if you intend to use PnP PowerShell mainly for SharePoint Online asset configuration that is. If you intend to use only the Microsoft Graph functionality of the PnP PowerShell modules you could consider the ClientId/ClientSecret route.

1. Simply the best community driven PowerShell module development initiative ever. Part of the PnP initiative. ↩

2. Read all about .NET Standard support for the various SharePoint CSOM implementation in this article. ↩

3. Read all about the .NET architecture here. ↩

4. Method of connecting to SharePoint in an ‘unattended’ manner permitting a ‘user context’ (still needed for some operations, because of legacy CSOM operations) and is both securable with and monitorable by CA policies. ↩

5. This is probably a good thing since the way you should enforce a ‘least privilege’ methodology for alternate (recommended) ‘App-Only’-based connection mechanics is as of yet unknown to me. First of all the App-Only credential/certificate approach that is being pushed is an ‘all or nothing’ approach at the moment. For instance once you grant an app the ‘Group.ReadWrite.All’ permission in Azure AD, there is no way to block the app access to a specific group/site. Service Principles seem to have too much power and lack fine-grained control as observed by others here and here as well. Secondly the App-Only approach has some unexpected bugs mentioned here and here at the moment. If you have more information on the subject, please leave a comment. ↩