Migrating Sharepoint 2010 to 2013

First let me start off by saying that I am not a Sharepoint expert. I would consider myself far more adept at Windows server administration in regards to Active Directory, Hyper-V, and other areas within the Server 2012 world.

When it comes to Sharepoint, I’m putting this post together in hopes of revealing some of the issues that I’ve come across with in my migrating of a Sharepoint 2010 farm to Sharepoint 2013.

What is Sharepoint?

sharepoint2013

The best way that I can describe Sharepoint is that it’s a collaborative platform that is extremely robust, full of features and capabilities. Sharepoint can be a CMS, wiki, blog, file sharing tool, and more, along with built-in tools for searching, indexing, auditing, and….more. It’s highly customizable and is often used by developers to build tools and act a central repository for pulling information. Office, Exchange, Active Directory: all these other Microsoft services, and more, plug into Sharepoint.

Really, Sharepoint can be a bunch of things, and I might even be underestimating what it can do.

However, with all this capability comes a cost: Sharepoint can be a major pain in the ass. The devil is really in the details when it comes to designing and deploying a Sharepoint farm, and even more so when you’re trying to migrate Sharepoint.

Why me?

Originally I was tasked with fixing the search feature in a Sharepoint 2010 farm, but the farm had two issues: the front-end search feature was completely broken, and the back-end had its own major problems. I was just suppose to get it working, which is easier said than done when you don’t really know what you’re doing — especially with Sharepoint. I figured my Google-Fu skills would get the job done, and it worked for the front end problems, but the back-end just wouldn’t work no matter what I did. Wanting to cut my losses and not waste anymore time, I told them that the farm should just be migrated (which is what they wanted to do anyways, but were hoping search would start working).

mistake[1]
I had no idea what I was getting in to. I wouldn’t really call it a mistake, but I clearly had no idea of the immense amount of work needed to migrate a farm that had customizations (and still don’t, because I’m hardly done).

This is nothing like ad-preping an old domain controller, joining the new server to the domain and promoting it to a DC, then demoting the old box. Nope. It’s just not that simple.

Ok, enough of my whining. Let me get to the details of what I needed and what I encountered, because if you googled one of the issues I ran in to, you just want to get it going.

Priming the Pump

If you’re new to migrating Sharepoint (or Sharepoint), then I recommend immersing yourself in some content.

I would first recommend the book Professional Sharepoint Administration 2013 by Shane Young, Steve Caravajal, and Todd Klindt. I think for a tech book, the book is well written and is very readable, and it provides context and background information for aspects of Sharepoint like service applications, the hierarchy of farm to web apps, to site collections, etc. This is absolutely important if you’re trying to understand how the entire picture is put together.

Next, I would grab some video series and check out some videos. On my list:

  • Trainsignal Sharepoint 2013 Administration – Step by step walk-through on installing and configuring Sharepoint 2013
  • Upgrading to Sharepoint 2013 by Shane Young – This was a great video for understanding the migrating process, and Shane certainly gives lots of information about the process, but his upgrade was far from normal and it went way too smoothly compared to my experience and what I’ve read online. Still, the video is gold.

I think those videos and the book really help set the stage for administrating Sharepoint, in particular for migration. The other thing is to get your hands dirty and install a few times — or have something break and think that wiping and reinstalling is going to fix everything.

The basic idea with migrating Sharepoint 2010 to 2013 is that you’re doing a database detach (backup and restore of the content database[s]), and reattaching it to a fresh farm. It’s in attaching it that you can start to run into issues.

The Devils I Encountered

Missing Features

The first issue that really caused problems with my install was migrating farm features and solutions from the old 2010 farm to the new 2013 farm. I thought I could just migrate it without the features and just have orphaned features and clean that up later. Well, I had problems, and I’m not entirely sure if that was a result of the failed features or something else (I believe it was something else, but it’s a good idea to fix the features). To find out what features you’re missing, run this:

Here, you’ll see all the details of the features/solutions you’re missing. With my migration, I fixed all of them because (at the time) I thought I needed to.

