New eBook for Splitting an Oversized Sub Site into a New Site Collection & Database

Most companies strive to implement solid governance plans and design their site structure accordingly, but reality often gets in the way. What was supposed to be a small site can have a sub site which grows unexpectedly. Next thing you know, your sub site alone has grown to over 100 GB. What do you do? If you don’t care that the URL of the sub site changes, then you can simply copy it to a new site collection with a new content database. This usually isn’t an option when people have links in documents and SharePoint sites that point to the original location. Moving it and trying to put forwarders or links to the new location is simply too painful. This detailed eBook will show you how to split that troublesome sub site off into a new site collection with its own content database using powershell and central administration while maintaining your URL structure. You'll get all the required steps with screen shots for the low price of $9.99 USD. If you're not satisfied, we'll gladly refund your money!

Windows PowerShell Command Builder for SharePoint 2010 Products and Office 365

If you're like us, you're starting to figure out that you can do much more with SharePoint through PowerShell than you can through Central Admin. Microsoft recognize that not everyone is comfortable with PowerShell so they've created an excellent tool to help rookies create scripts they can use for everyday administration tasks.


Windows PowerShell Command Builder for SharePoint 2010 Products and Office 365 is a Silverlight® 4 application that is designed to help IT professionals and power users learn how to use Windows PowerShell for administrative tasks. The Windows PowerShell Command Builder enables IT professionals and power users to visually assemble commands related to SharePoint 2010 Products and Office 365 in the browser and take those commands to their respective products.


You can access the tool here: http://www.microsoft.com/resources/TechNet/en-us/Office/media/WindowsPowerShell/WindowsPowerShellCommandBuilder.html


And the getting started guide is here: http://www.microsoft.com/download/en/details.aspx?id=27588


Here's a screen shot to give you an idea of how the drag and drop interface looks:

If you're interested in learning more about administering SharePoint with PowerShell, have a look at the following:


http://dmitrysotnikov.wordpress.com/2010/04/14/sharepoint-2010-powershell-cheat-sheet/
http://technet.microsoft.com/en-us/sharepoint/ee518673
http://technet.microsoft.com/en-us/library/ee806878.aspx


Happy scripting!

How to Delete a SharePoint Site and All of It's Sub Sites

We were recently doing some maintenance cleaning up old sites when we noticed an annoying feature. When you try to delete a site that has numerous sub sites, SharePoint will continually kick out errors telling you it can't delete the current site because it has sub sites. This forces you to manually go through and delete the lower level sites, then work your way up.

I understand this is a "safety" feature to help make sure you don't delete any sub sites you didn't mean to, but I really want to get rid of this legacy site that's taking up a big chunk of SQL disk.

