A customer of mine is still having issues with content deployment and has provided me with this interesting story;
Ah! Sharepoint 2007 continues to be a living and learning experience.
I’m sure there is a built in timer service that automatically creates one problem in perfect synchronicity with another one just to create maximum confusion. After a recent database server reboot, I started a standard deploy to copy the latest content from the staging environment to Internet environment. It crashed with a ‘can’t write’ package error, which could have been either of the two servers OR SQL servers, and I first suspected some permission changes post the reboot.
But no. It was a simple ‘out of space’ on the destination Sharepoint Web server. For future info: Sharepoint writes the deployment package to the directory windows/temp/content deployment/[guid] and *leaves* it there forever. The directory was full of deployments dating back to the original content creation. I can see no good reason to retain these so I simply deleted most of them – problem fixed..
This appears to be a bug. (shock! Horror!) because the admin gui clearly states:.
Specify where you want to store temporary files for content deployment jobs. These files are automatically deleted when the deployment job is finished.
This folder must have enough available disk space to store all the content that is deployed at one time..
Maybe a scheduled job to clean these up monthly would be a good idea?