Navigate Up
Sign In

SharePoint 2010 to 2013 Upgrade with HNSC

Item is currently unrated. Press SHIFT+ENTER to rate this item.1 star selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+ESCAPE to leave rating submit mode.2 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.3 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.4 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.5 stars selected. Press SHIFT+ENTER to submit. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.

You may also be interested in: SharePoint evolution conference 2013

 

Editor's note: Contributor Chris Grist is a SharePoint Architect at Beach Energy. Follow him @gristdog

2013-03-20-20102013Upgrade-01.pngI will start by saying this is not a step by step guide to upgrading from 2010 to 2013. Hopefully there are enough of you who have been through enough upgrades previously to have this process bedded down. The process is very similar as it was for 2007 to 2010. Therefore rather than reiterating it, please find a blog post from MSDN on this topic: http://blogs.msdn.com/b/alimaz/archive/2012/07/17/upgrading-from-sharepoint-2010-to-sharepoint-2013-step-by-step.aspx

I currently have a SharePoint 2010 farm, there is one web application with 20 or so site collections. The site collections are all path based (/sites/sitename) with the exception of the root. The first goal I had for my 2013 upgrade was to split out the site collections to host name site collections still under a single web application. This obviously means I can upgrade sites one by one at my leisure and that, with the exception of the root site collection, the original farm can stay as is until every site collection has been migrated. There are also obvious benefits of being able to now easily move site collections around between farms, the cloud and SharePoint vNext.

The first issue I had was with authentication, this is likely to apply to most of you. Microsoft recommends if you are using classic in 2010 to create a classic mode authentication web application in 2013. If you do not do this, your users will not be migrated and permissions will not work.

The issue that I had with this is I was already running some brand new sites on 2013 in my web application that was claims and there was no way I was going to sit there and replace all permissions classic->claims by hand. Luckily for me the method to move from path based site collection to host name site collection is to perform a backup and restore. Therefore I used an alternate web application created in classic mode to achieve this.

Below are the steps I have used to successfully move my 2010 path based site collections to 2013 host name based.

Step 1: Create a class mode web application in SharePoint 2013

New-SPWebApplication -Name “UpgradeApp” -ApplicationPool “UpgradeAppPool” -AuthenticationMethod “NTLM” -ApplicationPoolAccount (Get-SPManagedAccount “DOMAIN\spfarmacc”) -Port 443 -URL “https://sp2013″ –securesocketslayer

I am using SSL here, you may run in to some issues if using port 80 without a host name.

This step creates a classic mode web application, it also creates a content database but this can be removed later.

Step 2: Mount the SP2010 Content Database

Mount-SPContentDatabase -Name SP_Cont_UM_Accounting -DatabaseServer spsql2013 -WebApplication https://sp2013 –assignnewdatabaseid

This is the command you should be used to if you have done an upgrade previously. It will go through and attempt to upgrade the database to 2010, one attached my site is available at /sites/accounting. If you are doing more than one site collection during this upgrade, then repeat the process until all your content databases are in 2013. Errors and warnings are usually related to custom features, so it's advised to fix up as many as these as possible prior to continuing.

Step 3: Convert web application to claims

Convert-SPWebApplication -Identity “https://sp2013″ -To Claims –RetainPermissions –Force

This is the critical command, if you move your site collection before running this command you are going to have permission issues. This command will convert the web application to claims and organise all the permissions for you.

Step 4: Backup Site Collection

Backup-SPSite -Identity “https://sp2013/sites/accounting” -Path “c:\Backup\accounting.bak” –Force

It’s also possible to run this command from the central admin UI backup section.

Step 5: Restore Site Collection

Restore-SPSite -Identity ‘https://accounting.beachenergy.com.au’ -Path ‘c:\Backup\accounting.bak’ -DatabaseName ‘Accounting_Content’ -Force -HostHeaderWebApplication ‘https://sharepoint.beachenergy.com.au’ -Confirm:$false

I was stuck here for a while, so if you find this article after trying to follow MSDN/Technet you will now see why. This is the command to restore my site collection to another web application, as a host named site collection. The example from Microsoft has the URLs around the wrong way. The first URL needs to be your HNSC with the second being the URL of the web application.

Now all that is left to do is to try and load your new site and proceed with the SharePoint 2013 UI upgrade (oh and clean up the UpgradeApp web application), for future sites you can just repeat the process.

Categories: SPF 2013; Deployment; 2010

Comments

Eric R.

clarification on upgrade strategy

Hi Chris, thanks for this article. We have seriously been considering this option as we look at moving to SP2013, and the timing of your post was great for us. We would be able to consolidate multiple webapps into a single webapp and retain the same url for each site collection. This a huge benefit for us. I was hoping you could elaborate a bit on your statement of "The first goal I had for my 2013 upgrade was to split out the site collections to host name site collections still under a single web application. This obviously means I can upgrade sites one by one at my leisure and that, with the exception of the root site collection, the original farm can stay as is until every site collection has been migrated." My question I need some clarification on is how do you route the traffic to the NEW upgraded site collection while still sending all other traffic for sites not yet upgraded to the old sharepoint 2010 farm? For example. I have a webapp on 2010 named teams.company.com with several site collections under the managed path of /sites: http://teams.company.com/sites/site1 http://teams.company.com/sites/site2 If I want to upgrade site1 to 2013, I can do that based on your upgrade strategy. I have a hardware load balancer that I can send all traffic going to teams.company.com/sites1 to the NEW 2013 farm instead of the old 2010 farm. BUT when a user loads the content from the 2013 farm, there are references to resources (such as WebResource.axd) that are at the URL of http://teams.company.com/webresource.axd and the load balancer would not know to route that request to the SP2013 servers but instead that would be served up from the 2010 farm. In essence that would break the pure 2013 page loads as references were made outside the fully qualified site collection name space (teams.company.com/sites/site1) Are you able to preserve the host name across both site1 and site2 site collections but still perform a upgrade for just site1 and not site2? If so how do you split the traffic between each farm when both site collections are still resolved to the name teams.company.com/..... Thanks for your time. Eric R.

Posted 26-Mar-2013 by Eric R.

Notify me of comments to this article

E-mail:
   

Add Comment

Title:

 
Comment:
Email:

   


Name:

 
Url: