Tell me more ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.
up vote 2 down vote favorite
1

We're migrating from SP2007 to SP2010 and are seeing some error messages about missing web parts during the upgrade, but the error messages only list the GUID and not the web part name. Is there a way to easily get the web part name from a GUID? Maybe a PowerShell command?

share|improve this question
Did you run the pre-upgradescan before you migrated? This should've shown you if there are any orphaned Features in your farm. – James Love May 20 '11 at 17:39
James meant stsadm -o preupgradecheck – Alexey Krasheninnikov May 21 '11 at 5:14
Yes I did, cheers. Those admin tasks evade me sometimes... puts head back into sea of C# code – James Love May 21 '11 at 16:50
Yes, we did run the pre-upgradecheck. There were some missing features, but some of the other problems were web parts that we carried over from SP2003 in the database, but those web parts don't exist in the file system. We're doing some major clean-up now. – stomcavage May 24 '11 at 14:55

3 Answers

up vote 5 down vote accepted

Run the Get-SPFeature Powershell against your 2007 environment and it'll kick out a list of all of your features resolving the GUIDs to the names.

Powershell Commands to List SharePoint Features

To James' point, it sounds like you missed a step or two in your upgrade planning. Make sure you're running Test-SPContentDatabase before you kick off the actual upgrade to avoid those "oh by the way's" along the upgrade process.

  1. Run stsadm -o preupgrade check from 2007 farm
  2. Run Test-SPContentDatabase against the 2007 DB(s) from the new 2010 farm (this will show you what's missing; until this is clean don't proceed with the actual upgrade)
  3. Kick off database attach/upgrade

Test-SPContentDatabase information

share|improve this answer
If the GUIDs that Get-SPFeature return do not match those in your errors, it could be that the GUIDs are actually the web part instance IDs. I'm not sure if there's an easy way to resolve this, but I do have a solution (that I'm not keen on publishing) if you're still stuck, even after trying Mike's solution here. – James Love May 20 '11 at 17:59
This is all good information! However, I'm looking to identify particular Web Parts from the GUID not lists. Any advice? – Helmut Oct 25 '11 at 20:09
Try this post over on Phil's blog. You can use PowerShell to execute a SQL query to resolve the GUID against a particular feature or page. I've used this approach to identify the pages where the web parts were referenced so they could be removed. get-spscripts.com/2011/08/diagnose-missingwebpart-and.html. The other thing you should check is if the incompatible web parts are still in the web part gallery of any site; that can also throw an error. If you remove them, you must also clear the recycle bin or the references will remain in SQL and still throw the error. – webdes03 Oct 25 '11 at 22:30
up vote 1 down vote

Then I've got some bad news for you as the only way to find out the answers for many of these issues is to dive into the content database directly via SQL Server Management Studio. I know, I know, according to MS, you aren't supposed to ever go into the SQL database. Unfortunately, they provide horribly inadequate tools when it comes to the 2007-2010 upgrade which leaves people with very few other options. In order to answer your specific question, you will need to run SQL like this: 

SELECT WebParts.tp_SiteId, WebParts.tp_ID, WebParts.tp_ListId, WebParts.tp_Type, WebParts.tp_Flags, WebParts.tp_BaseViewID, 
    WebParts.tp_DisplayName, WebParts.tp_Version, WebParts.tp_PageUrlID, WebParts.tp_PartOrder, WebParts.tp_ZoneID, WebParts.tp_IsIncluded, 
    WebParts.tp_FrameState, WebParts.tp_View, WebParts.tp_WebPartTypeId, WebParts.tp_AllUsersProperties, WebParts.tp_PerUserProperties, 
    WebParts.tp_Cache, WebParts.tp_UserID, WebParts.tp_Source, WebParts.tp_CreationTime, WebParts.tp_Size, WebParts.tp_Level, 
    WebParts.tp_Deleted, WebParts.tp_HasFGP, WebParts.tp_ContentTypeId, AllDocs.DirName, AllDocs.LeafName
FROM WebParts INNER JOIN
    AllDocs ON WebParts.tp_PageUrlID = AllDocs.Id
WHERE (WebParts.tp_WebPartTypeId = 'c167c821-8b7a-598e-f56d-d94ba6459613')

(replacing the GUID with the web part type GUID you are looking for of course)

That isn't the exact SQL you will need but should get you started toward finding those missing pieces. A large number of the issues you will hit in the pre-upgrade check can be identified by querying the WebParts and/or the AllDocs tables in some way.

Note: this is just to help you identify the specifics of the issue - do not modify the data in any way.

share|improve this answer
Per Dave Wise's answer above: Thanks, that worked great. However, even though my SQL Query returned 9000 results, about 18 of the 50 GUIDs are still not in the list. What does that mean? Also, how do I go about identifying features and eventhandlers? Also, a number fo the GUIDs are specified for search, do I have to activiate these in SP2010 or do they come standard with Search Services? – Helmut Nov 1 '11 at 17:08
up vote 2 down vote

One quick trick (which doesn't quite get you what you want, but will be helpful) is to add "?Contents=1" to the end of the URL for any page. This will show you the /_layouts/spcontnt.aspx page which displays all of the Web Parts which are on the page, including those which are closed. It's often the case that the issues are with closed Web Parts, and you can remove them from this page. (Always a good practice in any case.)

If the issue persists, then you can see the GUIDs for some of the open Web Parts using the Developer Tools in IE7+ or Firebug in Firefox. You can use either tool to inspect the DON and search for the GUID.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.