Upgraded content databases generate an upgrade status report to make sure upgrade was successful ... Web Analytics (not
Migrating SharePoint 2010 to 2013 CA CALLAHAN
[email protected] HTTP://ABOUT.ME/CACALLAHAN
Prerequisites
Experience administering SharePoint
Previous experience with migration helpful
Understanding of :
Windows Server
SQL Server
Basic PowerShell (particularly the SharePoint related cmdlets)
Willingness to learn about migrating SharePoint and ability to sit through a presentation
Sense of humor*
Agenda
Migration Path
Services that can be migrated
Services that can’t be migrated
Preparing for Migration
House cleaning
Documentation
Customizations
Eight steps to Migration
Migration Path
Only SharePoint 2010 can be upgraded to SharePoint 2013
There is no “in-place” upgrade for SharePoint 2013
There is only “database attach” upgrading
There is no pre-upgrade check for 2010, only Test-SPContentDatase before attaching
Site collections can have an upgrade health check run before upgrade
Upgraded content databases generate an upgrade status report to make sure upgrade was successful
Site collections are upgraded individually, and start out, by default in 2010 mode
A temporary evaluation upgrade (copy) can be created for a site collection to see if there will be any problems upgrading before doing so permanently
Services that can be upgraded
Search
User Profile Service
Metadata Service
Secure Store
Business Connectivity
PerformancePoint
Services that cannot be upgraded
State
Usage and Health
Web Analytics (not a service anymore, part of Search)
Foundation Search (also no longer available in 2013)
Preparing for Migration
House cleaning
Visual upgrades
Orphaned sites
Large lists with too many columns
Extraneous document versions
Site collections that need to be moved to their own content databases
Decommission PowerPoint broadcast sites and Fast search center
Remove unused web parts, features, solutions, sites, etc.
Documentation
Customizations
Some might migrate, many won’t
Create at test environment to check your customizations as part of your prep
Authentication- convert classic web applications to claims (or plan for it on the 2013 server)
Site templates may need to be rebuilt (unsupported zones, controls in non-standard places can cause issues)
Convert Classic to Claims web applications
For User Profile- export synchronization key
Documentation
Some simple tools to gather information about your SharePoint implementation before migration.
Stsadm –o enumallwebs –includefeatures –includewebparts –includeeventreceivers –includecustomlistview >c:\enumallfarm.txt
PowerShell Script (specifically for SharePoint Foundation, but will work for Server too): http://technet.microsoft.com/en-us/library/ff645390(v=office.14).aspx
More thorough powershell script that generates numerous XML files: http://technet.microsoft.com/en-us/library/ff645391.aspx
Simple tool that generates hmtl file: http://spsfarmreport.codeplex.com/
To do file comparison between 2010 server’s 14 hive, and the 2013 server, some simple tools
WinMerge
FreeFileSync (portable too)
WinDiff
SPDocKit (not free, but a great documentation tool)
Converting Classic to Claims
Although 2013 can support classic mode authentication, claims based authentication is the default
Migration web application databases
You can migrate content databases from web applications that were using classic mode authentication to 2013 (not recommended)
You can migrate content databases from web applications that were classic mode, then upgrade them on the 2013 server (extra work)
You can upgrade the authentication mode on the web applications from classic to claims on the 2010 prior to migrating (suggested approach)
To do so: $webappname = read-host “Enter Web Application URL” $wa = Get-SPWebApplication $webappname $wa.UseClaimsAuthentication = $True $wa.Update() $account = read-host “Enter PS Policy Account” $account = (New-SPClaimsPrincipal –Identity $account –IndentityType 1).ToEncodedString() $zp = $wa.ZonePolicies(“Default”) $p = $zp.Add($account,”PSPolicy”) $fc = $wa.PolicyRoles.GetSPecialRole(“FullControl”) $p.PolicyRoleBindings.Add($fc) $wa.Update() $wa.MigrateUsers($True) $wa.ProvisionGlobally()
Migrating the User Synchronization Encrypted keyThe User Profile Service uses an encrypted key to synchronize with Active Directory. To migrate the
sync capabilities of UPS, you must export the key so you can import it on the 2013 server.
At elevated command prompt, at path: C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\Bin
Run MIISKMU.exe
It’s full name: Microsoft Identity Integration Server Encryption Key Management utility
Select Export Key
Enter Farm Administrator acct and password
Specify filename and location
The file will be saved as a BIN, back it up. Be sure it’s available to use on 2013 server during migration.
Eight steps to migration 1.
Install SharePoint 2013 (don’t forget language packs)
2.
Copy customizations over to the new server
3.
Run configuration and configure farm settings
4.
Move databases to new SQL Server
5.
Migrate Service Applications (that can migrate)
6.
Create Web Applications
7.
Test and Attach Databases
8.
Upgrade site collections
Migrate Service Applications
Service Applications can vary in terms of requirements and parameters
You can only migrate service applications using PowerShell
Generally, migrating a service application from 2010 to 2013 is very much like creating a new service application, except, if they need databases, they refer to the databases being migrated and possibly original passphrases (as in the case of Secure Store)
Create service application pool
Create service application, referring to databases to upgrade
Create proxy
Create Web Applications
You first need to create a web application to attach the content databases from the 2010 server
Make sure all settings and URLs are the same
You can use PowerShell or Central Administration
You can remove the database that gets created automatically
The migration itself should be done in PowerShell
To create a claims based web application (example): $auth = New-SPAuthenticationProvider New-SPWebApplication –Name “Portal” –ApplicationPool “Portal” –ApplicationPoolAccount contoso\sp_portalapppool –URL http://sp1 –AuthenticationProvider $auth
Pro tip: Do not use convert-spwebapplication
Test and Attach Databases
SharePoint 2010 does not have a preupgrade checker, however it does have a cmdlet to test individual content databases before upgrading them.
Test-SPContentDatabase –Name WebApplication
If there are errors they are often concerning server side dependencies or the database is using classic mode and the new web application uses claims
Attaching the content database to the web application will upgrade it.
Mount-SPContentDatabase –Name –DatabaseServer –WebApplication
Review database and upgrade status in GUI
Upgrade the Site Collections
Once the content databases are successfully attached to the new SharePoint 2013 web applications the site collections they contain are not upgraded automatically
They are still running as SharePoint 2010 site collections and can be upgraded individually
As a site collection administrator
As a farm administrator
They can, of course, do mass upgrades
The easy way to upgrade a site collection or two:
Use the Banner at the top of the site collection page
Use the link in the Site Collection Settings page
Use PowerShell
Before upgrading
Run the Site Collection Health Check
Can Create temporary Evaluation site collection
Select to create a temporary evaluation site collection (site name appended with –eval)
Usually lasts 30 days (can be changed)
DO NOT do work on temporary site- it is not permanent!
Summary
Migration Path
Services that can be migrated
Services that can’t be migrated
Preparing for Migration
House cleaning
Documentation
Customizations
Eight steps to Migration
Migrating SharePoint 2010 to 2013 CA CALLAHAN
[email protected] TWITTER: @CACALLAHAN FACEBOOK GROUP: FACEBOOK.COM/GROUPS/CALLAHANSPF HTTP://ABOUT.ME/CACALLAHAN
