During a recent upgrade of a SharePoint 2010 solution to 2013 I discovered something I first thought must be a bug in the upgrade process.
It was actually just “luck” that made us aware of the problem. Under each region site we had a landing page where users could add sub webs using a custom web part for provisioning. Visually you couldn’t tell something was wrong, but the provisioning failed because the custom code in the web part required the landing page to be of a specific site definition.
Sure enough, the WebTemplate property of the web revealed that the template is DOCMARKETPLACESITE. At first I thought I had made an error in the XML file that you place in 15\CONFIG\UPGRADE before upgrade. But no, it looked OK. And there was no signs of what had happened in the upgrade logs – except for a successfully web upgrade.
Then it hit me, what site definition id do DOCMARKETPLACESITE use? Oh, “10000” – the same as ours!
But hey, isn’t that a “reserved” ID for custom site definitions according to the documentation:
Specifies the ID of the site definition. To avoid conflict with IDs that are natively used in Microsoft SharePoint Foundation, use IDs with values greater than 10,000 when you create custom site definitions.
You can argue that they say greater than 10.000, but I bet most people don’t expect Microsoft to use 10.000…
To solve this we had to do the following:
- Change the web template ID in the SP2013-version of the site definition to a new number (15/TEMPLATE/<lcid>/XML/webtemp*.xml)
- Create a web on the same level as the old one, but using the new template
- Move all subwebs to the new web (Export-SPWeb / Import-SPWeb)
- Delete the old web
- Rename the new web
A basic check that could have revealed this earlier is to run the following PowerShell script in old and new environment and do a text compare to spot changes:
$wa = Get-SPWebApplication <URL> $wa | Get-SPSite -Limit All | Get-SPWeb -Limit All | Select-Object Url, WebTemplate | Export-Csv ".\[NAME].csv"