This article explains Version Chaining and associated Policy configuration/ operation designed to support flexible Version management.
SSProtect maintains distinct version history for every managed item*. Each time you securely access content, the associated item Version is incremented (on Close). You can view this progression by navigating to the Managed Files/Restore display from the :Foundation Client's icon in the notification tray. From the default Hostlist display, choose a managed file then Versions... for details:
* - Version history, available in Reports, does not currently apply to protected Email content.
New Instances or Continued Versions
If you copy a managed file, rename it, then open it for editing, what version does it carry on close? There are valid reasons to maintain a single Version Chain with the renamed/ moved file, and also valid reasons to create a new managed item instance tracked independently, starting with Version 1.
SSProtect supports both cases with Version Chain Policy that determines operational behavior.
Version Chain Policy
Rather than prompt (with options) each time you access an existing item that has been copied/ moved or renamed, SSProtect uses an optional, advanced Version Chain Policy defined by settings in the License and Components dialog. This reduces workflow interruptions by allowing you to predetermine the way Versions and managed instance tracking gets handled.
Version Chain Policy Impact
By default, vChain Policy does not enable Split vChains. As a result, when you rename and/ or move an instance of an SSProtect'd file, opening/ closing maintains the same Version Chain that existed before, bumping the Version by 1 and maintaining the history of filenames and locations associated with the managed item's progression.
With vChain Policy, you can choose whether or not to retain this default behavior or instead enable Split vChains. With Split vChains, accessing a renamed SSProtect'd item then closing, "splits" the Version Chain, creating a new, independently tracked item starting at Version 1.
vChain Policy further allows you to determine if Split vChain operation applies to move operations rather than only rename operations.
NOTE: Audit history is managed by :Assess, a :Foundation Component active for all Accounts.
Version Chain Policy is not applied when accessing shared content. More often than not, shared content is transferred from the Owner/ Creator to a sharing peer on another host computer (but not always). As a result, shared item placement doesn't typically match the location of the original item (in name/ path), but it doesn't make sense to create a new Version Chain for this case. As with any other access operation, filename and path information is retained with the activity record and, as a result, displayed in resulting Reports.
Version Chain Policy Configuration
Modify vChain Policy using controls in the License and Components dialog, which you can display from the notification icon's context menu of the same name:
Configuration is available to Privileged Users - an Organization Administrator, Delegate, or Individual Account holder.
Enabling Split vChains
Split vChains, when checked, enables Policy association for an Organization but does not actively enable the association for existing Accounts. As such, existing Account behavior is unchanged until a Privileged User navigates to Administer Users, edits a target Account, and checks Split vChain before saving changes.
This differs from the results of creating a new Account while Split vChains are enabled: new Accounts inherit the enabled association by default. You can visit each Account and disable Split vChain (from Administer Users) after creation/ Validation.
Further Split vChain behavior is described below.
RECOMMENDATION: Though :Assess Reports specifically denote activities that Split the Version Chain, inconsistent application of these rules may complicate Incident Response and/ or Forensic review of past proceedings. For this and other reasons, we recommend consistent application of vChain Policy to all Organization Accounts.
Split vChains for Individual Accounts
The procedure is essentially the same for Individual Accounts: Navigate to the License and Components dialog to enable Split vChains, though in this case you do not have to independently enable/ associate configuration with your Account: Individual Accounts are automatically configured to utilize the modified setting (different from the way existing Organization Accounts are handled).
To temporarily disable Split vChains, for your Individual Account, navigate to the Account Configuration display using the notification icon's context menu, then uncheck Split vChains.
The Move Splits option is only viable when Split vChains is enabled. Move Splits, when selected, applies Split vChain policy when items that are moved or copied to other folders - even if the result maintains the same filename (but different path). When not selected, Split vChain execution does not apply.
Changes to this option immediately apply to all Organization Accounts operating with Split vChain enabled (or your Individual Account): Refresh Login is not required.
Exclusive Hostlist does not require Split vChain operation, and impacts the Managed Files Hostlist that shows managed content for an Account's Host Computer. Display this interface with the Managed Files/ Restore menu item available from the notification icon's context menu.
This setting is most suitable when Split vChains is not Active, as operation will then have a more direct and visibly related impact to the result of working with files that change names and/ or locations while maintaining the same Version Chain over time.
This setting is also helpful when working with multiple folders that contain the same managed file.
When Exclusive Hostlist is chosen, Hostlist enumeration of managed files displays the last-used instance of any item in a Version Chain, even if a previous version carries a different filename and/ or folder. When de-selected, the Hostlist will enumerate and display both items, which can be confusing in certain use cases.
Starting in Version 10.6.4, you can toggle this setting from directly within the Managed Files/ Restore Hostlist using the Excl vChains checkbox. This immediately adjusts the resulting Hostlist's Working Set to reflect the chosen setting.
NOTE: Changes to the Exclusive Hostlist setting go into effect immediately, and are retained in the License and Components Dialog for backward compatibility.
Remove with Exclusive Hostlist
When performing Hostlist Remove operations, you may notice that new items appear when the list is automatically refreshed. These are the previously-suppressed items that had File IDs matching those you Removed. As such, you may need to repeat the operation several times to achieve your desired result.
NOTE: Items with the same name, but different Version Chains, will be displayed whether or not you're using the Exclusive Hostlist option. Adjust this setting based on the way you use related Version Chain Policy controls, as that will have an impact on the frequency of name collisions and a need to either isolate Version Chains or show multiple instances.
Examples for Version Chain Policy Impact
The use of Version Chain Policy controls can be confusing, especially to those unfamiliar with change management and/ or version control systems. As such, this section shows you, by way of example, exactly how vChain Policy affects operation.
If you wish to follow along, it may be prudent to create a new test Account for this (and related) activities. If you're a member of an Organization but are not a Privileged User, you will need to create an Individual Account since you won't have the ability to enable Split vChain for your Account.
To create a test Account, from your existing installation, Refresh Login... from the notification icon's context menu, then choose Create New... in the Login dialog's Profile dropdown. Use the directions in the article, Creating an Account with an email address you won't need for production (gmail aliases work well for these cases).
Remember to Login to your Test Account before proceeding. When finished, you can remove the Profile from your list with insight available in the article, Registering a 2nd Profile.
Default - No Split vChains
Let's start with default Account settings; vChain Policy is not enabled.
First, create a new file, which we'll call vChain-NoSplit.txt, and populate it with some text (you can't protect a 0-length file). From File Explorer, right-click the file and choose, SSProtect Activate to, "SSProtect" it.
Next, view Managed Versions (the Versionlist): Right-click the SSProtect icon in the notification tray, choose Managed Files/ Restore from the context menu, then select vChain-NoSplit.txt from the Hostlist and click Versions.... You should see Version 1 of the file in the resulting Versionlist display.
Return to File Explorer, select the file you created, then ctrl-c to copy the file, ctrl-v to paste. This should create a local copy called vChain-NoSplit - Copy.txt. Double-click the new, protected copy, make a change, then save/ close to re-protect it.
Finally, return to the SSProtect Versionlist and click Refresh: You should see two Versions of the original vChain-NoSplit.txt file. Click Host List.. to display the Hostlist pane: You should see both the original file and the copy. Select the copy then click Versions.... Notice anything in particular? Same data, different instances.
Configure Split vChains
Let's repeat this example with Split vChains:
Navigate to License and Components from the notification icon's context menu. Check Split vChains, then choose Yes to acknowledge the confirmation.
Re-enter your Login Credentials to proceed.
If you're a Privileged Organization User, navigate to Administer Users, select your Account then Edit, check Split vChain, choose Save, then finally OK.
If you're using an Individual Account, use the context menu to navigate to Account Configuration and check Split vChain, then click OK.
To verify that your Account is operating with Split vChains, navigate to the Account Configuration display using the notification icon's context menu, then verify Split vChain is checked. If not, return to the configuration steps to make the necessary adjustment(s).
Viewing the Impact of Split vChains
Let's repeat the progression now that you have configured Split vChains.
Create a new file, vChain-Original.txt, add some content, and SSProtect it to create Version 1.
Return to the Versionlist with the Managed Files/ Restore context menu item, select the protected vChain-Original.txt in the Hostlist, then click Versions... to view the Version 1 instance you just created.
Return to File Explorer and copy this instance to vChain-Original - Copy.txt. Open, modify, and close the protected copy, then return to the SSProtect Versionlist display and click Refresh.
Results Using Split vChains
Notice that, in the second progression with Split vChains, the 2nd protect operation does not create a Version 2 and associate it with the original file, as was the case in the first progression without Split vChains.
You can further verify this by returning to the Hostlist, selecting the 2nd progression's copied file (Refresh if not present), then view its' Versionlist to verify 1 instance of the independently-managed item.
Impact to the :Recover Archive
If you're using :Recover, you'll notice that this setting has a similar impact on the Archivelist (as you may have suspected). Choose Archive... from the Managed Files/ Restore display we've been using for Hostlist/ Versionlist visibility, then note that you there are three instances - one each for the files we created when working with Split vChains and only one for the progression we executed without Spit vChains.
Displaying the Latest Version
It's important to remember that, when disabling Split vChains, the Archivelist will present the last-used instance for the local host. Because the first progression didn't use Split vChains, there is only one Archivelist entry representing the last-used instance of that progression - which from our progression should still be vChain-NoSplit - Copy.txt.
You can quickly verify this behavior by making a change to vChain-NoSplit.txt content then performing Refresh in the Archivelist display: The listing will change, effectively replacing the copied instance with the noted file. Further details are available in :Assess File Sequence/ Detail reports.
Exclusive Hostlist Impact
If you now set Exclusive Hostlist then revisit the Hostlist pane, you will for the first progression (without Split vChains) see only one result, the latest instance you modified (either vChain-NoSplit.txt or vChain-NoSplit - Copy.txt) which matches behavior to that observed using the Archivelist for the same file(s).
Note, however, that you disable Exclusive Hostlist and return to the Hostlist display to see the original two files. This of course will not impact the Archivelist, which will display the last actively accessed instance.
As such, as you can see, Exclusive Hostlist serves as a display filter, and does not modify the underlying data driving Hostlist enumeration.
Impact of Release/ Re-Protect On Version Chains
In general, if you Release Protection for a managed item then immediately carry out an SSProtect Activate operation (with or without interim changes to file content), SSProtect will maintain the pre-existing Version Chain.
In fact, even if you rename and/ or move the file, Release Protections, perform Refresh Login, make changes to the file, then perform SSProtect Activate, SSProtect maintains Version Chain integrity as per Policy. This works with any type a file - one you, "own", one from an Organization Peer, and even one from a Third Party Trust.
As a general rule of thumb, if you cannot utilize Managed Access with In-Place Encryption and must instead Release/ edit/ (re)Protect, if you want to maintain Version Chain Policy processing integrity, rename and/ or relocate the target before performing Release then make certain you (re)Protect the target file of the same name in the same location.
Stated another way, when you Release an item then rename and/ or relocate it, subsequent Protect operation foregoes Version Chain Policy and creates a new progression starting at Version 1. This can be used to create an, "owned" instance of existing content you wish to independently manage.
You can search this site for more information on various topics, or use this link to submit a specific request. You can also send email directly to firstname.lastname@example.org, and our staff will respond to your needs as soon as possible.
This article was updated w/ v10.7.1 of the :Foundation Client