As a continuations of PowerShell script series, in this blog post , the first script enables to find orphans in SharePoint and the second script helps to find out the timer job history for a specified date and time range in SharePoint 2010

Detecting Orphans for the content DB in sharepoint 2010:

 $LogTime = Get-Date -Format yyyy-MM-dd_hh-mm
 $LogFile = ".FindOrphanSitesPatch-$LogTime.txt"
 
 if ((Get-PSSnapin -Name Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue) -eq $null ) 
 {Add-PSSnapin Microsoft.SharePoint.Powershell}
  
 $dbs = Get-SPContentDatabase
 start-transcript $logfile
 ForEach ($db in $dbs)
 {
     Write-Host “Detecting Orphans for the content DB: ” $db.name 
      
     $db.repair($false)
 }
 stop-transcript
 ########### end of script ################################################
 

Retrieve timer job history for a specified time range in sharepoint 2010:

 # Retrieve timer job history for a specified time range
 # Initial settings 
 Add-pssnapin Microsoft.SharePoint.Powershell
 $Wa = Get-SPWebApplication "https://XXX.am.XXX.com"    # Supply the web app url here 
 $From= "8/24/2015 02:00:00 AM"  # mm/dd/yyyy hh:mm:ss 
 $To = "8/24/2015 04:00:00 AM"
 
 # Retrieve all jobs in the time range 
 Write-Host "Listing all timer jobs that have run between $From to $To and storing it in CSV format" -ForeGroundColor Blue 
 $Wa.JobHistoryEntries | Where-Object {($_.StartTime -gt $From) -and ($_.StartTime -lt $To)} | Export-Csv TimerJobHistory.csv –NoType
 
 Write-Host "Done.." -ForeGroundColor Green
 
 # Retrieve all failed jobs in the time range 
 Write-Host "Listing all timer jobs that have failed to run between $From to $To and storing it in CSV format" -ForeGroundColor Red 
 $Wa.JobHistoryEntries | Where-Object {($_.StartTime -gt $From) -and ($_.To -lt $To) -and ($_.Status -ne 'Succeeded')} | Export-Csv FailedTimerJobHistory.csv –NoType
 
 Write-Host "Done.." -ForeGroundColor Green
 

In some scenarios, we may require to Create our Site Collection in a separate content DataBase. SharePoint does not allow us to do this directly. Because, the Content DataBases are created at the time of creating the WebApplications. i.e., When we create the web application, at that time, we are having an option to create the Content DB. But when we create some site Collections, then the Sites will get created on the Same Content DB, based on our Threshold limit of the DB.

But in certain cases, we may require to have a separate Content DB to take the backup and restore easily. In that case, let us how to do that step by step.

1. Go to Central Administration.

2. Click on Application Management.

3. Click on the “Manage Content Databases”

4. On the screen, change the WebAppliaction pointing to our Web Application.

5. Click on the Add a Content Database.

6. Enter the values as shown below.

7. Click on the OK.

8. We will be able to see the Content Databases.

Now, the next step is to create the Site Collection. But during the creation of site collection, we don’t have an option to choose the Content DB. To achieve this, what we can do is,

1. Click on the other Content Databases.

2. Make them as Offline on the Status.

3. Keep only our Content DB as Ready State.

4. Now, create the Site Collection. Obviously as the only DB is in Ready State, SharePoint will create the Site Collection in that DB.

Note:

Don’t Forget to make the other DB States as Ready again. If we forget, the other site collections will not work properly.

Happy Coding,

Sathish Nadarajan.

Recently I came across a requirement like retrieving the Content DB Size of a WebApplication using PowerShell. The WebApplication may have many Content DBs. So, all the Content DBs needs to be listed and their corresponding sizes needs to be exported into an Excel as output.

