- 10 minutes to read

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.

Verified Topic
SQL Server
MSDTC
Windows rights
Trusted for delegation
Register SPN
Database rights
Firewall
Linked Server(s)

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.

You set the SQL Server type (standalone, Always On Availability Group, or Azure SQL Managed Instance) and the connection string in the Nodinite Portal, Step 3: Infrastructure. See Connection Strings for tested formats.

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:

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, set by the LogDatabaseRecovery System Parameter).

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 Service Principal Names (SPNs) registered in Active Directory.

Tip

See the Service Principal Names (SPN) page for:

  • When SPN registration is required (distributed environments, linked servers, AOAG)
  • Registration commands for default instances, named instances, and clusters
  • Scenario-specific examples (single instance, failover cluster, Always On Availability Groups)
  • Validation with Microsoft Kerberos Configuration Manager tool
  • Troubleshooting common Kerberos authentication issues

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:

graph LR subgraph "SQL Server" roConfigDatabase(fal:fa-database Configuration database) --- | Linked Server | roLogDatabase(fal:fa-database fal:fa-database fal:fa-database Log databases) end subgraph "Application Server" roLoggingService(fa:fa-code-commit Nodinite Core Services) --- roConfigDatabase end

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

Scope Permission / Role Description Microsoft Docs Link
Instance public Rights to log on to SQL instances and databases used by Nodinite public role
Instance dbcreator Allows creating new databases (used to create Log Databases) dbcreator
Instance diskadmin Allows creating database files for new databases diskadmin
Instance securityadmin Allows managing server logins and assigning rights on newly created databases securityadmin
Database db_ddladmin Required for reading statistics and running maintenance DDL statements on databases; important for linked-server performance db_ddladmin
Database db_owner/sysadmin Required for shrink operations and certain administrative tasks (if DatabaseMaintenance is enabled) db_owner, sysadmin

For the full rights matrix and fallback model when policy blocks permanent sysadmin, see SQL Server Sysadmin Requirements.

Please review the following System Parameters:

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

[!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 in this article on linked server performance. Contact our support if you have any questions about this.

Why db_ddladmin is Important

Granting db_ddladmin to the account running remote T-SQL queries (such as those executed by the Nodinite Logging Service) is recommended because it allows the service to execute Data Definition Language (DDL) statements—like creating, altering, or dropping objects—on the target BizTalk databases.

  • Some logging and integration scenarios require temporary tables, views, or stored procedures to be created or modified during data extraction or transformation.
  • Without db_ddladmin, remote queries may fail if they need to create or alter objects, resulting in incomplete logging or errors.
  • Granting this permission ensures the service can adapt to schema changes or optimize queries for performance and reliability.

If you do not grant db_ddladmin

  • The service may be limited to read-only operations and could fail if it attempts to create or modify objects.
  • This could lead to missed data, failed logging jobs, or the inability to troubleshoot or extend logging capabilities.

In summary, db_ddladmin is important for robust, flexible, and reliable remote logging and monitoring, especially when schema changes or temporary objects are required.

All Nodinite Specific Databases

Database Permission Description Microsoft Docs Link
Configuration Database db_datareader Grants read access to all tables and views db_datareader
Configuration Database db_datawriter Grants write access to all tables and views db_datawriter
Configuration Database db_ddladmin Allows running DDL statements (e.g., create/alter/drop objects) db_ddladmin
Configuration Database sysadmin/db_owner Required for certain administrative tasks (e.g., shrinking databases) sysadmin, db_owner
Log Databases db_datareader Grants read access to all tables and views db_datareader
Log Databases db_datawriter Grants write access to all tables and views db_datawriter
Log Databases db_ddladmin Allows running DDL statements (e.g., create/alter/drop objects) db_ddladmin
Log Databases sysadmin/db_owner Required for certain administrative tasks (e.g., shrinking databases) sysadmin, db_owner

This table lists the minimum SQL Server permissions required for the Nodinite Configuration Database and Log Databases. Ensure these grants are set for uninterrupted operation, maintenance, and automation.

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 never calls the Nodinite Core Services; they connect to it. It opens connections of its own only through Linked Servers, to the Log Databases and to other databases Nodinite reads, such as the BizTalk databases. Every server also needs a domain controller for DNS and Kerberos. The diagram shows each host, with the port on the arrow, drawn from the side that opens the connection.

graph LR subgraph "Nodinite Core Services Server" roCS["fa:fa-box-full Web API, Log API, Logging Service, Monitoring Service, MCP Server"] end subgraph "SQL Server - Configuration Database" roConfig["fa:fa-database Configuration Database"] end subgraph "SQL Server - Log Databases and other linked databases" roLogDB["fa:fa-database Log Databases"] roBTS["fa:fa-database BizTalk databases, when used"] end subgraph "Domain Controller" roDC["fa:fa-server DNS, Kerberos, LDAP"] end roCS -->|"TCP 1433, MSDTC 135 + RPC"| roConfig roConfig -->|"TCP 1433, MSDTC 135 + RPC"| roLogDB roConfig -->|"TCP 1433"| roBTS roCS -->|"53, 88, 389"| roDC roConfig -->|"53, 88, 389"| roDC

Diagram: the Core Services connect to the Configuration Database, which reaches the Log Databases and other databases through Linked Servers; all servers use the domain controller for DNS and Kerberos.

The SQL Server, MSDTC, and domain controller ports are shared by all Nodinite components, so their full details live on one page, SQL Server Firewall Configuration. The tables below list each hop in one row per port and link there.

Between the Core Services and the Configuration Database

Direction Source Destination Protocol Port(s) Purpose Notes
Outbound Core Services Server SQL Server (Configuration Database) TCP 1433 SQL Server connection from each Core Service Default instance port; named instances and changed ports: Core Services to SQL Server
Outbound Core Services Server SQL Server (Configuration Database) UDP 1434 SQL Server Browser Only for a named instance without a port in the connection string; see SQL Server Browser Service
Both Core Services Server SQL Server (Configuration Database) TCP 135 + dynamic RPC range MSDTC distributed transactions Configure MSDTC on both servers; range and how to restrict it: Core Services to SQL Server

Between the Configuration Database and the Linked Servers

Direction Source Destination Protocol Port(s) Purpose Notes
Outbound SQL Server (Configuration Database) SQL Server (Log Databases, BizTalk databases) TCP 1433 Linked Server queries Only when the databases are on another instance; see SQL Server to SQL Server
Both SQL Server (Configuration Database) SQL Server (Log Databases) TCP 135 + dynamic RPC range MSDTC for Linked Server transactions Requires RPC and RPC Out on the Linked Server

Between every server and the domain controller

Direction Source Destination Protocol Port(s) Purpose Notes
Outbound Core Services Server, SQL Servers Domain Controller (DNS server) TCP/UDP 53 DNS name resolution Kerberos needs host names, not IP addresses; hosts-file entries are a fallback
Outbound Core Services Server, SQL Servers Domain Controller TCP/UDP 88 Kerberos authentication and delegation Needs registered SPN values; see Domain Controller ports
Outbound Core Services Server, SQL Servers Domain Controller TCP/UDP 389 LDAP account and group lookups

What to get right

  • Default and changed ports: SQL Server listens on TCP 1433 by default. Named instances and changed ports use their own port; put that port in the connection string you set in the Nodinite Portal (Step 3: Infrastructure) to avoid UDP 1434.
  • Same server: when SQL Server runs on the Core Services Server, no firewall rule is needed between them. Linked Servers on the same instance need no rule either, but they're still required.
  • Versions: these ports are the same in every Nodinite version.
  • Azure SQL Managed Instance uses other ports; see Azure SQL Managed Instance.
  • DNS (53): every server must resolve the others by name, including the Linked Server names and the Always On listener.

Tip

SQL Server Firewall Configuration also covers Always On Availability Groups and PowerShell commands to test each port.

Nodinite leverages the SQL Server concept of Linked Servers. Configure them before you run the v7 CLI package (Install Nodinite v7) 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.

Next Steps

Install Configuration Database
Linked Servers
System Parameters

Configuration Database
Core Services
LogAccessRoles
Log Databases
Logging Service
LogLocations
LogServiceUsers
Microsoft SQL Server
MSDTC
SPN
SQL Firewall
SQL Server Always On Availability Groups user guide
System Parameters
Troubleshooting
Trusted for delegation
Uninstall Configuration Database
Update Configuration Database