Prerequisites for the Nodinite Configuration Database

Prepare your environment for a seamless Nodinite deployment! This comprehensive guide details all prerequisites for installing the Configuration Database—from SQL Server and rights to firewall and linked server settings—ensuring optimal performance, security, and reliability.

✅ Follow a step-by-step checklist for smooth installation
✅ Ensure security and compliance with best practices
✅ Optimize SQL Server, firewall, and rights for high performance
✅ Minimize troubleshooting and accelerate time-to-value

This page outlines the prerequisites for successfully installing the Nodinite Configuration Database, which is a SQL Server database installed within a SQL Server instance.

Nodinite Configuration Database Checklist

The Nodinite Configuration Database is at the heart of your integration landscape. In a simple setup with a single machine, minimal administration is needed to keep everything running smoothly. However, in a complex, secure, distributed environment spanning multiple servers—with network load balancing, firewalls, network zones (WLANs), domains, DNS, group policies, and anti-virus/anti-malware software—you may spend significant time configuring each component correctly.

Use the checklist above to verify that you have completed all steps required to get Nodinite flying high!

SQL Server

You can deploy SQL Server on physical machines, virtual machines, or in the cloud, provided that the Windows version matches the prerequisites for your SQL Server version.

Important

It is your responsibility (or your IT organization/hosting partner) to backup the Nodinite Configuration Database regularly—at least once per day.

Please review the following articles about SQL Server for use with Nodinite:

• SQL Server Always On Availability Groups user guide
• Microsoft SQL Server

SQL Server Related Optimizations

To maximize your experience with Nodinite, implement all the suggestions below:

• Run Nodinite in dedicated SQL instances to guarantee hardware resources, avoid resource contention, and simplify troubleshooting.
  • Assign dedicated disk volumes for the Log Database to ensure extended logging does not impact other systems/services. Use the LogLocations system parameter to assign volumes.
• Keep the Logging Service close to the SQL Servers hosting the Log Databases for Nodinite

Repeat the optimizations below on ALL SQL Server instances (Configuration Database, Log Databases, BizTalk Databases)

• Use the -T1118 trace flag on SQL Instances (<2016) to optimize TEMPDB.
• Disable PAC Verification if your policy allows, on all Windows Servers running any Nodinite Core Services—this reduces RPC calls and improves performance.
• Install Nodinite on machines with dedicated Windows swap volumes (>2.5× physical RAM) and SQL disks with >300 MB/s R/W.
• Ensure a secure backup volume (or network share) is available with sufficient free space for Nodinite databases.
• Windows Servers hosting any Core Services should have at least 16GB RAM. Environments with high message volumes may require more RAM.
• For each core assigned to your SQL Instance (up to 8), create one tempdb file with 128 MB in size (no autogrowth).

  If you have 14 cores, create 8 tempdb files. Placing tempdb files on different volumes may further increase overall system performance.

• Nodinite Log Databases, when used with BizTalk, should be kept in Simple recovery mode (default).

Microsoft Distributed Transaction Coordinator (DTC)

The Configuration Database is involved in all SQL Server-related operations. Nodinite uses the Windows Service Microsoft Distributed Transaction Coordinator (DTC) to coordinate transactions that span multiple resource managers. We have created a dedicated tutorial for Nodinite with best practices for installing and configuring the DTC Windows Service.

You must configure the DTC as documented; otherwise, Nodinite will not function correctly.

What Windows Rights Does the Configuration Database Require?

Nodinite maintains the identity of the user account running Core Services threads when traversing servers on your network. For example, when the Logging Service fetches data from the BizTalk tracking database, it is the configured account that performs the remote operation. For Windows Integrated Security to pass and authenticate the user identity across servers, all tasks outlined in the checklist at the beginning of this tutorial must be properly configured.

The Configuration Database is a SQL Server database and is installed as part of the Core Services package. You must use a Windows account that has been configured with the appropriate rights in SQL Server. See SQL Server database rights.

For Kerberos to work, the servers must be properly configured:

Trusted for Delegation

This topic is detailed in the Trusted for delegation user guide.

Register SPN

When running Nodinite in a distributed environment, Kerberos requires all SQL Instances (both physical node names and cluster names) to have their SPNs registered in Active Directory.

Example 1: If you have a single-box server with BizTalk, SQL Server, and Nodinite, you don't have to register the SPN (not a distributed environment).

Example 2: If you have Nodinite Configuration Database installed on one Windows Server with a SQL default instance and BizTalk in another two-node failover cluster running two SQL instances (one default and one named instance), one for other BizTalk databases and one dedicated for the messagebox (BizTalkMSGBoxDb), you will have to register 7 SPNs in total (1 for Nodinite, 3 for the BizTalk instance, 3 for the BizTalk Messagebox instance).

1. SQL Server name for default instance with Nodinite Configuration Database
2. SQL Server first node name for default instance with BizTalk databases
3. SQL Server second node name for default instance with BizTalk databases
4. SQL Server cluster name for default instance with BizTalk databases
5. SQL Server first node name for named instance with messagebox database
6. SQL Server second node name for named instance with messagebox database
7. SQL Server cluster name for named instance with messagebox database

SQL Server Default Instance

The following example registers accountname for the default SQL Instance using an elevated command prompt (requires 'Domain Admin' rights):

setspn -S MSSQLSvc/myhost.redmond.microsoft.com accountname

SQL Server Named Instance

The following example registers accountname for the named SQL Instance using an elevated command prompt (requires 'Domain Admin' rights): Repeat for each combination of named instance/accountname.

setspn -S MSSQLSvc/myhost.redmond.microsoft.com:instancename accountname

What SQL Rights does the Configuration Database require?

For performance reasons, the Configuration Database accesses the databases directly using the Windows Service Account configured. The Configuration Database must have the following SQL rights assigned:

All SQL Instance(s) where Configuration Database and Log Databases are installed:

• public – Rights to log in to instances and databases
• dbcreator – Rights to create new Log Databases
• diskadmin – Rights to create the database files in Windows for new Log Databases
• securityadmin – Rights to assign the proper access rights on new Log Databases. Please review the following System Parameters:
  • LogAccessRoles
  • LogServiceUsers

  Remember, privileges do not replicate automatically on SQL Server Always On environments. Nodinite does this job for you.

• db_ddladmin – see note below
• Shrink Rights – Old Log Databases must be shrunk to regain allocated disk space, and the shrink operation requires membership in the sysadmin fixed server role or the db_owner fixed database role. See more here

Info

db_ddladmin is required for the service account to have proper rights to read statistics. Without this permission, performance may be degraded, especially for remote servers (linked servers). Read more here. Contact our support if you have any questions about this.

All Nodinite specific databases

• Configuration Database

  • db_datareader
  • db_datawriter
  • db_ddladmin
  • sysadmin or at least db_owner

• Log Databases (can be multiple)

  • db_datareader
  • db_datawriter
  • db_ddladmin
  • sysadmin or at least db_owner

Note

See the specific text for the SQL instance above for membership in either sysadmin and/or db_owner for the automatic shrink of Nodinite related Log Databases

What Firewall settings are required for the Configuration Database?

The Configuration Database requires both inbound and outbound ports to be opened. Since Nodinite is highly configurable, the actual ports in use may differ from those shown here.

The following image shows which Core Services are using the Configuration Database:

1. TCP Ports between Nodinite Core Services and the Configuration Database
2. TCP Ports between Configuration Database and Log Databases / BizTalk SQL Server

The Log API, Web API, Logging Service, and the Monitoring Service access the Configuration Database using the configured Windows Service Account.

1. TCP Ports between Nodinite Core Services and the Configuration Database

2. TCP Ports between Configuration Database and Log Databases / BizTalk SQL Server

The following Windows components access the Configuration Database, and the required ports must be allowed. Follow each link for detailed configuration guidance:

• DTC
• Trusted for delegation
• Windows rights
• SQL rights
• SPN registered

Linked Servers

Nodinite leverages the SQL Server concept of Linked Servers. The Install and Update Tool requires these to be properly configured BEFORE installing Nodinite for seamless cross-server operations and automation.

Review and follow the steps detailed in the linked servers section to ensure a robust and secure configuration.

Frequently asked questions

Additional solutions to common problems and the Nodinite Configuration Database FAQ exist in the Troubleshooting user guide.

Where do I add my custom built Search Field Plugins?

Warning

This feature is deprecated and is not even available with Nodinite 7.x and beyond.

Copy the custom built DLL to the 'Plugins' folder where the the Logging Service is installed. If the DLL is being replaced then you must restart the Logging Service.

Important

• Ensure the DLL after the copy paste operation is not blocked by Windows. Right-click on the DLL and select properties. Click the Unblock button if that option exists
• The DLL is not lost when doing an update. You may need to update your custom build DLL every now and then since it has references to base classes that may have been changed with breaking changes.

Next Step

Install Nodinite
System Parameters

Related Topics

• Core Services
• Configuration Database
• Log Databases