Support Tip: Using ZENworks Bundles to Backup User Data.


I was recently asked how ZENworks can be used to assist in backing up user data from PCs.  

Though ZENworks is not a backup solution, I did offer a few options.

One option is to take an image of a PC and use file explorer to extra out files if needed.  This however is far from ideal as it could not be run on a regular basis and restoring the data would be quite tedious.

A more viable and robust option is to use ZENworks Bundles to back up data from User Profiles and potentially other locations on a device to a network location.

(Note: Roaming Profiles and Folder Redirections are also an option, but both of those present challenges as well.  This could be useful for those who do not wish to pursue those or similar options.)

The sample bundle will use:

  • Robocopy to copy and mirror data so that only changed data will cross the wire.
  • Robocopy options are used to exclude non-data type files such as ISOs, MSIs, and EXEs.
  • Robocopy options are used to exclude HUGE files, which presumably are not data, even if not a specifically restricted data type

The sample bundle will

  • Ensure a user is logged in because we will be backing up user data to preferably the user's home directory where only they will have access to their data.
  • Ensure the device's Primary User is Logged into the device so that if a user logs into someone else's device, the backup of that profile is skipped.
  • Ensure that if a user has multiple primary devices, their data is backed up from multiple devices, but is maintained for each device.
  • Ensure the bundle will only run on the Corporate Network to prevent uploading data over the internet since that bandwidth is limited and access to the home directory would likely not be accessible anyway.
  • Scheduled with the lowest possible priority order and randomized on devices to minimize any potential spikes in network traffic.
  • Run Quietly so the user does not see it running.


The first part of the bundle I will show is the Single Action itself, which is set to run as "Logged on User" on the Advanced Tab, though that is not displayed.

  1. A Batch File Script action is used because it will run hidden and we do not want to see any user interaction
  2. In the example, three distinct source folders under the user's profile are selected.  Additional folders or alternate locations outside of the user profile could be selected.
  3. The Variable %TargetLocation% is defined in the bundle (shown later) and in my example is a specific UNC Path where the Home Directories are stored.  If there are drive letters mapped to the home directory, then that could be used in lieu of a UNC path.  If there are no drive mappings and there is not a common UNC path for all home directories, one could get any and uses added scripting to get the home folder of the logged-on user.  If someone needed help with that, I could address that but will avoid that complexity for now.
  4. The %ComputerName% Folder is added to ensure data from different devices is not mixed and the "Mirror" option does not delete needed files not stored on both devices.  Consider using the path \Backup\%computername% in the production bundle for the target folder, but in my example, I wanted to minimize the length of the command line for visibility.
  5. The Robocopy parameters after the source and destination paths do the following:
    • /MIR: Mirrors the destination directory with the source, including removing files no longer in the source.
    • /E: Copies subdirectories including empty ones.
    • /MAX: Any files over 2,000,000 Bytes are not copied.  This is an optional parameter than can be removed or size limit adjusted.  Designed to avoid copying huge files which may not be corporate data.
    • /R:1  Sets the Retry limit on failed copies to 1 so the script does not hang if it cannot copy any given file for any reason.
    • /xf *.zip *.iso *.exe *.msi  - restricts the copying of the listed file extensions since they may not be data.  File types can be added or removed from the list.
  6. The bundle is set to "Do not Wait" so that the bundle will allow other scheduled bundles to continue run while it runs in the background.
  7. Note: A "Launch" action was chosen instead of an "Install Action" because it is designed to be run over and over.


The graphic below shows how the %TARGETLOCATION% variable can be set in the bundle.  If desired, these same settings can even be set at the Zone Level or other locations so they are shared between bundles and do not need to be redefined.  If set at a higher level, the advantage would be that if the value ever needed to be changed, it would only need to be changed in one location.

Above I define two variables: TargetLocation and TargetLocation2.  My bundle uses the first one which assumes a common UNC path where all user home directories are stored.   The second variable could have been used if drives are mapped to the home directory.


This bundle also has a number of System Requirements Defined that serve various purposes:

  1. The "LogonServer" check will ensure that a user is logged into the device.  This variable does not exist when no users are logged into the machine.  Since the script is copying user data to a user location, we will want to ensure a user is logged into the device.
  2. The "Primary User is Logged IN" is an optional requirement we can use to ensure that is someone just briefly logs into a random computer, it will not backup any data from that device.  A user, however, can have multiple primary devices such as their Desktop and Laptop.
  3.  "Configuration Location" can be used to ensure devices do not try and run from an offsite location.  The value to check would depend on the locations configured in one's environment.


On the Summary Tab, I enabled bundle ordering and gave the bundle the lowest possible priority so it ran after any other scheduled bundles.


The Schedule I selected for this example is below but not the only possible schedule:

I chose to set the schedule for this bundle to run randomly between 9am and 2pm.  This would avoid heavy traffic at the assumed peak period of an 8am start time and spread it out over a period of 5 hours to avoid any spike in network activity.  This bundle is also set to "Process Immediately" if it cannot execute on schedule to catch any users who may work usual hours preventing the bundle from running during the expected hours.

Note: The bundle is also assigned to users instead of devices as another way to ensure it does not try to operate without a user logged in.

Above is a copy of my sample bundle.  At a MINIMUM, the  %TargetLocation% variable would need to be updated to match a valid value in your environment.

Many other settings could be changed to work best in your environment.  Hopefully, even if this bundle itself is not useful, it idea presented in the bundle could be useful in other bundles.

More Robust Example of showing how to only a bundle under certain conditions such as if a user is or is not logged in or perhaps only if a user's device is or is not locked.

This bundle makes use of variables, but variables can be used in many other instanced.  The following article is a much more expansive article on the use of variables.


Configuration Management
Comment List