SSIS developers / DBA's have come across a scenario where they want to copy the SSIS package that is deployed in the MSDB database of SQL Server 2005 / 2008 to file system so that they can copy the package across different environments like Dev / Test / UAT and Production. The best and the easiest way to move the SSIS Package is to use the DTUTIL command prompt utility in SQL server.
How to Copy SSIS Package from MSDB Database to File System
Once the SSIS Package that needs to be copied from MSDB Database to the file system is identified, the first step will be to establish a Remote Desktop Connection with the Source SQL Server where SSIS Package is currently deployed. The second step will be to go to Start > Run, type CMD, hit Enter, and enter the syntax which is highlighted below locally on the SQL Server. This will copy the SSIS Package Named SAMPLEPACKAGENAME.DTSX available under Integration Services > Stored Packages > MSDB to the user specified location. Please provide the path where the package needs to be copied in the file system and make sure that the file path doesn't have the "<" and ">" signs.
Syntax: COPY SSIS Package to File System
DTUTIL /SQL <PACKAGENAME> /COPY FILE;<DRIVE:\FOLDERNAME\PACKAGENAME.DTSX> /QUIET
Example: Copy SSIS Package to File System
The script below will copy SAMPLEPACKAGENAME SSIS Package from the MSDB Database to the user specified folder location entered by the user on the local / remote SQL Server. If /QUIET parameter is used it will overwrite the SAMPLEPACKAGENAME.DTSX package if it is already existing in the user specified folder location.
DTUTIL /SQL SAMPLEPACKAGENAME /COPY FILE;C:\SSISPACKAGE\SAMPLEPACKAGENAME.DTSX> /QUIET
How to Install SSIS Package to be Stored in the MSDB Database
Anotehr scenario that SSIS developers / DBA's come across is where they want to install the SSIS package that is available in the file system to the MSDB Database of SQL Server 2005 / 2008. The best and the easiest way to install the SSIS Package to MSDB Database is to use the DTUTIL command prompt utility in SQL server. This can be achieved by opening a Remote Desktop Connection to the New Server and by going to Start > Run, type CMD, hit Enter, and by entering the syntax below.
Syntax: Install SSIS Package to MSDB Database
DTUTIL /FILE <DRIVE:\FOLDERNAME\PACKAGENAME.DTSX> /COPY SQL;<PACKAGENAME>
Example: Install SSIS Package to MSDB Database
The script below will install the SAMPLEPACKAGENAME SSIS Package from the local / remote file location to the MSDB Database on the local SQL Server Instance. If /QUIET parameter is used it will overwrite the SAMPLEPACKAGENAME.DTSX package if it already exists in the MSDB Database.
DTUTIL /FILE C:\SSISPACKAGE\SAMPLEPACKAGENAME.DTSX /COPY SQL;SAMPLEPACKAGENAME /QUIET
How to Delete SSIS Package Stored in the MSDB Database
One last scenario that SSIS developers / DBA's come across is where they need to delete an SSIS package from the MSDB database of SQL Server 2005 / 2008. The best and the easiest way to Delete SSIS Package from the MSDB Database is to use the DTUTIL command prompt utility in SQL server. This can be achieved by opening a Remote Desktop Connection to the Server from where the user needs to remove the SSIS Package which is deployed under Integration Services > Stored Packages > MSDB. The use needs to go to Start > Run, type CMD, hit Enter, and follow the syntax.
Syntax: Delete SSIS Package from MSDB Database
The below script will delete the SSIS Package from MSDB Database on the local instance of SQL Server
DTUTIL /SQL <PACKAGENAME> /DELETE /SourceS <ServerName>
Example: Delete SSIS Package from MSDB Database
The script shown here will delete SAMPLEPACKAGENAME SSIS Package from Integration Services > Stored Packages > MSDB. The /SourceS parameter should have the server name from where the SSIS Package needs to be removed.
DTUTIL /SQL <PACKAGENAME> /DELETE /SourceS AKMEHTA
Conclusion
Using the DTUTIL Command Prompt utility allows the SSIS Developers and DBA to easily Install / Copy and Delete the SSIS packages, which are deployed on the MSDB Database. It helps to save a lot of time when packages need to be deployed across Dev / Test / UAT and Production environments.
