Não é possível implantar o pacote SSIS no SQL Server Data Tools 2015 (o nome do servidor de destino não permite a entrada de senha)

Você tem muita coisa acontecendo aqui.

Modelo de implantação de pacote vs projeto

A partir da versão 2012, os projetos SSIS podem escolher entre um modelo de implantação de pacote e um modelo de implantação de projeto. O Project permite que você crie artefatos de nível de projeto - gerenciadores de conexões compartilhadas, parâmetros de projeto (e pacote). O modelo de implantação padrão para novos projetos é o modelo de implantação do projeto.

A unidade de código implantável de um modelo de implantação de projeto é o arquivo .ispac. Seus pacotes SSIS + parâmetros de projeto + gerenciadores de conexões compartilhadas + arquivo de manifesto são compactados em um arquivo chamado MyProject.ispac. O arquivo ispac é implantado em um catálogo do SQL Server chamado SSISDB.

A unidade de código implantável do modelo de implantação de pacote é o próprio pacote SSIS. Você pode implantar o arquivo .dtsx em um sistema de arquivos, no repositório de pacotes SSIS (também apenas no sistema de arquivos) ou em uma instância do SQL Server. No entanto, o pacote SSIS será armazenado no MSDB (sysdtspackages90/sysssispackages)

A versão 2016 complica a matriz acima, pois agora podemos implantar pacotes .dtsx no SSISDB. Isso é para abordar a história de implantação incremental. Nos bastidores, ele gerará um ispac e é isso que é implantado. Mas isso é apenas para um servidor de 2016 que não ajudará sua história de 2012.

Versões SSIS

Os pacotes SSIS têm versões que correspondem à versão do SQL Server e das ferramentas com as quais você está trabalhando (2005/2008/2008 R2/2012/2014/2016/v.Next). Os pacotes são compatíveis apenas* com versões anteriores, portanto, se você cometer o erro de abrir um pacote de 2005 com as ferramentas de 2014 (ou implantar com ele) em uma instância de 2005, adivinhe, você atualizou para a versão atual e implantou em um local que não t falar esse dialeto.

2016 confunde esse problema porque as ferramentas agora suportam direcionamento (Projeto -> propriedades, Propriedades de configuração -> Geral: TargetServerVersion)

Implantação

Ispacs são implantados via isdeploymentwizard.exe ou você pode fazê-lo em TSQL.

-- You must be in SQLCMD mode
-- Otherwise, modify the value of $(isPacPath) down below
:setvar isPacPath "C:\sandbox\SSDTDeploy\TSQLDeploy\bin\Development\TSQLDeploy.ispac"

DECLARE
    @folder_name nvarchar(128) = 'TSQLDeploy'
,   @folder_id bigint = NULL
,   @project_name nvarchar(128) = 'TSQLDeploy'
,   @project_stream varbinary(max)
,   @operation_id bigint = NULL;

-- Read the zip (ispac) data in from the source file
SELECT
    @project_stream = T.stream
FROM
(
    SELECT 
        *
    FROM 
        OPENROWSET(BULK N'$(isPacPath)', SINGLE_BLOB ) AS B
) AS T (stream);

-- Test for catalog existences
IF NOT EXISTS
(
    SELECT
        CF.name
    FROM
        catalog.folders AS CF
    WHERE
        CF.name = @folder_name
)
BEGIN
    -- Create the folder for our project
    EXECUTE [catalog].[create_folder] 
        @folder_name
    ,   @folder_id OUTPUT;
END

-- Actually deploy the project
EXECUTE [catalog].[deploy_project] 
    @folder_name
,   @project_name
,   @project_stream
,   @operation_id OUTPUT;

Isso soa como o que você quer, porque você pode ser um usuário SQL local, mas se a memória servir, as funções acima fazem essa confusão de representação que dá errado se você não for um usuário do Windows.

Esta aplicação requer um dos componentes..

