Error on theme page post SharePoint 2010 upgrade

July 29, 2011

I recently upgraded a MOSS 2007 site to SharePoint Server 2010 which seemed to go relatively smoothly, however a short while after the upgrade a user reported they got an error when trying to set the theme on a new site.

When I checked this was indeed the case i got an object reference not set to an instance of an object error, see full error below. I spent some time looking into this and researching information online and I was able to establish the error was down to the fact that the theme gallery had not been created in the upgraded site.

I found some articles, see below, that seemed to deal with the same issue and while I found the information useful it didn’t supply instructions on how this could be achieved hence why I decided to document the steps I performed to correct this.

From looking at the articles above the options were to re-create the theme gallery or redo the upgrade. Realistically redoing the upgrade was not an option so this left me with trying to either move the theme gallery from another site collection or recreating it.

My first though was this was something I could do through SharePoint Designer so I opened a test SharePoint 2010 site and tried to export the themes list but quickly found this was not possible.

My next attempt was to try and copy from one SharePoint Designer instance to another. To do this I created a test site collection on the production environment and opened this in SharePoint Designer. With two SharePoint Designer windows open side by side I tried to copy the theme gallery from the test site and paste it into the upgraded site. This partially worked but it re-created it as a folder not a list so while I could browse to the URL it didn’t recognise it as a list.

Next I tried copying the theme gallery as a list template and re-create it using this. I navigated to the theme gallery on my test site collection and went to the settings but found there is no save list as a template option on this list. I got around this by getting the list ID of the theme gallery and then going to save another list and clicking save as a template. In the new screen I then replaced the list ID in the query string with the theme gallery list ID. This then allowed me to save the gallery as a template and I could see it in the list gallery. When I then went to create a new list I found the template I saved was not available. Thinking about it this made perfect sense as the default theme gallery list definition is mark as hidden so any new templates created using this type of list would also be hidden.

The solution that finally work was to create a new list through the UI but change the URL to supply the out of the box theme gallery list template ID. From research online I was able to identify that the theme gallery template ID was 123 so I went to the root of my site and created a list as normal but I then changed the URL removing the feature ID and changed the ListTemplate querystring parameter to 123. I entered the list name as theme and clicked ok. This created my list as expected but it was still in the wrong location. In order for the theme functionality to work the list had to be under the catalogs folder. To move the list I opened SharePoint Designer and simply dragged the list to where it should be. At this point I could now use the set theme functionality but there were no items so once again I opened my test site collection in SharePoint Designer and copied all the themes across to my upgrade site. When I then refreshed the choose theme page it worked and all the themes were available to choose from.


Being a developer normally I don’t use SharePoint Designer, however in this case I found it extremely useful to be able to move and manipulate objects in the SharePoint site.

Hopefully other people will find this useful, however please ensure if there is anything you are not sure of try it on a development environment first and always ensure you have a back up you can revert to before stating any work.

Full Error Details

Exception information:
    Exception type: NullReferenceException
    Exception message: Object reference not set to an instance of an object.
Thread information:
    Thread ID: 9
    Thread account name: DomainOurAccount
    Is impersonating: False
    Stack trace:    at Microsoft.SharePoint.ApplicationPages.ThemeWebForm.<>c__DisplayClass2.<LoadV4Page>b__0()
   at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass4.<RunWithElevatedPrivileges>b__2()
   at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)
   at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param)
   at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode)
   at Microsoft.SharePoint.ApplicationPages.ThemeWebForm.LoadV4Page()
   at System.Web.UI.Control.LoadRecursive()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

MOSS 2007 to SharePoint Server 2010 Upgrade Part 1

July 11, 2011

I have just finished a project to upgrade a client from MOSS 2007 to SharePoint Server 2010 and I want to share the process I used and the resource I found useful so it may provide a starting point to anyone else you needs to upgrade their system.

The best place I found for information was, as you would expect, the technet site for SharePoint 2010. From there you can find a whole raft of information on best practices, suggested approaches, things to consider and it really helped me formulate my approach but also justify it to the stakeholders involved in the project.


After reviewing the clients current setup one of the first things I noticed was they hadn’t installed service pack 1 or 2 so I knew this was the first thing I had to address.

From experience I know it is never advisable to install services packs directly onto live servers and this presented the first issue as there was no representative development environment which I could use to test the updates. After discussing this with some of our infrastructure team we decided to take a copy of the existing servers and place them into a virtual environment. This would then be placed in a private network thus giving me a duplicate environment that was isolated from the network.

Once I had tested the virtualised environment was up and running I then took a snapshot of the servers so I could return to the pre-service pack state at a later date. I then proceed to install both service pack 1 and 2. To help with this I found some very useful articles by Shane Young on How to install WSS and MOSS SP1 and Install Guide: SP2 for SharePoint (WSS v3 and MOSS 2007). All this was done with a recent copy of the content database in order to establish if the updates would cause any issues.

On a date agreed with the client the virtual servers were rolled back to the pre-service pack state. I then marked the live content database as read only so the client could still access the system but couldn’t update the content while the service pack updates were installed on the virtual environment. Just to ensure users could access the system but not update it I performed a series of tests trying to add items to lists and document libraries. Once I was happy with this I then backed up the SharePoint content database and copied it across to the virtual database server and restored it. At this point I encountered a variety of issues from the time it took to back up the database to the the time it took to transfer across the network. The biggest issue for me was being able to get the database back up file into the virtualised database server. As I mentioned we had set up the virtual environment in a private network which meant we couldn’t easily copy/move files onto the virtual servers. In the end the only solution was to have another server in the main network copy the database file to this then join the server to the private network.

After the service packs were installed and the site had been tested by both myself and the client the old servers were switched off and the new virtual ones added to the network.

This may seem like a lot of work but it gave me the ability to test without affecting the live system and provided some reassurance to the client as they were able to test the system before it went live.

Lessons Learned

One of the biggest lessons I learned from this was to allow time in the project plan for copying of the data from one environment to another. In this project the client’s intranet was just over 50GB and what I forgot to factor was the time it would take to back this up and copy it from the old servers to the new ones.

Next Steps

In my next article I will discuss the steps I followed to upgrade the site to SharePoint Server 2010 using the content DB attach upgrade method.

%d bloggers like this: