Someone please correct me if I'm wrong, but the way I move an SSIS package to the server is to first set up the Configuration Manager. To do that, right click on the solution name in the Solution Explorer and select Properties. Then I click on Deployment Utility and set CreateDeploymentUtility to True. You can change the output path if you want. Make note of the path because it will put the deployment utility there. As for the Debugging options, I have to set Run64bitRuntime to False since our current server is 32-bit. When you're done, click Ok.
On the Package Properties, it may be a good idea to check/set the ProtectionLevel. By default I think it's set to EncryptSensitiveWithUserKey. I always change mine to EncryptAllWithPassword or EncryptSensitiveWithPassword. You can always look those up for more info on them.
Then click on the Build menu option and build your solution. Now you need to navigate to the folder where it created the deployment utility. It should be a folder under your package solution. Double-click the file that has "Manifest" at the end of the name. This will launch an Installation Wizard. This will allow you to put the package on the server.
And that is how I deploy an SSIS package to a server.
Thank you for taking the time to reply to my vague and frustrated question!
I was able to run the manifest and the installer finished successfully from
C:\Documents and Settings\adamr\My Documents\Visual Studio 2005\Projects\Mas90 Repl\Mas90 Repl\bin\Deployment
I dont see the package on my server though so i can use that package in a schedule.
Heres where im confused, and some background info.
1. Standard installation of SQL 2005
2. Attached mdbs and ldbs of SQL 2000 Databases successfully. I had some basic knowledge of 2005 before we migrated, but didnt realize DTS was rebuilt into SSIS.
Questions
1. Do i have to install Integration Services on the SQL server itself?
2. If so, when i installed on devel box, it installed Visual Studio BIDS, can i NOT install that on the server?
3. I understand how this can be needed and really handy for the super advanced useage, but why is it so extensive?
4. I was following the guidelines in MSDN, and was able to create the manifest previously, however, it told me to copy the files to a folder on the server, then run it from there. Is there some good references youve found for a "Quick Start" guide.
It seems the new SSIS is designed FOR the super advanced users, and left the occasionaly admin in the dust.
I understand how you feel! I still feel frustrated with it myself at times.
1. According to BOL, “The Integration Services service is not required if you only want to design and execute Integration Services packages. However, the service is required to list and monitor packages using SQL Server Management Studio.” So it depends on what your intentions are.
2. I’m not sure if you can install 2005 without VS BIDS. I’ll have to look into it. Someone else here might know.
3. I’m sure someone else can better explain why it’s so extensive. I think the intent was to create a more powerful, robust tool for ETL processes.
4. Unfortunately, I have yet to find a good Quick Start guide out there for SSIS. I’ve learned through reading the BOL, searching the Internet, posting on forums, and though trial and error. I think there are a lot of people out there that are still trying to figure it out (including myself). It's definitely a big leap from DTS. This forum is a good place to go for help, though. Another site I like to go to is SQLIS.com.
Hopefully this info will help you out some. I’m sorry I don’t have better answers for you.
After building a solution, with many packages, and then deploying all the packages to SQL Server by executing the manifest… if I then make a change to just one of the packages how do I deploy just this one package and not all packages?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.