Tuesday, December 09, 2008

SharePoint MOSS 2007 - Troubleshooting Content Deployment Warning "A Web Part or Web Form Control type could not be found..."

After a recent deployment, we ran into a problem on our production and development farms where on every full or changed-only deployment, the following warning was being reported multiple times, listing unknown WebPart GUID's...

"A Web Part or Web Form Control type could not be found, or is not registered as safe. The Web Part will still be exported."

The really bad part is, these warnings show up as errors in the windows application log in the event viewer, which server administrators might over react to >_> So, lets look at how to troubleshoot these guys to make our server administrators happy...

Those listed unknown object GUID's are not the assembly GUID, but the SharePoint object id, which is just some random sharepoint key to identify the webpart in the database.

To troubleshoot, we took these sharepoint GUID's and looked through the SharePoint content deployment cab file. You can find that file path in the receiving publishing farm central admin under Operations->Content Deployment Settings. The path is on the server running the central admin site. In that directory, you'll find a directory for every deployment job thats been run successfully, and each one should hold a file named ExportedFiles1.cab. Extract that cab file to get at the manifest files for the deployment, you should end up with a set of files similar to the following:

These files hold the list of SharePoint objects, their GUID's and their more human readable properties. A snip of a sharepoint object in the manifest might look like this:

<SPObject Id="522e912c-13c7-43fe-aa0c-0966a859ed40" ObjectType="SPFile" ParentId="2b411f12-5969-426c-8225-e6a37ce8d6fd" ParentWebId="15d8b8b9-7b64-4b31-b3eb-24105b31725d" ParentWebUrl="/unc" Url="/unc/Pages/unsubscribe.aspx">

        <File Url="Pages/default.aspx" Id="522e912c-13c7-43fe-aa0c-0966a859ed40" ParentWebId="15d8b8b9-7b64-4b31-b3eb-24105b31725d" ParentWebUrl="/" Name="default.aspx" ListItemIntId="10" ListId="c52ee1b1-b21b-4b02-9f0e-7191842cde77" ParentId="2b411f12-5969-426c-8225-e6a37ce8d6fd" TimeCreated="2008-10-28T15:42:07" TimeLastModified="2008-12-08T23:14:18" Version="2.0" FileValue="00000809.dat" Author="2" ModifiedBy="14">





                <WebPart Name="e31419c7-3102-439b-8130-dc415519e690" PerUserProperties="/wEUKwAJAgICAwIBAQAAAgQChAELKjFTeXN0ZW0uV2ViLlVJLldlYkNvbnRyb2xzLldlYlBhcnRzLlBhcnRDaHJvbWVUeXBlAgIEBRZOQ1NfU0NfVW5zdWJzY3JpYmVGb3Jt" Level="major" WebPartZoneID="CenterColumn" WebPartTypeId="9a200b30-1bd5-a97f-03d6-907ef144236b" IsIncluded="false" WebPartOrder="0" FrameState="0" />

                <WebPart Name="953dce8d-74af-4c9d-a6af-10b69c126fef" PerUserProperties="/wEUKwAJAgICAwIBAQAAAgQChAELKjFTeXN0ZW0uV2ViLlVJLldlYkNvbnRyb2xzLldlYlBhcnRzLlBhcnRDaHJvbWVUeXBlAgIEBRZOQ1NfU0NfVW5zdWJzY3JpYmVGb3Jt" Level="major" WebPartZoneID="CenterColumn" WebPartTypeId="d91efffd-abdb-2f1b-d394-8683cb14a5dc" IsIncluded="true" WebPartOrder="0" FrameState="0" />



These SPObject elements should give us enough info to find the page/file causing deployment problems. In the example above, I found that the WebPart with the SharePoint object id of e31419c7-3102-439b-8130-dc415519e690 had been "closed" rather than deleted from a page, and I had later removed the webpart from the web.config and the bin directory, which was causing the problem.

To remove the closed webpart was a bit tricky, I had to edit the page reported in the SPObject element, browse for a Web Part, add the closed Web Part to a Web Part Zone on the page and then delete it from the page....

Make sure you do an Edit->Delete rather than clicking the X in the right corner of the Web Part pane...

Once you've found and fixed all these issues, you will probably want to do a full content deployment of the entire collection. I usually still get warnings/errors with the first deployment after making this kind of change, but deployments after that work fine.


smartyme said...

Hi, Thanks for teh post. I am having the exact same problem but I am having problem determining the page that has the web part. If I can find the page and identify the webpart, I can determine if it is safe or not. how do you identify the page from the SPobject? Thanks.

Bryan said...

Sumu, In the manifest xml files, the SPObject xml elements have File elements in addition to WebPart elements. The file elements have a URL property, which should be the url path to the page that SPOject element is refereing to in your site. You can see an example of that in the manifest XML snip in this blog post.

So, if you find a match on a WebPart element with the UUID you found in your error messsage, scroll up to find the File element within your current SPObject element and you should be good to go.

Keep in mind you may find the same web part match in several SPObjects if you used the same WebPart in multiple pages in your site. If that's the case, you'll have a bit of work to do hunting down all instances of the WebPart giving you trouble in your site, which is exactly what I ended up doing.

I hope that helps!

Raj Bezawada said...

I am having the same problem, but the job never runs fine so the temp files are deleted so quickly, I am not able to get a hold of it. I did check the manifest xml of a very old successful job. The giud is a webpart guid on Viariation Labels/DisplayForm.aspx

These looks like Sharepoint's own file

Bryan said...

Hey Raj,
If you dont have many pages marked in the job for deployment, you can try going page by page to see if you have any invalid closed webparts. If you find any closed web parts that are no longer needed, delete them and then do a full deployment.

Thats my best guess. If that doesnt seem to help, keep googling and let me know if you find a solution!

Gordon Comstock said...

Hi Bryan, great tip, thanks! How do I get the right GUID folder in the destination farm? I have several content deployment job but none of their GUID match with the folder name.


Bryan said...

Riccardo, I find the easiest way to troubleshoot is to run a deployment job by hand, then use the destination server's content deployment folder with the current date and time. Pull that cab file, extract the contents and search for the web part GUID.

As Raj points out, sometimes if the job fails the content deployment directory is deleted automatically from the destination server. I've found that for jobs that take a while to run, if youre quick enough, you can copy the deployment directory before it gets deleted.

I hope that helps!

Gordon Comstock said...

Thanks Bryan, I supposed that. I tried to look at the content deployment hidden lists in the source farm but all the GUID are different... I suppose that the folder name in the destination farm has its own GUID.