Com 2005/2008/2008 R2 você só poderia obter SSDT, nee BIDS, com a mídia de instalação. Isso significava que você precisava do Developer Edition no mínimo para criar seus pacotes SSIS. A partir de 2012, você pode baixar as ferramentas SSDT diretamente do MS sem ter uma licença para o SQL Server. No entanto, você está licenciado apenas para fins de desenvolvimento. As ferramentas de linha de comando não são classificadas como ferramentas de desenvolvimento, portanto, dtutil ou dtexec falharão em uma verificação de licenciamento e relatarão o acima (ou uma mensagem de erro semelhante).

A resolução, como você aponta, é instalar o Serviço de Integração na máquina que requer "mais" do que apenas o desenvolvimento de Serviços de Integração. Esteja ciente de que isso conta como uma instalação do SQL Server do ponto de vista do licenciamento, portanto, certifique-se de que a pessoa em sua organização que lida com o licenciamento esteja ciente das máquinas em que você fez isso para não ter uma surpresa desagradável na hora da auditoria.

De acordo com este post nos fóruns do MSDN, simplesmente não é possível. Você deve usar a autenticação do Windows para implantar o pacote. No entanto, descobri que, se eu clicar em 'Converter em modelo de implantação de pacote', a função Salvar cópia como me permite salvá-la no SQL Server. No entanto, tentar fazer isso me dá a seguinte mensagem:

Armazenar ou modificar pacotes no SQL Server requer que o runtime e o banco de dados do SSIS sejam da mesma versão. O armazenamento de pacotes em versões anteriores não é suportado.

Parece que o SSDT 2015 (embora você possa alterar o Deployment Target Server do SQL 2016 para SQL 2012 ou SQL 2014), não permitirá que você salve o pacote no SQL Server do SQL 2012 ou SQL 2014 sem instalar os tempos de execução do SSIS.

Um erro semelhante é gerado pelo dtutil , que parece ter as versões 110, 120 e 130 instaladas (nos C:\Program Files (x86)\Microsoft SQL Server\xxx\DTS\Binndiretórios) durante a instalação do SSDT2015.

C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn>dtutil /?

Utilitários do pacote Microsoft (R) SQL Server SSIS Versão 11.0.6020.0 para 32 bits Copyright (C) Microsoft Corporation 2012. Todos os direitos reservados.

Este aplicativo requer que um dos componentes: Integration Services, Business Intelligence Studio, Management Tools - Basic ou Database Engine seja instalado pelo SQL Server 2012 Standard, Enterprise, Developer, Business Intelligence ou Evaluation Edition. Para instalar um componente, execute a Instalação do SQL Server e selecione o nome do componente.

A instalação do recurso compartilhado do Integration Services da instalação do SQL 2012 não alterou a mensagem de erro ao tentar usar o recurso 'Salvar cópia como' dentro do SSDT, mas me permitiu usar o dtutil para copiar com êxito o pacote para o servidor.

TLDR;

• Converta seu projeto do Integration Services para usar o Modelo de Implantação de Pacotes.
• Certifique-se de que o Recurso Compartilhado do Integration Services esteja instalado localmente para a versão do SQL na qual você está implantando o pacote.
• Use dtutil para copiar o pacote para o servidor, ou seja C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn>dtutil /FILE "C:\path\to\mypackage.dtsx" /DestServer SERVER\INSTANCE /DestUser MyUserName /DestPassword MyPassword /Encrypt SQL;PackageNameOnServer;2;PackagePassword(você pode usar um nível de criptografia diferente ou em vez de usar /Encrypt use /Copy, veja a documentação do dtutil)

Se você fechar o Visual Studio, abra-o em um prompt de comando com o comando a seguir, ele solicitará sua senha necessária para se conectar ao outro servidor.

 runas.exe /netonly /user:OTHERDOMAIN\OtherUser "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe"

/netonly diz para usar apenas essas credenciais alternativas ao falar pela rede. Altere o OTHERDOMAIN\OtherUser para corresponder ao nome de usuário necessário para se conectar ao sistema remoto. E a última parte é o caminho para o Visual Studio 2015.

Feito isso, você poderá implantar sem fornecer credenciais alternativas novamente.

A propósito, eu recomendo que você instale o BIDS Helper gratuito para aproveitar o recurso Deploy SSIS Packages , que facilita a implantação de pacotes únicos. Você ainda precisa runas.exe embora.