Thru Server 9.10.0 Release Notes May 9 2019
User Account Expiration
New section to manage User Expiration is added to Administration area. Access to the subsections is controlled by a user role. Section contains the following subsections:
· Definitions: Create and manage User Expiration definitions. Available to Administrator role only.
· Rules -> Site: Assign/Remove a definition to create a rule on the site level. Available to Administrator role only.
· Rules -> User Groups: View and remove expiration rules assigned to user groups. Available to Administrator and Manager roles.
· Rules -> Users: View and remove expiration rules assigned to the users. Available to Administrator, Manager and Partner manager roles. Partner managers can only see users with the same email domain on this page.
Metadata
UserExpirationEnabled boolean (DataType=64) , values 0/1. Enable\Disable User Expiration feature. Default setting: 0 .
Note : in release 9.10.0 the setting disables user expiration processing, while user Expiration UI is always visible.
User Expiration Definitions
User Expiration definitions have the following properties:
Expiration Type
· Fixed period (in days) - The expiration time will be counted from the time when the user is created.
· Inactivity period (in days) - The expiration time will be counted from the time of the last user activity. The last activity counted as: the last login, last filesystem operation, the creation date of the user or the reactivate date of the user (if the user was deactivated early).
Expiration Action
· Delete: If a user account had expired, the account is deleted.
· Deactivate: If a user is expired, the account is deactivated.
Name
· Definition name will be referred in the actual rules assigned to Site/Group/User
Description text field
How to Assign Definitions to create rules
Expiration definitions can be assigned on the following levels to create expiration rules:
· Site: rule is applied to all users of the site.
· User group: rule is applied to all users of a specific group.
· User: rule is applied to a specific user.
Site Rule
To assign a definition to create a site level rule go to Administration -> User Expiration -> Rules -> Site. Setting is available only to Administrator role.
Warning:
When the rule is created on a Site level, a warning popup with OK and Cancel buttons is displayed with the number of users that will be expired after the rule is applied. Cancel cancels creation of the rule. It may take few minutes for a server to apply a rule if a user count is high.
User Group rules
To assign a definition to create expiration rule for a user group go to Administration -> Groups -> Any group -> Expiration tab. Available to Administrator and Manager roles :
User Group rules are listed under Administration->User Expiration->Rules->User Groups where administrators can view and manage the rules:
Warning:
When the rule is created on a User Group level, a warning popup with OK and Cancel buttons is displayed with the number of users that will be expired after the rule is applied. Cancel cancels creation of the rule. It may take few minutes for a server to apply a rule if a user count is high.
User Rules
To assign an expiration definition to specific user to create a user-level rule go to Administration -> Users -> Any user -> Expiration tab. Available to Administrators, Managers and Partner managers. Partner managers can only see users with the same domain on this page.
User rules are listed under Administration->User Expiration->Rules->Users where administrators can view and manage the rules:
Processing of Expiration Rules
Expiration rules are processed by the User Expiration microservice running on a schedule.
Processing of the expiration rules implements the following logic:
Fixed period rules:
Applied to the users with creation date older than expiration period of applicable rule.
Inactivity period rules:
Applied to the users with last activity date older than expiration period of the applicable rule.
The last activity date is defined as the latest date between the following fields:
· DateReactivated - the date of the last user reactivation.
· RetentionUserDateLastActivity - date of the last file system operation by the user.
· DateLastLogin - the date of the last login by the user
Expiration rules are processed in the following priority:
· Priority 1 : User level
· Priority 2 : User group level
· Priority 3 : Site level
For example: If a user should be expired based on last activity date by a site level rule, but is not expired by a user level rule - effective rule is that a user is not expired.
Conflict resolution for the User group rules:
In scenarios when a user is a member of the two user groups which have different user expiration rules, the following processing logic applies:
If a user was not expired by at least one rule, we consider the user not expired.
If user was expired by more than one rule with different action (deactivation and deletion), deactivation is selected over the deletion and expiration date of the rules is ignored.
Example: User group rules Delete after 10 days and Deactivate after 20 days – only Deactivate rule is used.
User Expiration Processing Audit
Expiration rule action is logged in the Audit User log with Performed By is set to a system user (the user with the role = 6).
A new Note field is added after the field Performed By in the User log, it contains duration, User Expiration definition name and object name, e.g. 30 days inactivity - <definition name>, User Group Accountants.
User Experience Improvements
New Design of Thru server Front page
Front page design is changed as shown.
Note on custom pages:
Due to the change in front page implementation, custom front pages are re-implemented and should be re-uploaded before migration. Archive with reimplemented custom pages is shipped with the server build. Custom page appearance did not change.
New Design of Thru server External Download Page
External download page design had changed as shown
File Upload Integrity Controls
Integrity checks are implemented as part of file upload process in the browser, hashes are verified for each uploaded chunk. The following controls are implemented in Thru server metadata settings available via back-end only:
· FileUploadHashCalculateMinMB - Minimum size of a file that is uploaded with hash calculation and validation. Default setting is 500. Value -1 disables calculation, value 0 – calculation is performed for all files.
· FileUploadHashValidationPoint - Points where the hash validation is applied, can be combined: 0 – No validation, 1 - in Request, 2 - in Web cache, 4 - after chunk is appended to the file. Default setting is 2 – in Web cache
· FileUploadChunkMaxRetryAttempts – Maximum number of retries to resend a chunk in case of hash mismatch. Default setting is 3.
General Improvements
· Editing of Email Archiving Project List from Thru Outlook add-in is now controlled by Local policies
· In GDPR mode delete with GDPR compliance is now set to off by default
· Support link on Thru portal pages can be configured via metadata parameter SupportURLTemplateConfigurable
optimizations
· Selection of a user to add to a group is now done with a single click
· Resolved a delay on Thru web email page when confirmation email is enabled
· In Admin > Users > Search by email address works by name or email domain
bug fixes
· Attempt to upload a folder upload via drag and drop now results in correct error message, in current release folder upload is not supported.
· Fixed the issue with default expiration date in case if expiration date interval is limited
· Fixed the issue with DefaultNoSSORedirect page.
· Fixed the issues with external download pages on all Apple devices and versions iOS
Deployment Notes
IIS Application pool
Starting with the server version 9.3.0 application pool must be used in Integrated pipeline mode.
Database Migration
Release: 9.3.3: Database migration is required from any previous release to release 9.3.3.
Release 9.3.4: Database migration is not required from release 9.3.3 to 9.3.4.
Release 9.3.5: Database migration is required from any previous release to release 9.3.5
Release 9.3.6: Database migration is not required from release 9.3.5 to 9.3.6.
Release 9.4.0: Database migration is required from any previous release to 9.4.0
Release 9.4.1: Database migration is required from any previous release to 9.4.1
Release 9.4.2: Database migration is required from any previous release to 9.4.2
Release 9.4.3: Database migration is required from any previous release to 9.4.3
Release 9.4.4: Database migration is required from any previous release to 9.4.4
Release 9.4.6: Database migration is not required from release 9.4.4 to 9.4.6
Release 9.5.0: Database migration is required from any previous release to 9.5.0
Release 9.5.1: Database migration is required from any previous release to 9.5.0
Release 9.6.0: Database migration is required from any previous release to 9.6.0
Release 9.6.1: Database migration is not required from release 9.6.0 to 9.6.1
Release 9.7.0: Database migration is required from any previous release to 9.7.0
Release 9.8.0: Database migration is required from any previous release to 9.8.0
Release 9.9.0: Database migration is required from any previous release to 9.9.0
Release 9.9.1: Database migration is not required from release 9.9.0 to 9.9.1
Release 9.9.2: Database migration is not required from release 9.9.0 and 9.9.1 to 9.9.2
Release 9.9.3: Database migration is not required from release 9.9.0, 9.9.1 and 9.9.2 to 9.9.3
Release 9.10.0: Database migration is required from any previous release to 9.10.0
web.config
Configuration file web.config changed in the server release 9.4.1
Configuration file web.config changed in the server release 9.4.3
Configuration file web.config changed in the server release 9.5.0
Configuration file web.config changed in the server release 9.6.0
Configuration file web.config changed in the server release 9.7.0
Configuration file web.config changed in the server release 9.8.0
Configuration file web.config changed in the server release 9.9.0