Today I was testing the SharePoint 2010 Content Deployment jobs. With the help of several blogs I managed to configure the Content Deployment quite easily. Using blogs of Becky Bertram and Benjamin Athawes, I figured out how to configure Content Deployment quite fast. Before we step into several gotcha’s I will explain a bit about the role of Content Deployment.
According to Microsoft TechNet, Content Deployment “… is a feature of Microsoft SharePoint Server 2010 that you can use to deploy content from a source site collection to a destination site collection”. With the help of content deployment, administrators are able to create a web application in which all content is managed (with the help of workflows and versioning). Besides this staging environment administrators create a second web application in which all content is displayed (only the major versions). The second environment does not allow users to update content. For example in this way we can set up a website. On the staging environment all changes can be made, approved by an approval process, and can be published to the website once all changes are approved. In this way we can reduce down time, and are able to correct any errors before they are made within the production environment. Herewith we can make sure that there are no spelling errors or wrong prices on the page.
Content deployment is especially useful when all content will be transported from one web application to the other. During the content deployment all kinds of content is copied to the destination web site. So all site columns, site content types, libraries, list, contents of lists and libraries, even web parts and even settings are placed in the destination web site. Even when a web parts isn’t deployed on the destination website the web parts is added tot the site. This will cause errors on the page. In this case the deployment of the web part on the destination web site is enough to let the web part function. It is important to know that a full copy is created, this means that all ID’s are also exactly the same as on the staging environment.
In the picture on the right side every step of the content deployment jobs is mentioned in the diagram. This flow diagram can also be found on TechNet. Using this flow chart you see that it is necessary to create a place where cab files can be stored temporarily. All with all a lot of steps are performed by SharePoint, and SharePoint will do this in simple environments within several minutes (quite impressive).
I also noticed during several tests that it is important to know what is changed in both the staging environment and destination website. When something is new or changed on the staging environment these changes will be deployed to the destination site during the Content Deployment job. However it might be possible to make changes in the production environment. These changes will not be replicated to the staging environment. When changes are made in the production environment and other changes are made on the staging environment, the changes on the production environment will still be in place. Once the editor changes the same settings in the staging environment (with other settings than the production environment), the changes to the production environment will be lost when the content deployment job is ready. At this moment all settings of the staging environment will be found on the production environment.
The content deployment jobs can use fully configured schedules in order to define when the jobs need to be executed. Here we have the possibility to start the job every hour, day, month or year. Besides this we are able to specify certain intervals on which the job should be run.
When using a publishing page there are even more possibilities to deploy new pages. When using these publishing page SharePoint delivers to possibility to add separate pages to the ‘quick deployment job’. This job can be configured to run for instance every 15 minutes. When the pages is edited and marked for deployment, the Quick deployment job will gather all marked pages and deploy them to the destination site. In this way content can de deployed very fast, without updating the entire website.
During the configuration I hit some gotcha’s which I wanted to share with you.
During my first tests I created a source Site Collection (Blank Site template), and I created a destination Site Collection (blank Site Collection). At this time the content deployment jobs failed because there was already content in the site which was the same as the source Site Collection. This is al because of the Style library which is included in a blank site template.
When configuring Content Deployment make sure that the target Site Collection is create without a template. Instead of choosing a default template go the Custom tab and on the tab choose for “< Select Template Later…>”. When the content deployment job is started for the first time the site and all of its contents will be created on the destination website.
- Configure Content Deployment from the beginning on. When a site is created and content needs to be added to the production environment the content deployment jobs will fail. Only when content deployment is configured from the start on, the solution will help you with content deployment.
When a content deployment job is running, new jobs cannot be started. So when you are programming a method which let the user start content deployment, please check if the deployment job is already running.
The Content Deployment jobs only publishes the most recent major version and the last minor version. All other versions are not used during the content deployment.
When there are any further questions about content deployment, please leave a remark at this blog.