3

I have run a preupgrade check on a SP2007 database to identify issues prior to upgrading to SP2010. The report shows a lot of messages for missing webparts. The strange thing is that I cannot identify these webparts. The message looks like:

WebPart class [293e8d0e-486f-e21e-40e3-75bfb77202de] is referenced [11695] times in the database [sharepoint-3], but is not installed on the current farm....

When I run a TEST-SPCONTENTDATABASE command on the SP2010 environment I get similar output. I have also downloaded the SP2007Migration.console.exe from CodePlex which takes the output of the TEST-SPCONTENTDATABASE from the SP2010 environment and runs that on the SP2007 environment to fetch all the sites/pages/webpart names etc.

Still the referenced web part issues relate to many sites and have a blank title. I have checked the sites to see if they have errors on the SP2007 environment but there are none. I have even mounted the database to SP2010 and after the migration the sites are looking fine. (So what are we talking about? haha)

Question is: what is the easiest way of identifying the webparts name, title, assembly etc as I have no clue where the issues are coming from. I need to know if I can safely ignore those like old references in the database which are perhaps from SP2003?

Thanks!

Serve Hermans
  • 68
  • 4

1 Answers1

3

This issue keeps cropping up.

To recap, the best way to do get a quick view of what is being used where in a given content database is with the stsadm command enumallwebs using the addtional parameters (supplied with the October 2009 Cumulative Update, if you are using SP2007):

stsadm -o enumallwebs -includefeatures -includewebparts -includeeventreceivers -includesetupfiles -includecustomlistview
Community
  • 1
SPDoctor
  • 9,613
  • 2
  • 34
  • 60
  • 2
    This is THE way to do it. The Guid cannot be used to backtrace the web part. – Wictor Wilen MCA MCM MVP Jun 07 '11 at 09:35
  • Yes, this works. Apologies for not having discovered the other issue earlier. So I can now see the Type of the webpart which is a default Microsoft.SharePoint.WebPartPages.ListFormWebPart. Keeps me puzzled as why preupgradechecker is referring oob web parts as 'not installed on farm'. Thanks @SPDoctor @Wictor-SharePoint-MVP – Serve Hermans Jun 07 '11 at 10:16
  • I used this and found the faulty webpart in the XML like this: But now what? What can I do to correct this? – Jasper Jun 09 '11 at 14:49