SealPath File Server is a version of SealPath Desktop that offers the ability to run as a resident of a file server and continuously protect documents in shared folders. Users that access “protected” shared folders in a file server can automatically protect the documents moving them to the folder.
The user can download SealPath File Server from:
Once downloaded it will ask for execution permissions:
After accepting the Terms and Conditions of Service, the software will be installed. The software checks installation pre-requisites such as having .Net4.5 framework installed. If you don´t have these components installed the software will automatically install them.
After this, SealPath File Server will request the credentials of the user that will run the service. This user is needed so that the protection service works correctly. Please don´t try to run the service with a local or network service. This user must be a local administrator user.
This service will be running continuously. It is necessary to install SealPath File Server in a server that is up and running 24x7, because it will be continuously monitoring what the users are storing in the “protected” shared folders to protect the documentation they leave on them. In the case you work with an array of disks not directly linked to a File Server, it will be needed that SealPath File Server to be installed in a server that is running 24x7 with access to the shared folders.
Once the installation process has finished, you can run the app from the start menu -> SealPath File Server -> SealPath File Server Desktop. The windows session has to be initiated with the same user that the FileServer service is running with. Enter the credentials (email and password) of an administrator of the SealPath Service (for example, the credentials used to enter in the Administrator’s Web Control Panel or a delegated admin created in this web console).
Let`s remind the users’ requirements to run SealPath FileServer:
- FileServer service must run with a user who is local administrator.
- The Windows session where the FileServer console (FileServer Desktop) is going to be executed, has to be initiated with the same user that the service is running with.
- The user who validates in FileServer Desktop must be an administrator of the organization in SealPath. The user should also be a protector user in the organization.
If the service cannot be installed or cannot start automatically, the program will be uninstalled. The following message is shown:
Possible causes of this installation error are:
- User’s incorrect credentials for the account which the service is running with.
- User without permissions. Besides being local administrator, the user should not be in the “Deny logon as a service” policy setting. Installer enables the “Logon as a service” setting, but it is superceded by the first policy setting if it were defined for this account.
After an installation error, it has to be assured that the user’s credentials are correct before going on, that the user who is performing the installation is a local administrator and that the account of the service does not belong to the policy setting “Deny logon as a service”.
The general operation of SealPath File Server is similar than SealPath Desktop and it can be consulted in section 5 of the Sealpath user and administration guide. This section focus on the explanation of SealPath File Server added functionalities, so only protected folders management and some configuration files will be addressed in this document.
To create a protected folder you only need to click on the “folders” menu in the main screen. Click on button to create a protection rule for a folder.
The parameters you can configure for every rule are:
- Activate: Checkbox that shows if the rule is enabled or not.
- Name: Name for the rule in the list of rules.
- Folder: Select the folder you want to protect in the hard drive.
- Recursive: Shows if you want to protect folders recursively.
- Protection: Assign one of the existing protections to the folder.
- Extensions of excluded files types: If you want to exclude some kind of document from the protection rule.
The new protection rule will be shown in the list of protection rules in the folders menu. From this list you can edit rules, create new ones or remove existing ones.
The documents the user stores in the folder will be automatically protected.
In the automatic protection operations within the folder it is possible that some events happen and SealPath Desktop alert you about that. An example can be seen in the following figure.
Clicking on the hyperlink “Show” you will see the list of events where you can see the reason behind the event and take actions. The events can happen because we have stored in the folder documents protected with other protection and you don´t have Full Control over that protection to re-protect the documents with a new protection.
Once you have reviewed these events, the red alert in SealPath Desktop will not be shown until new events appear.
Main folders alerts
The main folder alerts that SealPath File Server can show are:
- The document is already protected. You do not have permissions to change the document protection.
- Error protecting the document. The document may be locked by another application, or the current user is not authorized to access.
- The folder does not exist or is not accessible.
- Error protecting the file. Failure downloading the file from Sharepoint.
- Error protecting the file. Failure uploading the file to Sharepoint.
SealPath File Server allows the user to edit all fields that are set when she creates a protected folders.
SealPath File Server allows the user to edit the protection policy that has been assigned to a rule. When a protection policy is changed, the files inside the directory and subdirectories (for recursive folders) are protected again (with the new policy protection). SealPath File Server allows the reprotection of documents that has been copied (or moved) that are protected with a different (than the current folder) protection policy. The previous is allowed only if the folder has had recently assigned the current protection policy of the copied file.
Any change that occurs in a folder causes the verification of all documents in the directories and subdirectories (for recursive folders) to determine if the documents are protected according to the instructions in the folder.
Let's say a folder goes from inactive to active. When this change occurs is necessary to review the documents in the folder as it may contain some new document that was introduced when the folder was inactive and need to be protected. The same can happen when a folder goes from not recursive to recursive.
SealPath File Server and Desktop lets the user to delete protected folders. Simply select the folder you want to delete in the Folder tab and click on the delete button. SealPath File Server includes an option to unprotect documents when the user deletes a protected folder. To unprotect documents is necessary to tick the unprotect documents box in the folder deletion confirmation window. You can see an example in the following figure.
Creating rules below other rules
Suppose that a rule was applied recursively to a folder. The files in this folder and all the subfolders below it were protected with the protection defined for the rule.
Now you want one of the subfolders to have an automatic protection that is different from the one that was established in the top folder. As SealPath FileServer does not reprotect by default files that are protected with a policy different from the one defined in the rule (in order to avoid that anyone can protect freely moving the protected files from one folder to another), if it is established a different policy in this new rule, the files under this subfolder are not going to be reprotected, they will continue with the policy defined in the parent rule.
In order to allow policy changes inside a rule, there is an exception for the behaviour described in the paragraph above. Each rule stores a cache with the last 5 protection policies defined in the rule. If the system detects that the file is protected with a policy that is inside the policy cache of the rule, the file is reprotected with the new policy associated to the rule. Thus, when the administrator changes the rule policy, the system detects that the files in the protected folder have a policy that was applied by this rule in the past and reprotects automatically the files with the new policy.
Following this logic, when a rule is created in a subfolder below a folder that has a different rule, the first step that has to be done is to define as protection policy of the new rule the same policy of the parent folder. Once this configuration is accepted, the rule is modified to assign the policy that actually wants to be applied. The system detects that the files are protected with a policy that was already associated with the rule (the cache will have only one element, the first policy, that is the policy of the parent rule) and reprotects automatically the files below this subfolder with the new policy. Therefore, defining the policy of the rule of the top folder makes it be stored in the historical cache and allows the files to be reprotected.
Rules handling via PowerShell Rule Manager
It is a tool that allows you to manage folder protection rules through PowerShell commands.
The functions of this PowerShell commands allow you to make the following actions:
- Creation of new rules.
- Enabling and disabling rules.
- Deleting rules.
- Copy of protection rules.
- Export rules to an Xml file.
- Import protection rules from an Xml file.
- Backup copies of the rules and restoring the list of rules from the backup copy.
A more detailed description of the installation and functionalities of PowerShell Rule Manager can be found in the document "SealPath PowerShell Rule Manager - Operation Guide".
Automatic rule export as a backup
Every time a rule is added or updated, the list of rules in SealPath FileServer is exported to a file. The file is located in the "Powershell Rule Manager" tool directory, "%ProgramFiles%\SealPath Technologies\SealPath File Server\Tools\RulesManagerPowerShell". The name of the file in which the rules are exported is "RulesFoldersExportAuto.xml".
This file is generated as an automatic backup of the automatic protection rules. The rules are stored locally in the file "... rules.data" in the local profile of the user with whom the SealPath FileServer service runs, in "%localappdata%\sealpath". If for any reason this file is deleted or damaged, the administrator can recover the rules defined by importing this file.
This import is done with the "Powershell Rule Manager" tool. The "Set-ImportRules" command imports the rules present in this backup file. The default path that this command takes is "%ProgramFiles%\SealPath Technologies\SealPath File Server\Tools\RulesManagerPowerShell". This command searches files with name "RulesFolderExportAuto.xml" or "RulesFoldersConfigExport.xml" in this directory. The "-pathFile" parameter allows you to set a different route. If no file is found with one of those two names in the defined folder (or in the default directory if this parameter is not used), an error is returned telling that the rule file to be imported has not been found.
SealPath File Server allows the user to create protected folders that points to Sharepoint libraries and folders (2010, 2013, 2016 and Office365). There is no difference between a Sharepoint folder and a local folder in the creation process, the same functionality is offered for both of them. Below is a figure illustrating the creation of protected folders that point to Sharepoint.
Alfresco CMISS Folders
To add a rule with Alfresco CMISS it is necessary insert the SMB address of the directory. If this address is within the “root” parameter, will be treated as such.
Note: The user with start the SealPath service must have privileges in the Alfresco SMB / CIFS.
Sealpath File Server has a set of configuration files that allows to adjust its internal operation. Those configuration files allows to adjust parameters related to the concurrency, the memory management, Sharepoint connections, cache administration, logs administration among others. This section focus only in the parameters related to the SealPath File Server.
In this configuration file some parameters that determine the correct and optimal behavior of SealPath File Server are set. The parameters are set using the <add> tag, it has to attributes: one is a key and the other represent the value.
<add key="CheckRuleDirectoriesDelay" value="120"/>
This file server parameters can be classified in four categories: cache management, directory management, files protection and rule management.
- RuleLogSize: Max log size.
<add key="RuleLogSize" value="250"/>
- RuleLogTime: Max time(days) that a log can stay in a rule.
<add key="RuleLogTime" value="15"/>
- UpdateRuleViewDelay: User interface actualization time(seconds). For larger values the protection result will be showed slower. However if the value is very small you could load the processor with unnecessary updates. It is recommended that the value is between 5 and 10 seconds.
<add key="UpdateRuleViewDelay" value="5"/>
- PolicyHistoricalSize: Number of elements that can stay in the policy historical registry of a rule. For a larger value the policy historical registry will have more elements for each rule, so the user could lost the control of which files can change their protections using this folder.
<add key="PolicyHistoricalSize" value="5"/>
- EraseOldCacheDelay: Cache loop elimination period (minutes). The cache is eliminated periodically, but only is eliminated the cache that is no longer useful. For a larger value there will be a greater chance of being sub using memory however if the value is very small you could load the processor with unnecessary tasks.
<add key="EraseOldCacheDelay" value="1440"/>
- CheckRuleDirExistenceDelay: Rule directory existence period (seconds) used to verify the existence of those directories. A massage will be shown if the directory does not exist or is unreachable.
<add key="CheckRuleDirExistenceDelay" value="60"/>
- CheckDirRetryDelay: Each time the contents of a directory or subdirectory (that is being monitored) is modified is included in a list of directories that are going to be checked periodically for a certain time. This parameter indicate the period (minutes)in which the directory path is included in a list of directories to be scanned.
<add key="CheckDirRetryDelay" value="1"/>
- MaxTimeRetryDir: Max time (minutes) that can remain a directory in the list of regular verification.
<add key="MaxTimeRetryDir" value="60"/>
- CheckRuleDirectoriesDelay: All directories rules verification period (minutes).
<add key="CheckRuleDirectoriesDelay" value="120"/>
- MaxScanningDirTasks: Max directory scanning tasks. Indicates how many directories can be scanned in parallel. It is recommended this value to be less than the number of cores in the server. For a bigger value the directories could be scanned faster but also increases processor utilization. To set this parameter should be taken into account the MaxProtectingTasks parameter.
<add key="MaxProtectingTasks" value="2"/>
- MaxPendingDirToScan: Max number of directories pending to be scanned. For a larger amount of directory pending to be scanned the memory utilization will be grater.
<add key="MaxPendingDirToScan" value="1000"/>
- SharepointCheckDelay: Period (seconds) for verifying the Sharepoint directories rules. Determines the frequency of the queries to Sharepoint.
<add key="SharepointCheckDelay" value="60"/>
- MaxProtectingTasks: Max protecting tasks. Indicates how many files can be protected in parallel. It is recommended this value to be less than the number of cores in the server. For a bigger value the directories could be scanned faster but also increases processor utilization. To set this parameter should be taken into account the MaxScanningDirTasks parameter.
<add key="MaxProtectingTasks" value="2"/>
- MaxPendingFileToProtect: Max number of directories pending to be protected. For a larger amount of directory pending to be protected the memory utilization will be grater.
<add key="MaxPendingFileToProtect" value="100000"/>
Special settings in the configuration file AppSettings.config
There are three special situations where the default parameters have to be changed in the configuration file AppSettings.config.
- The file cache is deleted and the folders with protection rules has a number of files greater than 15,000.
- A copy of more than 15,000 files is going to be performed in a folder with a protection rule.
- A protection rule is added and it is associated with a folder that has a number of files greater than 15,000 inside.
In any of the situations enumerated above, the following parameters have to be changed in the configuration:
<add key="MaxPendingFileToProtect" value="200000"/>
<add key="UpdateRuleViewDelay" value="30"/>
<add key="CheckDirRetryDelay" value="120"/>
<add key="MaxTimeRetryDir" value="360"/>
<add key="MaxPendingDirToScan" value="20000"/>
<add key="CheckRuleDirectoriesDelay" value="10080"/>
When the number of documentos pending of review/protection is close to zero, the parameters will be returned to their default values.
In this file the Sharepoint connections are set. The user can add as many Sharepoint servers as needed. The configuration of each SharePoint server is added using a Site label as shown below:
<Site url="site" domain="domain" username="user" password="pass" online="false" deleteVersionHistory="false" deleteVersionHistory="false" relyingParty=""
Sharepoint configuration file example:
<?xml version="1.0" encoding="utf-8" ?>
<Site url="https://sharepoint.myCompany.com "
The first Site label that appears may serve as an example of configuration for Sharepoint 2010, 2013 and 2016. The second label is a configuration for Sharepoint Office365. The third one is a configuration with ADFS authentication.
The parameters that can be configured in a Site are:
- url: base address of the Sharepoint library.
- domain: domain name of the user (if she is validated in a domain controller).
- username: account for the connection (it should have Full Control over the folders that are going to be protected)
- password: password of the user for the connection.
- online: true if the Sharepoint is online (Office365) or false if the Sharepoint is on-premise.
- deleteVersions: true if the previous versions of the file protected will be deleted after the protected file is uploaded (recommended a false value).
- relayingParty: for an ADFS configuration.
- isAdfs: whether it is a site with ADFS authentication.
- adfurl: ADFS url.
NOTE: Password can be encrypted with SharepointConfigTool
There could be sites where the files are protected only when certain parameters are found or only after the user has made certain actions, they are not protected before these requirements are fulfilled. There are four parameters that allows to control these conditions. They are defined in the configuration such as:
The meaning of these columns is:
- columnStatus: it is the internal name of the “status” column in Sharepoint. The value of “COLUMN_STATUS_INTERNAL_NAME” should be the same as the internal name configured in the Sharepoint site for the Status column.
- unprotected: it is the internal name of the “not protected” state and it means that the file cannot be protected yet. The value of the parameter “UNPROTECTED_COLUMN_INTERNAL_NAME” should be the same as the internal name configured in the Sharepoint site for the state Unprotected.
- pendingStatus: it is the internal name of the “protection pending” state. The value of the parameter “PENDING_COLUMN_INTERNAL_NAME” should be the same as the internal name configured in Sharepoint for the value Pending.
- protectedStatus: it is the internal name of the “protected” state, not pending of any protection. The value of the parameter “PROTECTED_COLUMN_INTERNAL_NAME” should be the same as the internal name configured in Sharepoint for the state Protected.
The image following shows the configuration of a state column in a Sharepoint site. The values that can be assigned to this column are:
The values of the site configuration, related to the metadata, should be:
This file configures the connections to the Alfresco Cmiss servers. You can add as many Alfresco Cmiss servers as needed. The configuration of each Alfresco Cmiss server is added using a Site tag like the one shown below:
<?xml version="1.0" encoding="utf-8" ?>
The meaning of the site parameters is:
- URL: Address where Alfresco is accessed to the web (URL + port). It is also necessary to specify the Alfresco path.
- ROOT: To get the files is done by CMISS, but protection by SMB. Therefore, it is necessary to address the Alfresco by SMB.
- USERNAME: The username with minimum reading privileges in Alfreco.
- PASSWORD: Password of Alfresco user.
NOTE: Password can be encrypted with SharepointConfigTool
The Sites tag attributes relyingParty, isAdfs and adfsUrl of the SharepointSites.org configuration file are used to configure the SealPath File Server authentication in Sharepoint using ADFS. The relyingParty attribute must contain the Sharepoint identifier that has been assigned in the ADFS configuration. The adfsUrl attribute must specify the URL of the ADFS server.
The endpoint “/adfs/services/trust/13/usernamemixed” must be activated in the ADFS server to allow the correct authentication of the SealPath File Server (for more information about ADFS endpoints visit https://technet.microsoft.com/es-es/library/adfs2-help-endpoints(v=ws.10).aspx)..
Best practices for cloud storage services
SealPath File Server can be used to protect any folder, including a folder that is being shared using a cloud storage service. Most cloud storage services has a similar behavior. The user select a local folder who wants to be shared and everything that is entered in that folder is automatically stored in the cloud and syncs on computers that are connected to the same account.
OneDrive, Box, Google Drive, Dropbox, etc.
To use SealPath File Server in conjunction with one of these services is recommended to install the desired service software on the file server where it is installed SealPath File Server. After selecting the folder you want to sync with the cloud storage service the user can create a protected folder (in SealPath) that points to the shared folder or any of its subdirectories. Thus all that is introduced into the protected folder in any of the computers that are connected to the same storage service account will be protected immediately the service synchronize with the file server.
OneDrive for business
OneDirve for business should be used in conjunction with a Sharepoint library. The basic operation is the same as traditional OneDrive, the use of File Server with SealPath can be done as noted in the previous section. In this context the files should be copied only in the OneDrive folder, it shouldn’t be copied in the Sharepoint directory or library. Copy the files to Sharepoint folder may cause duplicate files, secure files and the corresponding unprotected version, which could result in an infinite protection loop for the same file.
Other possibility, equally valid, is to protect the Sharepoint library (or any of its subdirectories) which is connected to OneDrive. This approach has the advantage that it would not be necessary to install the OneDrive on the same computer where the SealPath File Server is installed.
If the Internet connection is done through a proxy, it can be configured in SealPath FileServer in Options/Proxy.
The communication can be done through the proxy defined for the machine in Internet Explorer or through a custom proxy that is defined here with URL and port (split by “:”).
For both of these options, the following cases can be configured:
- No user authentication required: no validation of credentials is required in this proxy connection.
- Windows integrated authentication: proxy authenticates users through Active Directory. The credentials that SealPath File Server provides for the proxy are the credentials of the account the service is running with.
- Credentials established by the user: proxy authenticates users through Active Directory or through a list of users. The credentials that SealPath File Server provides for the proxy are the credentials inserted in this configuration.
Sealpath FileServer can detect the proxy automatic configuration. The option ‘Automatically detect settings’ gets the configuration through the definition of a file “wpad.dat” in DNS. The option ‘Use automatic configuration script’ gets the configuration in the URL defined in the file ‘proxy.pac’.
If there were a communication failure because of an incorrect proxy configuration, the following message would be written in the log file of the service: “System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at … System.Net.WebException: The remote server returned an error: (407) Proxy Authentication Required”.
To configure and use this product efficiently is necessary to know some relevant aspects of its operation.
Detection of copied files
To detect the files which are copied to a protected folder we use standard windows mechanisms. Each time the user copy, create or modify a file or directory an event is generated indicating the action that has been performed and the file in question. SealPath File Server reacts to these events by checking the files (to determine whether to protect) and including them in a list of files to be protected.
There are five cases in which a folder is verified. Verification of a folder is to explore all its content to determine whether any file should be protected.
SealPath File Server boot
At boot time all protected folders and their subfolders are checked in order to protect all files that had not been protected.
New protected file
All new protected folder are analyzed to protect its original content.
Modifying rule parameters
The modification of any of the parameters of a rule cause the verification of the associated folder content to determine if is necessary to protect (for example, if a rule becomes recursive) or protect again any file (for example, protection policy change).
Regular rule verification
Windows mechanisms (that SealPath File Server uses) for detecting the copied, modified, and new files are limited to the event buffer size. To overcome these limitations we developed a loop that is responsible for verifying any folder that has been modified for a limited time. It can be configured by editing the CheckDirRetryDelay and MaxTimeRetryDir parameters.
Let's say 10,000 files are copied to a protected folder. Is it possible to detect 500 copies using the options available on Windows, the other 9500 could be undetected and therefore unprotected. In this context it is useful such verification.
When the system detects that the first file has been copied, the system adds the folder where the file has been copied to a list of folders that will be checked periodically. The first verification is done immediately after the folder is inserted in this list of folders. Thus the 9500 files that were not detected initially can be verified and protected.
Protected folder verification
Periodically it is started a loop that is responsible for verifying all protected folders in which had been copied or created any files since the last verification. The purpose of this verification is to ensure that no documents are left unprotected in case the file creation or modification had not been detected by the mechanisms that implements Windows. This loop can be configured by editing the CheckRuleDirectoriesDelay parameter.
Although SealPath File Server provides the same functionality for Sharepoint folders and local folders the handling and verification of them are completely different. The detection of changes in Sharepoint folders are made only by periodic verification. Periodically (with configurable time) is asked to Sharepoint server a list of documents that have been created, modified or copied since the last verification. The documents that must be protected are downloaded, protected and uploaded again to Sharepoint, when the upload is completed the unprotected version of the file is deleted.
The queries are performed using Sharepoint CAML (Collaborative Application Markup Language) which is a proprietary language based on XML that, among other things, can be used to query Sharepoint. To modify the frequency of these consultations the user should edit the SharepointCheckDelay parameter.
Connection with Alfresco CMIS
To identify which elements has to be protected, a CMIS (Content Management Interoperability Services) query is performed. This query is done through REST every minute and only returns those files that have had changes or have been created since the last query was done.