What is content deployment?
Content deployment deploys content from a source SharePoint Server 2010 site collection to a destination site collection. The complete source site collection can be deployed, or a subset of sites can be deployed. Content deployment, which is incremental by default, deploys only changed pages and related assets (such as images). A Quick Deploy feature supports the deployment of a single page by authors.
Content deployment jobs type
· Incremental
· Full
Content deployment security
· All Deploys all security-related information together with the content. This includes role definitions, access control lists (which map users and roles to the content they have permissions to view or edit), and users. This option is useful if the same set of users has the same permissions on the source and destination server farms. For example, when you deploy from an authoring server farm to a staging server farm, this option might be best because the same users need access to both sets of content. All is the default option.
· Role Definitions Only Deploys role definitions and access control lists that map the roles to the content but do not deploy users. In this option, the same roles apply in the source and destination server farms, but different users can be assigned to those roles in each server farm.
· None Deploys no security information. Security on the destination security farm must be managed by the administrators of that server farm by assigning users and roles to the farm's sites and content. For example, when you deploy from a staging server farm to a corporate Internet presence site, this option helps ensure that the security of the two server farms is managed separately.
How content deployment works ?
Description
1. When a content deployment job starts, it checks the change token to determine when the last successful content deployment job was run. If the length of time between the last successful content deployment job and the current one is so long that the stored change token is no longer valid, it will run as a full content deployment job, not an incremental content deployment job.
2. Next, the content to be included is exported to a temporary directory on the source server, where it is packaged into .cab files for transport, you can use the Microsoft.SharePoint.Deployment.SPExport namespace from the SharePoint Server 2010 API to export content.
3. After the files have been packaged into .cab files on the source server, the files are transported to a local temporary directory on the destination server via HttpPost.
4. During import, the .cab files are extracted to a temporary directory on the destination server, and then they are imported into the database. Any site collection features that are required by items that were included in the import are activated, and scheduling is then configured for the imported items,Alternatively, you can use the Microsoft.SharePoint.Deployment.SPImport namespace from the SharePoint Server 2010 API to import content.
5. after the import has finished, it returns either a Success or Failure status to the Central Administration server. If the import status is Success, the change token is saved. If the import status is Failure, the change token is discarded.
Understanding Change Tokens
The Change log is stored in the EventCache table of the content database. This table stores the information about all content changes in the content database. Each entry in the Change log contains among other things the following information:
1. A sequential number (Id) identifying the row in the event cache table
2. The timestamp (EventTime) when the change has happened
3. The type of the object (ObjectType) that has changed
4. Identification (one or multiple IDs) of the object that was changed
5. URL to the object that was changed (if the object has a URL)
6. The type of modification (EventType)
About the Change Token
Each time the change log is queried for changes, it returns the changes together with a Change Token which corresponds to a database entry up to which the querying application has been synchronized. This change token is of the format Int1; Int2; Guid; Time; Int3.
Example: 1;1;df6828cf-c303-453e-9eb6-e733f85611ac;633782543234470000;1510 Where,
1. Int1: Contains version information for the change token. Currently this value is always 1.
2. Int2: The scope the change token has been requested for. For example, if you ask for changes in the site collection this value will have the scope "Site". If you request changes for a sub site, it will contain the scope "Web". See the following table for possible values. Related to content deployment and the underlying API, this value is always 1 as content deployment always generates a change token with a scope of the whole site collection.
3. Guid: Guid of the object the change token belongs to. If the change token was requested for a site collection this will be the Id of the SPSite object.
4. Time: Timestamp (in ticks) of the change the token belongs to.
5. Int3: change number in the event cache table the change belongs to.
No comments:
Post a Comment