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?
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.
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.
- Run stsadm -o preupgrade check from 2007 farm
- 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)
- Kick off database attach/upgrade
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.
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.