SharePoint 2013 Upgrade
So you may have heard that the version cycle will start to be every 90 days for SharePoint going forward from SharePoint 2013 RTM. This is good news and, well bad news for those on the 2010 platform. This means that by not getting up to the 2013 platform soon you’ll miss out on a lot of the new things getting pushed down the pipe. With that said, more and more things are changing going forward and the model for which SharePoint will even exist could literally change every three months.
Unless you are on the bleeding edge of the Microsoft technology stack many of you are still recovering from a recent upgrade from 2007 to 2010. Some of us are still on the 2007 platform with no end in sight for upgrade to 2010 let alone 2013. Regardless of that, it is once again time to talk upgrade. This time around not a lot has changed, while at the same time much has changed.
So let’s cover the minimum stuff so far. First and foremost, there is no supported upgrade path from SharePoint 2007 to SharePoint 2013. If you are using the supported method of database detach/reattach you must first mount your databases to a SharePoint 2010 environment. More than likely there will be a 3rd party project to be able to push these changes however they would be supported by the vendor and not by Microsoft.
Next the prerequisites have changed a bit most notably .net and the AppFabric. Below are a list of perquisites you must install prior to installing SharePoint 2013. Just like in the past versions SharePoint 2013 will prompt you to install these prereqs. As well, just like in previous versions if you plan to do an offline install of the bits (no network access) you can use the PrerequisiteInstaller.Arguments.txt file to do so.
Application Server Role
Web Server (IIS) Role
Microsoft .NET Framework version 4.5 Release Candidate (RC)
SQL Server 2008 R2 SP1 Native Client
Microsoft WCF Data Services 5.0
Microsoft Information Protection and Control Client (MSIPC)
Microsoft Sync Framework Runtime v1.0 SP1 (x64)
Windows Management Framework 3.0 Release Candidate (RC) which includes Windows PowerShell 3.0
Windows Identity Foundation (WIF) 1.0 and Microsoft Identity Extensions
Windows Server AppFabric
Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)
With the introduction of more features and more caching in SharePoint 2013 the demand on physical resources in the SharePoint 2013 server farm has increased as well. For the SQL servers they now demand 8 gigabytes for small farms and 16 gigabytes for larger farms. They also require 4 cores and 8 cores respectively for each type of farm. Administrators should keep this in mind this is for each node of a cluster if redundancy is built into a given SharePoint 2013 environment.
The major software requirements are SQL Server 2012 x64 or SQL Server 2008 R2 x64 with service pack 1. Additionally the enterprise may choose to stay with Microsoft Server 2008 R2 with Service Pack 1 as that was a major requirement when using SharePoint 2010. With that said, the introduction of Microsoft Server 2012 has many enterprises weighing the option of upgrading to this latest version.
Just like the software changes there are some hardware changes as well. First the memory consumption will be going up. The most notable reason for this change is the AppFabric model. The reason for this is because the AppFabric in a way is kind of like in state memory for SharePoint. The AppFabric holds (in memory) streams of social data and displays that to a user in real time, it is not persistent so as timer jobs run, the data is refreshed. The good part is it has no impact on performance as long as the proper planning has been done to both account for the resources needed on the boxes for normal use as well as AppFabric this is again because that data is real time memory state vs. processor generated.
Additionally there is a larger requirement for single server installations. A single server install is when SQL server as well as SharePoint itself is all on one box. In the past this has been the cheapest most economical way to go for both small businesses as well as developers creating their sandbox. The requirement in RAM for an environment like this is 24 gigs total. If one takes a moment to really look at the numbers they would see that: 4 WFE, 16 SQL, X APP = 24 gigs so you are essentially replacing all the other services in one server farm.
There has literally been almost zero change when it comes to upgrading content databases from SharePoint 2010 to SharePoint 2013. In my opinion there are only 2 things worth talking about.
First let’s discuss the authentication changes in SharePoint 2013 Web Apps. So, in SharePoint 2013 there is no longer NTLM available for use for site collections. You may only create new web applications using claims authentication. Keep in mind, this doesn’t mean you need to fully deploy federated claims and trusted federation between other systems to just get SharePoint to work. You just need to make sure that the web app is “claims aware”. Interestingly enough, if you build your environment via PowerShell you’ll find that it is possible to host your SharePoint 2013 Central Admin site on an NTLM web application. No idea why.
Most importantly with upgrading content databases the fact that the content database may not have any site collections in it that rely on NTLM at the time of Upgrade. That means before you dismount your databases in 2010 you need to run some PowerShell to both upgrade your auth from NTLM to Claims but additionally, to convert all the users that have “active sessions” (something checked out etc) to claims.
This can be done fairly easily but obviously you’ll want to be careful what you do to your production farm. If you want to know how to convert your 2010 environment to Claims you can check out how to do that here.
Second, let’s discuss site collection upgrades in SharePoint 2013. This time around when you mount a content database site collections are not automatically put into “15 mode” or for that matter even made available to browse. An additional step is added this time around that allows the administrator to delegate when a site owner upgrades their site to SharePoint 2013. I can see most administrators taking the liberty of just upgrading all site collections as they do the mount just to make sure everything is buttoned up. But in some cases when an upgrade of an entire environment can take weeks when taking into account SLA down times and other work force factors, the ability to stager in your site upgrades for both performance as well as adoption will come in pretty handy.
Get-SPSite -ContentDatabase DBNAMEHERE -Limit All | Upgrade-SPSite -VersionUpgrade
This is where things change a bit with SharePoint 2013 upgrade. In 2007 we didn’t need to worry about Service Application upgrade, only SSP’s. Well with the new model in 2010, we now have the option to do so. The Service Application upgrade is VERY similar to the way content databases are upgraded. In fact they use all the same commands for PowerShell.
There are some caveats to upgrading the Service applications however. First and most notably not all Service Applications are upgradable in SharePoint 2013, and for that matter the ones that are sometimes are not 100% upgradable. Let’s take for example the Search Service Application. Search in SharePoint 2013 is changing pretty drastically this time around we have FAST integrated directly into Search for SharePoint. No more connectors and separate farms thank goodness. However that means a lot for the way data is stored and retrieved and for that reasons the index for search is not upgradable. In fact only the Search administration database and its settings are upgradable. So the good thing is if you have a complicated search architecture then you can keep all those settings. The bad thing is that if you have a simple search configuration just a ton of content, you’ll need to recrawl everything all over again. For customers with millions of documents this can be a real issue that should be carefully addressed.
Next let’s talk User Profile Service Application in SharePoint 2013. The good news is that not a lot has changed here in terms of upgrade so the process is overall fairly straight forward with one catch. The UPS has 3 databases in 2010 (as well in 2013), the Profile, the Sync and the Social. When upgrading the Social and the Profile databases its very straight forward, in fact the database schema doesn’t even change, it literally gets plugged and played.
That however leaves the Synchronization database. This is where things get tricky. When you declare a specific server in your SharePoint farm the “Sync Server” you set off a chain of reactions. First and most notably the issues with making sure you have allocated all the proper permissions to run the UPS both in AD as well as on the local machine. This by the way has not changed in 2013, to configure User Profiles Sync you need to do all the careful steps you did in the past, INCLUDING making sure those permissions are set and are correct prior to doing the upgrade of the Service Application.
Now the tricky part, when you declare this server you also are making some file level changes on the server itself. In the “<ROOT>\Program Files\Microsoft Office Servers\15.0\Synchronization Service\Bin” directory on the server lives a MIIS encryption file. This file is the encryption key that was generated so that your server is allowed to talk and make changes in Active Directory. Without this key on the new environment the server will not be allowed to make the synchronization. The process to export the key and reimport it into the new environment is fairly straight forward however it is still pretty tricky at the same time because you need utilize some PowerShell as well as some command line level scripting to export and import it.
The good news is there is a silver lining and that is you don’t need to upgrade the Sync database in order to upgrade the User Profile Service. You can just upgrade the Social and the Profile and recreate all the synchronization settings from scratch. Based on how straight forward your sync settings are (which OU’s and such) you are pulling could mean a very simple or difficult resetting of the sync settings. My preference is to reconfig the Sync.
The Managed Metadata Service Application is just as simple; however the last change you will need to make is adjusting the Content Type Hub if it has changed. Fifty percent of customers will change the URLs used in their new SharePoint farm (that % is totally made up but it’s a good amount). As a result of you moved to a new URL the content type hub will no longer work as it is looking for a different location. This can be changed with a quick PowerShell command.
The basic steps for upgrading a Service Application are as follows. Keep in mind some are slightly different depending on which ones they are (all via PowerShell mind you).
1. Create a new Web Application or Associate new Service Application with existing Web App
2. Create the Service Application
3. Create the Proxy for the Service Application
4. Mount the Service Application database
5. Refined steps for specific Service Application
Databases that can be upgraded to SharePoint 2013:
• Content Databases
• Sync Database
• Social Database
• User Profile Database
• Project Databases (all 4 databases get merged into 1 for SharePoint 2013)
• Secure Store Database
• Search Admin Database
• Managed Metadata Database
14 and 15 Mode
The last thing really worth mentioning is the 14 and 15 mode in SharePoint 2013. If you recall in 2010 we had/have the visual upgrade. This basically allowed us to render a newly upgraded site in the standard 2007 look and feel. This was great for not freaking out users when their site got upgraded. The bad part about this method is that the site rendered was the best we could do with the lack of the 2007 bits on the box. Therefore even though it looked like 2007 it didn’t work like 2007.
Most of the customizations for 2007 had to be upgraded to work in 2010. The good news this time around and I think will be a huge time saver for a lot of organizations is that we now have the SharePoint 2010 (14) bits directly on the server that come rolled out as part of the SharePoint 2013 install. That means that we can actually render 100% of the way SharePoint 2010 looked and worked in 2010. This means very few customizations both programmatic and look and feel will need to be upgraded in order to live in 2013!
The other good thing here is that on the fly the site owner can swap which look and feel they want. As they are upgraded they get the 14 mode but they are prompted (time duration set by the admin) on when they can upgrade their site. Once this happens SharePoint redirects the site to the “15” virtual directory instead of the “14” virtual directory. Making it completely seamless to the end user outside of the fact they have been upgraded.
So baring any actual script examples and screen shots that is the process in a nut shell. If you have done an upgrade from 2007 to 2010 you will find that upgrade from 2010 to 2013 is right in your wheel house… and almost, dare I say it… easy.