SharePoint 2013, SharePoint 2016 and SharePoint Online

Standalone installations are better suited for low-load environments such as a development or proof of concept environment. Since all components are installed on the same physical server as the K2 Server, there are no credentials passed between servers except to SharePoint Online.

All K2 components, IIS, SharePoint, and the database instance are installed on the same physical platform with connection to SharePoint Online if required.

Considerations for Standalone topologies

• When all K2 components are installed on a single, standalone server there are performance related issues that need to be considered. Although all components on a single machine will mitigate security requirements, there will be an impact on the processing capabilities of the physical machine.
• If this installation scenario is used for a development or proof of concept environment, K2 recommends additional RAM or a faster processor is used in order to maintain an acceptable level of performance.
• The Design Time and Runtime sites will be hosted on the same site.
• There are no credentials passed between servers, except if SharePoint Online is being used.

K2 installations can leverage existing infrastructure, for example installing the K2 databases on an existing SQL server. Alternative, it is common to install the K2 databases on a dedicated SQL server machine. This topology is suitable for smaller environments, such as Development, Test, Training or small-scale Production environments. If scaling for data availability is required, a SQL cluster would be best as this provides a redundant system for data availability.

All K2 components, IIS, SQL Reporting Services, and SharePoint are installed on one server, and the database are located on a separate server, with connection to SharePoint Online if required.

Considerations for a separate SQL server topologies

• If this installation scenario is used, it performs best as a development or proof of concept environment. K2 recommends that additional RAM or a faster processor is used in order to maintain acceptable levels of performance.
• Network connection speed between the Application Server and the SQL server must be as fast as possible with as little latency as possible (physical servers should preferably be on the same Gigabit-backbone.)
• K2 recommends you do not geographically separate the SQL Server from the application servers since this can introduce performance issues due to low bandwidth or latency between the K2 application servers and the SQL server.
• The SQL Server can share physical resources with other SQL databases or SQL Server Instances on the same SQL server, or be located on a dedicated SQL server/instance, or be located on an Azure SQL DB.
  • K2 recommends that SQL administrators track performance of the SQL server and address performance issues through standard Microsoft SQL Server scaling approaches.
• The Design Time and Runtime sites will be hosted on the same site.

A distributed environment consists of separate K2, IIS, SQL, and SharePoint servers.

All of the K2 components are separated out from the SharePoint components, with a separate SQL server.

Considerations for Distributed topologies

• For better performance, the recommended approach is to install the website components and application server components on the same physical machine, as described in Separate SQL Server and Distributed Environments.
• The same version of K2 must be installed on all K2 servers in the distributed environment.
• The same version of the K2 for SharePoint app must be installed on all K2 servers/Web servers in the distributed environment.
• In a distributed environment, K2 Pass-Through Authentication (PTA) or Kerberos is required to pass user credentials between physical or logical servers.
• Network connection speed between the Application Server and the SQL server must be as fast as possible with as little latency as possible (physical servers should preferably be on the same Gigabit-backbone.)
• K2 recommends you do not geographically separate the SQL Server from the application servers since this can introduce performance issues due to low bandwidth or latency between the K2 application servers and the SQL server.
• The SQL Server can share physical resources with other SQL databases or SQL Server Instances on the same SQL server, or be located on a dedicated SQL server/instance, or be located on an Azure SQL DB.
  • K2 recommends that SQL administrators track performance of the SQL server and address performance issues through standard Microsoft SQL Server scaling approaches.
• Clients access K2 Workspace (Deskop) via the IIS Server operating from the K2 Server. If the user environment expands so that the performance of the K2 Server is affected by the number of users logging onto K2 Workspace (Deskop), it is advised that the K2 Workspace (Deskop) be relocated to a different server.

The following section discusses the deployment of K2 components and K2 for SharePoint components in a Farm/NLB topology. (Due to the nature of a farm environment and its extensibility, the following is just an example of a basic farm set up.) When implementing a farm topology, configuration of Network Load balancing is required.

Considerations for Farm topologies

• The K2 Workspace (Deskop) and Web Services, K2 Designer and Runtime sites are hosted on a common IIS server. An option is to install K2 Workspace (Deskop) and the K2 Web Services on a separate web server farm. This will lessen the impact of client requests through K2 Workspace (Deskop) on the K2 Application Server. K2 strongly recommends the preferred method of keeping the K2 websites on the same physical server as the K2 application server.
• The same version of the K2 for SharePoint app must be installed on all K2 servers/Web servers in the distributed environment.
• Network connection speed between the Application Server and the SQL server must be as fast as possible with as little latency as possible (physical servers should preferably be on the same Gigabit-backbone.)
• K2 recommends you do not geographically separate the SQL Server from the application servers since this can introduce performance issues due to low bandwidth or latency between the K2 application servers and the SQL server.
• The SQL Server can share physical resources with other SQL databases or SQL Server Instances on the same SQL server, or be located on a dedicated SQL server/instance, or be located on an Azure SQL DB.
  • K2 recommends that SQL administrators track performance of the SQL server and address performance issues through standard Microsoft SQL Server scaling approaches.
• K2 Pass-Through Authentication (PTA) or Kerberos is required to pass user credentials between physical or logical servers.
• NLB can be configured by using either the operating system or specific hardware. In either case, NLB configuration should be completed before installing K2 smartforms. When installing components that will be load balanced, the installation must be performed on each machine independently.