SSIS Package Deployment Error on SQL Server 2019 Enterprise - error occurred during execution of user-defined ... aggregate "deploy_project_internal"

Question

I have the following error while deploying SSIS package:

A .NET Framework error occurred during execution of user-defined routine 
or aggregate "deploy_project_internal": System.ComponentModel
.Win32Exception: A required privilege is not held by the client 
System.ComponentModel.Win32Exception: at 
Microsoft.SqlServer.IntegrationServices.Server.ISServerProcess
.StartProcess(Boolean bSuspendThread) 
at Microsoft.SqlServer.IntegrationServices.Server.ServerApi.
DeployProjectInternal(SqlInt64 deployId, SqlInt64 versionId, SqlInt64 projectId, 
SqlString projectName) . (Microsoft SQL Server, Error: 6522)

picture from SQL Server Management Studio

I use: SSIS version 4.3 deploy it on SQL Server 2019 with SQL Server Management Studio 18.11.1

Everything works fine on the test environment with the same software stack as on production (where the described problem exists). I suppose, that because of the fact that on the problematic production environment there are more restrictive domain settings, so something is blocking the deployment.

I found similar posts:

• SSDT 2012 - ssis deployment error - Stack Overflow

• SSIS Deployment Error while deploying packages into SQL Server

Following the advises from the above post I repaired the SQL server installation, but they haven’t helped.

Answer 1

If you encounter an error

A .NET Framework error occurred during execution of user-defined routine or aggregate “deploy_project_internal“: System.ComponentModel.Win32Exception: A required privilege is not held by the client

then make sure that the SQL Server service account is added to the Local security policy “Replace a process level token” in ‘User Rights Assignments‘ in the secpol.msc console. A restart of the SQL Server service is required to change the permissions.

Answer 2

I encountered a problem where the Local Security Policy “Replace a process level token” did not have the NT SERVICE\MSSQLSERVER rights. This was due to the fact that the company's network security policies did not allow it for some reason. To make the necessary change without altering the overall security policies inherited from the domain, I had to modify the virtual machine by running SQL Server on the NETWORK SERVICE (NETWORK SERVICE was in the “Replace a process level token”).