Impossible de déployer le package SSIS dans SQL Server Data Tools 2015 (le nom du serveur de destination n'autorise pas la saisie du mot de passe)
Je suis extrêmement frustré. J'utilise SQL Server Data Tools 2015. J'ai un projet Integration Services et je souhaite déployer un seul package de cette solution sur SQL Server 2012. J'ai défini la solution sur Deployment Target Server Version sur SQL 2012. Je clique avec le bouton droit sur le package et sélectionnez Déployer, mais dans la partie Sélectionner la destination de l'assistant, cela me permet uniquement de sélectionner un nom de serveur (et de ne saisir aucune information d'identification). Cependant, je dois entrer un nom d'utilisateur et un mot de passe spécifiques car mon compte de domaine n'est pas une connexion valide.
Je comprends que cet assistant exécutera éventuellement isdeploymentwizard.exe et j'ai également examiné les paramètres et je ne vois aucun moyen d'entrer des informations de connexion en dehors d'un nom de serveur.
Comment puis-je déployer ce package sur le serveur en utilisant un nom d'utilisateur et un mot de passe au lieu d'un compte approuvé? J'ai l'impression que je dois manquer quelque chose d'incroyablement stupide, car je n'ai pas pu trouver quelqu'un avec un problème similaire même après avoir cherché sur Google pendant une heure. Apparemment, tout le monde déployant sur SQL Server à partir de SSDT2015 utilise un compte approuvé.
Modifier: dans les anciennes versions de BIDS, vous pouviez ouvrir le projet et sélectionner Fichier> Enregistrer la copie de .dtsx sous, puis l'enregistrer sur le serveur SQL et utiliser les informations d'identification. Cependant, dans SSDT, l'option Enregistrer la copie de vous permet uniquement d'enregistrer le package localement.
Selon cet article sur les forums MSDN, ce n'est tout simplement pas possible. Vous devez utiliser l'authentification Windows pour déployer le package. Cependant, j'ai constaté que si je clique sur "Convertir en modèle de déploiement de package", la fonction Enregistrer la copie sous me permet de l'enregistrer sur SQL Server. Cependant, tenter de le faire me donne le message suivant:
Le stockage ou la modification de packages dans SQL Server nécessite que le runtime SSIS et la base de données soient de la même version. Le stockage de packages dans des versions antérieures n'est pas pris en charge.
Il semble que SSDT 2015 (bien que vous puissiez changer le serveur cible de déploiement de SQL 2016 en SQL 2012 ou SQL 2014), ne vous permettra pas d'enregistrer le package sur SQL Server de SQL 2012 ou SQL 2014 sans installer les runtimes SSIS.
Une erreur similaire est générée par dtutil qui semble avoir les versions 110, 120 et 130 installées (dans les répertoires C:\Program Files (x86)\Microsoft SQL Server\xxx\DTS\Binn) pendant l'installation de SSDT2015.
C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn> dtutil /?
Microsoft (R) SQL Server SSIS Package Utilities Version 11.0.6020.0 pour 32 bits Copyright (C) Microsoft Corporation 2012. Tous droits réservés.
Cette application nécessite l'un des composants: Integration Services, Business Intelligence Studio, Outils de gestion - Basic ou Moteur de base de données à installer par SQL Server 2012 Standard, Enterprise, Developer, Business Intelligence ou Evaluation Edition. Pour installer un composant, exécutez le programme d'installation de SQL Server et sélectionnez le nom du composant.
L'installation de la fonctionnalité partagée d'Integration Services à partir de la configuration de SQL 2012 n'a pas modifié le message d'erreur lorsque vous essayez d'utiliser la fonctionnalité `` Enregistrer la copie sous '' dans SSDT, mais cela m'a permis d'utiliser dtutil pour réussir à copier le package sur le serveur.
TLDR;
- Convertissez votre projet Integration Services pour utiliser le modèle de déploiement de package.
- Assurez-vous que la fonction partagée Integration Services est installée localement pour la version de SQL sur laquelle vous déployez le package.
- Utilisez dtutil pour copier le package sur le serveur, c'est-à-dire
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(vous pouvez utiliser un niveau de cryptage différent ou au lieu d'utiliser/Crypter utiliser/Copier, voir la documentation de dtutil)
Vous avez beaucoup de choses ici.
Modèle de déploiement de package vs projet
Depuis la version 2012, les projets SSIS ont le choix entre un modèle de déploiement de package et un modèle de déploiement de projet. Project vous permet de créer des artefacts au niveau du projet - gestionnaires de connexions partagées, paramètres de projet (et de package). Le modèle de déploiement par défaut pour les nouveaux projets est le modèle de déploiement de projet.
L'unité de code déployable d'un modèle de déploiement de projet est le fichier .ispac. Vos packages SSIS + paramètres de projet + gestionnaires de connexions partagées + fichier manifeste sont zippés dans un fichier nommé MyProject.ispac. Le fichier ispac est déployé dans un catalogue SQL Server appelé SSISDB.
L'unité de code déployable du modèle de déploiement de package est le package SSIS lui-même. Vous pouvez déployer le fichier .dtsx sur un système de fichiers, le magasin de packages SSIS (également uniquement le système de fichiers) ou une instance SQL Server. Cependant, le package SSIS sera stocké dans la MSDB (sysdtspackages90/sysssispackages)
La version 2016 complique la matrice ci-dessus dans la mesure où nous pouvons désormais déployer des packages .dtsx dans SSISDB. Il s'agit d'aborder l'histoire du déploiement incrémentiel. Dans les coulisses, il va générer un ispac et c'est ce qui est déployé. Mais ce n'est que pour un serveur 2016 qui n'aidera pas votre histoire de 2012.
Versions SSIS
Les packages SSIS ont des versions qui correspondent à la version de SQL Server et aux outils avec lesquels vous travaillez (2005/2008/2008 R2/2012/2014/2016/v.Next). Les packages ne sont * compatibles que si vous faites l'erreur d'ouvrir un package 2005 avec l'outillage 2014 (ou de le déployer avec) vers une instance 2005, devinez quoi, vous avez mis à niveau vers la version actuelle et déployé vers un emplacement qui ne fonctionne pas '' Je ne parle pas ce dialecte.
2016 confond ce problème car l'outillage prend désormais en charge le ciblage (Projet -> propriétés, Propriétés de configuration -> Général: TargetServerVersion)
Déploiement
Les ispacs sont déployés via isdeploymentwizard.exe ou vous pouvez le faire dans 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;
Cela ressemble à ce que vous voulez parce que vous pouvez être un utilisateur SQL local, mais si la mémoire est bonne, les fonctions ci-dessus effectuent ce jiggery d'emprunt d'identité qui tourne mal si vous n'êtes pas un utilisateur Windows.
Cette application nécessite l'un des composants.
Avec 2005/2008/2008 R2, vous ne pouviez obtenir SSDT, nee BIDS, qu'avec le support d'installation. Cela signifiait que vous aviez besoin au minimum de Developer Edition pour créer vos packages SSIS. Depuis 2012, vous pouvez télécharger les outils SSDT directement depuis MS sans avoir de licence pour SQL Server. Cependant, vous n'êtes autorisé qu'à des fins de développement. Les outils de ligne de commande ne sont pas classés comme outils de développement, donc dtutil ou dtexec échouent tous les deux à une vérification de licence et signalent ce qui précède (ou un message d'erreur similaire).
La résolution, comme vous le faites remarquer, consiste à installer le service Integration Services sur la machine qui nécessite "plus" que le développement Integration Services. Sachez que cela compte comme une installation de SQL Server du point de vue des licences.Assurez-vous donc que la personne de votre organisation qui gère les licences est au courant des machines sur lesquelles vous l'avez fait afin de ne pas avoir une surprise désagréable lors de l'audit.
Si vous fermez Visual Studio, puis ouvrez-le à partir d'une invite de commande avec la commande suivante, il vous demandera votre mot de passe nécessaire pour vous connecter à l'autre serveur.
runas.exe /netonly /user:OTHERDOMAIN\OtherUser "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe"
/ netonly lui indique d'utiliser simplement ces informations d'identification alternatives lors de la conversation sur le réseau. Modifiez OTHERDOMAIN\OtherUser pour qu'il corresponde au nom d'utilisateur nécessaire pour se connecter au système distant. Et puis la dernière partie est le chemin vers Visual Studio 2015.
Une fois cela fait, vous devriez pouvoir déployer sans fournir à nouveau d'autres informations d'identification.
Soit dit en passant, je vous recommande fortement d'installer le BIDS Helper gratuit afin de tirer parti de la fonctionnalité Deploy SSIS Packages qui facilite le déploiement de packages uniques. Cependant, vous avez toujours besoin de runas.exe.