Completely Delete SharePoint Online Sites using PowerShell


This will be a quick and dirty post. If you’ve administered SharePoint Online at all, you know that when you delete a Site Collection it goes into a Site Collection Recycle Bin. There are times when you may want to completely remove the SPOSite immediately, including removing it from the Recycle Bin. There are two commands to accomplish this:

  1. Remove-SPOSite
  2. Remove-SPODeletedSite

That’s great, and to delete the sites you just need to run them in that order. However, I’m sort of lazy at times and want to run something ONCE and have it do the work for me. Aren’t all scripters like this?

To make this functionality possible using one call, I wrote a function which I’ll share below.

Essentially it just takes one parameter for URL, and it uses SupportsShouldProcess and ConfirmImpact to prompt you for confirmation. Assuming you oblige, it will run the Remove-SPOSite first, with Confirmation suppressed (-Confirm:$false) and with no wait. After that completes, it will use Start-Sleep and a do/while loop to wait until the SPODeletedSite status is ‘Recycled’. Once that returns true, it will run Remove-SPODeletedSite to get rid of the recycle bin item.

Here’s the Delete-SPOSite function:

Function Delete-SPOSite {
[CmdletBinding(SupportsShouldProcess=$true,ConfirmImpact="High")]
Param(
[Parameter(Mandatory)][System.String]$Url
)
    If($PSCmdlet.ShouldProcess($Url))
    {
        Remove-SPOSite -Identity $Url -Confirm:$false -NoWait
        Write-Verbose "Waiting for site to be added to Recycle Bin"
        do {Start-Sleep -Seconds 3}
        while((Get-SPODeletedSite -Identity $Url).Status -ne 'Recycled')
        Remove-SPODeletedSite -Identity $Url -Confirm:$false
    }
}

Return SPListItems using CSOM and PowerShell without writing CAML


I recently tweeted about my triumph when trying to accomplish returning all SharePoint List Items without the use of CAML or LINQ. The reason I wanted to do this might be strange, but I’ll try to explain my process and methodology and why I got to a point of wanting to make SharePoint do things it didn’t want to do. :)

As a very advanced SharePoint Scripter, I do a TON of PowerShell. If you’ve read this blog, follow me on Twitter or talk to me in person you probably knew that. Having said that, there are times when I want to iterate through all list items – either looking for a match or just to return all values. It’s not super common but it happens. Well it’s a very easy thing to do with server side code (read: PowerShell and the Microsoft.SharePoint.PowerShell snap-in).

Getting List Items using standard PowerShell

$web = Get-SPWeb http://someSiteUrl
$list = $web.Lists["SomeList"]
$list.Items #do something with them here

As you see on line 3, there is an Items collection property on the List object. This is great, end of story – IF you’re using server-side PowerShell code. However, I’ve been focusing a lot lately on integrating PowerShell into the CSOM space – specifically to manage SharePoint Online with PowerShell. If you’ve written any CSOM code, you know that things are done a little differently. Here’s an example of how to return a list item using PowerShell on the client-side – note that I’ve omitted about 12 lines of code that must take place before this to load the Microsoft.SharePoint.Client* assemblies, create ClientContext, get the SPWeb, etc.:

Getting a List Item using PowerShell Client-Side Code

$list = $GLOBAL:Web.Lists.GetByTitle("BigListLotsOfItems")
$item = $list.GetItemById(5)
$GLOBAL:Context.Load($item)
$GLOBAL:Context.ExecuteQuery()
$item["Title"]

That’s great, but if I wanted to return all items – the Client Object Model won’t give me List.Items. In reading MSDN, there are C# examples of how to write CAML queries to return all list items – but the whole point is that I don’t want to write CAML. Here’s the C# example – which I could have certainly translated to PowerShell if I wanted to do so:

Using C# to get all List Items

// Starting with ClientContext, the constructor requires a URL to the
// server running SharePoint.
ClientContext context = new ClientContext("http://SiteUrl");

// Assume the web has a list named "Announcements".
List announcementsList = context.Web.Lists.GetByTitle("Announcements");

// This creates a CamlQuery that has a RowLimit of 100, and also specifies Scope="RecursiveAll"
// so that it grabs all list items, regardless of the folder they are in.
CamlQuery query = CamlQuery.CreateAllItemsQuery(100);
ListItemCollection items = announcementsList.GetItems(query);

// Retrieve all items in the ListItemCollection from List.GetItems(Query).
context.Load(items);
context.ExecuteQuery();
foreach (ListItem listItem in items)
{
    // We have all the list item data. For example, Title.
    label1.Text = label1.Text + ", " + listItem["Title"];
}

So that’s great, but here’s how I went about getting all list items without writing CAML! I’ll break it down section by section, but if you’re impatient the whole solution is at the bottom. :)

Creating our Context

The first thing we need to do when working with SharePoint from the Client Side is create ClientContext. To do so using PowerShell, here is some example code:

$GLOBAL:Context = New-Object Microsoft.SharePoint.Client.ClientContext("http://someWebUrl")
$GLOBAL:Credentials = Get-Credential -UserName $EmailAddress -Message "Please enter your Office 365 Password"
$Context.Credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($Credentials.UserName,$Credentials.Password)
$GLOBAL:Web = $GLOBAL:Context.Web
$GLOBAL:Context.Load($GLOBAL:Web)
$GLOBAL:Context.ExecuteQuery()

Getting our SPWeb

Once we’ve created our ClientContext variable, we’ve already got the SPWeb. But just for transparency, here’s how you would/could access methods and properties of the SPWeb object:

$GLOBAL:Web.Title #returns Web.Title
$GLOBAL:Web.Description #returns Web.Description

Getting our SPList

Now, to get the List object – we’ll do the following:

$SPList = $GLOBAL:Web.Lists.GetByTitle("BigListLotsOfItems") #Note that BigListLotsOfItems is my List Title

Using the For loop to iterate through all items

And this is where the magic happens as they say. For anyone who has done any level of development or scripting, you know that the best way to loop while also allowing for modification of the array with which you’re looping is to use a For loop.

For ($i=0; $i -le $SPList.ItemCount; $i++)
{
}

This is a pretty standard implementation of the For loop, what I want to call out though is the use of Try/Catch/Finally. As a dabbling developer, I’m not sure if this is the intended use of Try/Catch/Finally – so if this is bad practice forgive me. :)

Essentially I start out by creating the ListItem variable, and then calling the Load method of the ClientContext variable. I do that before entering the Try/Catch/Finally. I then use Try {} to run the Context.ExecuteQuery method, and if that fails the loop will go into the Catch {} block – where I will increment the array by 1 ($i++) and then run the GetItemById(), Load() and ExecuteQuery() methods against the next $i in the loop.

$ListItem = $SPList.GetItemById($i)
$GLOBAL:Context.Load($ListItem)
    Try
    {
        $GLOBAL:Context.ExecuteQuery()
    }
    Catch
    {
        $i++
        $ListItem = $SPList.GetItemById($i)
        $GLOBAL:Context.Load($ListItem)
        $GLOBAL:Context.ExecuteQuery()
    }

Why did I do this? Well it’s really pretty simple. Since I have to use the GetItemById() method, I have to know the ListItemID of each ListItem. If someone has deleted an item, the ItemCount property won’t match the highest ID in the list – right? So if there are 5 items but someone deleted a few at one point or another – the highest ID might be 7 or 8, without incrementing by 1 on a failure, we’ll never get to 7 or 8…

And so now that we’ve discussed all of that, here’s the final example script.

The Final Solution

$GLOBAL:Context = New-Object Microsoft.SharePoint.Client.ClientContext("http://someWebUrl")
$GLOBAL:Credentials = Get-Credential -UserName $EmailAddress -Message "Please enter your Office 365 Password"
$Context.Credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($Credentials.UserName,$Credentials.Password)
$GLOBAL:Web = $GLOBAL:Context.Web
$GLOBAL:Context.Load($GLOBAL:Web)
$GLOBAL:Context.ExecuteQuery()
$SPList = $GLOBAL:Web.Lists.GetByTitle("BigListLotsOfItems")
For ($i=0; $i -le $SPList.ItemCount; $i++)
{
    $ListItem = $SPList.GetItemById($i)
    $GLOBAL:Context.Load($ListItem)
    Try
    {
        $GLOBAL:Context.ExecuteQuery()
    }
    Catch
    {
        $i++
        $ListItem = $SPList.GetItemById($i)
        $GLOBAL:Context.Load($ListItem)
        $GLOBAL:Context.ExecuteQuery()
    }
    Finally
    {
        #Return item here and do something with it.
    }
}

And that – my friends – is how you can get all List Items from a SharePoint list using PowerShell and CSOM. Hopefully this is helpful for someone else.

The future of InfoPath & SharePoint


Over the past several years I’ve grown very comfortable with InfoPath and SharePoint. In the 2007 days it was a great tool to provide advanced forms capabilities to the end user, with very little development knowledge or experience needed. Things like data connections to query and expose external data, conditional field formatting, user interface adjustments and conditional views were all configurable by anyone who was comfortable with Microsoft Office. I grew very accustomed to helping customers provide an elegant and intuitive interface for data entry. It was also common to tie the forms to a back-end workflow, which could take a business process from paper and sneakers to 1′s and 0′s, fully automated. It was beautiful. And it worked.

SharePoint 2010 took InfoPath even further, allowing us to quickly and *very* easily edit the default forms for a SharePoint list using InfoPath. Now we could do things like provide branding, conditional formatting and data connections in a standard list item form. Sure, it wasn’t the easiest thing to extend beyond the OOTB capabilities of InfoPath, and don’t get me started on the complete omission of Managed Metadata support; but it was a great starting point for custom forms. THAT was the pinnacle for InfoPath. That’s the best it would ever be and for some reason, that’s the last time the InfoPath team would get to develop any *new* features for InfoPath and SharePoint.

When SharePoint 2013 and Office 2013 were released, there were a lot of head scratchers – wondering “what’s next with InfoPath?” I was one of them, and I was increasingly concerned that the end of life was coming. Well, it’s here. InfoPath is officially going bye bye. Now we’re left wondering what’s next, and I suppose if you’re lucky enough to attend #SPConf14 you may just find out. Until that’s released however, we’re all left wondering.

I’m open to change, and I’m definitely hoping Microsoft knocks this decision out of the park. However, I am extremely doubtful there will be anything that comes to close to the ease of which InfoPath could be used to extend SharePoint’s data entry forms. Sure, there are those who are great at writing custom code and building HTML/JS forms – I’m not one of them. Most people who USED InfoPath aren’t either. InfoPath shined in its ability to give the power user some freedom and power – I just don’t see anything new on the horizon that will be as easy to use. Maybe I’m wrong, I hope I’m wrong – but until I see it I won’t believe it.

The ultimate question I have at this point is: does Microsoft even make an attempt at a replacement? Or do they leave the power-user-forms-building to 3rd party ISVs such as Nintex, Dell, etc.? That remains to be seen, but I for one am excited to hear what’s next for InfoPath & SharePoint. I guess we’ll have to wait and see.

Ryan Dennis is a SharePoint Solutions Architect with a passion for SharePoint and PowerShell

Follow

Get every new post delivered to your Inbox.

Join 938 other followers

%d bloggers like this: