System.ComponentModel.Win32Exception: A required privilege is not held by the client while Deploying SSIS Project

My name is Archana CM from Microsoft SQL Developer Support team, we support SQL Connectivity issue along with data access technologies and SSIS.

We had a scenario where one of my customer was facing an issue while deploying SSIS Project in SQL Server 2012. In this blog today I am discussing on what was the issue while deploying the SSIS project and how we could resolve the issue.

While Deploying the SSIS Project to SSIS 2012, my customer was having a trouble and he could see the below error message, he had tried to deploy on different machines but still the issue was same. The main problem was, my customer was not using the default SSIS Service account "NT SERVICE\MsDtsServer110" to run SSIS service but rather he was using one of the domain accounts.

Error Message while deploying the SSIS project was

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.Win32Excepbon:

at Microsoft. SqlServer. IntegrationServices.Server.ISServerProcess.StartProcess(Soolean

bSuspendThread)

at Microsoft.SqlServer.IntegrationServices.Server.ServerApi.DeployProjectlnternal(SqlInt64 deployld,

SqIInt64 versionld, SqlInt64 projectld, SqlString projectName)

. (Microsoft SQL Server, Error: 6522)

From the above error message it’s very clear that issue is because of some permissions, and hence first suggestion was to add the user account under DCom.

1. Run Dcomcnfg.exe. Dcomcnfg.exe provides a user interface for modifying certain settings in the registry.

2. In the Component Services dialog, expand the Component Services > Computers > My Computer > DCOM Config node.

3. Right-click Microsoft SQL Server Integration Services 11.0, and then clickProperties.

4. On the Security tab, click Edit in the Launch and Activation Permissions area.

5. Add users and assign appropriate permissions, and then click Ok.

6. Repeat steps 4 - 5 for Access Permissions.

7. Restart SQL Server Management Studio.

8. Restart the Integration Services Service.

But in this case, these steps din’t help us to resolve the issue and more permission was required, we had to further dig deep to resolve it.

By default, for SSIS All rights are granted to the per-service SID for both default instance and named instance: NT SERVICE\MsDtsServer110. Integration Services does not have a separate process for a named instance.

Permission granted by SQL Server Setup to NT SERVICE\MsDtsServer110 are

Log on as a service (SeServiceLogonRight)

Permission to write to application event log.

Bypass traverse checking (SeChangeNotifyPrivilege)

Impersonate a client after authentication (SeImpersonatePrivilege)

In our case,my customer dint want to use the default account (NT SERVICE\MsDtsServer110) but he wanted to use the domain account as started earlier.

So here are the permissions we gave to the domain account under User Rights Assignment on SQL server machine.

Run-> Secpol.msc -> User Rights Assignment: Add the domain user to the below listed security privileges:

• Log on as a service (SeServiceLogonRight) : https://technet.microsoft.com/en-us/library/cc739424(v=ws.10).aspx

• Replace a process-level token (SeAssignPrimaryTokenPrivilege) : https://technet.microsoft.com/en-us/library/cc784623(v=ws.10).aspx

• Bypass traverse checking (SeChangeNotifyPrivilege) : https://technet.microsoft.com/en-us/library/cc739389(v=ws.10).aspx

• Adjust memory quotas for a process (SeIncreaseQuotaPrivilege) : https://technet.microsoft.com/en-us/library/cc736528(v=ws.10).aspx

• Permission to start SQL Writer

• Permission to read the Event Log service

• Permission to read the Remote Procedure Call service

Also we captured the process monitor trace (Download available at https://technet.microsoft.com/en-us/sysinternals/bb896645.aspx ) , we could see that "isdeploymentwizard.exe" was having permission issue in below registry Keys. After adding the domain account under all the below registry key, we were able to resolve the issue completely.

The result of process monitor may defer based on the account with which SSIS service need to be executed and serve machines, run the tool on individual machine to provide the permission to the registry keys for the account with which SSIS service need to be executed.

Some of the Reference Links

Integration Services (SSIS) Projects

https://msdn.microsoft.com/en-us/library/ms138028.aspx

Deploy Projects to Integration Services Server

https://msdn.microsoft.com/en-us/library/hh231102

Comparison of Deployment of Projects and Packages

https://msdn.microsoft.com/en-us/library/hh213290

Author : Archana(MSFT) SQL Developer Engineer, Microsoft

Reviewed by : Snehadeep(MSFT), SQL Developer Technical Lead, Microsoft

Comments

• Anonymous
  September 15, 2013
  The comment has been removed

• Anonymous
  November 12, 2013
  I'm still struck, thanks for this "nice feature". Two days and still doesn't work.

• Anonymous
  December 30, 2013
  I was struggling with this error for more than 2.5 months and finally able to resolve the error by adding the sql server engine account under replace a process level token and adding the sql server engine account also under dcomcfng.exe as explained above and restarting sql server engine and ssis helped resolved this finally.

• Anonymous
  April 18, 2017
  Hi Team. This post has been very helpful. Please I can't deploy my ETL project, having the same errors you have above. The first three steps of the deployment were successful, only the last step failed (deploying project)1) I am using a service account to run the SQL server Agent job. 2) I have given all the required permissions as you stated above. 3) I am currently using the process monitor to check the isdeploymentwizard.exe. I am not having the errors you have above but I have some NOT FOUND.Can someone help me? How can I add a domain account under a registry key as you stated above. Thanks.

• Anonymous
  August 20, 2018
  The comment has been removed

  • Anonymous
    August 30, 2018
    Can you please check with your Active Directory Admin team, if there are any domain group level policies and confirm