Using the OfficeDev PnP PowerShell Cmdlets for both on-prem and in the cloud

The Office 365 Developer Patterns and Practices PowerShell Cmdlets turn out to be lifesavers for many people. They easily allow you to create artifacts in your SharePoint sites, like lists, fields, etc. without needing to click around or write a complex C# application.

The PowerShell Cmdlets come in 2 versions: one for Office 365 and one for on-prem. The reason for this is that the CSOM SDK, which the cmdlets use behind the scenes, also come in two versions.

There are two installers available, but when you install them both, only one set of the cmdlets seem to be loaded when you open PowerShell. Why that is I will explain below.

A bit of background

PowerShell has functionality to auto-load modules. It does this based upon a path environment variable and it will scan the folders in that variable to find the modules. The easiest way to see the environment variable is by opening PowerShell and then you enter:

The result will be a list of paths. In there, if you have the PnP PowerShell Cmdlets installed, you will see a reference to the installation location of the cmdlets. By default, that will be something alike

When you open PowerShell, it will scan that folder for modules and if its finds one it will load that module into memory. Now if you install both versions of the cmdlet, both will be added to the path, but as they have the same signature, only one of them will be loaded into memory. The modules will be loaded on-demand, so if you open PowerShell, they will not be there yet, but the moment you, for instance, use the Connect-SPOnline cmdlet it will load the module into memory.

To see all modules that are currently loaded and available, enter:

You’ll see something alike:

PowerShell Cmdlets

Notice that, although I installed both versions of the PowerShell Cmdlets, only one module has been loaded. In this case the V16 version, which is for SharePoint Online. The reason for this is the order of the paths in the PSModulePath environment variable. While both modules are in that path, the first one that matches the Connect-SPOnline cmdlet will be loaded.

Now, say that you have both an online Office 365 tenant and you have a local SharePoint server too, and you want to write a script that handles both?

Setup your environment

The first step is to install both versions of the PowerShell Cmdlets from https://github.com/officedev/pnp-powershell/releases

Then remove the paths from the PSModulePath environment variable. So remove all references to the PnP PowerShell modules. This will prevent PowerShell from auto loading the cmdlets. To modify the environments variables, just press the Windows key and start type “environment”. It will offer you an option to edit the environment variables:

PowerShell Cmdlets

Then in your script you can then manually load the PowerShell Cmdlets using (everything on one line):

Replace V15 with V16 if you want to load the Office 365 version of the cmdlets. The path shown above is different if you install the cmdlets for all users. Then you will find the modules in

Using the approach above it’s possible to write a single script that, depending on the environment you’re using, loads the correct cmdlet module.

  • Heath Groves

    Thanks dude 🙂

  • Great post, thanks! I had to use “-Prefix” with PNP cmdlets to differentiate from SPO TechNet cmdlets. Both have Get-SPOSite, but it works differently.

About the author

Erwin is a Microsoft MVP, Microsoft Certified Master, and Microsoft Certified Solutions Master and works at Rencore. He is the product manager for SPTransformator, helping customers to successfully migrate from on-premises solutions and traditional solution packages to the new add-in model for SharePoint. Erwin is a core member of the SharePoint Patterns and Practices team (https://dev.office.com/patterns-and-practices) helping developers worldwide with code samples, scenarios, solutions, and guidance to successfully implement customizations for SharePoint and SharePoint Online. Erwin is speaking regularly at SharePoint conferences around the world, like Ignite 2015, and is one of the organizers of SharePoint Saturday Stockholm, the largest SharePoint focused conference in Scandinavia.