To fix the missing features, I utilized some powershell from Shane Young over on his blog. He explains what each part of the code does, but I’m just going to post the gist of it.

First, on the 2010 farm, grab the features and put them into your working directory (from elevated prompt):

Then you have to move those features to the 2013 farm. Within an elevated powershell prompt and in the directory with the features, run this code that will install the features into the farm (but it won’t deploy the features, that’s next):

Finally, you have deploy the features. Run this to deploy the code (again, elevated prompt), and go grab some coffee or go to lunch (it’s going to take a bit of time):

If you’re lucky, it’ll without a hitch. If you’re like me, you’ll run into problems with particular features. For my farm, first I found the GUID of the feature that didn’t deploy:

Copy the GUID and paste it into this:

You’ll have to run that for each feature that failed. Now you may not want to run that for each web application, so then change “-AllWebApplicaitons” with “-WebApplication” followed by the web application GUID. Here’s the Install-SPSolution information on the cmdlet.

For features that are missing, start googling the GUIDs and feature names. At one point I had to search deep, and for one feature I had to go to archive.org, down the MSI, unpackage the MSI and manually install the files and update the web.config. I think this is abnormal, but the feature I was looking for was gone and the website it came from had long been decommissioned.

Site Collection Not in Site Map

This problem caused me the most of amount of headaches. I kept getting this error after running Mount-SPContentDatabase:

cN5xO[1]

“Database … contains a site [GUID] that is not found the site map. Consider detach and reattach the database.”

Ok. That’s weird, that’s not how it went in the videos! They just attached and went on their merry way deciding whether or not to upgrade the site collection. I kept having this issue after every database mount and upgrade; I checked that every mount point was correct, every alternative access mapping (AAM) was correct, and I even wiped and reloaded several times to get it working — all to no avail.

Then came I got some help from reddit. I was told to check the AAMs, but I did check the AAMs and everything looked correct.

That was the problem. After trying to remap the site with an alternative access mapping, it turns out I can’t map to a host-named site collection.

WTF is a host-name site collection? I didn’t know there was a difference. Turns out there’s a huge difference and it’s why my site collection has failed to be mounted, because there was a mapping that had a name of the site collection that I was trying to mount to my web application. In other words, I needed to have my host headers with a different name for my web application.

After renaming my host headers to something that didn’t conflict with the site collection, I wiped the database from SQL and removed it from Sharepoint 2013, then I mounted the DB again.

Success. Holy shit, it worked!

Holy+it+worked+_7b0fc2e3260659bcf7f8499f9d7b4c92[1]

Of course, I wasn’t completely done. According to this TechNet article on host-named site collections, I needed to add some bindings in IIS and then set the AAMs in powershell, to the best of my knowledge, is where the host-header sites are modified. To modify the AAM, I typed this:

Of course, you need to set it to the appropriate zone. You can also see your host-header AAMs by typing this:

And now I have a working site collection. I still to need to update it from classic authentication to claims, then test the site collection in 2013 mode, and then fix whatever else comes after that, but those two items above were the things that kept me hung-up the most.

Other Sharepoint Resources

Here’s some other Sharepoint resources that may be helpful:

  • Todd Klindt’s Blog – The man is a repository of endless Sharepoint information, a Jedi Master in Sharepoint. He has a listing of build/update numbers
  • Sharepoint Subreddit – These guys are just awesome. I’ve yet to be told to RTFM, but that doesn’t mean it won’t happen. These guys are genuinely helpful, and there’s even more helpful Sharepoint info the sidebar.
  • Script to Help Sharepoint Updates Go Faster – If you ever need to run Sharepoint updates, this script is the bomb. It essentially shuts down services that would cause the update to slow down, applies the patch, then restarts the services. If you have to run successive updates, I recommend restarting between updates.
  • Sharepoint StackExchange – I don’t really find this place helpful, but sometimes you never know! Questions get asked daily and most go unanswered. The Sharepoint subreddit is more helpful, IMHO.

Alright. I’m done. Happy Sharepoint migrating!