Thought of Sharing to the community.

 $LogTime = Get-Date -Format yyyy-MM-dd_hh-mm
 
 $LogFile = ".ContentDBSize-$LogTime.rtf"
 
 #cls
 
 ##================================================================================================
 
 ## Description : Get the Content DBs and their Sizes
 
 ## Author : Sathish Nadarajan
 
 ## Date : 09-Jan-2015
 
 ##================================================================================================
 
 $Host.UI.RawUI.WindowTitle = "-- Get Content DBs Size --"
 
 $StartDate = Get-Date
 
 Write-Host -ForegroundColor White "------------------------------------"
 
 Write-Host -ForegroundColor White "| Get Content DBs Size |"
 
 Write-Host -ForegroundColor White "| Started on: $StartDate |"
 
 Write-Host -ForegroundColor White "------------------------------------"
 
 #start-transcript $logfile
 
 ################################################### Add SharePoint PowerShell Snapin ######################################
 
 if ( (Get-PSSnapin -Name Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue) -eq $null ) {
 
 Add-PSSnapin Microsoft.SharePoint.Powershell
 
 }
 
 ########################################################### End of PowerShell Snapin ########################################
 
 ########################################################### Set the Exxecution Path #########################################
 
 $scriptBase = split-path $SCRIPT:MyInvocation.MyCommand.Path -parent
 
 Set-Location $scriptBase
 
 ########################################################### End of Set the Exxecution Path ##################################
 
 ########################################################### Prepare the Output File with Header #############################
 
 $Output = $scriptBase + "" + "ContentDBInfo.csv";
 
 "WebApplication" + "," + "ContentDBName" + "," + "Size in MB" | Out-File -Encoding Default -FilePath $Output;
 
 ############################################### End of Prepare the Output File with Header ##################################
 
 $webApplication = Read-Host "Please enter the WebApplication URL"
 
 $contentDataBases = Get-SPContentDatabase -webapplication $webApplication
 
 Write-Host "The Count of Content Databases for the WebApplication is :- " $contentDataBases.Count -ForegroundColor Green
 
 if($contentDataBases.Count -ne $null)
 
 {
 
 for($i=0; $i -le $contentDataBases.Count-1; $i++)
 
 {
 
 Write-Host $contentDataBases[$i].Name
 
 $contentDataBase = Get-SPDatabase | where-object { $_.Name -eq $contentDataBases[$i].Name }
 
 $webApplication + "," + $contentDataBase.Name + "," + $contentDataBase.disksizerequired/1024/1024 | Out-File -Encoding Default -Append -FilePath $Output;
 
 }
 
 }
 

Happy Coding.

Sathish Nadarajan.

In general, I have covered all possible activities to be performed at a high level for performing the migration from SharePoint 2010 to SharePoint 2013 in my previous articles.

Always perform the test migration in your SIT or Model Office Environment before proceeding to configure the Pre-Production, Production and DR.

Develop an automated PowerShell script especially for building the configuration of the SharePoint Servers. This would be very helpful in building multiple servers within shorter time.

3^rd Party Migration tools can helps save time and will be useful only when you have large content with less customizations, Unstructured content which you plan to revamp and redefine, Move external content into SharePoint, Granular migration of content, If your content is business critical and the users are not ready to wait for a smaller period of time in read only mode during the migration as the tools provide greater flexibility in incrementally performing the migration while you do it in a phased manner.

If you have not used Remote Blob Storage, Plan to enable it and migrate content into RBS from your content database after performing the migration as this would help largely in your cost to manage data in SQL Server.

Though migrating in a live environment is not easy and will end up in encountering different level of issues, my idea is to provide a consolidate view of the different set of activities that needs to be performed at various stages of the version upgrade and will definitely help in preparing and planning for the upgrade.

Once you have performed the database attach upgrade in a phased manner or complete an end to end upgrade, you will have to perform additional steps to complete the whole SharePoint migration activity. Though there are lot of articles in the web that describes the steps in detail the below article will help you understand the tasks to be performed post migration.

Features that do not work after upgrade:

There might be an exhaustive list, but I have covered the common ones that happen in any environment

1. Project Web Access Sites will not work with the SharePoint 2010 experience. They will only work when you upgrade them to SharePoint 2013 experience mode.
2. Enable settings:

             1. Enable "Workflow Auto Clean Up timer job"

             2. Configure Search service application based on the new search topology defined and run a Full Crawl for all your content sources.

Migrate to SharePoint 2013 UX Mode:
Most of the Site Collections will continue to work with SharePoint 2010 user experience. By default It is not automatically upgraded to SharePoint 2013 user experience while you perform the content database upgrade.

You can later force all the site collections to upgrade to SharePoint 2013 experience (or)

You can allow Site Collection Admins to perform the upgrade using Self Service Site Collection

Prepare a list of site collections that should done by Farm Administrators. This list might include sites that are business critical, Extremely large sites which holds data more than 5 GB of data, Specialized Site Collections (i.e.. Search Center Sites, PWA Sites, etc..) and Sites that are heavily customized using custom site definitions, farm level customization’s etc…

