- 10 minutes to read

Prerequisites for the Nodinite Logging Service

Prepare your environment for a successful Nodinite Logging Service deployment. The Logging Service processes every Log Event, creates and maintains the Log Databases, and reads its settings from the Configuration Database, so most of its prerequisites are about SQL Server rights and network access.

In Nodinite v7 the Logging Service is one of the Core Services: its own IIS web site, installed with the Core Services package that you generate in the Nodinite Portal. The overall v7 prerequisites are in the Install Nodinite v7 prerequisites summary; this page covers what is specific to the Logging Service.

Understanding What the Logging Service Needs

graph LR subgraph "Nodinite Portal" roPortal(fa:fa-sliders Service account, port, TLS) end subgraph "Application Server (Core Services host)" roLoggingService(fa:fa-hard-drive Logging Service - IIS) roWebAPI(fa:fa-cloud-sun Web API - IIS) end subgraph "SQL Server" roConfigDatabase(fa:fa-database Configuration Database) --- | Linked Server | roLogDatabase(fa:fa-database Log Databases) end roPortal -. generated package .-> roLoggingService roWebAPI <--> | HTTPS, Portal ports | roLoggingService roLoggingService --- | SQL, DTC, Kerberos | roConfigDatabase roLoggingService --- | SQL, DTC, Kerberos | roLogDatabase

Diagram: The Nodinite Portal sets how the Logging Service is hosted; you prepare the SQL Server rights, MSDTC, Kerberos, and firewall rules between the Logging Service, the Web API, and SQL Server.

What Who sets it Where
Service account (identity) of the Logging Service You, in the Portal Step 2: Auth – Service account defaults, or per service in Step 4: Servers – Core platform services
Logging Service port You, in the Portal Step 4: Servers – Core platform services; confirm in Step 6: Allocated ports
TLS domain name and certificate You, in the Portal Step 4: Servers – Core host Configuration
SQL Server type and connection string You, in the Portal Step 3: Infrastructure – SQL Server connectivity
IIS site, application pool, bindings The installer CLI Step 7: Run the CLI workflow
MSDTC, Kerberos delegation, SQL Server rights, firewall You, before you run the installer This page

What the Portal and installer set, and what you prepare yourself.

Nodinite Log Database Checklist

The Log Databases sit 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, anti-virus/anti-malware, SQL Server clusters, SQL Server Always On, ... you may spend many hours getting every piece of the puzzle in place.

Verified Topic
Service account and port set in the Nodinite Portal
MSDTC
Windows rights
Trusted for delegation
Database rights
Firewall

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

Microsoft Distributed Transaction Coordinator (DTC)

The Nodinite Logging Service makes use of the Windows Service Microsoft Distributed Transaction Coordinator (DTC), which coordinates 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.

Important

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

What Windows rights does the Logging Service require?

In Nodinite v7, the Logging Service runs as its own IIS web site under the service account you set in the Nodinite Portal (Service account defaults, or per service in Core platform services). The installer CLI creates the site and application pool with that identity; don't change the identity in IIS Manager.

Service Account Requirements

  • Use a domain account or a gMSA account; a gMSA must exist in Active Directory before you run the installer
  • The service account must have Logon as a Service rights - see How to set Logon as a Service right
  • The service account must have the SQL Server rights in the next section
  • This service should always be running
  • This service should not be clustered - Read more on the Support page to get technical assistance from our team

Changing System Parameters or Log Agent settings never requires a restart of the Logging Service.

Kerberos Configuration

For distributed environments where the Logging Service accesses remote SQL Server instances (e.g., BizTalk databases via linked servers), Kerberos delegation must be configured. See the Trusted for delegation guide for step-by-step instructions.

What SQL Rights does the Logging Service require?

For security and performance reasons, the Logging Service accesses the databases using its Windows Service Account. The SQL Server connection itself is set in the Portal (SQL Server connectivity) and described by the SqlServer System Parameter.

The Logging Service must have the following SQL rights assigned.

Instance specific settings

For all SQL Instance(s) where the Configuration Database and Log Databases are located, you must add the account and grant the service account the rights detailed next.

Account

The service account used for the Logging Service must be defined on each SQL server node with the Nodinite Configuration Database and Log Databases.

  • Shrink Rights – Nodinite can perform the shrink command on old Log Databases (NOT the current online database), which requires membership in the sysadmin fixed server role and/or the db_owner fixed database role. This is controlled by the 'DatabaseMaintenance' System Parameter. For more information, read about DBCC SHRINKDATABASE.

Use SQL Server Sysadmin Requirements for a complete rights matrix and what to configure when the service account is not sysadmin.

Important

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 about linked server query performance considerations. Contact our support if you have any questions about this matter.

Account rights

Scope Permission / Role Description Microsoft Docs Link
Instance public Right to log on to SQL instances hosting the Nodinite Configuration and Log Databases database-level roles
Instance dbcreator Allows creating new databases (used to create Log Databases) dbcreator
Instance diskadmin Allows creating database files and managing disk for databases diskadmin
Instance securityadmin Allows managing server logins and assigning rights on newly created databases securityadmin

Database specific settings

Apply settings on each and every SQL instance where Nodinite databases are hosted.

Info

You must repeat the security settings on all nodes if you are using SQL Server High Availability (Always On Availability Groups).

MSDB

Database Permission Description Microsoft Docs Link
MSDB db_datareader Grants read access to MSDB tables used for scheduling and jobs db_datareader
MSDB db_datawriter Grants write access to MSDB tables used for scheduling and jobs db_datawriter
MSDB db_ddladmin Allows running DDL statements in MSDB when maintenance tasks require it db_ddladmin

Grant Execute rights on all existing and future stored procedures in MSDB for the account used by the Logging Service:

GRANT EXECUTE TO [Domain\\user]
GRANT EXECUTE ON SCHEMA::dbo TO [Domain\\user]

Replace [Domain\user] with the Windows account being used for the Logging Service.

If applicable, repeat the grant on all nodes part of an AOAG environment.

  USE MASTER
  GO
  GRANT VIEW SERVER STATE TO [DOMAIN\USER]
  GRANT ALTER ANY AVAILABILITY GROUP TO [DOMAIN\USER];
  GO

Replace [DOMAIN\USER] with the Windows account being used for the Logging Service. The Login must exist.

If applicable, repeat the grant on all nodes part of an AOAG environment. When the Logging Service creates a Log Database on an Always On Availability Group, it also needs the backup share in AvailabilityGroupBackupPath.

Nodinite databases

Database Permission Description Microsoft Docs Link
Configuration Database db_ddladmin/db_owner Allows running DDL statements or full ownership when maintenance is enabled db_ddladmin, db_owner
Configuration Database sysadmin/db_owner Required for certain administrative tasks (e.g., shrinking databases) sysadmin, db_owner
NodiniteLog_* db_ddladmin/db_owner/sysadmin Allows DDL operations or full ownership when DatabaseMaintenance is enabled db_ddladmin, db_owner

Grant Execute rights on all existing and future Nodinite stored procedures for the account used by the Logging Service:

GRANT EXECUTE TO [Domain\\user]

Replace [Domain\user] with the Windows account being used for the Logging Service.

Important

If you are reading this, you are probably also interested in the following System Parameters:

What Firewall settings are required for the Logging Service

The Logging Service talks to the Web API on the same server, to SQL Server, and to the domain controller. It creates the Log Databases itself, starting with the first one, so the SQL Server ports must be open before it starts. 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 - IIS"] roWebAPI["fa:fa-cloud-sun Web API - IIS"] end subgraph "SQL Server" roConfig["fa:fa-database Configuration Database"] roLogDB["fa:fa-database Log Databases"] end subgraph "Domain Controller" roDC["fa:fa-server DNS, Kerberos, LDAP"] end roWebAPI -->|"Logging Service port"| roLS roLS -->|"Web API port"| roWebAPI roLS -->|"TCP 1433, MSDTC 135 + RPC"| roConfig roLS -->|"TCP 1433, MSDTC 135 + RPC"| roLogDB roConfig -->|"Linked Server"| roLogDB roLS -->|"53, 88, 389"| roDC

Diagram: the Logging Service and the Web API call each other on their Portal ports, the Logging Service connects to the Configuration and Log Databases, and it uses the domain controller for DNS and Kerberos.

Ports Set in the Nodinite Portal

On Windows Server, each Core Service is its own IIS web site on its own port. You set the ports per environment in the Nodinite Portal (Step 4: Servers – Core platform services), and the Portal lists them in Step 6: Allocated ports. Ports in examples, such as 40000–40004, are examples only. The installer CLI configures the IIS bindings from these values; it doesn't change your firewall rules.

Between the Logging Service and the Web API

The Web Client shows the state of the Logging Service to Users: it asks the Web API, which queries the Logging Service. The Web API finds the Logging Service through the ProductArtifactsPath System Parameter, set by the installer.

Direction Source Destination Protocol Port(s) Purpose Notes
Inbound Core Services Server (Web API) Core Services Server (Logging Service) TCP (HTTPS) Logging Service port Status and operations requested from the Web Client Set in the Portal; no rule needed unless a host firewall restricts local traffic
Outbound Core Services Server (Logging Service) Core Services Server (Web API) TCP (HTTPS) Web API port The Logging Service calls the Web API Set in the Portal; same server

Between the Logging Service and SQL Server

The SQL Server, MSDTC, and domain controller ports are shared by all Nodinite components; their full details live in SQL Server Firewall Configuration.

Direction Source Destination Protocol Port(s) Purpose Notes
Outbound Core Services Server SQL Server (Configuration and Log Databases) TCP 1433 Read settings, process Log Events, create and maintain Log Databases Default instance port; named instances and changed ports: Core Services to SQL Server
Outbound Core Services Server SQL Server 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 TCP 135 + dynamic RPC range MSDTC distributed transactions Configure MSDTC on both servers; see Core Services to SQL Server

The Configuration Database reaches the Log Databases, and the BizTalk tracking databases when you log from BizTalk Server, through Linked Servers; those SQL Server to SQL Server ports are on the Configuration Database prerequisites.

Between the Core Services Server and the domain controller

Direction Source Destination Protocol Port(s) Purpose Notes
Outbound Core Services Server 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 Domain Controller TCP/UDP 88 Kerberos authentication and delegation to SQL Server See Kerberos Configuration and Domain Controller ports
Outbound Core Services Server Domain Controller TCP/UDP 389 LDAP account and group lookups

What to get right

  • Default ports: the Logging Service and Web API ports have no fixed default; use the values in Allocated ports. SQL Server uses TCP 1433 unless you changed it.
  • Versions: Nodinite v7 replaced the fixed port of earlier versions with the Portal ports; see Why do Nodinite use port 8000 when you clean up old rules.
  • DNS (53): the Core Services Server must resolve the SQL Server names, including Always On listeners, and its own TLS host name.

Frequently asked questions

Additional solutions to common problems and the Nodinite Logging Service FAQ exist in the Troubleshooting user guide.

Note

Nodinite v6 is no longer supported. To move an existing v6 installation, follow Updating from v6 to v7.

Next Steps

Install Logging Service
Key System Parameters for Logging Service
Search Fields

Configuration Database
Core Services
LogAccessRoles
Log Databases
Logging Service
LogServiceUsers
Message Types
MSDTC
Search Fields
SQL Server Firewall
System Parameters
Troubleshooting
Trusted for delegation
Uninstall Logging Service
Update Logging Service
Users
Web API