SharePoint 2013 upgrade design and architect step 1 - SharePoint 2010 farm inventory and reports

In order to have a success SharePoint 2013 upgrade as we discussed in previous blog, the first and key step is the SharePoint 2010 farm inventory and reports. Create inventory and gather information from 2010 farm will help determine the 2013 farm topology plus a performance baseline and information about the environment. You could use the inventory and reports to design new 2013 farm, plan migration procedure, and automate to reapply all the custom configurations.

The following picture from Metalogix presentation described the SharePoint 2010 inventory.  

Here are some major inventory information you should gather and the purpose.

1. Farm configurations - Used for 2013 new architect design

• Alternate access mapping
• Authentication providers and authentication modes that are being used
• Quota templates
• Managed paths
• Incoming and outgoing e-mail settings
• Web.config like view state settings and blob cache
• All service and associations with Webapps
• Certificates
• Governance setting (Features, versioning, allow designer…)
• IIS settings like compressions and redirects
• FAST search configuration
• Max file size, email file size, attachment size configuration
• Other resource throttling configuration (list, number of look-ups ...)
• Session view states configuration
• Farm and webapp property bag settings – This stores in config DB and will not migrate to 2013

Most of the farm configurations are stored in either web.config files or config database that will NOT be migrated. One example is the farm and webapp property bag settings. As a result, you should identify all the configurations and automate the process to reconfigure them on 2013 farm.

2. Content usage - Use for upgrade planning

• Number of sites
• Number of databases
• Number of users
• Long URLs - larger than 265 will fail during upgrade and we already have report
• Self-service site management settings
• Managed managed metadata usage
• In progress workflow - workflow may need to republished and restart
• Site template used for each site - some template will be depreciated
• Web analytical usage- this needs to be replaced by new search
• Sandbox solution usage report
• Error webpart report
• Orphan site report
• Orphan database report
• Orphan feature report
• Orphan event receivers report 
• Missing definition field types
• Missing list definition lists 

Sandbox solutions will not be automatically upgraded to 2013 version. You need to repackage them and recompile them for 2013. The critical issues is the saved site templates used for 2010 provisioning. The right procedure is to identify them, create a site based on it, remove the saved templates, upgrade the site created, save the upgraded site to new site template on 2013.

The error webpart report is very useful to identify any failed webpart. 

Orphan site, orphan database, orphan feature, orphan event receiver reports will give you plan to remove them before the upgrade.

3. Customizations especially on the following items - Used for upgrade and clean up

• API related to claims that need to be changed
• Site definition
• Master pages and user control
• Workflows
• Set-SPCustomLayoutsPage custom page
• Discussion board to add all attachments into single view customization (Will cover this in future blog

SharePoint 2013 changed the master page design and you would need to use new html file to change master pages. If you are using Set-SPCustomLayoutsPage to redirect the OoB pages to custom page, this will not work on current version of SharePoint 2013. The bug has been reported and is waiting for solution.

 

4. Third party software we are using now - Used for upgrade and clean up

• Quest webaprt
• Muhimbi 
• Lightning tool bcs metaman
• NextLabs
• DocAve
• Codeplex Property Bag Settings Tool
• WireBear MetaDataNavExpansion tool
• Matan
• Media Player Sharepoint Web Part
• "Digital Clock" Sharepoint Web Part
• Tzunami eRoom migration tool
• Fab 40
• Bamboo
• BAInsight

Some third party solutions might not work on SharePoint 2013 and you would need to work with each vendor. The critical two issues here are NextLabs does not support claims at this point and Fab 40 will no longer supported by Microsoft. We will continue working to provide solutions on these upgrade or clean up.

In summary, the success of the SharePoint 2013 upgrade starts with farm inventory and reports. We will publish other upgrade steps in details in future blogs.

Tips to resolve error "Unable to load workflow actions from the server"

Recently, we have run into  "Unable to load workflow actions from the server" multiple times when users try to create or modify a workflow using SharePoint designer. Here is the error message.

 

It seems worth to summarize the major possible reason that might cause the issue and the procedure to fix it.

  

First, missing feature is the most common reason. You could follow Ian Hayse’s blog to use Fiddler verifying any missing feature. We had removed Bamboo PM suit from our environment but some reference still remained on app server. The Fiddler captures the missing feature error as in the following screenshot. The action is to clean up the feature or add back the feature if needed.

You can identify the exactly missing feature is as highlighted. The solution is to clean up the Bamboo features and components in our case. If you still need the missing feature, you should install again to avoid such issue.

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown.</faultstring><detail><errorstring xmlns="http://schemas.microsoft.com/sharepoint/soap/">Failed to find the XML file at location '14\Template\Features\ProjectCentralContentTypes\feature.xml'</errorstring><errorcode xmlns="http://schemas.microsoft.com/sharepoint/soap/">0x80131600</errorcode></detail></soap:Fault></soap:Body></soap:Envelope>

Second, corrupted workflow action file is the second common reason. You could verify the procedure form Microsoft site. The action is to copy the correct workflow action file and bounce IIS. We had corrupted file on one of the WFEs and it was fixed by coping the file from another server.

Third, corrupted SharePoint designer cache. You can delete the designer cache as described in this blog. 

There may be some other reasons that might cause the same issue. You should always try to IISRESET and clean up designer cache as the first two steps.