A couple of years ago I published a blog post, “Using Copy-SPSite to rename Site Collections in SharePoint 2013” to much fanfare and adulation. Okay, okay, adulation might be a bit strong (might) but it was a good find nonetheless. I thought I had reached the pinnacle of renaming Site Collections. I thought that my career was all downhill from here. I was going to be relegated to a has been. “Hey, remember that time back in ‘12 when I renamed a site collection without backing it up? “ I thought I was sunk.

Then the February 2015 CU came out.

Buried in all the bugs fixes and regressions was a cool new piece of functionality, the ability to rename site collections without backing them up or without copying them. Whatcho talkin’ ‘bout, Willis! In this blog post I’ll show you how to use it.

TL;DR

I know some of you have short attention spans, so I’ll throw out the PowerShell code to do this right away:

$site = Get-SPSite http://portal.contoso.com/sites/foo
$uri = New-Object System.Uri("http://foo.contoso.com")
$site.Rename($uri)

To get 100% success I have to force the Content Database to refresh its site map with this:

((Get-SPSite http://foo.contoso.com).contentdatabase).RefreshSitesInConfigurationDatabase()

and run an IISReset. The IISReset isn’t always necessary, but it’s good to plan for it. If you have a short attention span, you’re released now. Go chase something shiny. Look! A rabbit! If you want to see the rest of the story, keep reading.

The Whole Story

When I first learned about this new method for SPSites, it was billed as a way to change path based site collections to Host-Named Site Collections (HNSC). Path based site collections are the ones we’ve been using since the beginning of time. They have the form of http://servername/managedpath/sitename. In my Redirection blog post the $V variable in the picture halfway down the page is the path. It’s the unique part between site collections. A path based site collection has a URL that looks like this:

https://portal.contoso.com/sites/foo and https://portal.contoso.com/sites/bar

In both cases the host is the same, portal.contoso.com. The thing that makes them unique is the path; /sites/foo and /sites/bar. When using host named site collections it’s the hostname that’s unique. Examples are:

https://foo.contoso.com and https://bar.contoso.com

HNSCs are something that users have wanted since SharePoint came out. No one wants to type the full URL out, they all want to type something short. SharePoint 2013 has a soft limit of 20 Web Applications per farm, so that isn’t really an option. Previous versions of SharePoint offered functionality close to HNSCs, but it was never really usable. Thanks to Microsoft hosting SharePoint Online, and making heavy use of HNSCs, they’ve gotten much better in SharePoint 2013. I have no problem recommending them, in the right situations. The issue then becomes how to make the transition. Backing up your path based site collection, deleting it, then restoring into a HNSC works, sort of, but it becomes a real pain when working with large site collections. Also, deleting a site collection is scary business, and not for the faint of heart. Finally, it just seems unnecessary. All the juicy data is staying in the same place, why should we have to take it out just to put it right back in? Ain’t no one got time for that! February 2015 CU to the rescue.

Starting with build 15.0.4693.1001 we can change the URL of a path based site collection to that of a host named site collection. Here’s the whole process, with pictures:

First I created a site collection:

New-SPSite -Url http://portal.odfbdemo.com/sites/moveme -Template sts#0 -Name "Move me with PowerShell, Por Favor" -Description "Site moved with PowerShell" -OwnerEmail todd@contoso.com -OwnerAlias odfbdemo\todd

And threw it into a browser, just to make sure it worked.

Then I changed the URL in PowerShell:

$site = Get-SPSite http://portal.odfbdemo.com/sites/moveme
$uri = New-Object System.Uri("http://moved.odfbdemo.com")
$site.Rename($uri)

Then did a quick check to make sure it took:

It looks like it did. I’ll refresh my browser, just to make sure it’s really gone. It is.

Before my site collection can work at http://moved.odfbdemo.com that hostname must resolve in DNS. I could have created a single A record to handle that. Instead, since I knew I’d be doing a lot of HNSCs, I created Wildcard DNS Record. That will cover all hostnames at odfbdemo.com that don’t already have a record in DNS. After I made the DNS record I pinged it just to make sure it was working. If you try to ping the site up in your browser before you make the DNS change, you might have to restart your browser for it all to work. Browsers have been known to cache an IP address from time to time.

With DNS squared away, let’s go back to the browser and try to load it up.

Que up the sad trombone. Turns out this was easy enough to fix. We need to run the RefreshSitesInConfigurationDatabase method on the content database our newly renamed site collection.

((Get-SPSite http://moved.contoso.com).contentdatabase).RefreshSitesInConfigurationDatabase()

In a couple of cases during my testing I also had to throw in an IISRESET to really clear up the errors. After that, success was mine!

One of the February 2015 CU KB articles mentions the new renaming functionality, but only mentions it in the context of going from path based to HNSC. That alone is impressive enough, and I could have stopped there. But I didn’t. I also tested this going from path based site collection to path based site collection. I must have eaten my vegetables that day because it worked. I used this PowerShell command to create the source path based site collection:

New-SPSite -Url http://portal.odfbdemo.com/sites/oldpath -Template sts#0 -Name "Move me from one path to another" -Description "Please work, please work" -OwnerEmail todd@contoso.com -OwnerAlias odfbdemo\todd

I made sure it worked in Internet Explorer, then I ran the following PowerShell to rename it to http://portal.odfbdemo.com/sites/shinynewpath

$site = Get-SPSite http://portal.odfbdemo.com/sites/oldpath
$uri = New-Object System.Uri("http://portal.odfbdemo.com/sites/shinynewpath")
$site.Rename($uri)
((Get-SPSite http://portal.odfbdemo.com/sites/shinynewpath).contentdatabase).RefreshSitesInConfigurationDatabase()

It looked like this:

Then I fired it up in Internet Explorer at its fancy new URL:

I hate to brag, but it worked.

It merits further testing, but on the surface it looks like it’s possible to rename path based site collections to new paths, or HNSCs.

If you try this, let me know how it turns out.

tk

ShortURL: http://www.toddklindt.com/RenameSiteCollections