This post was most recently updated on January 4th, 2023.
3 min read.While running “New-PnPSite” (or actually any other site creation method in PowerShell or programmatically), the site creation fails, and instead you get back an error like the one below:
New-PnPSite : {"d":{"Create":{"__metadata":{"type":"SP.Publishing.CommunicationSiteCreationResponse"}, "SiteStatus":3, "SiteUrl":""}}}Ouch! Where does this come from? In the code of New-PnPSite, the actual function call is shown below:
var results = ClientContext.CreateSiteAsync(creationInformation);
var returnedContext = results.GetAwaiter().GetResult();(Source)
So, the error is not thrown by a PnP cmdlet, but rather comes from SharePoint CSOM. This is pretty normal and not surprising but means we can’t debug it that much, as CSOM is not open source.
Alright – what can we do to fix this? There are a couple of things – but first, let’s take a look into the call itself and its SiteStatus value!
What does SiteStatus in that response mean?
Okay – your New-PnPSite didn’t seem to result in a new site being created, but rather you got an error and a status code that doesn’t tell you much. What now?
My understanding of the status codes is the following:
- 1
- We’re getting there! Please wait, you’ll get your site eventually.
- Throttling or high resource usage means you’ll get your site a bit later.
- Implement logic for backing off or sleeping, if you need the URL of the group or if you need to apply any modifications to it afterward.
- 2
- Site created, you’re good!
- Should also return the URL.
- 3
- Fatal error. All hope is lost.
- You’ll need to handle this in your code, by implementing a fallback logic or just handling the error.
Weirdly enough, the best source I have for these status messages is this conversation on GitHub: https://github.com/SharePoint/PnP-PowerShell/issues/1179
Reasons and resolutions
Multiple reasons can cause the issue. One of the most typical ones from my experience is that the URL was already in use.
Sounds simple, right? However, this doesn’t mean that there actually would be a site with that URL. The URL is still reserved also for removed sites that are in the recycle bin, and there’s no GUI for removing these sites from said bin.
Remove a removed site from the recycle bin to free up the URL
Luckily, we do have PowerShell commandlets to do this task for us!
Time needed: 15 minutes
How to list all deleted sites on your SharePoint Online tenant using PowerShell?
- Open SharePoint Online Management Shell
Open Terminal or PowerShell or SharePoint Online Management Shell or anything where you can then import the SharePoint Online module.
- Log in to your tenant
Logging in to your tenant happens with code somewhat like the below:
Connect-SPOService -Url "[tenant-admin.sharepoint.com]"
It should start an interactive login flow. - Enumerate the sites in your 2nd stage recycle bin
Now you can enumerate what’s in your Recycle Bin. Below is the PowerShell commandlet to see which sites are in the second stage recycle bin:
Get-SPODeletedSite - (OPTIONAL): Remove the deleted sites to free up their URLs
To get rid of one or more of them, you can call Remove-SPODeletedSite.
See this blog article on how to do that: https://www.koskila.net/remove-spodeletedsite-actually-remove-sharepoint-online-site/!
That’s all for that fix! But wait – what if you did NOT have a removed site with the reserved URL?
Well, there are a couple of other options…
Remember to enclose your variable values in quotation marks in your scripts
This one was pointed out by Kevin in the comments -section below – a useful reminder, even if I haven’t run into this error being returned.
But what other options are out there?
Could this be a Microsoft issue?
Okay – maybe it wasn’t your fault, after all! If the site wasn’t in the recycle bin and PnP libraries work as they should, it’s only this site creation that’s not working… Well, maybe it was Microsoft messing it up all along! This might especially be the case if the issue persists for site creation using different methods (GUI, CSOM, 3rd party tools) and different URLs.
There’s a bug ticket about this reported on PnP GitHub, but truthfully, I don’t think the issue is ever in the PnP code – it’s usually an underlying issue in the datacenter: https://github.com/SharePoint/PnP-PowerShell/issues/1542
The resolution could be to just contact Microsoft Support and get them to flip a switch. Sorry – no silver bullets here! 🤔
He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
