Last week at customer side we faced the issue that project deployment of a SQL 2012 SSIS Project was not possible any more. On Wednesday we deployed the Project with Project-Deployment-Modell and all went fine. Doing the same thing on Friday with the new build the deployment failed. The following error message appeared:
Msg 6522, Level 16, State 1, Procedure deploy_project_internal, Line 0 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) At first I thought it’s a Visual Studio 2010 / Data Tools issue. So I tried to deploy the project using the stored procedure „catalog.deploy_project“ but it failed with the same issue. On another server the deployment worked. So the project itself was still fine. While searching the web for error code and the error message I found hints pointing in the direction of CLR- or DCom-Permissions. Others reported that the error reappeared after a reboot. I checked the SQL-Server and Windows errorlog. The server was rebooted in the meantime and admins told the some group policies might have been applied to the server. So I tried the solutions presented in the web but none really worked, neihter giving the SQL-Server-Engine-Account and the SSIS-Service-Account the full permission in DCom-configuration nor adding the Service-Accounts to the local administrator group. Using Local-System-Account was no option as it was set to use Active-Directory-Service-Accounts. Another search in the internet brought up the hint to do a SQL-Server-Repair-Installation. But it was also said that this „fix“ only works to the next reboot. So this couldn’t be the correct answer. But then it came to my mind: „If a Repair-Installation helps and we know it has something to do with permissions and Group-Policies, let’s check which permissions are granted during the (Repair-)Installation.“ Microsoft says the following permissions are required:
|SQL Server Service
|Permissions granted by SQL Server Setup
|SQL Server Database Engine: (All rights are granted to the per-service SID. Default instance: NT SERVICE\MSSQLSERVER. Named instance: NT SERVICE\MSSQL$InstanceName.)
|Log on as a service (SeServiceLogonRight) Replace a process-level token (SeAssignPrimaryTokenPrivilege) Bypass traverse checking (SeChangeNotifyPrivilege) Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)Permission to start SQL WriterPermission to read the Event Log servicePermission to read the Remote Procedure Call service
|SQL Server Agent:(All rights are granted to the per-service SID. Default instance: NT Service\SQLSERVERAGENT. Named instance: NT Service\SQLAGENT$InstanceName.)
|Log on as a service (SeServiceLogonRight) Replace a process-level token (SeAssignPrimaryTokenPrivilege) Bypass traverse checking (SeChangeNotifyPrivilege) Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)
|SSIS:(All rights are granted to the per-service SID. Default instance and named instance: NT SERVICE\MsDtsServer110. Integration Services does not have a separate process for a named instance.)
|Log on as a service (SeServiceLogonRight)Permission to write to application event log. Bypass traverse checking (SeChangeNotifyPrivilege) Impersonate a client after authentication (SeImpersonatePrivilege)
Information from: Microsoft By checking the granted permissions I saw that the one „Replace a process-level token (SeAssignPrimaryTokenPrivilege)“ was not granted to the SQL-Server Engine- Account. I added the Account of the Engine and the Agent, restarted both services.
Et voilà! The deployment is working again! To make sure the permission will survive the next reboot, it was only necessary to add the Accounts via GPO to this right and everything is working again. You can test this behavior the revoking this right from the Agent-Account . The next job start will bring up the same error message as above. Good luck with fixing this issue.