Site Collection Level Setting to exclude specialized Site collection

          -SpSite.AllowSelfServiceUpgrade

          – If set to false. The systems status message will not display the notification. This can be done for the list of site collections that are not allowed to be upgraded by Site Collection Admins

Features that do not work if migrated to SharePoint 2013 UX Mode:

Most of the items that worked in 2010 mode will continue to work after upgrading to 2013, but there are some exceptions to that. Requesting and performing a test with “upgrade evaluation site collection” will help to identify issues with the UI customizations done in the site which I would later explain in this article.

• Sites that are created with all Workspace templates(Document/Meeting Etc..) will not work if upgraded to SharePoint 2013
• The CSS and JavaScript’s that override the default SharePoint scripts might not work properly.
• Fast Search Center sites will work only in SharePoint 2010 experience and cannot be upgraded.

Force All Site Collections to Upgrade to SP 2013 User Experience Mode by Farm Admin:

Perform a backup of the farm before moving on to upgrading the site collection to 2013 user experience mode.

If you need to force all the 2010 site collections to be migrated to 2013 User experience , then you need to use power shell and perform the upgrade – Get-SPSite | Upgrade-SPSite – VersionUpgrade.

Configure Environment to Allow Site Collection Admin to perform Self-Service Site Collection Upgrade:

If you have planned to allow Site Collection Admins to perform the Site Collection upgrade, as a Farm administrator you have the following options below to control the upgrades performed by the site admins.

1. Upgrade Throttle Settings at Content Database Level:

            -SPContentDatabase.ConcurrentSiteUpgradeSessionLimit

            -Maximum no.of concurrent site collection upgrade that can occur in a content database. When limit is exceeded then it is queued to be upgraded

2. Web Application Upgrade Thottle Settings (SPWebApplication.SiteUpgradeThrottleSettings)

Displays information about the below settings

            -SPWebApplication.AppPoolConcurrentUpgradeSessionLimit

            -Maximum no. of concurrent site collection upgrade that can occur in the web application. When limit is exceeded then it is queued to be upgraded. Default is 5 per web server

            -SPwebApplication.UsageStoragelimit

            -Maximum size of a single site collection that can be upgraded within the process. When limit is exceeded then it is queued to be upgraded by timer job later

            -SpWebApplication.SubWebCountLimit

            -Maximum no. of subwebs a single site collection can have for upgrade to occur within the process. When limit is exceeded then it is queued to be upgraded by timer job later          

3. Web Application User Notification Settings:

When a site collections of a web application is available to Site Collection admins for upgrade, the farm admin can setup a status bar to show on all the sites to provide information on performing the upgrade. Also can send reminders to site collection admins to perform the upgrade

            -SpWebApplication.UpgradeMaintenanceLink

            -A link to appear in the maintenance system status message that appear on the top. Through this you can provide information about the upgrade status/Escalation contacts to end users

            -SpWebApplication.UpgradeReminderDelay

             -Time to have the upgrade notification to be available to end users. Default is 30 Days

Steps to perform by Site Collection Admin before upgrading to SharePoint 2013 mode:

