August 9, 2013 at 10:30 am
I've built an SSIS Project created in SQL Server Data Tools which I'm trying to deploy to our Staging SQL 2012 Server, and I'm getting this error while trying the deploy.
TITLE: SQL Server Integration Services
------------------------------
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)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&ProdVer=11.00.3128&EvtSrc=MSSQLServer&EvtID=6522&LinkId=20476
------------------------------
Most of the articles mentioning this error suggest not to use local service accounts, which we're not. We're using domain accounts for all of the SQL Server services. Also one article also suggested adding the account used by the SQL Engine to the local Admin group since the deploy has to write to the file system, and I've done this as well with no luck.
The thing is permissions are at least somewhat in place because the deploy created the Project Folders under the SSISDB catalog on the server.
Update: I copied the Project to the SQL Server and tried deploying it using Catalog.Deploy_Project and it gave the same error. I'm logged in using a domain account that's in the Local Admin group, so I'm thinking it's a permissions issue from the SQL Service accounts. The domain accounts used by the SQL Engine Service and SSIS Service are both local admin accounts too, so I'm not sure what else to check.
Any other suggestions on things to attempt? Thanks.
Sam
August 12, 2013 at 8:36 am
Seems like the issue is related to a bug in SQL when certain AD Group Policies are pushed to the server. The suggested short term 'fix' I'm seeing on a few other forums is to run a SQL Server Repair which will enable deployment to work until the next reboot, but the only concrete way to fix this issue is for the AD Group Policy to be removed. I'm not familiar with the group policies being enforced no our network, so that'll take some time to figure out.
At any rate it's still and issue, but for anyone else encountering this maybe this'll help.
Sam
October 5, 2015 at 8:02 am
Verify the OS permissions for SQL Server and SQL Server Agent service.
They specifically need "Replace a process level token" to allow you to deploy to the SSISDB catalog.
Shawn Melton
Twitter: @wsmelton
Blog: wsmelton.github.com
Github: wsmelton
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply