Prerequisites for the Logging Service
The Log Database sits in the end of the "spider web" and on a single box machine you may have virtually no administration at all to get everything working. On the other hand, in a locked down distributed environment spanning multiple servers with network load balancing, firewalls, network zones (WLAN's), domains, DNS, group policies, anti virus/anti malware, SQL Server clusters, SQL Server Always On, ... you may end up spending a lot of hours to get every piece of the puzzle in place.
Rest assure, Nodinite is built on Microsoft standard products and these form the very foundation for most enterprise business applications of today. We are working hard on cloud enabling Nodinite as the required services mature one piece at a time to make sure you get a future proof solution for your business.
|Trusted for delegation|
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)
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 able to function
- This service should always be running.
- This service should not be clustered, contact our support if you need technical assistance
- The Logging Service may have to be restarted when changing some of the System Parameters or Log Agent Configuration settings.
The Logging Service initiates a process that may span multiple Log Databases and also some BizTalk Server Databases if Logging from BizTalk is enabled. In order for the account, running the Logging Service, to authenticate with SQL Server, Kerberos must be properly configured. This is detailed in the Trusted for delegation part of the Log Database prerequisites user guide.
For performance reasons the Logging Service accesses the databases directly using the Windows Service Account configured.
The Logging Service must have the following SQL rights assigned:
Apply settings for The Windows account used for running the Logging Service (Windows Service)
The account running the Logging Service must exist on each SQL server node.
- public - Rights to logon to instances and databases
- dbcreator - Rights to create new IMLog databases
- diskadmin - Rights to create database files for new databases
- securityadmin - Rights to assign rights on new databases
- db_ddladmin - se note below
- Shrink Rights - Nodinite performs 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. See more here
Note: db_ddladmin is required in order for the service account to have proper rights to read statistics. Without this permission performance may be degraded, especially true for remote servers (linked servers). Read more here. Contact our support if you have any questions about this.
Apply settings on each and every SQL instance where Nodinite databases are hosted.
You must repeat the security settings on all nodes if you are using SQL Server High Availabilty.
|< SQL Server 2016||>= SQL Server 2016|
- Grant Execute rights on all existing and future stored procedures:
Replace [Domain\user] with the Windows account being used for the Logging Service
GRANT EXECUTE TO [Domain\user]
- sysadmin or at least db_owner
NodiniteLog* (can be multiple )
- sysadmin or at least db_owner
Note: **See specific text for SQL instance above for membership in either sysadmin and/or db_owner for automatic shrink of Nodinite related databases
The Logging Service requires both inbound and outbound ports to be opened. Since Nodinite is highly configurable, the actual ports in use may differ from what's being exampled here.
- TCP Ports between Logging Service and Web API
- TCP Ports between Logging Service and SQL Server You must ensure that TCP ports used are allowed by your firewalls, depending on location of the SQL database the actual ports used may differ. The following Windows Services are involved:
|53||DNS||The Agent needs to know where your other servers/services are (can sometimes optionally be solved using entries in the local hosts file), 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|
Nodinite shows the state of the Logging service for Users within the Web Client. The Web Client asks the Web API which in turns queries the Logging Service. The Logging Service uses the Web API to provide all its features.
You must ensure that TCP ports used are allowed by your firewalls, depending on location of the SQL database the actual ports used may differ. The following Windows Services are involved:
- RPC Ports, kerberos 88 TCP
- SQL Server ports, usually 1433, depends on your actual configuration
- DTC - Facilitates transactional support
- DNS - Windows needs to know where your servers are (can of course also be solved using hosts)
- 53 both TCP/UDP