1. Perform a Pre-Upgrade Site Collection Health Check (http://technet.microsoft.com/en-us/library/jj219720.aspx) – Helps to identify the unghosted files.
2. Optional Step: Request for an Upgrade Evaluation Sites (http://technet.microsoft.com/en-us/library/jj219650.aspx) -A Site Collection Admin can request a evaluation site using the Site Settings page. A "Create Upgrade Evaluation Site Collection" timer job creates a SharePoint 2013 Preview copy of the SharePoint 2010 Site Collection and sends an email to the site collection admin. The site administrator can validate and review all the functions and decide on to upgrade the original site collection. The Site Collection automatically expires in 30 days which is the default. By default, Site Collections more that 100 GB is not allowed to be created. This can be adjusted using the MaxSizeForSelfServiceEvalSiteCreationMB property of the SPWebApplication using Powershell.
3. Perform a Deferred Site Collection Upgrade – Upgrade the site collection using the option in the Site Settings page.
4. Review Site Collection Upgraded – Verify the issues that has occurred during the upgrade .A report is generated to show the issues that occurred during the upgrade and is available in Site Collection Upgrade page which is in  Site Settings – under Site Collection Administration (http://technet.microsoft.com/en-us/library/jj219531.aspx)
5. Troubleshoot Site Collection Upgrade Status – Refer the TechNet article http://technet.microsoft.com/en-us/library/jj219648.aspx

That concludes the upgrade of SharePoint 2010 to SharePoint 2013. Hope you had a better understanding about the various steps involved in performing the upgrade of SharePoint 2010 to SharePoint 2013.

Most important part of performing the upgrade or migration from SharePoint 2010 to SharePoint 2013 is to plan on how and when to perform the actual database upgrade after you have setup the fresh SharePoint 2013 Environment. In this post I will be covering the steps that you should be performing during the change window for the migration.

Plan to perform these migration phase wise. If you have very large content and you foresee that you can’t upgrade all of the Web Applications on a weekend, then plan to upgrade 1 Web application per weekend and perform the cutover to end users for every weekend. Subsequently you need to plan for making your search available for the moved content for your other web applications that live in the old farm until the phased migration is complete.

You can first setup the search in SharePoint 2013 environment and then connect your old SharePoint 2010 farm to the search service application and then start the phased migration.

During Upgrade (Follow the below Upgrade Order)

1. Plan to perform the upgrade on a long weekend considering the actual time to implement, Validation time and the backout time required to roll back in case of a failure.
2. The plan should be based on the time identified during your test upgrade
3. Follow the below order of upgrade

1. Perform Services Upgrade First (http://technet.microsoft.com/EN-US/library/jj839719.aspx)

1. Disable the Web Analytics Service Application in the SharePoint 2010 farm
2. Backup the databases related to the service application in SharePoint 2010.
3. Ensure that all service application pools are created in the target farm
4. Create the relevant service application and proxy in the target farm
5. Upgrade the relevant service applications by attaching the database and upgrading it based on the information provided in the TechNet Article
6. Start service instances only after your service is created with upgraded database.

2. Configure Web Application

Connect the service instances by connecting to the proxy groups(Some content databases upgrade may use service instances)

3. Upgrading Content Database:

Before performing a content database upgrade

a. Disable "Workflow Auto Clean Up" timer job to preserve associations and running instances of workflows. After disabling leave an hour time for the running job to complete.

b. Make the database in Read-Only mode.

c. Perform a Copy only Backup and Move the a backup to the new SQL Server 2012

d. Before  upgrading make sure you have not set the database in Read-Only mode in the new SQL Server 2012

Use the Core Commands required for Upgrade (To be done for all content databases)

a. Test-SPContentDatabase (Replacement for Stsadm -PreUpgradeCheck)-

1. Can be performed on a live database during off-peak hours.

2. To find issues, Orphans, Missing features, missing templates/site definitions, missing webparts

3. Site Collection in content database but not in config database sitemap or vice versa

4. Use -ShowRowCounts switch to find out database row size. Helps to find the time required to complete the upgrade.

b. Mount-SpContentDatabase

Attaches content database to a farm and starts upgrading the database. If the upgrade fails, the Upgrade-SpContentDatabase can be used to restart the upgrade process after fixing the issues that caused the failure.

c. Upgrade-SpContentdatabase

1. Used mainly for Build to Build upgrade of content database.

2. For version to version upgrade this can be used to restart the upgrade when there is failure in the upgrade process after executing the Mount-SpContentdatabase.

3. Can be run parallel on different content databases

Perform the Content Database upgrade in parallel using the Mount-SpContentDatabase Command

a. Move the mdf, ldf, ndf files from the old SQL Server to the new SQL Server 2012.

b. Add the databases to the database instance using powershell or SQL Management Studio

c. Use Mount-SpContentDatabase command to attach and Upgrade the database

d. If you encounter failures, review the upgrade log and correct the issues. Once corrected you can use the Upgrade-SpContentDatabase command to re-start the upgrade process.

4. Validate the Upgrade Process – http://technet.microsoft.com/en-us/library/cc424972.aspx

Review Errors

1. Review Upgrade Status Page in Central Administration for Errors and Warnings
2. Review Upgrade error log files available in  %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS
3. Review Correlation errors in ULS logs during the upgrade period
4. Review Application Event Logs for possible Errors or Warnings.

a. Application Event logs are sources of finding service account login failures

b. Domain Connectivity Failures

c. Custom Solution Provisioning errors

d. External Service connection failures

c. Server incompatibility between other SharePoint servers due to patch levels of the software’s installed

Solve Issues

1. First Solve issues that are authentication errors, assembly load errors, process crashes as that would have high impact on the functionalities
2. Solve issues related to missing server file dependencies and customizations
3. Solve issues related to content

General Testing

1. Identify and test sites based on criteria’s like Business critical sites, heavily customized sites, Sites that use Third Party solutions, Specialized site collections (i.e.. Content Type Hub, MySite Host) and Sites that use external connections via BCS, Office Data Connection Files for data.
2. Validate if all the site features exist and sites created on custom site definitions work
3. Basic Testing should include creating of Web Applications, Site Collection for SharePoint 2010 Mode and SharePoint 2013 Mode, SubSites based on Site Definitions, Feature activation on both SharePoint 2010 Mode and SharePoint 2013 Mode, Add Web Parts in both modes, Add Pages in both modes, Create Libraries/Lists/Content Types in both modes, Create Workflows in 14 mode, e.t.c….
4. Try logging in with different authentication providers for your site collections.
5. Validate User Lookup works in Central admin and any Web application
6. Ensure that all the Service accounts and App Pool accounts are member of the SPDataAccess Role Account

Finally the Migration is complete and you will have all your web applications in the SharePoint 2013 Environment. There would be no change in the way the UI behaves as your web applications run in SharePoint 2010 mode in the SharePoint 2013 environment. But still you have few more activities to be performed to utilize the full power the new SharePoint 2013 which I will be covering in my next article.

There are lot of activities to be performed before starting the actual migration. In this post I have covered the most important activities to be completed before the time you are planning to perform the actual database upgrade of SharePoint 2010 to SharePoint 2013

Pre-Requisites:

1. Target servers should not have any other version of SharePoint
2. Mandatorily apply SP1 or above for the SharePoint 2010 Environment or else Remote BLOB and Workflows might encounter issues after the upgrade.
3. Make sure you have the required hardware and software setup.(http://technet.microsoft.com/en-us/library/cc262485.aspx)
4. Make sure you have all the language packs installed and up to date.

Test and Clean SharePoint 2010 environment ( http://technet.microsoft.com/en-us/library/ff382641.aspx)

1. Perform Upgrade Check

• Test-SPContentDatabase – To identify upgrade issues in the 2010 environment use 2013 version of Test-SPContentDatabase on 2010 content database. Use the tool available in the link to review the issues which is very helpful(http://blogs.msdn.com/b/chandru/archive/2012/03/11/making-use-of-test-spcontentdatabase-generated-output.aspx)
  • Run the above test-spcontentdatbase command on content databases during off-peak load time on the database as it might impact your live environment slightly.
  • Issues with content can be identified using the command
  • Windows account to claims conversion issues.
  • Large Lists that would affect the upgrade process.
  • Incorrect authentication providers
  • Various configuration issues in the Web Application settings
  • Orphaned Sites
  • Missing Site Definitions, Customization’s and Features.

2. Features:

• Web Analytics related features should be removed from the Site collections if they are present in the Site Collection. Web Analytics works along with Search in SP2013
• Features related to Office Web Apps like PowerPoint broadcast site will not work in 2013. So those should be removed before the upgrade.
  • To Remove PowerPoint BroadCast Sites (Get-SpSite|Where-Object{$_.RootWeb.Template -eq "Powerpoint Broadcast#0"}|Remove-SpSite). This Site Definition will be available if you have installed Office Web Access in your 2010 environment.

3. Authentication:

• Migrate Web Application to Windows Claims if you have used Classic Authentication because in SharePoint 2013, Claims is the only authentication method. (http://technet.microsoft.com/en-us/library/gg251985(v=office.14).aspx). Verify all external data sources work as expected after migrating to the claims environment
• Forms Authentication works without issues if you have the same name for the membership and role providers that you have set for the web application

4. Clean Up:

• Delete Stale sites. Sites that are no longer used. Power shell script can be used to identify the older sites based on the last modified date property of the site to find out whether it is stale or not.
• Upgrade 2007 UI based Site Collections that run on 2010 environment to 2010 mode by Visual upgrade(Get-SpSite|foreach-object{$_.VisualUpgradeWebs()})
• Repair Data Issues
  • Perform Orphan Clean Up on all content databases using – stsadm -o databaserepair – deletecorruption
  • List delete that are corrupt – stsadm -o forcedeletelist
  • Cleanup variations – stsadm -o variationsfixuptool

5. Perform Visual Upgrade of old SharePoint Sites in the SharePoint 2010 farm:

Perform a Visual Upgrade for all the upgraded SharePoint 2007 sites. These will not work if you have not done visual upgrade for older sites. This is usually done when you might have upgraded from SharePoint 2007 to SharePoint 2010 using Get-SPSite | ForEach-Object {$VisualUpgradeWebs()}.

6. Document the below Farm Information required for Manual implementation:

Use the below Upgrade Worksheet from Microsoft to record the important information that will be required to done manually in the new SharePoint 2013 servers

(http://www.microsoft.com/en-us/download/details.aspx?id=30370) – Upgrade Worksheet from MS

• Gather Service Application Settings
• Export MIIS Encryption key for User Profile Service Application. Can be done in Central Admin
• Record Passphrase of the Secure Store Service Application
• Use PowerShell to enumerate to find the Web Application, Site Collection and Content database and record them to validate after the upgrade
• Custom Full Trust(GAC) and Partial Trust Solutions(BIN) to be deployed in the new environment
• Export Admin Deployed InfoPath Form templates and Data Connection files (UDCX)- Export-SPINfoPathAdministrationFiles – Exports to a CAB file
• Export Excel Services Trusted Data Connection files.
• MSI Deployed Third Party Components – Contact Vendor and get the latest solution for the SP2013
• Files that are deployed using XCopy or manually copied into file systems. Consider a moderate effort to be spent in packaging the files into WSP packages.
• Content Databases- That has issues with Orphans and Referenced Customizations
• Farm Web App- Alternate Access Mappings, Authentication Providers, Managed Paths, Installed/Registered features, Installed customizations and Web.Config changes.
• Cross Farm Topology , Search Topology, Logical Topology and Farm Topology
• Use Windiff tool from MS to document the below items
  • To Check the Web Server Extensions folder/directory structure in the SharePoint server. Perform it for all App, WFE Servers
  • GAC Assemblies in all the APP/WFE Servers
  • IIS Web Site Directories on all APP/WFE Servers
  • Patch Levels of Windows, IIS, SQLserver and SharePoint
  • Take a backup of all the above data which would useful to fix if there are issues after the upgrade

7. Re-organize content to reduce the risk of upgrade failure for content database

If there is more than one site collection per Content Databases and if they are more than 100 GB then it try to divide into multiple content databases by moving Site Collection.

Prepare the new SharePoint 2013 environment

1. Build SharePoint 2013 farm based on redesigned topology or as-is topology. Deploy and Activate required features and Services on servers in the farm
2. Configure Farm Settings like Blocked File Types, Usage and Health data collection settings, Diagnostic logging e.t.c.. as per your old environment or as per your new farm design.
3. Create Service Applications and Proxies in the farm as per your farm topology and use the same settings that you had in the SharePoint 2010 farm.
4. Import the MIIS Encryption key that was exported from the SharePoint 2010 UPS and the start the User Profile Synchronization Service
5. Secure Store Service – Restore the Passphrase which you used in the SharePoint 2010 environment.
6. Create Web Applications with similar SharePoint 2010 Setup.
7. Create the required User Policies, IIS Bindings, Authentication providers, AAM Settings, Managed Paths and Web.Config changes, Quota templates, Email settings and Certificates and all Web Application level settings
8. Connect the Web application to the service application proxy groups.
9. Install Third Party Components, Customization’s, Farm Solutions and Partial trust Solutions
10. Deploy required features and installers
11. Deploy or Install all required Full Trust or Partial Trust Solutions in all the WFE/APP Servers.
12. Configure Office Web Apps server
13. Configure Azure Bases services that would require for your new SharePoint 2013 environment (i.e.. Workflow Manager, Access Control Services E.t.c..)
14. Make sure you have adequate space for your transaction log files as this might grow during the upgrade process. http://msdn.microsoft.com/en-us/library/ms365418.aspx
15. Setup Http to Https redirection modules so that if you have any http based embedded links in office docs or bookmarks of users will continue to work

Preparing for Upgrading Customization’s:

1. Custom Site Definitions

• Upgrade definitions files and Update Onet.xml file
• Turn existing list instances into feature based list instance

2. Customization Security Changes

• No partial trust code solutions (Solutions that are deployed in Bin Directory) need to validate such solutions and update the CAS Policies in the web.config

3. Customization Deployments

• Install 2013 solutions first and then deploy 2010 solutions. Make sure you activate 14 mode features first and then activate 15 mode features
• Update references to _controltemplates and _Layouts folder to point to new 15 hive directory in the custom solutions
• If you plan to support both 2010 and 2013 mode in your farm , then deploy farm solutions to 14 hive and 15 hive folders . In the below command the –CompatibilityLevel parameter decides on which folder to deploy

Install-SPSolution -Identity contoso_solution.wsp -GACDeployment -CompatibilityLevel All

4. Search Customizations:

• Custom solutions that use FullTextSQLQuery will not work and needs to be modified to use with FastQueryLanguage (FQL) or KeywordQueryLanguage (KQL)

Setup Account Requirements for performing the upgrade:

• Active SqlServer Login on the SQL Server
• Account must be member of DB_owner group of the database
• Account must be a member of WSS_Admin_WPG group in the Config database
• Account must be member of farm admin group
• Account must be part of local admins group on the server

That concludes the 3^rd part of the series. Building customizations is the important aspect of the preparation and should be well planned. Identify the time required to build the customizations. Try to automate the preparation tasks using PowerShell and it would be a gold source for your environment. Keep updating it using tools like System Center configuration manager.

Planning for the upgrade is the most important part of a successful migration. Below are some of the key points to consider before starting migrate / Upgrade from SharePoint 2010 to SharePoint 2013.

1. Prepare a governance plan with the business to understand the below implications

   a)Create a Notification Plan for Business community

1. Include information about timeline of the read-only environment and upgrade timeline.
2. What would happen if there happens to be a roll back and the expected downtime for the business community?
3. Provide directions to site collection admins about the self-service upgrade capabilities.
4. Adoption policy or Training plan for End users on the new environment and modified/customized SharePoint applications.
5. Client Software update plan if any.
6. Technical Information on what would work and what would not in the new environment.

                  i. Checkout Out state will be lost after the upgrade

                  ii.  Third Party solutions that does not have a upgraded version for the new 2013 environment or that changes the user interaction for end users in the system.

    b) Allow/Deny SharePoint 2010/SharePoint 2013 Mode Site Collections to be created and run in the new SharePoint 2013 environment

   c) Allow/Deny Self-Service Site Collection upgrade which can be performed by Site Collection Admins

1. Communication Plan and Training Plan for the site collection admins on performing the self-service site collection upgrade.
2. Prepare a list of site collections that has to be upgraded by farm admins and excluded them from allowing self-service upgrade.
3. Prepare Farm admin support plan for Site Collection Admins to log in issues when they migrate to the new 2013 environment.
4. Make sure you have installed vendor supplied third party components for both 2010 and 2013 versions in the environment.

  d) Update any new governance policies for the 2013 environment

1. Allow 14 Mode Site Collections to be created or not after the upgrade.
2. Allow 14/15 Mode Site Collections to work side by side.
3. Large Lists Throttling.
4. Define Application Management Policies that defines how the new SharePoint Apps should be governed in the 2013 environment(http://technet.microsoft.com/en-us/library/fp161237.aspx#AppPolicy)
5. Identify features that will not be supported based on the future roadmap of SharePoint product and validate with the business for allowing usage of the templates for end users.( http://technet.microsoft.com/en-us/library/ff607742.aspx)

  e) Update your operations support model to reflect any changes to the end user support structure.

2. Do a Performance assessment in the old SharePoint 2010 Environment, to validate after the upgrade. This needs to either improve with the Hardware, Network or Software Configuration.

   a) Identify and define baseline performance requirements for SharePoint page response times on Peak and Average Traffic time, Upload/Download time, time required for Backup/Restore Site, time required for accessing the site via the different set of authentication providers, high critical apps response time e.t.c…

   b) Use Profilers to identify and measure current performance.

       i.      Client Profiler – Ex. Jquery Profilers,

       ii.      Network Profiler – Ex. Bandwidth and Latency test ,

       iii.      Server Profiler –Ex. SQL Server Profile, PerfMon.

       iv.      Hardware Profiling – Profiling Disk Drive IOPs.

   c) Plan to implement Tools like Compuware Vantage that simulates on-going network performance by the use of synthetic and real user monitoring which would help to

   d) Plan for using Request Manager for SharePoint 2013 to improve performance.

   e) Plan to implement Blob Cache and Object cache to improve performance on 2^nd and Subsequent page load time and download time.

   f) Plan to use Distributed caching service, a new feature in SharePoint 2013 which provided in-memory caching, to improve authentication time and page response time.

