- 9 minutes to read

Prerequisites for the Log Database

Prepare your environment for a successful Nodinite Log Database deployment. This comprehensive guide covers all technical requirements, from SQL Server configuration to distributed transaction coordination and Kerberos authentication.

Understanding the Log Database Architecture

The Nodinite Log Database stores all logged events, messages, and metadata from integrated systems. Understanding its architectural role helps you configure prerequisites correctly.

graph LR subgraph "Application Server" roWebAPI("fa:fa-cloud Web API") roLogAPI("fa:fa-cloud-arrow-down Log API") roLoggingService("fa:fa-hard-drive Logging Service") roMonitoringService("fa:fa-watch-fitness Monitoring Service") end subgraph "SQL Server" roConfigDB("fa:fa-database Configuration Database") roLogDB1("fa:fa-database Log Database 1") roLogDB2("fa:fa-database Log Database 2") roLogDB3("fa:fa-database Log Database N") end roWebAPI --> | DTC Transactions | roConfigDB roLogAPI --> | DTC Transactions | roConfigDB roLoggingService --> | DTC Transactions | roConfigDB roMonitoringService --> | DTC Transactions | roConfigDB roConfigDB --> | Linked Servers | roLogDB1 roConfigDB --> | Linked Servers | roLogDB2 roConfigDB --> | Linked Servers | roLogDB3

Diagram: Log Database architecture showing Core Services accessing Log Databases through Configuration Database linked servers with distributed transaction coordination.

Key Architectural Principles

  • Centralized configuration — Configuration Database coordinates access to all Log Databases via linked servers
  • Distributed transactions — MSDTC ensures data consistency across servers when logging events
  • Windows authentication — Kerberos handles secure identity delegation across network boundaries
  • Scalable storage — Multiple Log Databases can span different SQL Server instances for performance and capacity

What You'll Find on This Page

  • Complete prerequisite checklist — Verify all requirements before installation
  • SQL Server requirements — Version compatibility, backup strategy, instance configuration
  • MSDTC configuration — Distributed transaction coordinator setup for multi-server operations
  • Windows authentication — Service accounts, delegation, and Kerberos SPN registration
  • Linked server setup — Configuration commands for default/named instances, clusters, and AOAG
  • Firewall configuration — Port requirements for SQL Server, DTC, Kerberos, and RPC
  • Best practices — Security hardening, performance tuning, and troubleshooting guidance

This page describes the prerequisites to successfully install and run the Nodinite Log Database. The Log Database is a SQL Server database and is installed in a SQL Server instance.

Nodinite Log Database Checklist

The Log Database sits at the end of the "spider web." On a single box machine, you may have virtually no administration at all to get everything working. In a locked-down distributed environment spanning multiple servers with network load balancing, firewalls, network zones (WLANs), domains, DNS, group policies, and antivirus/antimalware, you may spend many hours getting every piece of the puzzle in place.

Rest assured, Nodinite is built on Microsoft standard products—the foundation for most enterprise business applications today. We are working hard on cloud-enabling Nodinite as required services mature, one piece at a time, to ensure you get a future-proof solution for your business.

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

Use the checklist above to verify that you have performed all steps required to get Nodinite flying (most probably already managed when you performed similar tasks for the Configuration Database).

SQL Server

Please review the Microsoft SQL Server user guide for general information.

Important

It's you (or your IT-organization/hosting partner/...) responsibility to make sure a backup of the Log Database is regularly taken, at least once per day

You can run SQL Server on Windows Servers implemented on physical machines, virtual machines, and in the cloud. The actual Windows version used must match the prerequisites for Microsoft SQL Server version being used.

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. On an Always On Availability Group, see Always On Availability Groups and the AvailabilityGroupBackupPath System Parameter.

Microsoft Distributed Transaction Coordinator (DTC)

The Log Database is involved in all SQL Server-related operations and Nodinite uses the Windows Service Microsoft Distributed Transaction Coordinator (DTC) that is responsible for coordinating transactions that span multiple resource managers. We have written a dedicated tutorial for Nodinite with our best practices for how to install and configure the DTC Windows Service.

You must configure the DTC as documented, otherwise, Nodinite will not be operational

What Windows rights does the Log Database require?

Nodinite keeps the identity of the user account for running Core Services-related threads when traversing servers on your network. This means for example that when the Logging Service fetches data from Log Databases and/or BizTalk tracking database it will be the configured account that performs the remote operation. For the Windows Integrated Security to be able 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 Log Database is a SQL Server database and is installed as part of the Core Services package. Since the Log Database is a SQL Server database, you must use a Windows account that has been configured with the appropriate rights in SQL Server, see SQL Server database rights.

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 Log Database require?

For performance reasons, the following Core Services accesses the Log Databases through the linked server from the Configuration Database using as default the Windows Service Account configured.

