Michael Yeager's MSDN Blog : web content management

Balancing your MOSS Content Types

mty — Tue, 03 Jun 2008 18:59:00 GMT

I have found that the following two issues can be critically important when architecting a catalog style WCM site:

1. The intention to use the Content Query Web Part (CQWP) to roll up lower level detail pages to higher level summary pages can have a major effect on your “Content Type Architecture” The CQWP has the ability to query across multiple sites by Content Type. In a “catalog” style site where one is drilling down to detail pages, the ability to roll up across many different Pages libraries by Content Type can be a crucial functional detail

2. Another important detail is the fact that a content type can have many layout pages. Often the authoring team wants to be able to switch between layout pages for the same content. You can do that by simply making sure the layout pages share the same content type, and that the fields that each layout page shares line up properly.

The first issue encourages the site architect to create more content types to make it easier to roll-up the content. The second issue encourages the site architect to create fewer content types each having multiple layout pages so that the authoring team can easily switch between layouts.

Content Deployment Debugging Links

mty — Wed, 07 May 2008 21:43:00 GMT

There is more info on Content Deployment issues in earlier blog entries here.

The main thing is to first install SP1 and KBs 941422, 948945 and 950279, and 952698 and 952704 (these last two may rollup all the changes in the earlier KBs, I am trying to confirm that).

Beyond that, the best information on debugging Content Deployment jobs can be found on Maxime Bombardier's blog:

http://blogs.msdn.com/maximeb/archive/2008/02/19/debugging-content-deployment-issues.aspx

(setting versioning to only Major Versions in the Style Library helped me out big time)

and in parts 5 and 6 of Stefan Goßner's series on content deployment:

http://blogs.technet.com/stefan_gossner/archive/2007/10/12/deep-dive-into-the-sharepoint-content-deployment-and-migration-api-part-5.aspx

Also note that there are quite a few fixes included in SP1 plus the post SP1 rollups KBs 941422 and 948945 and 950279.

http://support.microsoft.com/kb/941274

http://support.microsoft.com/kb/948945

http://support.microsoft.com/kb/950279

There are two KBs that are specific to Content Deployment with 60+ fixes. If you have having serious CD problems, you'll need to talk with Customer Support Services to obtain these:

http://support.microsoft.com/kb/952698

http://support.microsoft.com/kb/952704/

In theory these two are a rollup of all the previous Content Deployment hogfixes. I am still trying to confirm that this is true.

Non Obvious Details about Content Deployment

mty — Tue, 06 May 2008 23:44:00 GMT

When you have Quick Deployment job, and you edit a page and add it to Quick Deployment, the job appears in a list called:

Quick Deploy Items

Go to: http://<mysite>/Quick Deploy Items to view it.

If Quick Deploy is failing, you can go to this list and delete the problem items out.

Also note that your deployment jobs (like your backup jobs) end up in the Timer Job Definitions found in the Operations section of Central Admin. If your Full Deployments are failing, delete them out of the Timer Job Definitions before restarting (the same with failed backups).

Content Deployment Failure

mty — Tue, 08 Apr 2008 23:25:00 GMT

Was able to work through an interesting content deployment issue on a medium SharePoint farm with the help of the following kb:

http://support.microsoft.com/kb/947285

All Content Deployment Jobs were failing and the error in the event log indicated a 404 not found. Which doesn't make a lot of sense since the deployment was not to a separate farm, but to a web application on the same farm.

By setting up the trace log on the SharePoint Services Timer Service on the Central Administration server of the farm, I was able to see that the url for the publishing web request included the server name. It turned out that the team that set up the SharePoint farm created a dns name for the Central Administration server, and deleted the server:port entry from the Alternate Access Mappings.

Tried re-setting the Alternate Access Mapping for the Central Administration server back to servername:port, but this did not solve the issue. Used psconfig to unprovision then reprovision Central Administration with default settings (servername:port):

http://technet.microsoft.com/en-us/library/cc263093.aspx

and that solved the problem - all of the Deployment Jobs now work perfectly. There was one Deployment Job between farms that was also not working, and the target farm was built the same way. Unprovisioning the Central Admin on the target farm and then reprovisioning it cured that cross farm deployment job.

Sounds like a big deal to blow away the Central Admin web and then recreate it, but the psconfig tool makes it quite simple and painless.