3. Update your capacity planning document as per your current sizing requirements (http://technet.microsoft.com/en-us/library/ff758647.aspx)

   a) Prepare a storage forecasting plan for the next 3 years based on the past storage metrics and percentage of user and content growth.

   b) Ensure you plan the capacity based on the roadmap your organization has on consolidating other applications into SharePoint.

   c) Measure Requests per second based on No. of concurrent users during peak and off hours and provide inputs to architecture team if required to redesign farm topology

4. Develop new Farm/Search/Network/Storage topologies based on your performance assessment results, Capacity planning documents and new features you plan to use in SharePoint 2013

5. Plan to upgrade the content in a phased manner which would ideally reduce the impact. Plan for less critical site collections first and move on to the high critical apps.

6. Prepare a plan, if required, to reorganize content in the farm. This might be consolidating site collections of same nature, remove repetitive information, archive content that is less critical and unused.

This concludes the preparation you have to make before actually starting the migration. Plan well as it helps you to identify risks involved in the migration.

After talking to a few consultants who had been upgrading the SharePoint 2010 farm to a SharePoint 2013 farm, I have consolidated the important aspects of upgrading/migrating a SharePoint Farm and would help a SharePoint Consultant who read this to prepare an estimate or aware of the high level tasks to be executed for the version upgrade of a SharePoint 2010 environment to a SharePoint 2013 environment. I will also continue to make updates on the different type of issues that I encounter and PowerShell automation scripts that would help in each step of the migration.

