- 4 minutes to read

The BizTalk Logging Agent has the following prerequisites for the target environment

This page describes the prerequisites for enabling Logging from BizTalk Server to Nodinite.

graph LR subgraph "Nodinite App Server" roLoggingService(fal:fa-hard-drive Logging Service) end subgraph "
Nodinite SQL Server" roLoggingService --> |High privileges|roNI roNI(fal:fa-database Nodinite SQL Server Instance) end subgraph "BizTalk SQL Server" roNI --> |Linked Server
Low privileges| roBTMgmtDB(fal:fa-database BizTalkMgmtDb) roNI --> |Linked Server
Low privileges| roBTDTADb(fal:fa-database BizTalkDTADb) end

Currently, the Logging Service hosts the BizTalk Server Logging feature, and therefore, you must make sure to meet the Prerequisites for that service.

If you want to enable the feature Logging from BizTalk Server, in addition to the Logging Service - Prerequisites, you must also make sure to meet the requirements documented on this page.

In the case BizTalk Server databases (BizTalkMgmtDb and BizTalkDTADb) are installed on remote SQL instances, Nodinite jumps to these remote SQL instances using the concept of Linked Servers. So, make sure to manually add the Linked Servers accordingly on your Nodinite SQL instance before configuring and enabling the Logging.

Note

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 set of ports in use.

  1. Between the Logging Service and the BizTalk Server instances
Port Name Inbound Outbound TCP UDP Comment
53 DNS The Agent needs to know where your other servers/services are (can sometimes optionally be solved with user-defined entries in the hosts file in each Windows server instance), review the following 'Microsoft' user guide
88 Kerberos Review 'Microsoft Kerberos' user guide
135 DTC/RPC This port is shared between many Windows Services
1433/... SQL Server instance ports (multiple) Depends on policies and settings on target environment. Please review the How to configure RPC dynamic port allocation to work with firewalls user guide

Security

User rights

  • We generally recommend the use of Domain accounts. Local accounts can/should be used only for single server solutions (Test, QA, DEV, POC....)

    It is possible to use a SQL account (bypassing Kerberos), if the SQL Instance for the BizTalk databases allows for the use of mixed logins. We recommend to stick with Windows accounts. In the case of Windows Authentication, Kerberos must be properly configured.

SQL Rights

The account running the Logging Service when used for Logging from BizTalk Server, must have the following SQL rights assigned to be able to read events and messages from the BizTalk databases:

SQL Instance(s)

On all SQL instances with the listed BizTalk databases:

  • public - 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, there is no additional need to configure Windows to enforce the use of the Kerberos security protocol.
  • For distributed solutions, for example when Nodinite is installed on one (or more) server(s), and the databases are also located on multiple SQL instances, Kerberos must be used.

For Kerberos to work, the Active Directory must be properly configured for involved Windows Servers:

  • Trusted for delegation

  • All SQL Instances (both physical node names and cluster names) must have their SPNs registered in the Active Directory SPN
    Example: If you have Nodinite on one SQL default instance and BizTalk in a two node cluster running the messagebox in its own instance you will register 7 SPN's in total (3 for the BizTalk default/named instance, 3 for the BizTalk Messagebox instance and 1 for Nodinite)

If you are reading this text, chances are your SQL Server instances are running with accounts that do not have the right, upon service start, to register the SPN with Active Directory. This may happen, if you are running the SQL Server instance with a local account, or a domain account that lacks the rights to register the service (SPN). If so, the latter is logged in the SQL Server audit log. read more here

Default instances

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

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

Named Instances

The following example registers accountname for the named SQL Instance using an elevated command prompt (requires AD domain rights): repeat for each combination of named instance /accountname.

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

In order to validate what SPNs are registered for the account running the SQL Instance, execute the following command:

setspn -l accountname

DTC/MSDTC

Review the MSDTC user guide for additional information.

Next Step