Unable to deploy package to ssis 2014 Catalog

Recently ran into trouble because our Active Directory environment was upgraded to 2012, and I could no longer deploy packages to our SQL Server 2014 SSIS Catalog due to the following 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

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)

I found a nice blog post from Archana, a Microsoft SQL Developer, that helped resolve the issue, but was a bit wordy with the solution.

http://blogs.msdn.com/b/dataaccesstechnologies/archive/2013/08/20/system-componentmodel-win32exception-a-required-privilege-is-not-held-by-the-client-while-deploying-ssis-project.aspx

Long and short of the article was to follow the steps outlined below for the user account that needs access, and then run gpupdate on the server in question:

Odd authentication behavior

Just recently I came across some odd behavior when trying to connect to my SQL 2012 server via and SSIS package and ultimately SSMS from an external connection.  I’ll cut to the chase and tell you that the error I was receiving was the following:

The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider)

As it turned out, something went awry with the trust connection between the SQL server and the Active Directory Domain Controller that was not allowing my user account to authenticate.  Simply going into SQL Server Configuration Manager and re-entering the user password for the various services resolved the issue, however, not so simply, it took me about 7 hours of tweaking to figure out that was the problem…

The odd thing about this is that I was working in my environment on a Tuesday with no issues, connecting externally, etc.  Wednesday I was traveling for work, and upon my return on Thursday, any external connections I tried resulted in the error above.  The really strange thing about the error is that I could connect locally just fine, and I would only get it for external connections.

I went through the normal steps to check for external connectivity i.e.:

  1. Reboot (Fortunately, it’s just a server used for reporting, and not our SAP installation)
  2. Make sure SQL Browser and other services were running
  3. image
  4. Check the windows firewall (did an external port scan to make sure 1433 was open)
  5. Check the SQL Server Network Configuration protocols were enabled
  6. image
  7. Make sure external connections were enabled in Database Properties
  8. image

Even after all these steps and more, I simply could not find an answer, so I turned it over to my Sys Admin for another set of eyes, and almost immediately he found it by changing the “Log on as” account to local system.  This wouldn’t solve my problem completely, because I would need access to network shares within the domain, however, it got me pointed in the right direction, and viola! I was back in.

As it turns out, we have been recently doing some work on our domain as they put Win Server 2003 to End of Life, and upgraded to Windows Server 2012 Active Directory.  This helped me to remember that even when you think everything is working and configured the way it should be, there are always situations where something that’s happening externally to your own “silo” can still affect what you’re doing.  Always check with the Sys Admins and bounce the question of team mates when you run into issues.