Upgrade and Migrate will be interchangeably used as to perform the version upgrade, We should be setting up a new set of servers and migrate the content from a live farm to the new 2013 farm.

As most of you know the only approach available and the approach I have documented is the Database Attach Upgrade for the SharePoint 2013 Migration.

The migration performed using the traditional way and there are no third party migration tools used. Anything that gets stored in the database is upgraded by this method, but whatever is in the file systems that are not available as part of the standard SharePoint 2013 build are not migrated and has to be manually installed and setup before performing the database attach upgrade.

Golden Rules

1. Always perform a test migration before performing the actual migration.

As you all might know the different functions and parts of a SharePoint system is complex and highly extensible in nature, for a perfect migration we should always consider performing a migration in a test environment to understand the complexity

2. DO NOT CHANGE WEB APPLICATION URL’s that requires upgrade

If you change the Url, the impact would be very high and might end up in failure of upgrade as the whole SharePoint design relies on the URL

3. Plan to use Deferred Site Collection Upgrade to minimize impact of upgrade

General Considerations:

1. Client Requirements

• Office 2010/2013
• MS Workspace works for 2010 and 2013 Mode sites
• SkydrivePro only works for 2013 Mode Sites
• IE 8.0 or Higher

2. Database that are supported for Migration/Upgrade:

