LogAccessRoles - System Parameter
LogAccessRoles lists the SQL Server database roles that the Logging Service grants on each new Log Database to the service accounts in LogServiceUsers. It is one of the System Parameters applied in How a new Log Database is created.
At a Glance
| Property | Value |
|---|---|
| Key | LogAccessRoles |
| Data type | string (database roles, separated by semicolons) |
| Default | db_datareader;db_datawriter;db_ddladmin |
| Read by | Logging Service |
| Takes effect | Within about 15 seconds; no restart needed. Applies to the next Log Database the Logging Service creates. |
| Status | ✅ Active |
| Since | Nodinite 3; renamed from ImLogAccessRoles in Nodinite 7 |
How It Works
When the Logging Service creates a new Log Database, it gives every account in LogServiceUsers access to it with each role in this list. The two parameters work as a pair: LogServiceUsers says who, LogAccessRoles says what. Existing Log Databases are not changed.
Assigning roles needs the securityadmin server role (or sysadmin) for the Logging Service account. Without it, new Log Databases get no service account access until a DBA grants it; see SQL Server Sysadmin Requirements.
Value Format
A semicolon-separated list of SQL Server database roles, without spaces:
db_datareader;db_datawriter;db_ddladmin
Choosing a Value
- Keep the default; it follows the principle of least privilege and is what the Nodinite Core Services are set up to use.
- Change it only when your DBA requires a different model, for example a custom role your organization uses, and check that every service still works against the next new Log Database.
Frequently Asked Questions
Can I assign access rights manually?
Yes, and you must when you create Log Databases manually or the Logging Service lacks securityadmin. Grant the same roles to the same accounts; the SQL rights for the Log Database and the Prerequisites & Permissions checklist on the Core Services page list what each service needs.