The solution? Run the following powershell command. Be sure you have a good backup in case you change your mind and substitute the site name (http://site/subsite) with the name of the sub site you want to nuke.

function RemoveSPWebRecursively(
  [Microsoft.SharePoint.SPWeb] $web)
{
Write-Debug "Removing site ($($web.Url))..."


$subwebs = $web.GetSubwebsForCurrentUser()


foreach($subweb in $subwebs)
{
RemoveSPWebRecursively($subweb)
$subweb.Dispose()
}

$DebugPreference = "SilentlyContinue"
Remove-SPWeb $web -Confirm:$false
$DebugPreference = "Continue"
}


$DebugPreference = "SilentlyContinue"
$web = Get-SPWeb "http://site/subsite"
$DebugPreference = "Continue"

If ($web -ne $null)
{
RemoveSPWebRecursively $web
$web.Dispose()
}

List All SharePoint 2010 Databases

If you're like me you've setup numerous SharePoint 2010 test boxes in order to get comfortable with all the great new features. Because I'm running in a test environment I hadn't been paying too much attention to the SQL server I was using. Yesterday I logged in and found a staggering number of similarly named databases which were no longer being used because the test boxes were done.

So how do you figure out which databases are which? There's a great SharePoint Powershell cmdlet you can run on your SharePoint server that will give you a list of all the databases your server is using:

Get-SPDatabase | Sort-Object disksizerequired -desc | Format-Table Name

When you run the command, you'll get a list of all the databases similar to the following:

Now that you have your list, log into SQL Server Management Studio and delete the corresponding databases:

Get-SPDatabase | Sort-Object disksizerequired -desc | Format-Table Name | out-file c:\databases.txt

You can also see how big the databases are by running the following:

Get-SPDatabase | Sort-Object disksizerequired -desc Format-Table Name, @{Label ="Size in MB"; Expression = {$_.disksizerequired/1024/1024}}

Automate SharePoint 2010 Farm Backups with Powershell

***Update (01/07/2013): We recently noticed that installing KB2506143 (Windows Management Framework 3.0) breaks the ability for SharePoint Powershell to run the backup. Uninstall it and the script should start working again.***

We've had a lot of requests for more details on how to setup automated SharePoint backups with PowerShell, so we've gone ahead and created a detailed ebook which outlines the steps and permissions you need to get your backups up and running. In addition to screen shots, there are also copies of the scripts we use as well as an email notification section that will let you know if your backups failed. Simply click on the Buy Now button below and you can pay with your Paypal account or credit card. At only $9.99 USD, it's thousands cheaper than a 3rd party solution and will let you sleep a little sounder at night. If you're not satisfied, we'll gladly refund your money! For the basic steps minus some of the more advanced funtionality, see below.

I recently built several server farms for our developers to work on. In order to make sure I could restore the farms to their original condition, I setup the following automated backup process. Below is a brief outline of the steps.

1. Create a folder on a local drive of the SharePoint 2010 server called backups (E:\backups). Share that folder as "backups" and give the account you used to install SharePoint as well as the farm and SQL database accounts full access (share permissions and NTFS).

2. Create a folder in E:\backups called Scripts. Inside there you create 4 files:

• backupsharepointfarm.ps1 – This script will backup your entire farm to the share you created. This script will contain the following:

Add-PsSnapin Microsoft.SharePoint.Powershell
Backup-SPFarm -Directory \\ServerName\Backups -BackupMethod full

• cleanbackups.ps1 – This script will check the spbrtoc.xml file and delete backups older than 7 days so you don’t run out of disk space. You can change $days value. This script will contain the following:

# Location of spbrtoc.xml
$spbrtoc = "E:\Backups\spbrtoc.xml"

# Days of backup that will be remaining after backup cleanup.
$days = 7

# Import the Sharepoint backup report xml file
[xml]$sp = gc $spbrtoc

# Find the old backups in spbrtoc.xml
$old = $sp.SPBackupRestoreHistory.SPHistoryObject |
? { $_.SPStartTime -lt ((get-date).adddays(-$days)) }
if ($old -eq $Null) { write-host "No reports of backups older than $days days found in spbrtoc.xml.`nspbrtoc.xml isn't changed and no files are removed.`n" ; break}

# Delete the old backups from the Sharepoint backup report xml file
$old | % { $sp.SPBackupRestoreHistory.RemoveChild($_) }

# Delete the physical folders in which the old backups were located
$old | % { Remove-Item $_.SPBackupDirectory -Recurse }

# Save the new Sharepoint backup report xml file
$sp.Save($spbrtoc)
Write-host "Backup(s) entries older than $days days are removed from spbrtoc.xml and harddisc."

• Backup.bat – This is a simple batch file to run the above backupsharepointfarm.ps1 script. Create a scheduled task to run it every night. The file contains the following:

powershell -command E:\Backups\Script\BackupSharePointFarm.ps1

• Clean.bat – This batch file will run the script to clean out older backup files (cleanbackup.ps1). The file contains the following:

powershell -command E:\Backups\Script\cleanbackups.ps1

3. Create a scheduled task that will run both of the .bat files you created and set them to run at night when no one’s around. You have to make sure the scheduled tasks are set to run with the SharePoint farm account. After a full week you’ll have a directory with 7 days worth of backups similar to the following:

Note: In order to run PowerShell commands on your server, you need to open powershell and execute the following command: Set-ExecutionPolicy Unrestricted

There are several factors involved in running a successful scripted backup which are covered by Todd Klindt in the following Microsoft SharePoint forum thread: http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/f755e7c1-bd0a-4c00-9be6-bbca83cf666b/.

1.Your Central Admin app pool account must have read/write access to the location of the backups.

2.Your SQL Service account must have read/write access to the location of the backups.

3.If you're running a farm backup from STSADM or Windows PowerShell, the account you're running it as must have read/write access to the location of the backups

4.The location must be accessible from the SharePoint machine the backup is running on.

5.The location must be accessible from the SQL instance that SharePoint is trying to back up.

6.This is why all the examples are UNCs, \\server\share, and not local paths, C:\backups

That’s about it. Give it a try and let me know if you have any problems. The file and share permissions are critical!