I have a had a SharePoint installation since SharePoint Portal Server 2003. I have since upgraded to MOSS 2007, and have now upgraded to SharePoint 2010. When I did the upgrade to SharePoint 2010 I found out that there were lots of issues with the upgrade and it actually failed. Interestingly, most everything still works and is usable to end users. I found the logs from the upgrade to not be very useful because they don’t tell you what the issue was referencing and how to fix any of the issues. Below I walk through how to go about figuring out what the issue is at least about.
In each case, I recommend using SSMS (SQL Server Management Studio) to execute queries against each content database(s) to help you figure out what is being referenced. After that, you can decide if you want to ignore it, remove it, or try to find a fix such as installing the missing thing in question. What I found is that many of the things from either SharePoint Portal Server 2003 or MOSS 2007 are really the issue and are just not there in SharePoint 2010. In those cases, I just end up deleting the reference, but do so with caution on a non-production copy of SharePoint. Most importantly, test your changes. In many cases the issue is with a site so the amount of testing required is minimal.
After you resolve one or more issues you can
- Open a command prompt as Administrator and execute iisreset.
- Go to Central Administration | Monitoring | Review problems and solutions | Missing server side dependencies | Reanalyze Now button on the ribbon.
Missing Site Definition
1 Sites in database [WSS_Content] has reference(s) to a missing site definition, Id = , Lcid = . Remedy: The site definitions with Id 6215 is referenced in the database [WSS_Content], but is not installed on the current farm. The missing site definition may cause upgrade to fail. Please install any solution which contains the site definition and restart upgrade if necessary.
-- Get the web sites that are being referenced
select fullurl from webs where webtemplate = 6215
I went to the url (that I got from the query above) and found that the site had issues in MOSS 2007 as was not used. In my case, I deleted the site since it was not used and had not children sites. Alternatively, if you can’t delete the site AND it is the same as a standard Team Site, then you can change the webtemplate to the standard Team Site template using this technique.
Database [WSS_Content] has reference(s) to a missing feature: Id = [448e1394-5e76-44b4-9e1c-169b7a389a1b]. Remedy: The feature with Id 448e1394-5e76-44b4-9e1c-169b7a389a1b is referenced in the database [WSS_Content], but is not installed on the current farm. The missing feature may cause upgrade to fail. Please install any solution which contains the feature and restart upgrade if necessary.
-- Get the web sites that use this feature
select fullurl, description from features join webs on (features.webid = webs.id) where featureid = '448e1394-5e76-44b4-9e1c-169b7a389a1b
I went to the url (that I got from the query above) and investigated.
Missing Setup File
File [Features\NintexWorkflow\NintexCatalog\repair.aspx] is referenced  times in the database [WSS_Content], but is not installed on the current farm. Please install any feature/solution which contains this file. Remedy: One or more setup files are referenced in the database [WSS_Content], but are not installed on the current farm. Please install any feature or solution which contains these files.
-- Get the web sites that use this site
select * from AllDocs where SetupPath like '%Features\NintexWorkflow\NintexCatalog\repair.aspx%'
The only time setup files become a issue (that I am aware of) is when you save a Site as a Template and then try to use that template. I have not seem having missing setup files interfere with anything else. So, I just ignored these error since we don’t have the product anymore.
Missing Web Part
WebPart class [a21e5d41-9cab-1dd6-934f-fe972fd40238] is referenced  times in the database [WSS_Content], but is not installed on the current farm. Please install any feature/solution which contains this web part. Remedy: One or more web parts are referenced in the database [WSS_Content], but are not installed on the current farm. Please install any feature or solution which contains these webparts.
-- Get the site that has the web part
select s.fullurl, d.DirName, d.leafname, tp_ZoneID, tp_partOrder
from webparts p
join alldocs d on (p.tp_PageUrlID = d.ID)
join sites s on (s.id = p.tp_siteid)
where tp_WebPartTypeId = ‘a21e5d41-9cab-1dd6-934f-fe972fd40238’
You can get the site that has the web part. You will usually see that the web part does not render properly or says something about an error for a particular web part. That is usually the issue. it can be a bit tricky if everything looks ok though. In other words you may not see the issue on the site though. The problem in this case is usually that someone has closed a web part instead of deleting it.
There are two ways to delete the web parts.
- Add a ?contents=1 to bring up the Web Part Maintenance page. Click the ones that says Error and then click the Delete button. Much simpler
- To delete it you need to add it back to the page and then delete it. To add them click the Add a web part button on one of the zones and then click the Advanced Web Part gallery and options link at the bottom right on the screen. Then in the Add Web Parts panel that shows up on the page, click the Closed Web Parts collection. The web parts that have errors will say (Web Part Error) in the list of web parts before you add them.
NOTE: The query also has the zone id which tells you what zone it is in. This is usually something life left, right, top, bottom, etc. You can use this to get an idea of where on the page the web part is. The problem is that if it was closed it appears to show the last zone it was part of instead of null or something like that. Each zone can have multiple web parts. The order that they are displayed is shown in the partOrder. 1 = first, 2 = second, etc.
Assembly [Nintex.Workflow.Features, Version=188.8.131.52, Culture=neutral, PublicKeyToken=913f6bae0ca5ae12] is referenced in the database [WSS_Content], but is not installed on the current farm. Please install any feature/solution which contains this assembly. Remedy: One or more assemblies are referenced in the database [WSS_Content], but are not installed on the current farm. Please install any feature or solution which contains these assemblies.
SELECT s.fullurl, webs.fullurl, assembly, hostType
from EventReceivers e
join webs on (e.webid = webs.id)
join sites s on (s.id = e.siteid)
where Assembly = ‘Nintex.Workflow.Features, Version=184.108.40.206, Culture=neutral, PublicKeyToken=913f6bae0ca5ae12'
I went to the url (that I got from the query above) and investigated. I didn’t find that very useful. Then I looked at the hostType column in the results and in my case had a value of 2. Which according to the Microsoft reference is for a list. So, I used SharePoint Manager to go to each of the lists for the site and looked at the EventReceivers Property (Collection). You can then delete the appropriate Event Receiver using Powershell. Do the deletion at your own risk. I tried it on a copy of the content database and I didn’t see any adverse effects, and I have read that others have done it also, but it seems a bit risky to me in general. Try this on a copy of your content database before you do it on production would be my recommendation. You can also use SharePoint Manager to delete any hidden lists which have the EventReceiver. Again, use caution. If this is not a show stopper, you may consider just leaving the issue alone. That is what I did in my production environment since I was to chicken. Here is a good thread.
If you would like similar scripts, but using Powershell, you may want to start here.