Quickly Remove ALL Webs under a Site Collection Using PowerShell

I was cleaning up my demo site collection, and I needed to remove all subwebs… Here’s a quick one-liner of PowerShell to do exactly that.

Get-SPSite <SiteUrl> | Get-SPWeb -Limit All | ForEach-Object {Remove-SPWeb -Identity $_ -Confirm:$false}

Remove SharePoint List Views Using PowerShell

Ever have a need to delete list views using PowerShell?  Of course you do, it’s a great reason to use PowerShell!

Luckily for us, there is great access to the Object Model and we can readily access lists, items, and of course views.

I threw together a nifty little function that accepts three parameters, WebUrl, ListName and ViewName and will remove a single view from a SharePoint list.

The code is quite simple, basically we grab an SPWeb object using the WebUrl parameter – we then grab an SPList using the ListName parameter, and finally we grab an SPListView using the ViewName parameter.  Once we’ve drilled down to the specific SPListView, we can call the Delete() method using the ID of the view.

Here’s my function, enjoy!

function Remove-SPListView {
Start-SPAssignment -Global
$SPWeb = Get-SPWeb $WebUrl
$List = $SPWeb.Lists[$ListName]
$View = $List.Views[$ViewName]
Stop-SPAssignment -Global

Use Find/Replace in PowerShell to fix InfoPath Forms after moving to a new Site Collection

I know I know, that’s a really long title.

I found some pretty good PowerShell how-to’s which described how to use Get-ChildItem to iterate through a folder – checking each item for a string and then using -replace to fix the string.

However, my situation was slightly different as I wanted to walk through a SharePoint 2010 Form Library – fixing InfoPath forms which had been moved into a new site collection and thus did not open in the browser and would not save due to the old reference to the XSN.

I’m sure there may be better methods on moving XSNs and XMLs across site collections where maybe this wouldn’t be necessary, but if you’re reading this I’ll assume you don’t care.

In any case, what I ended up doing (after obviously re-publishing the XSN template to the new site collection so new IP forms wouold work) is:

  1. Copy all of the forms using Windows Explorer (we didn’t care about versions or modified by metadata, just the content type metadata) into the new Form Lib.
  2. Run the following PowerShell code to fix each XML file – replacing the link to the old XSN with a link to the new XSN (Note: I ran this on my desktop, NOT on the server as I didn’t need any SP cmdlets):
$files = Get-ChildItem \\sitecollection\davwwwroot\FormLib -Filter "*.xml"
foreach ($file in $files) {
(Get-Content $file.fullname) | ForEach-Object {$_ -replace "http://sitecollection/library/OLDXSNPATH.xsn", "http://newsitecollection/library/NEWXSNPATH.xsn"} | Set-Content $file.fullname

Voila, all IP forms are now fixed and will not only open in the browser as expected – but I can now update these forms in the new location as they now point to the correct XSN template.

If you’re a frequent reader you’re probably thinking “Wow, normally he gives us these nice functions with parameters, help, etc.”… You’re right, this time it was a quick and dirty chunk of code. However, chances are I’ll need to do this again – so I did actually write a function for future needs:

function Reset-InfoPathTemplateLink {
$files = Get-ChildItem $FilePath -Filter $FileExtension
	foreach ($file in $files) {
		(Get-Content $file.fullname) |
		ForEach-Object {$_ -replace $OldPath,$NewPath} |
		Set-Content $file.fullname
	} #end foreach
} #end function

To run the function, first dot-source it and then use the following syntax:

Reset-InfoPathTemplateLink -FilePath "\\sitecollection\subsite\formlib" -FileExtension "*.xml" -OldPath "http://sitecollection/doclib/template.xsn" -NewPath "http://newsitecollection/newdoclib/newtemplate.xsn"

As always, happy PowerShelling!