- 9 minutes to read

BizTalk Server Logging Prerequisites for Nodinite

Unlock secure, high-performance BizTalk Server logging and monitoring with Nodinite. This page provides everything you need to connect BizTalk DTA data to Nodinite, ensuring robust integration, compliance, and visibility for your business-critical processes.

On this page, you’ll learn how to:

  • ✅ Connect BizTalk DTA databases to Nodinite for seamless, secure logging
  • ✅ Set up Linked Servers and firewall rules for reliable, uninterrupted data flow
  • ✅ Configure user rights, SQL permissions, and Active Directory for compliance
  • ✅ Avoid common pitfalls with clear, actionable steps

How BizTalk Data Flows to Nodinite

graph TD User[BizTalk Admin/User] --> BizTalkDTA[BizTalk DTA Database] BizTalkDTA -->|Linked Server| NodiniteSQL[Nodinite SQL Server] NodiniteSQL --> LoggingService[Nodinite Logging Service] LoggingService --> NodiniteApp[Nodinite App Server]

This diagram shows how BizTalk DTA data flows through Linked Servers to Nodinite’s Logging Service and App Server for monitoring and analysis.

Step 1: Prepare Linked Servers

Nodinite requires Linked Servers to be configured on the Configuration Database SQL instance to access BizTalk databases (BizTalkMgmtDb and BizTalkDTADb). Linked servers must be created before you configure and enable logging.

Tip

Comprehensive Linked Servers Guide: 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
  • Troubleshooting common linked server connectivity issues

Note

If BizTalkMGMTDb and BizTalkDTADb are on different SQL Server instances, create two Linked Servers.

Step 2: Configure Firewall Settings

Nodinite Logging Service requires proper firewall configuration to fetch data from BizTalk SQL Instances. Ensure the necessary ports are open for SQL Server, Kerberos authentication, and distributed transactions.

Tip

Comprehensive SQL Server Firewall Guide: See the complete SQL Server Firewall Configuration page for:

  • Detailed port requirements for on-premise SQL Server (1433, 135, RPC dynamic ports)
  • Always On Availability Groups (AOAG) firewall configuration
  • Kerberos and Active Directory authentication ports (88, 389, 636, 445)
  • RPC dynamic port allocation and restrictions
  • Troubleshooting common connectivity issues
  • Testing connectivity with PowerShell commands

Step 3: Set Up Security and User Rights

The Nodinite Logging Service accesses BizTalk databases through Linked Servers. The account that needs permissions depends on your linked server security context configuration:

  • Passthrough authentication (recommended): The service account running the Logging Service needs SQL permissions on BizTalk databases
  • Impersonation: The account specified in the linked server security mapping needs SQL permissions

Tip

Service Account Options: See comprehensive guides for configuring service accounts:

  • gMSA accounts — Group Managed Service Accounts with automatic 30-day password rotation (Nodinite v7+)
  • Logon as a Service right — Traditional service accounts with manual password management

For detailed information about linked server security context (passthrough vs impersonation), see the Linked Servers guide.

Account Type Best Practices:

  • ✅ Domain accounts (recommended) — Required for distributed solutions with Kerberos authentication
  • ✅ gMSA accounts (Nodinite v7+) — Automatic password rotation, enhanced security
  • ⚠️ Local accounts — Only for single-server test/dev setups
  • ⚠️ SQL accounts — Temporary workaround if BizTalk SQL Instance allows mixed logins; Windows authentication with Kerberos is recommended for production

Step 4: Assign SQL Permissions

The account in use on the Linked Server that the Nodinite Logging Service use must have these SQL grants set on the following BizTalk SQL instances:

The following table summarizes the required SQL Server permissions for the account used by the Nodinite Logging Service to access BizTalk databases. Each permission ensures secure and reliable data extraction for logging. Review the descriptions and follow the links for more details on each SQL Server role.

Database Permission Description Microsoft Docs Link
All Instances public Allows basic logon rights to the BizTalk SQL Instances public Database Role
BizTalkDTADB db_datareader Grants read access to all tables and views db_datareader
BizTalkDTADB db_ddladmin Allows running DDL statements (e.g., create/alter/drop objects) db_ddladmin
BizTalkMGMTDB db_datareader Grants read access to all tables and views db_datareader
BizTalkMGMTDB db_ddladmin Allows running DDL statements (e.g., create/alter/drop objects) db_ddladmin

This table lists the minimum SQL Server permissions required for the Nodinite Logging Service to access and process BizTalk DTA and MGMT database data. Ensure these grants are set for uninterrupted logging and monitoring.

Step 5: Configure Active Directory for Kerberos

  • For single-server solutions, Kerberos configuration is not required.
  • For distributed solutions (multiple servers/instances), configure Kerberos - Set "Trusted for delegation" on all Windows Servers and register SPNs for all SQL Instances.

Tip

Service Principal Names (SPN) Registration:
See the comprehensive Service Principal Names (SPN) guide for:

  • When SPN registration is required for Windows authentication
  • Registration commands for default instances, named instances, and clusters
  • Scenario-specific examples (including 7-SPN cluster configurations)
  • Validation with Microsoft Kerberos Configuration Manager tool
  • Troubleshooting common Kerberos authentication issues

Step 6: Review DTC/MSDTC Configuration Review DTC/MSDTC Configuration

Ensure MSDTC is configured and running on all involved servers. See the MSDTC guide for details.

Visual Summary: End-to-End BizTalk Logging Flow

flowchart TD subgraph BizTalk SQL Server A[BizTalk DTA Database] B[BizTalk MGMT Database] end subgraph Nodinite SQL Server C[Nodinite SQL Instance] end subgraph Nodinite App Server D[Nodinite Logging Service] E[Nodinite App] end A -- Linked Server --> C B -- Linked Server --> C C -- Logging Service --> D D -- Data to App --> E

This diagram summarizes the end-to-end flow from BizTalk DTA/MGMT databases to Nodinite’s Logging Service and App for monitoring and analytics.

Next Step

Nodinite requires Linked Servers to be configured on the Configuration Database SQL instance to access BizTalk databases (BizTalkMgmtDb and BizTalkDTADb). Linked servers must be created before you configure and enable logging.

Tip

Comprehensive Linked Servers Guide: 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
  • Troubleshooting common linked server connectivity issues

Note

Multiple SQL Instances: If you have BizTalkMGMTDb and BizTalkDTADb on different SQL Server instances, you need two Linked Servers.

What Firewall settings are required for enabling Logging from BizTalk Server

In addition to the firewall settings already in place for the Logging Service, you must also enable the ports specified in this section.

To retrieve data from BizTalk Server, the Logging Service fetches data directly from the SQL Instances for BizTalk Server with the BizTalkMsgBoxDb and the BizTalkDTADb database. These databases may exist on different SQL Instances. These may have different sets of ports in use.

The following sections detail firewall requirements organized by service. Three types of servers participate in the logging interchange:

  • Nodinite Server - Where the Nodinite Logging Service is installed
  • SQL Server - SQL Server instances hosting BizTalk databases (BizTalkMgmtDB, BizTalkDTADb, BizTalkMsgBoxDb)
  • Domain Controller (DC) - Active Directory server for Kerberos/LDAP authentication (when using Windows authentication)

SQL Server Connection (Nodinite Server → BizTalk SQL Servers)

Required for connecting to BizTalk databases (BizTalkMgmtDB, BizTalkDTADb, BizTalkMsgBoxDb) via Linked Servers. The Logging Service connects directly to these SQL instances to fetch log data.

Tip

Comprehensive SQL Server Firewall Guide: See the complete SQL Server Firewall Configuration page for:

  • Detailed port requirements for on-premise SQL Server
  • Always On Availability Groups (AOAG) firewall configuration
  • RPC dynamic port allocation and restrictions
  • Troubleshooting common connectivity issues
  • Testing connectivity with PowerShell commands
Direction Source Destination Protocol Port(s) Purpose Notes
Outbound Nodinite Server SQL Server TCP 1433 SQL Server default instance Default port. Named instances use dynamic ports in range 49152–65535
Outbound Nodinite Server SQL Server TCP 49152–65535 SQL Server named instances Dynamic port range. Check SQL Server Configuration Manager for specific port
Outbound Nodinite Server SQL Server TCP 135 RPC Endpoint Mapper Required for MSDTC distributed transactions and Linked Server communication
Inbound SQL Server Nodinite Server TCP Same as outbound Response traffic Automatically allowed by stateful firewall inspection

Tip

Multiple SQL Instances: BizTalkMgmtDB and BizTalkDTADb may be hosted on different SQL Server instances. Ensure firewall rules allow the Nodinite Server to reach all SQL Server instances hosting BizTalk databases. Create separate Linked Servers for each SQL instance.

Authentication (Nodinite Server → Domain Controller)

Required when using Windows authentication for SQL Server connections. Kerberos must be properly configured for distributed solutions with multiple servers.

Direction Source Destination Protocol Port(s) Purpose Notes
Outbound Nodinite Server Domain Controller TCP/UDP 88 Kerberos authentication Required for domain authentication. Review 'Microsoft Kerberos' user guide
Outbound Nodinite Server Domain Controller TCP/UDP 389 LDAP Standard LDAP queries for Active Directory
Outbound Nodinite Server Domain Controller TCP 636 LDAPS (Secure LDAP) Required for secure LDAP authentication
Outbound Nodinite Server Domain Controller TCP 445 SMB Used if Group Policy or certificate access is needed
Inbound Domain Controller Nodinite Server TCP/UDP Same as outbound Response to Kerberos / LDAP Usually allowed by stateful firewall inspection

Note

DNS Resolution: All servers (Nodinite Server, SQL Servers, and Domain Controllers) require outbound access to DNS on TCP/UDP port 53 for name resolution. You can optionally solve this using entries in the local hosts file on each server. Review 'DNS works on TCP and UDP' user guide.

Tip

Single Server Solutions: For single-box solutions where Nodinite and BizTalk databases are on the same server, Kerberos configuration and most firewall rules are not required.

Important

Stateful Firewalls: Most modern Windows Firewall implementations are stateful, meaning inbound response traffic for established outbound connections is automatically allowed. The inbound rules listed above are primarily for reference and troubleshooting scenarios where stateful inspection may be disabled or restricted.

Security

User rights

  • Use Domain accounts for best practice. Use local accounts only for single server solutions (Test, QA, DEV, POC....)

    You can use a SQL account (bypassing Kerberos) if the SQL Instance for the BizTalk databases allows for mixed logins. We recommend using Windows accounts. If you use Windows Authentication, you must configure Kerberos properly.

SQL Rights

The account running the Logging Service for BizTalk Server Logging must have the following SQL rights to read events and messages from the BizTalk databases:

SQL Instance(s)

On all SQL instances with the listed BizTalk databases:

  • public - You must have the right to logon to the SQL Instances for BizTalk Server

BizTalkDTADB

  • db_datareader
  • db_ddladmin

BizTalkMGMTDB

  • db_datareader
  • db_ddladmin

Active Directory Configuration

  • For single box solutions, you do not need to configure Windows to enforce the use of the Kerberos security protocol.
  • For distributed solutions, for example when you install Nodinite on one (or more) server(s), and the databases are also located on multiple SQL instances, you must use Kerberos.

For Kerberos to work, you must properly configure Active Directory for all involved Windows Servers:

  • Trusted for delegation
  • All SQL Instances (both physical node names and cluster names) must have their SPNs registered - see the comprehensive Service Principal Names (SPN) guide for registration commands, examples (including 7-SPN cluster configurations), and troubleshooting

DTC/MSDTC

Review the MSDTC user guide for additional information.

Next Step