SharePoint 2016, SharePoint 2019 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 Server, there are no credentials passed between servers except to SharePoint Online.

All product 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 product 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, we recommend 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.

The product installations can leverage existing infrastructure, for example installing the databases on an existing SQL server. Alternative, it is common to install the 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 product 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. We recommend 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.)
• We recommend 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 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.
  • We recommend 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 Nintex Automation, IIS, SQL, and SharePoint servers.

All of the 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 the product must be installed on all servers in the distributed environment.
• The same version of the Nintex K2 for SharePoint app must be installed on all servers/Web servers in the distributed environment.
• In a distributed environment, 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.)
• We recommend 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 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.
  • We recommend that SQL administrators track performance of the SQL server and address performance issues through standard Microsoft SQL Server scaling approaches.
• Clients access Workspace(Desktop) via the IIS Server operating from the Server. If the user environment expands so that the performance of the Server is affected by the number of users logging onto Workspace(Desktop), it is advised that the Workspace(Desktop) be relocated to a different server.

The following section discusses the deployment of the product components and Nintex 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 Workspace(Desktop) and Web Services, Designer and Runtime sites are hosted on a common IIS server. An option is to install Workspace(Desktop) and the Web Services on a separate web server farm. This will lessen the impact of client requests through Workspace(Desktop) on the Application Server. We strongly recommend the preferred method of keeping the websites on the same physical server as the application server.
• The same version of the Nintex K2 for SharePoint app must be installed on all 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.)
• We recommend 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 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.
  • We recommend that SQL administrators track performance of the SQL server and address performance issues through standard Microsoft SQL Server scaling approaches.
• 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 smartforms. When installing components that will be load balanced, the installation must be performed on each machine independently.