SQL Server Requirements
Scope: SessionLimit 2.0
SessionLimit environment requires a supported SQL Server version and configuration to host the SessionLimit database.
SQL Server can be located on:
SessionLimit server computer,
A computer that is remote from the site server.
The following instances are supported:
The default or named instance of SQL Server,
A SQL Server Always On failover cluster instance,
A SQL Server Always On Availability Group.
Supported versions of SQL Server
In a hierarchy, SessionLimit server access the same SQL Server database:
The SQL Server versions you use remain in support by Microsoft.
For SQL Server 2016 and prior, support for each SQL Server version and service pack follows the Microsoft Lifecycle Policy. Support for a specific SQL Server service pack includes cumulative updates unless they break backward compatibility to the base service pack version
SQL Server 2019: Standard, Enterprise or Express. You can use this version with cumulative update 5 (CU5) or later, as long as your cumulative update version is supported by the SQL Server lifecycle. CU5 is the minimum requirement for SQL Server 2019 as it resolves an issue with scalar UDF inlining.
SQL Server 2017: Standard, Enterprise or Express. You can use this version with cumulative update version 2 or higher, as long as your cumulative update version is supported by the SQL Server lifecycle.
SQL Server 2016: Standard, Enterprise or Express. You can use this version with the minimum service pack and cumulative update supported by the SQL Server lifecycle.
SQL Server architecture version
Configuration Manager requires a 64-bit version of SQL Server to host the site database.
Database collation
SQL Server that's used for the database must use the following collation: SQL_Latin1_General_CP1_CI_AS.
Database compatibility level
The following table identifies the recommended compatibility levels for Configuration Manager site databases:
SQL Server 2016
130, 120, 110
130
SQL Server 2017
140, 130, 120, 110
140
SQL Server 2019
150, 140, 130, 120, 110
150
db_owner Role Is Required
db_owner Role Is RequiredIn SQL Server, assigning the db_datareader, db_datawriter, and EXECUTE permissions to a database user account grants basic access:
Read access to all tables and views
Write access to all tables and views
Ability to execute stored procedures and functions
However, these permissions are not sufficient for operations that require schema-level changes, dynamic object creation, or advanced maintenance tasks. In such cases, the user must be granted the db_owner role.
Why db_datareader, db_datawriter, and EXECUTE Are Insufficient
db_datareader, db_datawriter, and EXECUTE Are InsufficientThese permissions only cover basic data access and do not authorize tasks such as:
Creating, altering, or dropping database objects (tables, views, stored procedures)
Managing schema changes or deploying updates requiring structural modifications
Creating or modifying temporary tables or dynamic objects in complex stored procedures
Running dynamic SQL that interacts with system objects or requires implicit object creation
Performing index management, constraint changes, or rebuilding indexes
Executing database-level maintenance scripts or optimization tasks
As a result, certain scripts, procedures, or maintenance operations will fail due to insufficient privileges under the current permission model.
Why the db_owner Role Is Necessary
db_owner Role Is NecessaryGranting the db_owner role resolves the above limitations by providing full control at the database level, including:
Unrestricted object creation and modification (tables, views, stored procedures, functions, schemas)
Dynamic SQL and application processes that rely on temporary or dynamic object generation
Execution of database maintenance jobs (index rebuilds, statistics updates, etc.)
Full administrative access for deployments, updates, and troubleshooting operations
This role ensures that any application component, automation script, or administrative process can operate without encountering permission-related errors.
To ensure stable operations and prevent future permission issues, we recommend assigning the db_owner role to the service or application account in use.
This will:
Enable all required operations without disruption
Eliminate permission-based failures in dynamic or schema-altering processes
Support ongoing maintenance, optimization, and deployment tasks efficiently
Action Required:
Please provision the db_owner role for the relevant SQL Server account on the specified database.
USE [SessionLimit];
GO
CREATE USER [DOMAIN\gmsa_account_name$] FOR LOGIN [DOMAIN\gmsa_account_name$];
GO
ALTER ROLE [db_owner] ADD MEMBER [DOMAIN\gmsa_account_name$];
GO
Last updated