Compartilhar via

Error While Deploying SSIS 2012 project from SSDT to SSIS Catalog : System.ComponentModel.Win32Exception: A required privilege is not held by the client

  • Artigo

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.

I ran across this issue in one of my newly set up Sql 2012 Servers when I tried to deploy a project to the SSIS Catalog using the Project Deployment Model. I set Sql 2012 up in 3-4 of my servers and never encountered this before. I was using my same domain account across all the Servers. I tried to grab a profiler but could not find any calls to the system stored procedures used for deployment, so my guess was the call is not even reaching to Sql.

After spending a few hours, I was actually able to get past the problem even though I’m not sure if I found out the exact cause! In this case, I’m pretty sure that SSIS is doing a CreateProcessAsUser() using my account credentials, and the SQL/Agent service account is not involved. The SSIS Catalog only accepts Windows Auth (because it does account impersonation during deployment, validation and execution).

Since the deployment process is making call to an executable residing in the file system (outside of Sql), I suspected that the Sql Server Service Account would come into question . I changed the Sql Server Service Account from built in default “Nt Service\MSSQLSERVER” (New account introduced in Denali) to another account with admin rights on the system and VOILA!! it started working.

This seems to be an issue specific to the Sql Service account permissions; however I could not reproduce the problem in my other machines though my service runs as “Nt Service\MSSQLSERVER”. I believe it has something to do with the group policy. SSIS is launching the external process to do the deployment (ISServerExec) in much the same way that SQL Agent runs its jobs. In similar SQL Agent cases, it looked like service account requires the “Act as part of the operating system” account policy.

 

Author : Debarchan(MSFT) SQL Developer Engineer, Microsoft

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

Comments

  • Anonymous
    January 21, 2013
    I havent restarted the SQL service after changing the settings and this didnt resolve my issue... Do I need to restart the service too ? Please be clear. Thanks !

  • Anonymous
    January 21, 2013
    Please specify the changes performed by you. Did you try changing the SQL Server service account to run under any local admin account. Any changes to the service account will automatically request for the service restart. or if you talking about “Act as part of the operating system” account policy, then this change wouldn't require any restart of the service. Please let us know about the changes performed by you.

  • Anonymous
    January 21, 2013
    About this change : -- talking about “Act as part of the operating system” account policy, then this change wouldn't require any restart of the service. It definitely needed a machine reboot ! and it fixed my issue. I went back and did my own research work and learnt that Act as a part of the operating system doesn't get initialized unless the OS is rebooted [as per Mark Russ ( Windows Guru )]. Please make the necessary change to your article , so that it will help others like me ( and they don't end up wasting their time ).

  • Anonymous
    February 20, 2013
    Max, Thanks, will update the article accordingly.

  • Anonymous
    May 07, 2013
    Any updates on what causes this? And if there is a hotifx available? I might be able to fix the problem, but it might return at any moment as well...  Thanks in advance!

  • Anonymous
    May 08, 2013
    Also, these rights/policy changes didn't work for me. I had to repair my SQL Server install and then it worked again.

  • Anonymous
    May 15, 2013
    ...and then it stopped working again. Have done the repair again and that fixed it, but I'm afraid the problem will re-appear after the next reboot :-/

  • Anonymous
    May 15, 2013
    Jorg, This seems to be lingering. Is there a way you could open a support request with Microsoft PSS to investigate this further?

  • Anonymous
    July 01, 2013
    The comment has been removed

  • Anonymous
    July 01, 2013
    The comment has been removed

  • Anonymous
    July 16, 2013
    Happen to resolve this issue with one of my customers after following the below steps. -> Note down your SQL Server Service account & SQL Agent Service account. -> Go to Start-> Run-> secpol.msc-> Local Policies->User Rights Assignment   check if these 2 accounts are a part of the following policies.       -> Log on as a service       -> Act as part of OS       -> Adjust memory quotas       -> Logon as batch job       -> Replace a process level token -> If not, add them explicitly. -> Reboot the machine. Be sure that the domain level group policy settings aren't overriding these settings. [Note: Any deny permissions will have precedence over grant permissions]

  • Anonymous
    September 14, 2013
    Realy suffered by this issue. What is solution to fix this one?

  • Anonymous
    September 30, 2013
    Hi, the missing permission is the following: Replace a process-level token (SeAssignPrimaryTokenPrivilege). Apply this right to the SQL-Engine-Account and restart the Engine. Then the deployment should work again. See: blog.oraylis.de/.../fixing-sql-2012-ssis-deployment-error-6522-a-required-privilege-is-not-held-by-the-client

  • Anonymous
    June 01, 2014
    Guys, I followed both these links blog.oraylis.de/.../fixing-sql-2012-ssis-deployment-error-6522-a-required-privilege-is-not-held-by-the-client blogs.msdn.com/.../system-componentmodel-win32exception-a-required-privilege-is-not-held-by-the-client-while-deploying-ssis-project.aspx and above steps, But none of them solved my problem. Then I repaired my SQL Server instance which fixed my issue. Thanks

  • Anonymous
    May 13, 2015
    Based on my observation, this happens when the SQL Server is set to run under the built in network account, but the Agent under a Windows account. So the security handshake does not occur (no delegation). Thus the remedy is in having the both services run under the same account.

  • Anonymous
    August 24, 2015
    Your suggestion did not work for me. What did end up working was the following: blog.oraylis.de/.../fixing-sql-2012-ssis-deployment-error-6522-a-required-privilege-is-not-held-by-the-client

    • Anonymous
      March 30, 2016
      The comment has been removed

  • Anonymous
    October 11, 2016
    This wouldn't happen to have anything to do with the 'Allow logon locally' user rights in Group policy? Like SSRS, SSRS not able to use a runas account unless it has the allow logon locally rights.

  • Anonymous
    April 19, 2017
    The comment has been removed

    • Anonymous
      April 19, 2017
      Forgot to add, After making the change, it now worked for me, no more errors after four months

  • Anonymous
    August 24, 2017
    The comment has been removed

  • Anonymous
    January 13, 2019
    This error just showed up for me after installing a Windows Server 2016 update. Beware! All the SSIS jobs on the server stopped working, and producing this error. Then I learned it wasn't necessarily SQL Agent, since I also had the error come up when trying to deploy projects via SSMS > Integration Services Catalog > Deploy Project. Tried uninstalling the update but that didn't work. I didn't have access to some of the other things I read about. I finally tried a SQL Server repair on the instance and that most fortunately fixed it.