Wednesday, May 9, 2012

Changing SharePoint Site Definition to Original Team Site by updating the content database directly

Imagine you have a custom Site Definition in your MOSS 2007 SharePoint installation that is basically the same as the original Team Site Site Definition. In the end, your custom Site Definition ended up not being needed at all because it was so much like the original Team Site Site Definition. Now every time you upgrade SharePoint or stand up another copy of your SharePoint you have to upgrade and install these custom site definitions. This may also unnecessarily complicate any migration to SharePoint Online (part of Office 365). So, you decide you want to change the Site Definition that these sites use, to now use the default Team Site Site Definition instead of your custom one. One of the big requirements is that the we have a full fidelity copy of the site. By that I mean we don’t lose version history of files in document libraries and all site content is preserved. The question is how do you do this?

WARNING: I MUST first tell you these are NOT SUPPORTED or ALLOWED by Microsoft and you should proceed with caution and please test this on a non-production environment first. By directly modifying the SharePoint Content Database you are breaking the rules set in place by MS and it is possible MS would not help you if you have made any of these changes. I of course assume no responsibility for any harm caused by this code.

I have personally used these on production environment after testing that the changes didn’t break anything, but this was my environment and is by no means a representation of your environment.

You can use the Microsoft supported method of doing this using stsadm and export/import as I show you here, but you have to tweak the files before you import, figure out how to keep the alerts and workflows. In the end it is a lot of time and a lot code. To further complicate things, site collections and sites need to be handled differently also. In the end, the risk seemed quite high that I would miss something even after spending days writing code and testing. I found the testing to be very time consuming because of the time required to export and then import even small sites. To slow it down even more, there are only so many sites you can mess up before you just need to restore the content database again so you have more sites to test on.

If your site definition doesn’t add any value to a site really and they are the same as the default site definitions for the most part then you can update the content database directly. Again, this is absolutely not supported by MS and I assume no responsibility for issues this may cause. With that said again, try it on a dev or QA environment and I do lots of testing to convince yourself it works and I if you are lucky this hack will work.

OK here is all you need to do.

Let’s assume your site definition is called MySiteDef.

  1. Open SSMS and connect to your SharePoint content database (often called something like WSS_CONTENT).
  2. Run the following two updates (one for Team Site and one for Document Work space) assuming your site definitions are based on of these. These will affect saving your site as a template and then creating a new site and does not appear to affect the ability of your existing sites to render.
    update alldocs set setuppath = Replace(setuppath, 'MySiteDef', 'STS') where setuppath = 'SiteTemplates\MySiteDef\default.aspx'
    update alldocs set setuppath = Replace(setuppath, 'MySteDef', 'STS') where setuppath = 'SiteTemplates\MySiteDef\defaultdws.aspx'
  3. Next run the following update assuming your id of your site definition is 30001.
    update webs set webtemplate = 1 where webtemplate = 30001

That is it. So simple and best of all there is no downtime. If anyone tries this let me know how it works for you.

1 comment:

Charles Babcock said...

Brent I have a few questions and some observations. So far I am partially successful using your method. Can you contact me?