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?


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).

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:

Test-SPContentDatabase -name <Database Name> -webapplication http://<yourfarm>

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):

(Get-SPFarm).Solutions | ForEach-Object{$var = (Get-Location).Path + “\” + $_.Name; $_.SolutionFile.SaveAs($var)}

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):

Get-ChildItem | ForEach-Object{Add-SPSolution -LiteralPath $_.Fullname}

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):

Get-SPSolution | ForEach-Object {If ($_.ContainsWebApplicationResource -eq $False) {Install-SPSolution -Identity $_ -GACDeployment} else {Install-SPSolution -Identity $_ -AllWebApplications -GACDeployment}}

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:

Install-SPSolution -Identity <Long GUID here> -AllWebApplicaitons -GACDeployment -Force

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:


“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!


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:

Set-SPSiteUrl (Get-SPSite 'http://<thisdamnsite>') -Url 'http://www.itfreakingworks.net' -Zone Internet

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

Get-SPSiteUrl (Get-SPSite 'http://teams.contoso.com')

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!

Skill Atrophy

One of the greatest threats to a young IT professional is skill atrophy. You work hard at developing a skill set over a given period of time, and you even go so far as to earn a certification in such a skill set — and then you quit using it.

The old appropriate is appropriate here: “Use it or lose it.”

Recently while working at a site, and much to my frustration, my skills in router and switch configuration — even just layer 2 and 3 protocols — had started to atrophy because I hadn’t touch a device in five months — then bam! I’m setting up not just layer 5-7 devices, but I’m also setting up layer 2 and 3. I’ve been working so long in the higher layers that I started to forget basics in layer 2 and 3.


Layer 3 Switch


The hard part is that it was something rather ridiculous. It was a layer 3 switch, and turned the gateway port into a routed port instead of a switched port, thinking that I would separate out a server farm from the layer 2 network that it was attached to through that port. Nothing was getting DHCP requests on this switch and it was frustrating me to no end, not to mention I had to local techs looking over my shoulder and just standing there wondering what was going on! In the end, it was by getting help from my boss and co-worker that lead me down the road to figure out what I had been doing wrong.

So how does one prevent skill atrophy? The obvious answer is to practice, but that may not always be an option, especially if you’re in an environment where the work constantly changes and you’re insanely busy (that’s my excuse at least). Perhaps doing Packet Tracer simulations — for CCNA folks like myself — would be really helpful here.

Another idea is just good documentation, even trying to take a snapshot in time to see what you were doing. Copy your configs and annotate the configs to explain what the heck you were thinking — even encouraging this at your company so that other techs, or future techs, can get an idea of what’s going on.

Asking for help is always an option, especially if you’re really stumped. Time wasted can never be taken back (it’s a sunk cost), so realizing you’re failing bad early on can help mitigate future problems. To quote Freakonomics writer Steve Levitt, “Fail quickly.” However, at the same time, realize your failure is also a learning and/or reinforcement opportunity and will make you a better IT professional.

And of course, there’s also a good IT professionals google-fu, but you should be relying on that constantly, otherwise, are you learning any of this stuff?

All this being said, I’ve learned my lesson and I’m better because of it.

What I Learned This Week

Here’s my first installment of “What I learned This Week”. It’s just a collection of topics that I’m hoping to solidify into solid memories versus fluid, potentially lost ones.

  • Sysprep doesn’t work on upgrades. Sysprep is a tool used for imaging, and according to the error log generated after I attempted a sysprep on a Windows 8.1 machines that was upgraded from Windows 8, you cannot sysprep machines that were upgraded.
  • In Ubuntu 12.04, the DHCP server isn’t named DHCP3 but isc-dhcp-server. The settings also different; dhcpd server settings are located in /etc/dhcp/dhcpd.conf. More info here.
  • The MCSA is a pain in the a–, especially the 70-412. That was the hardest MS test I’ve taken.

That’s all folks.

That's all folks!