contentACCESS documentation – version 3.0

  1. Introduction to contentACCESS
    1. Services provided by contentACCESS
    2. Software requirements
  2. Installation of contentACCESS
  3. contentACCESS Tools
    1. Installing Virtual drive
    2. Installing the Proxy server (contentACCESSWS)
    3. Installing the Proxy web services
    4. Installing Outlook forms
    5. Legacy email archive connectors
    6. Legacy archive connector for Metalogix Archive Manager Exchange Edition (MAM EE)
    7. Legacy archive connector for Email Lifecycle Manager (ELM)
    8. Installing TECH-ARROW’s WinShortcutter
  4. contentACCESS Central Administration
    1. Central administration login
    2. contentACCESS Central Administration user interface
  5. Tenants in contentACCESS
    1. How to create a new tenant
    2. Tenant limitations
    3. How to provide access to a tenant (adding new tenant administrators)
    4. Tenant administrator invitation types
  6. General system configurations
    1. Connection
    2. User interface
    3. Users — role types, creating new users, adding user logins
    4. How to activate your license key
    5. How to create user logins to an already existing user?
    6. System administrators
    7. Login providers
      1. External login provider configuration
      2. Associating an enabled provider with a user login
      3. contentACCESS users in third party systems
    8. System
    9. Licensing
    10. Notifications
    11. Monitoring — how to find out possible misconfigurations / reasons of potential system/job failures
    12. Distributed environment in contentACCESS — Clusters
    13. Statistics
    14. How to create/configure databases — All databases
  7. Common features
    1. Databases
    2. Schedules
    3. Retentions
    4. Storages
    5. Exchange connections
    6. Importing contentACCESS configurations from files
      1. Manual import of Exchange servers/groups/mailboxes to the contentACCESS Address book
      2. Importing File Archive root folders to be archived
  8. Creating new jobs in contentACCESS
  9. Jobs’ page, jobs’ context menu
  10. File Archive
    1. Introduction to File system archive
    2. File Archive settings
    3. Databases
    4. System settings
    5. Retentions
    6. Storages
    7. Root folders
    8. Aliases
    9. Schedules
    10. Provisioning settings and managing access to contentWEB
    11. Configuring aliases
    12. Configuration of jobs available in contentACCESS File Archive
    13. Configuration of File system archive job
    14. Configuration of a File system restore job
    15. Configuration of File system recovery job
    16. Configuration of Remote shortcutting job
    17. Active/inactive documents in File system archive
  11. Email Archive
    1. Important settings before creating an Email Archive job
    2. Database settings
    3. System settings
    4. Provisioning settings
    5. Retention settings
    6. Shortcuts in email archiving
    7. Storing of archived emails
    8. Creating email archive schedulers
    9. User experience
    10. Exchange 2013+: Mail app in OWA 2013+ or on MS Outlook 2013+ desktop version
      1. Deployment in contentACCESS Central Administration
      2. How Mail app works in MS Outlook 2013+ and OWA 2013+
    11. Exchange 2010: OWA 2010 integration
    12. Address book objects
    13. Granting access rights for mailbox users and explicit users to view the mailbox archive?
    14. Creating contentWEB users (option 1)
    15. Manage access to a mailbox archive (option 2)
    16. How the end user logs in to contentWEB (archive)
    17. Database and store assignment in email archiving
    18. How to assign database and storage to an Exchange group?
    19. How to assign database and storage to a mailbox?
    20. How to move data from source database/storage into a second (target) database/storage?
    21. Creating Email archive jobs: archive, restore, recovery, mailbox move, shortcut synchronizaion
    22. Email archive job
      1. Email archive job configuration
    23. Email restore job
      1. Email restore job configuration
    24. Email recovery job
      1. Email recovery job configuration
    25. Mailbox move job
      1. Mailbox move job configration
    26. Shortcut synchronization job
      1. Shortcut synchronization job configuration
  12. Custom plugins
  13. Email management job configuration
  14. SharePoint archive plugin
  15. Storage replication plugin
  16. Sharing plugin
  17. Datengut plugin
  18. Email synchronizer plugin
  19. contentWEB
    1. Logging in to contentWEB
  20. officeGATE
  21. accessGATE Mobile
  22. Virtual drive
  23. Terms of use
  24. FAQ

6.12.Distributed environment in contentACCESS — Clusters

Why is it efficient to use clusters? A server cluster is a group of independent servers (nodes) working together as a single system to provide high availability of services for clients. When a failure occurs on one computer in a cluster, resources are redirected and the workload is redistributed to another computer (node) in the cluster. It can happen, that one processing job is currently running on a processing node, but a server failure occurs and the server will shut down. In this case a second, alternative node (either with “Job runner” or “Universal” role) can pick the task up to finish the archiving process. To achieve this, the running of this particular job should be allowed on any available node.

contentACCESS’s cluster technology guard against the following types of failure:

