I have spent a lot of time looking for documentation and guidance on two things for Nintex External (Live) Forms:
1) which Nintex services are required to run to enable external forms to work properly, and
2) which services should run on which servers in a multi-server high availability SharePoint 2016 farm
Details of my SharePoint 2016 on-premises farm: 2 web front end servers in a DMZ behind a load balancer, 2 application servers in the internal network, 2 SQL 2017 AlwaysOn servers in the internal network. I've installed and deployed Nintex 2016 Forms Enterprise and Workflow Enterprise successfully (workflows and forms work fine) and have run Install-ExternalPlatform, even though that supposedly happens during the install process, so it theoretically is not a necessary step. There are five Nintex services in my farm:
Nintex Connector Workflow Queue service
Nintex Connector Workflow service
Nintex External Forms Online service
Nintex External Relay service
Nintex Workflow Start service
After explaining the details of my environment to a Nintex support engineer, his guidance was to run the services on whatever servers I need to run them on in order to make it work in my environment (i.e., not super helpful). A Nintex forms architect told me in an email, "As far as HA (High Availability) scenarios, SharePoint best practices should be adhered to." To me, that meant I should run my application server services on both of my APP servers, and my web front end services on both of my WFE servers.
One problem with that is the Nintex Workflow Connector Workflow service is only available to start on the server that homes central admin. I'm including some of the links that I either found or that an engineer or product manager sent to me to help me figure it out. The bottom line, however, is I still haven't found any good information that indicates what the Nintex services each do, which service needs to run in order to enable external forms, doc gen, or external workflow start, or how to setup these services to be highly available so that if one of my APP or WFE servers goes down, the service continues to operate.
Resources that are lacking in depth:
So, after striking out a couple of times, I'm looking for some help from someone who may have been down this road already and has made it work. Thanks in advance for your help!
Hi, Matt - unfortunately, I have not - no replies and no additional information from Nintex. I fear that the company is so focused on cloud that they aren't spending resources on thing like this that are critically important to on-premises customers, which is why I was hoping another customer had figured it out and could give me some guidance. If you find out anything in your research, I would sure appreciate whatever guidance you could provide. Thanks!
I also have a similar requirement for Nintex 2019, and didn't get much help from Nintex support engineer and don't see anything about configuring Nintex Services in a SharePoint 2016/2019 minrole environment.
Same here for on-premise 2019. Installation of Nintex workflow/forms pulls app and wfe systems out of minrole compliance, and the standard answer "just make them custom roles" is not something I really want to do.
Well, here I am three years later asking the same questions, this time about Nintex 2019, but my sense is that it's much the same as 2016.
To wrap up my 2016 comments/questions, I ultimately determined through trial and error that Nintex 2016 was not designed to be highly available because it was impossible to run certain services on multiple servers in a farm simultaneously.
Then 6 months ago in this post about 2016 minrole compliance, I finally found written confirmation from Nintex that this is true:
I must say, I was a bit horrified by this statement: "These services can be configured to run on any server in the farm, but should only have 1 instance running per farm, as having additional service instances is redundant and may conflict with each other."
Anyone in charge of providing a stable, capable, and reliable technology platform knows that having redundancy is a good thing, not a bad one. If this statement is a reflection of the Nintex architecture team's true perspective, it's time for a major shift. Go figure out those conflicts, Nintex folks!