Office PnP Cmdlets Now Use *-PnP* Prefix
tl;dr;
If you have not been paying attention, the (awesome) PowerShell PnP Cmdlets are undergoing a big change. How do I know this you might ask? Well, I could have found this out the easy way by reviewing the 2nd November PnP recording information from Vesa Juvonen. However, as I often do, I learned the hard way.
To see the announcement and a demo, view the video below. What follows is is how I came to learn of the change while I was working with the Office PnP PowerShell cmdlets and some Azure Functions goodness.
Test Driving Azure Functions
With the recent introduction of Azure Functions I have been kicking the tires to see what they are capable of and how they benefit SMB's and enterprise customers. I have been trying different language options with Azure Functions and have tried C#, nodejs, and even a simple Python sample, but wanted to try some PowerShell.
While looking for how to get some PowerShell working in an Azure Functions, I ran across a recent blog post from John Liu, Build your PnP Site Provisioning with PowerShell in Azure Functions and run it from Flow. This seemed like a perfect exercise and combined a few of the new and shiny things I have been learning including Functions and Microsoft Flow (which is now GA).
Following the steps that John lays out, everything seemed to be going great. Then, this happened...
2016-11-10T14:24:51.342 Connect-SPOnline : The term 'Connect-SPOnline' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
at run.ps1: line 20
I knew it was too good to be true! This has to be more difficult than he's describing, right. Well, turns out it was a pretty simple issue, I just had to learn the hard way. :-)
Loading PowerShell Modules in Azure Functions
Loading external modules in Azure Functions requires creating a modules
folder and then adding your assemblies or scripts to this folder. The Azure Functions runtime will load these modules when your function starts. The process is described in perfect detail in this StackOverflow answer by the Azure Function team's @tohling.
Calling the Office PnP PowerShell Cmdlets
Well, the modules
folder exists and the modules were all added to the modules
folder. I know the assemblies and files exist in the right place. The screen shot below was proof that the modules were loading when the Function starts, so what is the problem?
To confirm that Connect-SPOnline
was actually available, I resorted to classic debugging - Write-Output
to the rescue. I adding the following to the script:
Line 7 is the key. The line initially read Get-Command -Module *-SP*
. Well this turned up no results. There really was no Connect-SPOnline
command! Worse, there were NO SP* commands! WTF!?! I have used the PnP PowerShell cmdlets in the past, and I know Connect-SPOnline
is one of them.
Well, turns out there was a change to the PnP PowerShell cmdlets only 14 days before. I searched the Github repo for Connect-SPOnline, and got nothing, so I started hunting for changes, and found that all of the cmdlets (nearly all of them) were change to *-PnP*
. Changing Line 7 to Get-Command -Module *-PnP*
now returns results.
Great! All the cmdlets are there! Now I can use the new Connect-PnPOnline
, Get-PnPProvisioningTemplate
, etc. and things are working now. To see the Github repo changes, view https://github.com/OfficeDev/PnP-PowerShell/commit/6b3136c77e83481ff54ab12b3252918445b3e067.
Thanks to John Liu for the start!
I'm working on another post about the changes I made to John's code in order to get a longer running site collection provisioning process to work. Stay tuned.
HTH - let me know if you have an opinion or suggestion on how we can make a change.