✓ System and hardware failures, which affect hardware components such as CPUs, drives, memory, network adapters, and power supplies.

✓ contentACCESS’s application and service failures, which affect the software, its applications and essential services.

Thanks to clustering in contentACCESS, the user can make the job processes scalable, and thus increase the performance. The user may decide how the nodes should be used, and how the work processes should be divided between them. The jobs can be run on a specific or any available node. It is also possible to install the full contentACCESS on one node and the contentACCESS server part on another nodes to ensure a better performance for job processing and for contentACCESS as a whole. It is also possible to use the nodes in a balanced mode; in this case the nodes are selected according to their Memory and CPU usage. The actually running jobs on the node will be considered as well.

There are 3 main node roles available in contentACCESS (can be adjusted from the context menu of the particular node).

✓ Universal: this type can be used for all operations performed in contentACCESS;

✓ Model provider (retriever) type can be used to publish models, i.e. this type is used to connect client applications with contentACCESS and to retrieve items through these client applications;

✓ Job runner (processing) type was developed to run jobs (plugin instances) in contentACCESS.

The user must decide, which role type he assigns to a particular node, how he divides work processes between the nodes, and how he makes the work processes more effective. A typical use case is, when a customer installs the contentACCESS server, Central Administration and contentWEB on one node, and contentACCESS server on a second node. Then he sets the first node to “Universal” and the second to “Job runner”, and assigns File system archive jobs to the first node, and the Email archive jobs to the second node.

Now, let’s assume, that contentACCESS is already installed one the first “main” node (TANEWS), where the file system archive jobs are running. Now our customer decided to buy TECH-ARROWS’s Email archive, and he would like to run email archive jobs on a second node. To achieve this, he needs to install the contentACCESS server on a second node (e.g. TECHNB0002).

Before the user starts to install any contentACCESS component on a second node, it is always recommended to set the node to disabled (to prevent the new node from picking up new tasks before it is fully configured). We set now the default role type to “Job processing”, as we will use it to run the email archive jobs. For more information about these default cluster settings please refer to section System, section “Cluster settings”.

Documentation144
To install any contentACCESS component on a second node, start to run the contentACCESS setup package on the selected server (TECHNB0002). Follow the installation steps of the wizard. In the 3rd step of the installation process select the components that should be installed on this second node. As mentioned above, in this use case we select the contentACCESS server to install on this second node:

Documentation145
In the 9th step of the installation process the user is asked to set the system database connection. Enter the server name, where the system database is already installed (in our case it is installed on our 1st node called “TANEWS”), enter the name of the already existing system database (in this case it is “CONTENTACCESSDB”; can be checked on the SQL server), type here the database user credentials and the database schema.

Documentation146

Important!!! In the Database connection settings either a domain user must be specified (if Windows authentication is used), or an SQL user’s credentials must be added to connect to the database.

Finish the installation process of this second node. Now, let’s check the available nodes in the Central Administration.

Status pane of nodes, grid of nodes, available operation from the nodes’ context menu: Nodes where contentACCESS components are installed can be viewed with navigating to System tab ⇒ Services ⇒ Cluster, in the nodes’ grid below the status bar (displayed with green color on the below displayed screenshot).

Documentation147

Screenshot: Nodes’ grid

There are 2 control buttons available in the status pane of the available nodes:

✓ “refresh” button serves to reload the last cluster status from the database;

✓ “disable auto refresh”/”enable auto refresh” buttons serve to disable/enable auto refresh (in every 5 seconds) of the last state from the database.

The node where contentACCESS Central Administration is installed is marked with a bold black color.

Documentation148

How a node can be configured? Node configurations are available for the user from the node’s context menu, with clicking on “Edit” in the dropdown list and configuring it in the “Change node” dialog.

Documentation149
Documentation150
In this dialog it is possible to set up the following node configurations:

Enable/disable a node with checking/unchecking the Enable checkbox;

Change the role assignment of the selected node with selecting the role type from the Role dropdown list;

Set the maximum count of jobs that can parallel run on the node (option Max. job count).

The following information are available in the nodes’ grid, when reading from left to right:

Status: This column marks if the selected node is online or offline, i.e. if it is ready to process tasks or not.

Documentation151
The node can have one of these 3 statuses:

The green (Documentation151.1) spot means, that the node is enabled, i.e. its service is running and the node is ready for processing;

The yellow (Documentation151.2) spot means, that the node is disabled, i.e. its service is stopped and the user cannot run any plugin on it. However the server is still running.

The red spot (Documentation151.3) means that the contentACCESS server on the selected node is currently turned off. A node in offline status can be started again with starting up its service (“GATE.contentACCESS” windows service must be started).

Our TECHNB0002 node was installed in disabled mode, which is indicated with a yellow spot in the status column:

Documentation152
The node can be enabled/disabled with opening the node’s context menu, clicking on “Edit” and checking/unchecking the “Enabled” checkbox in the “Change node” dialog:

