Run Nodinite on Windows Server

Nodinite supports a traditional Windows Server installation path that remains the full operational baseline for production use. This runtime is the default option for organizations that need the complete installation footprint, including Windows-integrated authentication, IIS hosting, and the standard Windows service and agent model.

This guide explains what is available in the Windows path, what the runtime architecture looks like, and how it differs from the container-based runtime tracks.

Current Scope and Intended Usage

The Windows Server runtime is the standard deployment path for production and test environments where the complete Nodinite footprint is required.

• Nodinite Core Services run in IIS on Windows Server.
• Monitoring and logging agents can be installed as part of this runtime path.
• Windows authentication can be used, with OAuth 2.0/OpenID Connect also supported.
• This is the most complete runtime for environments that require full agent support and traditional enterprise hosting models.
• Use this path when you want the standard installation model instead of the experimental container-based tracks.

Important

The Windows Server installation remains the full baseline runtime. Container deployments currently focus on Core Services only and do not include the same agent coverage.

Understanding the Windows Runtime Architecture

The current Windows runtime model uses IIS-hosted Nodinite Core Services with a standard Windows-based identity and infrastructure model.

Diagram: The Windows Server runtime hosts Core Services in IIS, connects to SQL Server, supports Windows and OAuth-based identity patterns, and includes the broader agent model used in the standard installation path.

Authentication Model in Windows Server

The Windows Server deployment supports the standard Windows authentication model and also supports OAuth 2.0/OpenID Connect for modern identity integration.

• Use Windows-integrated authentication when the environment already relies on Active Directory and Kerberos.
• Configure OAuth 2.0/OpenID Connect when you prefer modern identity federation or mixed-platform access patterns.
• Environment-specific settings are managed in the standard installation and configuration flow for the selected deployment.

Service Accounts and Permissions

• gMSA accounts — Configure Group Managed Service Accounts (gMSA) for Nodinite services; eliminates manual password rotation
  • Install Certificates for gMSA — Install certificates required when running services under gMSA accounts
• Logon as a Service right — Grant the Windows "Log on as a service" right to Nodinite service accounts
• Trusted for delegation — Configure Kerberos constrained delegation for multi-hop authentication (web → app → SQL)
• Cannot read configuration file due to insufficient permissions — Resolve IIS access-denied errors reading web.config or appsettings.json

Kerberos and Authentication

• PACVerification — Disable PAC Validation to reduce DC round-trips when Kerberos ticket validation causes delays

Windows Services and Components

• Transactions MSDTC — Enable and configure Distributed Transaction Coordinator for cross-database transactions
• MSMQ Queue Access denied — Fix access-denied errors when Nodinite services read or write MSMQ queues

Configuration and Compatibility

• Configuration Error - targetFramework — Resolve ASP.NET targetFramework configuration errors after .NET upgrades
• Windows FIPS Mode Compatibility — Understand compatibility implications when Windows FIPS 140 mode is enforced on the server
• Why do Nodinite use port 8000 — Explanation of the default port 8000 and how to change it