• All Content Databases
• Project Server Databases
• Search Admin Database (Search Topology needs to be recreated and content to be re-indexed)
• User Profile and Social Database
• Managed Metadata Database
• Secure Store Database

3. Databases that are not supported for Migration/Upgrade:

• Config Database
• Search Crawl Database

4. Read-only Support not available for Access Service Database.

5. After the migration most of the SharePoint 2010 site collections will work as the underlying 14 Hive folder(SharePoint 2010) is still available as part of the SharePoint 2013 build which is called the SharePoint 2010 Mode in the SharePoint 2013 environment.

6. SharePoint 2010 and SharePoint 2013 site collection can co-exist and work in the same environment.

7. A feature called Deferred Site Collection upgrade can be used by a Site Collection Administrator to perform a test migration to see how his site would look in the SharePoint 2013 mode and later on migrate to the SharePoint 2013 user experience mode after he confirms and tests his site.

8. Web Analytics and Office Web Apps related features cannot be migrated or upgraded to SharePoint 2013.

9. Web Analytics and Project Web Access (PWA) will not work in the even in SharePoint 2010 mode after the migration. They will only work when you switch over the SharePoint Site collection to SharePoint 2013 mode.

10. Consider 3rd Party Migration tools when:

• When your 2010 environment needs heavy restructuring of content when it is migrated into the SharePoint 2013 environment. The tools provide a greater flexibility in terms of merging site collection and splitting them while migration.
• When you hold large file content from different data sources other than SharePoint (File)
• When 2010 site is less custom built and does not use heavy custom templates for site creation
• When you want to delegate the task of site/content restructuring to the site collection administrators.

10. If you hold Remote Blob Storage in your SharePoint 2010 environment, While migrating to the new servers, you need move your content to the same physical path that you have configured on your SQL Server machine. If you move to a different location, then the references will break and might not work.

That concludes the important key aspects to remember before proceeding to plan on preparing for the upgrade to SharePoint 2013.

In my next post we will look on what should be taken care before performing the migration as lot of planning is the key success of a migration.