Incrementally Update a Deployed UPK Player (using XCOPY)

Publishing incremental updates to UPK content will usually be faster than publishing to a new location due to UPK's ability to incrementally publish the content that has changed. However, it's not very common for UPK Authors to publish directly to the production environment. This means that most authors need to publish content to a staging location and then move the content from that staging location to the production location. In this post, we'll look at how we can deploy content from a staging location to a production location by incrementally updating a UPK Player package using the Windows command XCOPY. The basic principles discussed here can likely be applied to similar file copy utilities. If you do use a different utility to perform a similar task, please let us know in the comments.

First, we will identify the the staging location where content is published and the production location where content is deployed. The locations I'll use for my examples are:

Staging location: "C:\staging_location\Publishing Content\PlayerPackage"
Production location: "Z:\production_location\VirtualDirectory"

Now, we will choose the XCOPY options. Below is a list of the XCOPY options we've selected for the purposes of this example:

/D -- used without a date specified to copy only the newer files. REQUIRED
/E -- copies directories subdirectories, including empty ones. REQUIRED
/C -- copies even if errors occur. OPTIONAL
/F -- displays full file names. OPTIONAL; Useful if you log the results.
/H -- copies hidden and system files. OPTIONAL; Probably not necessary, but just in case.
/R -- overwrites read only files OPTIONAL; Probably not necessary in most situations.
/Y -- overwrite files without prompting. REQUIRED

Next, we will construct the XCOPY command using the options. In the example below I've used all of the options, but feel free to drop any of the options marked as optional above. Note the options can be consolidated with a single forward slash as I've done in my example:

xcopy "C:\staging_location\Publishing Content\PlayerPackage" "Z:\production_location\VirtualDirectory" /DECFHRY

That command will work, but instead of typing this out each time we want to update the production location with new content, we'll use a batch file. The first few lines of the batch file will establish variables to hold the locations of the source (staging_location) and destination (production_location). This allows you to easily change either location without rewriting the entire batch file.

The first variable, 'source', will need to be the PlayerPackage folder in the staging location where the UPK Authors publish the content. To establish this variable use the SET command:

set source="C:\staging_location\Publishing Content\PlayerPackage"

The next variable, 'dest' (short for destination), will need to be the folder on the web server where you want the content to be updated.

set dest="Z:\production_location\VirtualDirectory"

Now we will update the XCOPY command, replacing the two locations with the two variables:

xcopy %source% %dest% /DECFHRY

Your entire batch file should look something like this:

set source="C:\publisheded_location\Publishing Content\PlayerPackage"
set dest="Z:\mapped-drive-to-web-server\virtual-directory"
xcopy %source% %dest% /DECFHRY

Save the file and you're finished! When you execute this batch file, it will update the files that have changed since the last time the content was published, significantly reducing the time it takes to deploy your UPK content.

Additional considerations

  • When this batch file is manually executed a DOS window will appear and display the files that are being updated. Once the XCOPY completes, the DOS window will disappear.

  • You can also have this batch file launched periodically using a scheduled task. You may even want to coordinate this with a scheduled command line publishing process. For example, you could have a scheduled publishing occur on a Friday evening. Have the content reviewed on the staging server on Monday and have the xcopy batch file scheduled for a Wednesday.

  • There is a way to perform this content deployment process with very little downtime. Consider maintaining two identical folders of content on the production environment. This will allow the content to be incrementally copied to the folder on the server which is not currently live. Once the copy has finished, switch the virtual directory to the updated folder.

  • Consider writing the results of the batch file to a log file along with the start and end times to track your updates.

  • Using this method to update content can make it easier for a System Administrator to empower a UPK Author to deploy content. The UPK Author would be given a way to start this batch file without requiring the System Administrator to be involved each and every time content needed to be updated.

  • XCOPY does not offer a way to remove unused files. Consider updating your batch file to remove files from the destination which are not present in the source. Alternatively, use more advance file syncing software to keep the destination folder free of unnecessary files.(Thanks, Graham.)

Good blogpost and nice if you are used to copy and paste between the source location (e.g. My Documents folder) and the target share (the content directory on the web server). However, another option is to use the commandline publishing option, so you can directly publish on the server via a batch file. Our users can't open a fileshare, because the web server is hosted via the intranet. I don't like FTP as a publishing option to this web server), however, if you use FTP, I suppose there are also tools that can copy only changed files as well. We use a .NET application we wrote to upload a playerpackage via z ZIP file. The zip file is extracted on the server itself. To upload with ZIP is much faster than via FTP or UNC (file share) because the player consist of many small files.

Posted by Sjoerd de Vries on April 17, 2011 at 10:07 PM PDT #

Hello Sjoerd, Thanks for great comment. UPK's command line publishing is a great feature. Publishing on the server with the command line publishing feature will require a UPK client and a supported version of Word for publishing document outputs (including Print It! mode.) Many customers also have security restrictions which prevent Word (or similar applications) from being installed on the server. And you are absolutely correct that transferring a single ZIP file is much faster than a folder full of files. Best regards, Marc

Posted by marc.santosusso on April 18, 2011 at 09:59 PM PDT #

Thanks for this post but how does this technique deal with files that exist in production that no longer exist in the staging area? After the copy these files will still exist in the target producton area.

An additional "delete files no longer needed" step needs to be introduced after the XCOPY. Or use something like robocopy with a /purge option ( to perform a source to target synchronisation.


Posted by Graham on June 23, 2011 at 10:47 PM PDT #

Hello Graham,

Thank you very much for the comment--you raise an excellent point. You're absolutely correct that this approach does not address removing files which are no longer used as XCOPY does not provide a way to remove files (as far as I'm aware.) I find that UPK customers who are incrementally updating content are usually adding or updating existing content and rarely removing content.

The goal of the post was to provide a starting point for customers who want to reduce the time it takes to deploy small incremental updates in a published Player package. Also, I wanted to highlight an approach which: A) uses a tool that everyone has available to them; and B) does not have a huge learning curve. In a Windows environment, XCOPY seemed the obvious choice despite its limitations. I'm sure there is other magic that one can perform with DOS commands that will remove files from the destination that are not in the source. A quick look on the internet suggests that the pushd and popd commands might be good starting points if the are used recursively. This certainly falls into more advanced territory than I wanted to tackle in this post.

The good news is that any files that are no longer used should not have any impact on the published content. The size they consume should be negligible. If the content is so vastly different that the size of the orphaned files is significant, the process of using XCOPY was likely not the right approach for deploying the content. That is to say, deleting the destination folder and copying the new source would be the better approach in cases where a significant amount of content has been removed.

Robocopy seems like a worthy tool to synchronize folders and I welcome comments from anyone who has used it to assist in the deployment of UPK content.

Thanks again for your comments. I'll update the post to include a bullet in the "Additional considerations" section.

Best regards,

Posted by Marc Santosusso on June 24, 2011 at 12:30 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

The authors of this blog are members of the UPK product development, management, and marketing teams. On this blog, you'll find UPK news, tips/tricks, upcoming events, and general information on UPK - the easy-to-use, comprehensive content development, deployment, and maintenance platform for increasing project, program, and user productivity.


« July 2016