Quick Deployment Concepts
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.
Enable Quick Deployment
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:
- The job will be marked as enabled by adjusting a field in the list item relate to this quick deploy job in the Content Deployment Jobs list if the root site of the central admin web site.
- The unique Id of the quick deploy job is added to the quickdeployjobs property in the property bag of the root web of the source site collection which stores the Ids for all enabled quick deploy jobs in XML format.
Allow users to perform Quick Deployment
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.
Perform a quick deployment
The following prerequisites need to be fulfilled to allow a user to perform a quick deploy:
- The user has contributor rights on the Quick Deploy Items list – means he is a member of the Quick Deploy Users group.
- At least one quick deploy job is enabled for the site collection – means that at least one unique id for a quick deploy job has been added to the quickdeployjobs key.
- The page is in a valid state to be quick deployed – means that the latest revision of the page is a major version or an approved minor version that is scheduled to go live in the future.
- No save conflict has happened.
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.
Potential problems related to Quick Deployment
Possible Problems when enabling a quick deploy job
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:
- Disable the quick deploy job
- Ensure that the user has rights to update the property (e.g. by adding him to the site collection administrator group)
- Enable the quick deploy job again
Possible Problems when selecting incorrect content
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.
Quick 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.
Quick 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.
Possible Problems with backup/restore
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 method is very effective to resolve this issue:
- Manually start all quick deploy jobs for the site collection to ensure that the quick deploy items list gets cleared from valid entries
- Disable all quick deploy jobs to ensure that the ids of the valid quick deploy jobs are removed from the quickdeployjobs property in the property bag of the source site collection
- Delete the quickdeployjobs property using object model (it will be recreated when enabling the quick deploy jobs later) (see code sample below)
- Delete all entries in the Quick Deploy Items list (only invalid items should be in the list by now) either manually or using object model! Important: do not delete the list itself! Only delete the items in this list!
- Reenable all quick deploy jobs for the source site collection which will recreate the quickdeployjobs property and add the unique ids of the valid quick deploy jobs back to the property.
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: