Prerequisites for the Nodinite Configuration Database
This page describes the prerequisites to successfully install the Nodinite Configuration Database. The Nodinite Configuration Database, is a SQL Server database, and is installed in a SQL Server instance.
Nodinite Configuration Database Checklist
The Configuration Database sits in the middle 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/antimalware 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 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.
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.
SQL Server
You can run SQL Server on Windows Servers implemented on physical machines, virtual machines and in the cloud. Actual Windows version used must match the prerequisites for SQL Server version being used.
Important
It's you (or your IT-organization/hosting partner/...) responsibility to backup the Nodinite Configuration Database regularly, at least once per day.
Please review the following articles about SQL Server for use with Nodinite:
SQL Server related optimizations
To maximize your experience with Nodinite you should implement all the suggestions below:
- Nodinite should run in dedicated SQL instances to guarantee/dedicate HW resources and avoid competing demands for resources, aid in the troubleshooting and avoid blame game situations
- At least assign dedicated disk volumes for the Log Databases to make sure extended logging does not fault any other system/service
- Keep the Logging Service close to the SQL Servers hosting the Log Databases for Nodinite
Do repeat optimizations below on ALL SQL Server instances (Configuration Database, Log Databases, BizTalk Databases)
- Use -T1118 Trace flag on SQL Instances (<2016) - Optimizes TEMPDB
- Disable PAC Verification if your policy allows for this option to be set on all Windows Servers running any of Nodinite Core Services - Less RPC calls, improves performance
- Nodinite should be installed on machines with dedicated Windows swap volumes (>2,5*physical RAM) and SQL discs should have > 300 MB/S R/W.
- There should be a secured backup volume (or network share) available with sufficient free space for Nodinite databases
- Windows Servers hosting any of the Core Services should have at least 16GB RAM. Environments with a large number of messages logged and processed may need additional RAM
- For each core assigned with your SQL Instance (up to 8), create 1 tempdb file with 128 MB in size (no autogrowth)
If you have 14 cores that means you have 8 tempdb files. Putting the tempdb files on different volumes may increase overall performance of your system
- Nodinite Log Databases, when used together with BizTalk should be kept in Simple recovery mode (default)
Microsoft Distributed Transaction Coordinator (DTC)
The Configuration 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
What Windows rights does the Configuration 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 BizTalk tracking database it will be the configured account that actually performs the remote operation. For the Windows Integrated Security to be able to pass and authenticate the user identity across servers all tasks outlined at the checklist in the beginning of this tutorial must be properly configured.
The Configuration Database is a SQL Server database and is installed as part of the Core Services package. Since the Configuration 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.
For Kerberos to work then the servers must be properly configured:
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) have its SPNs registered in Active Directory.
Example1: If you have a single box server with BizTalk, SQL Server and Nodinite you don't have to register the SPN (not a distributed environment)
Example2: If you have Nodinite Configuration Database installed on one Windows Server with a SQL default instance and BizTalk in another two node fail-over cluster running 2 SQL instances (1 default and 1 named instance), one for other BizTalk databases and one dedicated for the messagebox (BizTalkMSGBoxDb) you will have to register 7 SPNs in total (1 for Nodinite, 3 for the BizTalk instance, 3 for the BizTalk Messagebox instance)
- SQL Server name for default instance with Nodinite Configuration Database
- SQL Server first node name for default instance with BizTalk databases
- SQL Server second node name for default instance with BizTalk databases
- SQL Server cluster name for default instance with BizTalk databases
- SQL Server first node name for named instance with messagebox database
- SQL Server second node name for named instance with messagebox database
- SQL Server cluster name for named instance with messagebox database
SQL Server Default Instance
The following example registers accountname for the default SQL Instance using an elevated command prompt (requires 'Domain Admin' rights):
setspn -S MSSQLSvc/myhost.redmond.microsoft.com accountname
SQL Server Named Instance
The following example registers accountname for the named SQL Instance using an elevated command prompt (requires 'Domain Admin' rights): repeat for each combination of named instance/accountname.
setspn -S MSSQLSvc/myhost.redmond.microsoft.com:instancename accountname
What SQL Rights does the Configuration Database require?
For performance reasons, the Configuration Database accesses the databases directly using the Windows Service Account configured. The Configuration Database must have the following SQL rights assigned:
All SQL Instance(s) where Configuration Database and Log Databases are installed:
- public - Rights to login to instances and databases
- dbcreator - Rights to create new Log Databases
- diskadmin - Rights to create the database files in Windows for new Log Databases
- securityadmin - Rights to assign the proper access rights on new Log Databases, please review the following System Parameters:
Remember, privileges do not replicate automatically on SQL Server Always on environments. Nodinite does this job for you.
- db_ddladmin - see note below
- Shrink Rights - Old Log Databases must be shrunk to regain allocated disk space, and the shrink operation requires membership in the sysadmin fixed server role or the db_owner fixed database role. See more here
Info
db_ddladmin is required 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.
All Nodinite specific databases
-
- db_datareader
- db_datawriter
- db_ddladmin
- sysadmin or at least db_owner
Log Databases (can be multiple )
- db_datareader
- db_datawriter
- db_ddladmin
- sysadmin or at least db_owner
Note
**See specific text for SQL instance above for membership in either sysadmin and/or db_owner for the automatic shrink of Nodinite related Log Databases
What Firewall settings are required for the Configuration Database?
The Configuration Database 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.
The following image shows which Core Services are using the Configuration Database:
- TCP Ports between Nodinite Core Services and the Configuration Database
- TCP Ports between Configuration Database and Log Databases / BizTalk SQL Server
The Log API, Web API, Logging Service and the Monitoring Service accesses the Configuration Database using the configured Windows Service Account.
1. TCP Ports between Nodinite Core Services and the Configuration Database
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 |
2. TCP Ports between Configuration Database and Log Databases / BizTalk SQL Server
The following Windows Components are accessing the Configuration Database and used/configured ports must be allowed, follow each link for details:
- DTC
- Trusted for delegation
- Windows rights
- SQL rights
- SPN registered
Linked Servers
Nodinite uses the SQL Server concept of Linked Servers. The Install and Update Tool requires these, to be properly configured BEFORE installing Nodinite.
Review and follow the steps further detailed in the linked servers section
Frequently asked questions
Additional solutions to common problems and the Nodinite Configuration Database FAQ exist in the Troubleshooting user guide.
Where do I add my custom built Search Field Plugins?
You simply copy the DLL to the 'Plugins' folder of the Configuration Database. If the DLL is being replaced then you must restart the Logging Service.
Important
Make sure the DLL after the copy paste operation is not blocked by Windows. Right-click on the DLL and select properties. Click the Unblock button if that option exists
Next Step
Install Nodinite
System Parameters