The case of Get-SPOSite


If you use both the PnP cmdlets and the Microsoft Office 365 Management cmdlets, you might have noticed that both have an Get-SPOSite cmdlet. And those conflict. There are a few ways around that problem, but they are cumbersome. To resolve this, basically the only way is either them (Microsoft) or us (PnP) rename the Get-SPOSite cmdlet. So we sat down with the PnP Core team, looked at a few scenarios, and we came up with what I describe a bit below in this post.

First a bit more about the problem: The O365 Management Shell Get-SPOSite cmdlet returns a list of all the sites in the tenant, whereas the PnP Get-SPOSite cmdlet returns a CSOM Site object. Very different functionality. So, we have 2 cmdlets, same name, very different functionality. Confusing. What you might not be aware of is that whatever module is loaded first (that usually happens when you execute either Connect-SPOService or Connect-SPOnline) will make the version of Get-SPOSite ‘win’. So if you execute Connect-SPOService before Connect-SPOnline then you will default to the Get-SPOSite cmdlet from the Office 365 Management Shell. And the other way around with PnP; execute Connect-SPOnline before Connect-SPOService and the Get-SPOSite cmdlet will come from that PnP Module. Not very intuitive.

Now, you can force PowerShell to use a specific version of the Get-SPOSite cmdlet in 2 ways:

You can load the module with a -Prefix attribute, alike

From that moment on you have to use all the PnP cmdlets with the My prefix, alike “Get-MySPOSite”, or you specify the full module name in front of the cmdlet. This means:

to use the PnP version and

to use the Microsoft version.

Although it works, it is also cumbersome. So we came up with a big change.

A big change

We decided to rename the cmdlets from <verb>-SPO<noun> to <verb>-PnP<noun>. So this means for instance that   Get-SPOList  will now be called   Get-PnPList  and   Get-SPOProvisioningTemplate  will be called   Get-PnPProvisioningTemplate . To make the process as smooth as possible, we do create aliases when you install the modules for all cmdlets so that the -SPO versions will still work. We plan to deprecate (remove) the aliases sometime next year and we will announce that ahead of time.

This means that starting from the November 2016 release, we urge you to change your scripts to use the cmdlets with the PnP prefix instead of the aliases with the SPO prefix.

The poor Get-SPOSite cmdlet

There is one special case: the   Get-SPOSite  cmdlet.  Starting with the November 2016 release, when you use the  Get-SPOSite  cmdlet from our module you will see a warning, urging you to start using   Get-PnPSite. Both will still work, but the   Get-SPOSite  cmdlet will be deprecated (removed) in the January 2017 release.


For your reference, a list of the renamed cmdlets (all 177 of them)