Applies to LANDesk Management Suite 9 SP2 and greater
LANDesk Content Replication can be used to keep files updated and current throughout an enterprise. The process uses a LANDesk managed node assigned as a Replicator to move files from configured Sources to target Preferred servers. There are several steps in the process and LANDesk uses existing agent functionality and tools to perform the replication.
For more information on Content Replication and Preferred servers see : Using LANDesk Content Replication
Creating the File List
The first step in a replication task is started is creating the file list. The Replicator will start with a Source and replicate it to all assigned Preferred servers. The Replicator will first compare the files and hashes that are on the Source with the ones that are already on the Preferred server. Any files that are missing or where the hash doesn't match will be replicated to the Preferred server.
The manifest of files is only created every 30 minutes.
The replicator.log will show the following to indicate if it recreated the manifest or not:
"Manifest file is old or missing so will be re-generated"
or
"Manifest file will NOT be regenerated."
Download the Files
Once the Replicator has identified the files that need to be replicated to the Preferred server, it will download the files needed to the cache on the Replicator. This will be located in C:\Program Files\LANDesk\LDClient\SDMCache. The download will use the bandwidth throttling settings configured in the Replicator settings. All files that are downloaded will remain in the cache of the Replicator for a period of time. This time can be configured as part of the Replicator settings.
Push the Files to the Preferred server
The Replicator will next use the write credentials configured in the Preferred server settings to write the files to the Preferred server. The Preferred server must have a UNC share in order for the Replicator to write to it. The Preferred server can also deliver files to clients via HTTP, but UNC must be available for replication to work. For each files that is copied to the Preferred server the Replicator will write a hash file. The file contains details about the file including the hash. This file is written to a custom directory named LDHashDir that is created in each folder and sub-folder. The LDHashDir will contain a special hash file for each file that was written to the Preferred server by the Replicator.
Ending the Job
If the Replicator is configured to continue until the job is complete, it will copy all the files needed to a Preferred server, then move on to the next Preferred server assigned to the same Source. The Replicator will download any additional files needed for the subsequent Preferred servers. Once the first Source has been replicated to all assigned Preferred servers the Replicator will move on to the next Source.
If the job is configured to end after a certain amount of time, it will stop when the set time is reached. The time starts when the job starts. For example, a job is set to start at 8:00 PM and run for 4 hours. If the job drifts a little and starts at 8:30 PM, it will not end until 12:30. When the job reaches the maximum time period it will stop replication right where it is. If it is in the middle of a file, the partial file will remain on the Replicator.
Resuming a Job
There are a variety of reasons that a job may be interrupted or stopped before it is complete. It could have been manually stopped by the administrator, maxed out the allowed duration, or the Source, Preferred server or Replicator could lose power or network connectivity. LANDesk will resume the replication at or near where it left of the next time the replication job runs. Exactly where the job will resume depends on why the job stopped.
Manually Stopped
If the job was manually stopped by the administrator selecting Disable task in the LANDesk console, the job will resume right on the file that it stopped on
Ran Out of Time
If the job was stopped because it got to the maximum allowed duration, the job will resume right on the file where the job stopped.
Preferred server or Source Becomes Unavailable
The Replicator will update the core with the most current status and resume within a few files of where it stopped.
Replicator Becomes Unavailable
The Replicator frequently checks in with the Core server and sets a checkpoint every 200 files. If the Replicator loses power or crashes, the next replication job will resume at the most recent checkpoint that was sent to the Core server. For example, a Replicator gets to file 200 and sends a checkpoint to the core. Then it gets to file 375 and the power goes out. The next time the job runs, it will resume at file 201.
For more information on Content Replication and Preferred servers see: