SSIS Package Deployment Failure using SSDT

Question

SSIS fails almost immediately on the final "Deploying project" step of the Deployment Wizard (Package Deployment Model), using Visual Studio 2010 (SSDT) connecting to a SQL 2012 Server:

Failed to deploy project. For more information, query the operation_messages view for the operation identifier '10028'.  (Microsoft SQL Server, Error: 27203)

The report XML contains few clues to the issue, however the "0x80131904" could indicate a possibly network library issue.

System.Data.SqlClient.SqlException (0x80131904): Failed to deploy project. For more information, query the operation_messages view for the operation identifier '10026'. 
                    at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
...
 Microsoft.SqlServer.Management.IntegrationServices.CatalogFolder.DeployProject(String projectName, Byte[] projectStream)
...    
Error Number:27203,State:1,Class:16

The Operation_Messages view returns no data for that ID.

The Integration Services' Catalog All Operations report simply reports a Failed/Deploy Project.

Interestingly, the package deploys successfully if I run the Wizard via the SQL Server Management Studio (right-click on the Projects tab for the project and choose Deploy Project and browse/import the ispac file). Note that I'm running SSMS remotely as well as VS2010/SSDT, so I'm not sure why only VS2010 is failing.

I also tried adjusting the Server-wide Default Logging Level to Verbose but this didn't seem to provide any additional info.

Any thoughts on why SSDT is failing to deploy the package?

Answer 1

I was having this error (and pulling my hair out) -- even though I didn't have any rows in the operation_message view, there was a row in [catalog].[operations]. I noticed server_name was the old name of the machine. For the most recent successful deployment in [catalog].[operations], the server_name was the current name of the machine.

I also noticed both SELECT @@SERVERNAME and SELECT SERVERPROPERTY('SERVERNAME') were both returning the machine's old name. (Usually @@SERVERNAME would have the stale name but SERVERPROPERTY('SERVERNAME') would have the current name).

So I ran

exec sp_dropserver 'old_name';
GO
exec sp_addserver 'current_name';
GO

and restarted the SQL service, and then the deploy worked.