Change Site Collection Managed Path after move from different version of SharePoint

​In order to change a Managed Path for a site collection we need to backup and restore that site collection to the new Managed Path.

I attempted to backup and restore a site collection today, with the goal of changing the managed path from:


After mounting the 2010 version Content DB in from the 2010 Production farm, into the 2013 farm, and attempting to run the PowerShell to backup and then restore the site collection, I ran into an error:
Restore-SPSite : <nativehr>0x80070003</nativehr><nativestack></nativestack>.

Once I ran the Visual Site Collection upgrade and brought the site collection up to 2013, I could run my script to backup/restore and get the managed path changed.

I found this which explained some things for me:

While the below comment from that thread doesn’t address the exact scenario, it may also be helpful for us to know:

I am wondering if anyone noticed but on SharePoint 2013 we have lost a lot of the flexibility in the restore process?

On SharePoint 2010 you could and still can restore from one SP20120 server to a another SP2010 server with a different cumulative update/version, once the destination server (where you trying to restore to) does not have a cumulative update that is pre that of which is installed on the source server. In summary site collection backups would restore to SharePoint servers which has equal or above cumulative updates.

Example of this…

You could.. 1. Backup a site collection from Server A with December 2010 CU and then restore to Server B running July 2011 CU.

2. Backup a site collection from Server A with SharePoint Foundation December 2010 CU and then restore to Server B running SharePoint Server December 2010 CU. (Foundation –> Server)

3. Backup a site collection from Server A with December 2010 CU and then restore to Server B running December 2010 CU. (Identical servers)

You could not… Backup a site collection from Server A with July 2011 CU and then restore to Server B running December 2010 CU.

Example 1 & 2 above are no longer available on SharePoint 2013

Moral of the story seems to be that you better make sure your major version and CU levels are on par before you attempt changing the managed path like this. By running the Visual Site Collection upgrade everything got brought into SP 2013 mode and the process could complete.

The PowerShell used was:

#Get the from Site Collection URL
$fromURL = ""
#Get the to Site Collection URL
$toURL = "
#Get DB Reference
$Database = Get-SPContentdatabase "org_SiteAContentDB1"
#Location to the backup file directory to store Site Collection backup files
$backupPath = "d:topSharePointBackupsorg_SiteAContentDB1.bak"
#Backing up Site Collection prior to moving
Write-Host "Backing Up Site Collection…."
Backup-SPSite $fromURL -Path $backupPath -force
#Removing Site Collection from old managed path
Write-Host "Removing Site Collection from old managed path location…"
Remove-SPSite -Identity $fromURL -Confirm:$false
#Restoring Site Collection to new Managed Path
Write-Host "Restoring Site Collection to new managed path location…"
Restore-SPSite -Identity $toURL -Path $backupPath -Confirm:$false
#Remove backup files from the backup directory
Remove-Item $backupPath

PowerShell Intellisense-like Syntax Highlighting for Visual Studio 2012

Following up to my previous post which details the requirements to get PowerShell intellisense in Visual Studio 2010, here is the recipe for getting the same goodies in Visual Studio 2012:

PowerShell is an essential tool for advanced SharePoint development & administration. Unfortunately Visual Studio doesn’t offer PowerShell code syntax highlighting or Intellisense natively. You can however use Adam Driscoll’s plugin PowerGUI VSX from Codeplex, which runs on top of PowerGUI.

Note: Development seems to have stopped for a while on that project, not sure if it’s just super stable for 2012 and no updates have been required or what, but in any case, go to the Codeplex page and show some love to encourage further development.

PowerGUI V requires the free, standalone application PowerGUI. Please download the correct version:

Some useful sources for SharePoint PowerShell scripts and advice:

Windows PowerShell™ command-line interface is a new command-line tool and supporting scripting language from Microsoft that complements Cmd.exe in the Windows administration context. In the SharePoint administration context, Windows PowerShell supersedes the Stsadm.exe administration tool. Moving forward, you should use Windows PowerShell scripting technology to develop any new command-line scripts in SharePoint.

SQL Server PowerShell & SharePoint – Set Autogrowth on Content DB’s

​The SQL Server provider for Windows PowerShell exposes the hierarchy of SQL Server objects in paths similar to file system paths. You can use the paths to locate an object, and then use methods from the SQL Server Management Object (SMO) models to perform actions on the objects.

For the TechNet reference, check here:

For a video walkthrough and great summary of it, check here:

In this scenario, we’re going to use it for a repetitious task in most  SharePoint installations, which is, to assign more sensible Autogrowth settings to your Content DB’s.

For the full rundown on why we need to modify SQL Server settings (and can’t just do it from SharePoint directly), check around the 20 minute mark on this video:

1. Open up a PowerShell instance on your SQL Server.

2. Since our task is to set the FileGrowth properties of all the content DB’s, let’s first check out the FileGrowthType Enumeration:
Your options are:

​Member ​Description
​KB ​File growth occurs in the specified number of KB.
​Percent ​File growth occurs as an amount that is a specified percentage of the existing file size
​None ​The file will not grow automatically.

The FileGrowthType enumeration class is served by the (datafile) GrowthType property and the (logfile) GrowthType property.

Modify your server instance names and autogrowth preferences in the following script, and execute! The filter displayed on it filters to apply only to databases and logfiles with “Content” in the name – the typical naming scheme to indicate SharePoint content databases. Modify to taste:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SMO") | out-null
$SMOserver = New-Object ('Microsoft.SqlServer.Management.Smo.Server') -argumentlist $Server
$databases = $SMOserver.Databases;
foreach ($DB in $databases | where{$_.Name -like '*Content*'}) {
    #Set Log File growth
 foreach ($DBLF in $DB.logfiles) {
  $DBLF.set_Growth("51200"); #50mb 
 #set File Growth 
 $DBFG = $DB.FileGroups;
    foreach ($DBF in $DBFG.Files) {
  $DBF.set_Growth("102400"); #100mb