On-Premises Installation Overview

ConceptShare provides an installer application, which guides you in the installation of a ConceptShare instance.

The ConceptShare installer includes a license file that contains your installation (instance) information, which will be required by the installer. If you do not have this particular file, contact our Sales Engineering team.

The installer facilitates the following functionality:
  • Management of multiple instances (if applicable)
  • Management of the ConceptShare Database
    • Downloading of the template (boiler plate) database for initial installation
    • Initialization of the database (setting license/contractual settings, and configuration of database-specific features)
  • Management of the ConceptShare Queue Server
    • Installation/Update of the Windows Service
    • Uninstallation of the Windows Service
  • Management of the ConceptShare website
    • Installation of ConceptShare updates (in the form of releases for your particular instance)
  • Update of various installation settings and client licenses
Table 1. Deployment Scenarios

There are several deployment scenarios where various components can be installed on separate servers or additional servers. The installer application is optimized for single-server deployments, but it also supports dual server deployments where the database (SQL) resides on a separate server. All other deployment configurations such as multiple web servers, queue services or DB clustering are beyond the scope of the ConceptShare installer and will require application of manual updates to individual components.

Deployment Option Description
Single-Server Deployment In this scenario, all ConceptShare services (web, queue, and database) reside on the same server. This is a common deployment scenario for a development, QA, or small on-premises installation.
Dual-Server Deployment In this scenario, all ConceptShare services, with the exception of the database, reside on the same server. In this setup, a centralized SQL instance is available instead of a dedicated instance directly on the server.

Installation is generally the same as the single-server deployment but with the exception of some prerequisite steps that must be manually performed (highlighted in the On-Premises Installation: Instructions).

Triple-Server Deployment In this scenario, each ConceptShare service is divided into its own dedicated server. This is common when the Queue service (the main processor) is handling a fair amount of asset, event, and email processing to warrant using a dedicated and potentially more powerful hardware.

To use the installer, you must copy over and manually apply the updates to the queue (highlighted in the On-Premises Installation: Instructions).

High Availability / Load-Balanced Environments Several configuration options are available for creating a high-availability (HA) environment. For example, you can add a load balancer in front of several web servers, and then balance the load on those servers as needed.

Furthermore, you can create similar multiple queue servers, and then change the configuration of each queue server to handle different asset types, and process different queue items. A queue service handles assets, as well as all the operational functionality within ConceptShare, such as events, callbacks, workflows, reminders, and other core services.

To make the database server high-availability, use the Microsoft technologies that are available for clustering and fail-overs.

You can also use the following high-availability scenarios:
  • Hot/Hot: All services are active and balancing the various loads.
  • Hot/Warm: A primary set of services is active, and a secondary set is online and ready to go in the event of a failure.
  • Hot/Cold: A primary set of services is active, and a secondary set is available offline but can be turned on and configured if the primary set becomes unavailable.
Table 2. Load Balancing

Load balancing is subdivided into the following categories:

Category Description
Web Load Balancing ConceptShare can be placed behind a load balancer to improve responsiveness and availability. You can choose the load-balancing scheduling algorithms that you prefer:
  • Fault-tolerant
  • Load-balanced by number of connections
  • Round-robin
  • Others
When load balancing, ConceptShare recommends using session persistence or stickiness.

ConceptShare also provides a heartbeat functionality that ensures the IIS can properly serve a request and that the underlying database is acceptable. You can configure your load balancers to test this URL, and upon failure, take that system out of the rotation. The heartbeat URL will return OK in the content body of the response if the system passes all system checks. Use the URL: http://your.cs.server.domain/system.ashx?f=hb.

Note: ConceptShare does not provide direct support or assistance with configuring or managing load-balancer hardware or systems because that is the responsibility of the infrastructure team.
Database Load Balancing All database clustering is performed at the SQL-instance level or lower (Windows Clustering/SQL Clustering). ConceptShare can run within a cluster but cannot provide support on creating, configuring, or maintaining such clustered environments. Contact your infrastructure team for assistance.
Queue Load Balancing The ConceptShare queue service can be load-balanced across multiple machines to provide high availability. Each queue service can run the same configuration to provide an even balance across the cluster.

Alternatively, the individual queues can be configured so that certain types can be processed by one queue service and not by the other queue services. For example, in some high video transcoding environments, you may have a server with more processing power than the others. You can configure that server to process the video component, and configure the remaining servers to handle the rest of the queue traffic. Each queue can be independently configured (on/off, maximum number of threads). The service has several queues, which are processed as noted in the following table (along with their default maximum number of threads).

Table 3. Queues
Type Sub-Type Description Number of Threads
Asset <All> Processes all assets uploaded to the system <# Cores> - 1
Email <All> Processes all outgoing emails <# Cores> - 1
Generate <All> Processes all requests to generate content such as review summaries, project exports, and reports <# Cores> - 1
Event <All> Processes all events 2
Callback <All> Processes all system-configured callbacks 1
Check Workflow Processes all time-based workflow events 1
Check Reminder Processes all system reminders 1
Check Online Poller Checks for orphaned user sessions and terminates them 1
Check Maintenance Performs system maintenance 1
Check Notification Digest Processes expired notification digests 1