Special Installation Scenarios

Create Tagging Service Application on an existing (empty) database

If the tagging database is created initially by script or from SQL Server Management Studio, the following points must be considered:

• Database Collation: The database collation needs to be set to: Latin1\_General\_CI\_AS\_KS\_WS (also recommended for SharePoint service application databases).
• READ_COMMITTED_SNAPSHOT: The tagging database requires parameter READ\_COMMITTED\_SNAPSHOT enabled. This parameter is checked by MatchPoint during the creation of the database schema.

When modifying the READ\_COMMITTED\_SNAPSHOT parameter, MSSQL requires no active connections on the database (see http://technet.microsoft.com/en-us/library/bb522682.aspx for further information).

Therefore it is strongly recommended to set this parameter to ON before the schema is created by the MatchPoint Tagging Service. If this is not possible, all active sessions on the database (like MS SQL Server Management Studio) must be closed before the tagging service database schema is created.

Least Privilege Environments

MatchPoint supports SharePoint least privilege scenarios. Configuring a least privilege environment has the following advantages:

• Every (web application) application pool can be configured with a separate domain account.
• This account is not required to be a farm administrator, therefore it is possible to limit the permissions a user can acquire when operating on such a web application.
• The farm administrator account itself is not required to be a local administrator of the server.

MatchPoint will generally execute commands using the permissions of the current user (impersonated).
For some applications (i.e. accessing the tagging service application), the permissions of the application pool account are used (using "revert to self").

Some administrative operations that are concerning farm functionalities can only be executed with SharePoint farm administrator privileges. Since MatchPoint cannot obtain these credentials by using the application pool account, such operations will be hidden within the GUI in least privilege scenarios.

In such a case, you can activate the corresponding functionality by using the "SharePoint 2016 Management Shell" (with farm admin privileges).

Features that require farm administrator privileges are:

• Creating instance associations
  This requires permissions to write to the SharePoint configuration database
• Starting and scheduling MatchPoint timer jobs
  This requires permissions to start SP timer jobs
• Publishing MatchPoint Workspace provisioning templates
  This requires permissions to deploy solutions farm wide

If an instance association is created, the web application's application pool account will automatically be assigned with permissions on the MatchPoint tagging service application and on the configuration document library (on the MatchPoint Administration site).

Multi Frontend Environments

For the installation of MatchPoint in multi-frontend environments, please make sure that the solution packages are correctly deployed to all frontend servers.

If MatchPoint is configured with cacheable data providers, each frontend server will persist a separate memory cache. Therefore it is strongly recommended to configure the load balancer to assign sticky sessions. Otherwise users might experience confusing search behavior as the caches could have different cache states. (This is of course not only true for MatchPoint related caching but also for caching in general.)

In multi-server environments where the Microsoft SharePoint Foundation Web Application service is stopped on the server hosting the Central Administration, it is recommended to execute the installation on a frontend web server. The installation can either be done manually or by using the installer executable. The following points must be considered:

• MatchPoint PowerShell cmdlts are only provisioned to servers that run the Web Application service.
• Ensure that the SPTimerv4 service is restarted and an iisreset is executed on every server after the installation of the MatchPoint solutions.
• Tagging Service Instances are created on every server in the farm with initial state "Stopped". They can be started from Central Administration.
• Tagging Service Instances and Applications are not visible in Central Administration if Colygon.MatchPoint.dll is missing on the assembly cache of the server that is hosting Central Administration.
• If Colygon.MatchPoint.wsp was retracted from one server it is required to re-deploy the Colygon.MatchPoint.TaggingService.wsp using the -force parameter (to ensure the Colygon.MatchPoint.dll on each server assembly cache where Colygon.MatchPoint.wsp was retracted).
• If Colygon.MatchPoint.TaggingService.wsp was retracted from the farm it is required to re-deploy Colygon.MatchPoint.wsp using the -force parameter.
• If Microsoft SharePoint Foundation Web Application instance was stopped on a server in a farm, SharePoint retracts the Colygon.MatchPoint.dll from the global assembly cache of the specified server. This requires to re-deploy Colygon.MatchPoint.TaggingService.wsp using the -force parameter.

Multiple MatchPoint Instances

MatchPoint allows the setup of multiple MatchPoint instances within one SharePoint farm. For such a setup, please note the following constraints:

• A MatchPoint instance is not related to the physical architecture of the SharePoint farm (frontend servers, indexing- and query servers) - just like the SharePoint web application layer is not related to the physical farm layer.
• A SharePoint web application is always associated to exactly one MatchPoint instance.
• You can create multiple tagging service applications and therefore multiple tag stores. The Tag Store Id you define for each tagging service application becomes part of the tag string and is evaluated whenever tags are applied, searched for or displayed in the system.

If your MatchPoint instance contains multiple web applications, you have to ensure that all web applications that belong to that instance are in the same SharePoint application proxy group. Otherwise a web application will not have access to the complete metadata model.
If multiple MatchPoint instances are using the same tag store, you have to ensure that tag provider IDs and keys are unique within the importers from both instances.