graph LR subgraph "SQL Server" roConfigDatabase("fa:fa-database Configuration Database") --- | Linked Server | roLogDatabase("fa:fa-database fa:fa-database fa:fa-database Log databases") end

Diagram: Configuration Database accessing Log Databases through linked servers for distributed query execution.

When the Logging Service creates a new Log Database, it grants the database roles in the LogAccessRoles System Parameter to every account in LogServiceUsers. Creating databases needs elevated rights; see SQL Server Sysadmin Requirements, or create Log Databases manually when your policy doesn't allow them.

What Firewall settings are required for the Log Database?

The Log Databases never open connections to the Nodinite Core Services. The Logging Service creates them, starting with the first one, and writes to them; the Log API writes Log Events to the active Log Database; the Configuration Database reads them through Linked Servers. 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" roLS["fa:fa-hard-drive Logging Service"] roLogAPI["fa:fa-cloud-arrow-down Log API"] roOther["fa:fa-box-full Web API, Monitoring Service, MCP Server"] end subgraph "SQL Server - Configuration Database" roConfig["fa:fa-database Configuration Database"] end subgraph "SQL Server - Log Databases" roLogDB["fa:fa-database Log Databases"] end subgraph "Domain Controller" roDC["fa:fa-server DNS, Kerberos, LDAP"] end roLS -->|"TCP 1433, MSDTC 135 + RPC"| roLogDB roLogAPI -->|"TCP 1433, MSDTC 135 + RPC"| roLogDB roOther -->|"TCP 1433, MSDTC 135 + RPC"| roConfig roConfig -->|"TCP 1433, MSDTC 135 + RPC, Linked Server"| roLogDB roLS -->|"53, 88, 389"| roDC roLogDB -->|"53, 88, 389"| roDC

Diagram: the Logging Service and the Log API connect to the Log Databases directly, the other Core Services reach them through the Configuration Database and its Linked Servers, and 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 Log Databases

Direction Source Destination Protocol Port(s) Purpose Notes
Outbound Core Services Server SQL Server (Log Databases) TCP 1433 The Logging Service creates and maintains Log Databases; the Log API writes Log Events Default instance port; named instances and changed ports: Core Services to SQL Server
Outbound Core Services Server SQL Server (Log Databases) 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 (Log Databases) TCP 135 + dynamic RPC range MSDTC distributed transactions Configure MSDTC on both servers; see Core Services to SQL Server

Between the Configuration Database and the Log Databases

Direction Source Destination Protocol Port(s) Purpose Notes
Outbound SQL Server (Configuration Database) SQL Server (Log Databases) TCP 1433 Linked Server queries Only when the Log 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; a named instance or a changed port uses its own port. Put the port in the Linked Server definition and connection string to avoid UDP 1434.
  • Same instance: keeping the Log Databases on the same SQL Server instance as the Configuration Database removes the SQL Server to SQL Server rules. The Linked Server is still required.
  • New Log Databases: the Logging Service creates every Log Database itself, including the first one, so open these ports, and grant its account the SQL Server rights, before you start it.
  • 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 Linked Server names and Always On listeners.

Nodinite requires Linked Servers to be configured on the Configuration Database SQL instance to access Log Databases, BizTalk databases, and other remote SQL resources. Linked servers are always required, even when all databases reside on the same SQL Server instance.

Tip

See the complete Linked Servers page for:

  • When and why linked servers are required (always, regardless of database distribution)
  • Configuration commands for default instances, named instances, clusters, and AOAG
  • RPC and RPC Out settings for distributed transactions
  • Security context configuration for Windows authentication
  • Always On Availability Groups (AOAG) listener configuration
  • Failover cluster considerations
  • Troubleshooting common linked server connectivity issues

Quick Reference: Linked Server Names

Environment Default Instance Named Instance
Stand Alone localhost OR ServerName localhost\instancename
Fail-Over Cluster ClusterName ClusterName\instancename
Always On (AOAG) ListenerName ListenerName\instancename

Important

Before installing, create linked servers from the Configuration Database SQL instance to:

  • Local and remote Nodinite Log Databases
  • BizTalk BizTalkMGMTDb and BizTalkDTADb (if using BizTalk logging)
  • Dynamics 365 databases (if using Dynamics 365 monitoring)
  • Any other custom databases Nodinite needs to query

Frequently asked questions

Common problems and the FAQ for the Log Database can be found on the Troubleshooting page.

Next Steps

Install Log Databases
Linked Servers
System Parameters

Configuration Database
Core Services
Linked Servers
Log API
Log Databases
Logging Service
Microsoft SQL Server
Monitoring Service
MSDTC
SPN
SQL Firewall
System Parameters
Troubleshooting
Trusted for delegation
Uninstall Log Databases
Update Log Databases