Documentation153

Server name: The server name where the contentACCESS node is installed is displayed here. Our first node is installed on server “TANEWS”, and the second node installed on “TECHNB0002”.

Documentation154

Server IP: The IP of the server, where the node is installed is displayed here.

Documentation155

Memory usage, CPU usage, Overall load: Displays actual information about the load balance of the selected node. If the cluster selection strategy is set to “Balanced”, then the nodes will be selected for the tasks that they should perform according to these values. If the node is in offline status, the value will be “0”. If the value is more than 70%, then the value will get a red background color.

Documentation156

Running job count: Informs the user about the currently running job count on a specific node. On the screenshot below we can see, that on node “TANEWS” two file system archive jobs are running. With clicking on the arrow sign at the left side of the row the user may open the details of these 2 job runs:

Documentation157

Role: A node can be either universal, job runner or model provider; the role type of the particular node can be viewed here. As we can see, our “TANEWS” node has assigned “Universal” role, and “TECHNB000” has assigned “Job runner” role.

Documentation158
The assigned roles can be edited with clicking on “Edit in the node’s context menu, and setting the desired node in the “Change node” dialog.

Documentation159
If we are planning to use a node for multiple tasks in the future, we can modify its role to “Universal”.

Max. job count: The maximum count of jobs that can be parallel run on a node can be viewed right here. The number of jobs that can run on a node can be limited. In case of our nodes this job count is unlimited.

Documentation160
This value can be adjusted with opening the “Change node” dialog from the node’s context menu. Click on “Edit” in the node’s context menu, and set the desired value in the dialog. Now we set this value to “10”:

Documentation161
If 10 jobs will be parallely running on this node, and we want to start up a new, 11th job that should run on this node, then this job will be in waiting status until the processing node will be available.

Documentation162
If our 11th job could be run on any available node, then another node will pick it up for processing. The node where the job should run depends on the job settings. For more information check section “Jobs’ page, jobs’ context menu “.

Enabled: A node can either be enabled (it is online, and its service is currently running), or can be disabled. A node is disabled, when it is running, but it is unavailable for further processing tasks. By default, the nodes are in enabled state, but it is recommended to set them here as disabled in case of planned system updates, or if any failure occurred and the problem must be fixed.

Documentation163
To enable/disable nodes open the “Change node” dialog with clicking on “Edit” in the node’s context menu, and check/uncheck the “Enabled” checkbox in the dialog.

Documentation164
In the last columns of the grid the time of Last start/Last stop and Last ping are available.

How to assign a job to the selected node? Now we will assign an Email archive job to the “TECHNB0002” node. We navigate to the Email Archive tab ⇒ Archive ⇒ Jobs on the ribbon, and open the Jobs’ page. Here we click on + new to create an email archive job, which will be assigned to this node.

Documentation165

The “Add new job instance” dialog will open. Here we set up the desired job, and select “TECHNB0002” from the “Run on node” dropdown list. Then we click on “Add”.

Documentation166
We need to configure the newly added job on its job configuration page. For more information how to configure processing jobs refer to the respective sections.

Now we can enable the TECHNB0002 node.

Documentation167
The node will start to run the assigned job at time which is configured in the job’s scheduler settings.

Important!!! When configuring a job that may run in a cluster system the administrator must specify a storage and a database that is accessible by all the nodes in the cluster. If a node which picks up the job can’t access the configured storage or database, the job will fail and will not execute the task:

  • In the database repository settings of the database (selected for the job) the administrator must establish the connection with SQL user credentials. If an explicit user is not specified, then the contentACCESS service user will be used, and the service must run under the same domain user. This ensures that the database can be accessed by the job regardless of where it is running.
  • In the storage repository settings of the storage (specified for the job) the administrator must specify the storage as a network share (e.g \\ServerName\RootFolder\Subfolder) so it can be accessible by the job from everywhere.

How to shut down a node? In certain cases it might happen, that a node should be turned off. This operation can be done from the context menu of the selected node. Click on the ellipses (…) and select “Shutdown” option from the dropdown list. With this action the contentACCESS service on the selected node will be turned off, and the node will get a red color (offline). Node shutdown is a deferred action and it might take 1 minute.

Documentation168
If you are quite sure that you want to shut down the node, answer “OK” for the following pop-up window:

Documentation169

Note: If you are about to turn off the node where Central Administration is running, a next pop-up window will warn you about this again.

Documentation170

How a node can be deleted? With this action the user may delete a node from the node list. Only nodes with offline status can be deleted. When the contentACCESS service is started up again, the node will appear in the list. To delete it, click on it, open its context menu with a click on the ellipses (…), then select “Delete”.

Documentation171
contentACCESS will ask the user again, if he is sure about deleting the node.

Documentation172

Yes No Suggest edit
Help Guide Powered by Documentor
Suggest Edit