Part 1 - The BasicsPart 2 - The Basics continuedPart 3 - ConfigurationPart 4 - CommunicationPart 5 - Quick DeploymentPart 6 - LoggingPart 7 - Change Token BasicsPart 8 - Job and Change TokenPart 9 - Job and Timerjob
Quick deployment enables authors to select specific items to be quick deployed as soon as possible. The problem here is that authors are usually not allow to start timer jobs. To overcome this limitation it is required to store the information about which items have to be quick deployed at a place where a normal author of the site collection has write permission. And this is a list inside the source site collection. The quick deploy job that performs the actual deployment has to read the information about the items to be quick deployed from this list when it runs.
As multiple different quick deploy jobs which can run with different schedules can originate at the same source site collection it is required that the items are flagged for each of quick deploy job separatelly. So it is required that the author knows about all the enabled quick deploy jobs. As the author does not have rights to enumerate all quick deploy jobs it is required to store the information about all enabled quick deploy jobs at a place where the author can read. And this is in the property bag of the root site of the source site collection.
To enable quick deployment you need to modify the settings of the Quick Deploy Job listed on the Manage Content Deployment Paths and Jobs page.
To enable Quick Deployment you need to check the "Allow Quick Deploy jobs along this path" option.
As soon as a quick deployment job for a path is enabled two things will happen:
To be allowed to perform quick deployment, a user needs to have rights to create new items in the hidden Quick Deploy Items list in the root site of the site collection. This list does not inherit permissions by default and only site collection administrators and members of the Quick Deploy Users group have the required permissions.
Be aware that the title of this list is localized. In a german system (e.g.) the title will be Elemente für schnelle Inhaltbereitstellung. But the URL will always be http://url-to-site-collection/Quick%20Deploy%20Items.
The recommended way to give users permissions to perform a quick deployment is to add them to the Quick Deploy Users group.
The following prerequisites need to be fulfilled to allow a user to perform a quick deploy:
A user can perform a quick deployment of a publishing page using the console provided by the publishing feature. This action creates an entry in the Quick Deploy Items list (which resides in the root Web of the source site collection) for each of the enabled quick deployment jobs providing the server relative URL to the item that has been selected for quick deployment.
That means if the site collection is the source for three content deployment paths where each has an enabled quick deployment job you will get three list items per quick deployed publishing page.
As soon as the quick deploy job gets executed it will retrieve the list of all the items flagged for this specific quick deploy job and deploy them. After a successful quick deploy the deployed items are removed from the Quick Deploy Items list.
As outlined earlier in this section the quickdeployjobs property in the property bag of the source site collection has to be adjusted to enable a quick deploy job. Problems will occur in a situation that the user trying to enable the quick deploy job does not have rights to adjust the value of this property.
In this situation the user will see an access denied and an option to enter credentials of a different user. Using the "Back" button in the browser will allow the user to go back to the content deployment paths and jobs page and here he can see that the quick deployment job is marked as enabled now.
The problem is that only part of the enabling has happened: the job itself has been flagged as enabled by adjusting the field in the list item in the content deployment jobs list in the central admin web site but the unique Id of the job has not been added to the property bag of the source site collection.
The result of this inconsistency will be that the items being quick deployed will not be added to the quick deploy items list for this specific quick deploy job.
In case that this is the only quick deploy job for this site collection it will also mean that the Quick Deploy option in the authoring toolbar will remain disabled.
The following method is very effective to resolve this issue:
Quick Deployment allows authors to pick specific pages for content deployment. This is vital for companies which need to quickly update specific pages on their site which need to be independently updated from other content that would be deployed with an incremental deployment. Quick deployment will deploy only the selected publishing pages and resources bound to these pages. In addition, it is not possible to select items in a regular document library or list for quick deployment.
BenefitQuick Deployment enables authors to register specific items for quick deploy which will be deployed to the target farm independent from any other changes that have been done on the source farm since the last full or incremental deployment.
CaveatsQuick deployment only deploys publishing pages and resources bound to these pages. Sites and lists are not deployed through quick deployment. Due to this, all target folders and libraries for all deployed items must already exist on the target farm. For example, consider the scenario where a new picture library has been created and a picture from this picture library has been bound to a field in a publishing page that needs to be quick deployed. Quick deployment will fail if the picture library has not been previously deployed to the target site collection. Due to this limitation the group of users allowed to do quick deploy should be limited as they have to know exactly about this limitation and they also have to be aware about which content has already been deployed before to the target and which has not been deployed. Otherwise an author quick deploying a page which references a resource outside the already deployed libraries can cause an important press release which has to go live asap to fail to deploy as the quick deploy job fails.
In case that quick deploy has been enabled for a site collection before taking a backup means that the property bag of the root site of the site collection contains the unique id of a quick deploy job of this farm.
After restoring the backup in a different farm means that the quickdeployjobs property now contains the unique id for a job that does not exist in the current farm.
Problems with this scenario will occur as soon as quick deployment is enabled for this site collection again in the new farm. What happens now is that whenever an author selects a page for quick deployment two entries will be placed in the quick deploy items list: one for the job in the new farm and one for the job that only existed in the original farm.
The items for the job in the new farm will get deployed and afterwards these items will be removed from the quick deploy items list.
But the items that have been added for the job that does not exist in the current farm will remain in the list forever (or at least till they get cleaned up manually).
In the past I have had a couple of support cases where several ten-thousand of these orphaned entries existed in the quick deploy items list.
Even cleaning up such a huge list is challenging and time consuming.
To correct this it would be required to remove the invalid entries from the quickdeployjobs property in the property bag of the source site collection and afterwards it would be required to delete all entries from the quick deploy items list which do not belong to valid quick deploy jobs.
The following code sample demonstrate how to enumerate all enabled quick deploy jobs in the system and dump the unique ID of these quick deploy jobs:
The following code sample demonstrates how to dump the content of the quickdeployjobs key for a given site collection:
The result emitted by the above listed code piece will look similar to this:
Each guid in the property represents a different quick deploy job.
To delete the quickdeployjobs key (see backup/restore problem above) you can use the following code:
I can't believe that there have been no comments, this entire series is fantastic and I thank you for your effort. My question with Quick Deployment is I can not figure out what the Guid in the title references when a quick deployment item is added. You can view it in the Quick Deploy Items view when an item is added. Any idea?
Thanks - your code to clean up the property bag did the trick.
The Guid in the Title field is the Id of the QuickDeploy Job itself. This is stated in the part about "Possible problems with Backup/Restore".
Thus: ContentDeploymentJob.Id == ListItem.Title
Great blog series...very helpful and well-written
This series of articles is amazing. One thing that I noticed, is that by just stopping/re-starting the quick deploy jobs the "quickdeployjobs" property bag doesn't get cleared. What I did was to uncheck/check the "Allow Quick Deploy jobs along this path" option in each quick deployment job and that did create the "quickdeployjobs" property bag.
that was what I meant with "Disable all quick deploy jobs" / "Reenable all quick deploy jobs". :-)
Sorry if my explaination was not clear enough.
I have a site collection but I can only quick deploy items that are in the root site. On any other site in the site collection the item will not be added to the Quick Deploy Items list.
Just to clarify the quick deploy job run correctly, it is when I select an item that to quick deploy that is not in the root site I get an error (An unexpected error has occurred.) rather than the message 'This item has been submitted for Quick Deployment' So more to do with adding an item to the list to be quick deployed rather than the quick deploy itself.
this is an interesting one!
Can you enable callstack="true" and set customerror="off" in the web.config to get a better error message?