Hands-On Microsoft SQL Server 2008 Integration Services part 62 doc

588 Hands-On Microsoft SQL Server 2008 Integration Services
Under these conditions, you will be using either a package deployment utility, which
can deploy multiple-package projects along with package configurations and miscellaneous
files or custom-developed scripts that could be simple windows batch files to do the
trick. A sample of a simple batch file will be discussed later in the chapter.
A package deployment utility is used after you’ve created a package and package
configurations, and are ready to deploy. To create a deployment utility, you need to
configure the Deployment Utility section of the project properties before building the
project. Three properties here can be configured to control deployment of your project.
Once you configure these properties, you can create a package deployment utility by
building a project on the computer where the Integration Services project is stored.
The build process automatically includes the packages, package configurations, and
miscellaneous files in the project and adds a manifestation file that is gracefully called
the Deployment Utility.
AllowConfigurationChanges
You can assign a True or False value to this property. The True value lets you update
configurations during deployment of the package; False lets you omit the update
option during deployment. You can use this feature when you have to distribute a
deployment utility to remote administrators for deploying the project, but do not want
them to be able to make changes to configurations. This is also useful when you are
redeploying packages after making a few changes, but do not want configurations to
be changed.
CreateDeploymentUtility
This property also has True or False value options. A True value lets the build process
create a deployment utility for the Integration Services project; a False value prohibits
the creation of deployment utility. You need to specify a True value if you want to
create a deployment utility, as the default value of this property is False.
DeploymentOutputPath
When you create a new project using BIDS, a bin subfolder is also created along with
other files within the project folder. The default path shown in this property—i.e.,
bin\Deployment—refers to the same bin folder under the project. When you build

the project, the packages, the package configurations, miscellaneous files, and the
deployment utility file are added in this folder. You can change this path to create your
deployment utility at a central location within the organization.
Chapter 13: Deploying Integration Services Packages 589
Deploying Integration Services Projects
The last step in the Integration Services project deployment journey is the deployment
of the project. After having created packages for the project, package configurations,
and the deployment utility, there isn’t much left other than actually running the
deployment utility to deploy the Integration Services project.
As you create the deployment utility, a manifestation file with the extension
SSISDeploymentManifest is created along with packages, configurations, and
miscellaneous files in the folder specified in the DeploymentOutputPath property of
Integration Services project. You need to copy this deployment folder to the deployment
computer and execute the SSISDeploymentManifest file to install the Integration Services
project. Executing the SSISDeploymentManifest file starts the Package Installation
Wizard, which then guides you through the process of package installation.
Next you have to decide where you want to install the package. If you choose to
install your package in the file system, the package and other files such as configurations
and miscellaneous files will be saved to the specified folder on the file system. However,
if you choose to install the Integration Services package in the SQL Server, the package
will be saved in the sysssispackages table in the MSDB system database and the other
files will still be saved to the file system in the folder specified.
During the life cycle of a package, you may need to modify the package either
to add functionality or to accommodate changes happening somewhere else in
the environment. In such cases, you may be making changes to your project in the
development environment and then testing in the test environment. Once those
changes have been tested successfully, you are again facing the task of deploying your
project. This redeployment differs slightly from the first deployment of the project.
You may want to change the deployment process during redeployment—e.g., you
may not want to make any change to package configurations during deployment—

and so you will set the AllowConfigurationChanges property to False. Second, if
you’ve made changes only to some of the packages and do not want to redeploy all the
packages within a project, you can create a new Integration Services project and add
only the packages to the project that you want to redeploy. When you add a package
to an Integration Services project, the configurations associated with the package are
automatically added to the new project and you don’t have to worry about them.
The following Hands-On exercise lets you create a deployment utility and then
install the Integration Services package to the deployment computer.
Hands-On: Deploying an Integration Services Project
Create a package deployment utility for the Contacting Opportunities with
Configurations project and finally deploy the package.
590 Hands-On Microsoft SQL Server 2008 Integration Services
Method
Deploying a project involves going through three simple steps:
Configure the Integration Services project properties.
c
Build an Integration Services project. c
Install the Integration Service project. c
Exercise (Configure Project Properties)
Before you can create a deployment utility, you must configure the project properties.
These properties provide control over the deployment process.
1. Open Contacting Opportunities with Configurations project using BIDS.
2. In the Solution Explorer, right-click the Contacting Opportunities with
Configurations project and choose Properties from the context menu.
3. In the property pages, click the Deployment Utility under Configuration
Properties on the left pane. Specify True in the AllowConfigurationChanges and
CreateDeploymentUtility properties (see Figure 13-12). Leave the default bin\
Deployment path in the DeploymentOuputPath property. Click OK to close the
property pages.
Figure 13-12 Configuring Project properties

Chapter 13: Deploying Integration Services Packages 591
Exercise (Build the Project)
Building an Integration Services project is quite easy using the Solution Explorer in BIDS.
4. In the Solution Explorer, right-click the Contacting Opportunities with
Configurations project again and choose Build from the context menu.
Alternatively, you can also do this from the Build menu.
5. You will see a success message in the bottom-left corner in BIDS as well as in the
Output window in BIDS.
6. Using Windows Explorer, you can see that the deployment files have been added
in the folder C:\SSIS\Projects\Contacting Opportunities with Configurations\bin\
Deployment. These files consist of conoppo.dtsConfig, the package configurations
file; Mailing Opportunities with Configurations.dtsx, the package XML file;
and Contacting Opportunities with Configurations.SSISDeploymentManifest,
the package deployment utility. Copy the Deployment folder to the deployment
computer in the C:\Temp folder.
Exercise (Install and Run the Package)
After creating the deployment utility, you can install your package using the DTSInstall
.exe command-line tool or by double-clicking the SSISDeploymentManifest file. If you
want to use the DTSInstall.exe tool, you have to specify the complete path and filename
for the manifest file while invoking Package Installation Wizard.
7. On the deployment computer, go to the C:\Temp\Deployment folder using
Windows Explorer and double-click the Contacting Opportunities with
Configurations.SSISDeploymentManifest file. This will start the Package
Installation Wizard after a few seconds. Click Next on the Welcome screen.
8. On the Deploy SSIS Packages screen, you can choose between File System
Deployment and SQL Server Deployment of the package. Select the File System
Deployment radio button. Click Next.
9. Click Browse and browse to C:\SSISDeploy folder, and then click Make New
Folder to create a Contacting Opportunities with Configurations folder. Select this
folder and click OK to return and see C:\SSISDeploy\Contacting Opportunities

with Configurations listed in the Folder field. Click Next to go to the next screen.
Click Next again in the Confirm Installation screen.
10. In the Configure Packages screen, expand Property under the Configurations
section. You can see the two properties, Subject and ToLine, listed there. You
can modify the value of any configuration here by clicking in the Value field of
the configuration. Click Next when you’re done.
592 Hands-On Microsoft SQL Server 2008 Integration Services
11. In the Finish the Package Installation Wizard screen, review the summary that
tells you about the package to be deployed, the configuration file to be used, the
folder where it will be installed, and the log filename. Click Finish to deploy the
package.
12. Browse to the C:\SSISDeploy\Contacting Opportunities with Configurations
folder using Windows Explorer. You will see the Mailing Opportunities with
Configurations.dtsx file in the folder.
13. Open the command window, go to C:\SSISDeploy\Contacting Opportunities
with Configurations directory, and type the following at the command prompt:
dtexec /file "Mailing Opportunities With Configurations.dtsx"
You will see the various steps being completed and scroll through the window,
finally returning a DTSER_SUCCESS message.
Review
To deploy a project, you need to configure its deployment properties and make sure
that the CreateDeploymentUtility property is set to True. Once the deployment utility
is created, you can install the package by running the deployment manifest file. You
can also invoke the Package Installation Wizard using the DTSInstall.exe tool. You
have also seen that if the AllowConfigurationChanges property is set to True during
deployment utility creation, you get an opportunity to modify package configurations
during deployment of the package. Make sure you use this aspect when you are
deploying to several computers with different environments, if you are not using
indirect package configurations.
One of the benefits of using configurations is the ability to pass them on the cmd

line when executing a package. This is very handy and practical, especially when you
are executing a package on the same server that is acting both as a test and development
server with different configurations. In this way, you can choose which configuration
file to pick up, as environment variables will not work in this case, due to their inability
to point to both versions of the configuration file.
Custom Deployment
Sometimes the deployment procedures are guided by already-adopted deployment
standards that might be different from what SSIS deployment tools can provide. Also,
in the bigger picture, you might need to deploy lots of other stuff along with packages
and you find that the available tools don’t provide you an ability to deploy all of the
changes in one go. In such instances, you might prefer to adopt custom-developed
scripts to deploy SSIS packages and the other changes together. Typically, your
deployment stuff will be made up of the following entities:
Chapter 13: Deploying Integration Services Packages 593
SSIS package files c
SSIS configuration files c
SQL scripts to populate configurations if you are using SQL Server–based c
configurations
SQL scripts to create or apply changes to SQL Server databases, tables, or other
c
objects
SQL scripts to create SQL Server Agent jobs
c
Rollback scripts c
One simple example could be batch file scripts that could be used to deploy all of
these entities. A sample of various parts of such a batch file is listed here:
REM***************************************************************
REM Set Variables for Control file
REM****************************************************************
SET DB_SERVER = DatabaseServerName

SET SSIS_SERVER = SSISServerName
SET CONTROL_DATABASE = ControlDatabaseName
SET ENVIRONMENT = PRODUCTION

REM****************************************************************
REM Use the following to copy SSIS packages from a Network Share on to the
Production SSIS Server
REM*****************************************************************
XCOPY "\\ServerName\DeploymentShareName\%Environment%\SSISPackages\*.*" "\\%SSIS_
SERVER%\F$\DeploymentFolder\SSISPackages\" /Y

REM****************************************************************
REM Use the following to deploy an SSIS package from a folder to the MSDB database
on the SSIS Server. You do not need to use this step if you are using File System
deployment of packages.
REM*****************************************************************
dtutil /Q /FILE "\\%SSIS_SERVER%\F$\DeploymentFolder\SSISPackages\Package1.dtsx" /
DESTS %SSIS_SERVER% /COPY SQL;"/SSISPackages/Package1"

REM*****************************************************************
REM Use the following to run a TSQL script on the database Server to populates
configurations to an SQL Server table, Create SQL Server database objects or an
SQL Server Agent job.
REM****************************************************************
SET INPUT_FILE= \\%DB_SERVER%\F$\DeploymentFolder\SQLScripts\
SetSSISConfigurations.sql
SET OUTPUT_FILE= \\%DB_SERVER%\F$\DeploymentFolder\SQLScripts\LOG_OutPut.txt
SQLCMD -S %DB_SERVER% -d %CONTROL_DATABASE% -E -i %INPUT_FILE% -o %OUTPUT_FILE%
594 Hands-On Microsoft SQL Server 2008 Integration Services
So, using this or probably extending the previous example, you can carve out a

reasonably simple solution that deploys the changes both in SSIS and in SQL Server
databases all in one go.
Summary
You have completed an interesting journey to deploy Integration Services packages.
You have created package configurations, used direct and indirect methods to specify
configurations for a package, created a deployment utility, and deployed a package
using the Package Installation Wizard. You now understand the difference between
copying a package and deploying a package, and you’re now able to create indirect
configurations to make the deployment process as easy as a copy operation.
Migrating to Integration
Services 2008
Chapter 14
In This Chapter
c
Upgrade Advisor
c
Migrating Data
Transformation Services
Packages
c
Upgrading Integration
Services 2005
c
Summary
596 Hands-On Microsoft SQL Server 2008 Integration Services
A
s you have started this chapter, I can safely assume that you have worked with
DTS 2000 and perhaps are looking to migrate to Integration Services.
And if you have completed previous chapters and have worked with various
components of Integration Services such as Control Flow tasks, Data Flow transformations,

connection managers, variables, property expressions, and package configurations,
you can very well appreciate that Integration Services is totally different from Data
Transformation Services of SQL Server 2000. In fact, Integration Services is not an
upgrade of DTS; rather, it is altogether a new tool. This chapter will cover migration
of both DTS 2000 and Integration Services 2005 to Integration Services 2008.
For one thing, Data Transformation services have been deprecated in SQL Server
2008, though 32-bit management, run-time, and design-time support for DTS
packages have still been provided in SQL Server 2008. With that in mind, you may be
wondering what exactly you can do to your existing DTS 2000 packages. Integration
Services provides options that you can use to migrate DTS packages into SSIS. Later,
in the exercises in this chapter, you will use a DTS 2000 package provided in the
RawFiles folder. Before you start checking out the options, you’ll need to analyze your
packages to determine whether they can be migrated; if they can be, you need to be
aware of issues that might come up during migration. You can analyze your DTS 2000
packages using the Upgrade Advisor. Let’s start the chapter with a discussion of the
Upgrade Advisor, and then we will look at the migration options.
Upgrade Advisor
As a DBA of SQL Server 2000 or SQL Server 2005, very soon you might find yourself
face to face with having to upgrade to SQL Server 2008, if you have not upgraded
already. The reason could be an end of support for legacy software, or you may want
to use the enhanced performance and new features provided in SQL Server 2008.
Microsoft provides a starting point for help in the form of an Upgrade Advisor and
recommends that you run it to analyze how your upgrade project will go before you get
started on any project upgrades.
The Upgrade Advisor is used to analyze the configurations of SQL Server 2005 or
SQL Server 2000 components and identifies issues that you must address to ensure a
successful upgrade. The reports generated by this tool let you plan how to deal with
issues during an upgrade and the migration process. You can install the Upgrade
Advisor from the SQL Server 2008 product media, or you can download it from
Microsoft’s downloads center. Be sure to go through the system requirements for

installing the Microsoft SQL Server 2008 Upgrade Advisor.
In the following Hands-On exercise, you will install the Upgrade Advisor and then
run it to analyze your DTS 2000 packages.
Chapter 14: Migrating to Integration Services 2008 597
Hands-On: Analyzing DTS 2000 Packages
with SQL Server 2008 Upgrade Advisor
You need to analyze your existing DTS 2000 packages before upgrading them to
Integration Services format to learn about any issues that may come up during migration.
Method
In this Hands-On exercise, you will be using the Upgrade Advisor to analyze an existing
package, Importing Contacts.dts, provided in C:\SSIS\RawFiles. This exercise has two
main parts:
Installing the Upgrade Advisor
c
Running Upgrade Advisor and viewing an analysis report c
Exercise (Install Upgrade Advisor)
You will use SQL Server 2008 product media to install the required software in the
following steps. However, if you don’t have the product media, they can be freely
downloaded from Microsoft Download Center.
1. Run setup from the SQL Server 2008 media and click the Install Upgrade
Advisor link in the Planning page. The installation is straightforward and simple
(Figure 14-1).
Exercise (Run the Upgrade Advisor
to Analyze DTS 2000 Packages)
You will run the Upgrade Advisor to analyze the Importing Contacts.dts package and
will see the report.
2. Choose Start | SQL Server 2008 R2 Programs Group and start the SQL Server
2008 R2 Upgrade Advisor. You’ll see the Welcome page, which provides links
to documentation, the latest updates, and two links for Launch Upgrade Advisor
Analysis Wizard and Launch Upgrade Advisor Report Viewer. These two

components are the main components of the Upgrade Advisor.
3. Click the Launch Upgrade Advisor Analysis Wizard and click Next on the
Welcome screen of the Analysis Wizard.
4. Select the components you want to analyze in the SQL Server Components screen.
For this exercise, make sure you select the Data Transformation Services check
box as shown in Figure 14-2. You can also use the Detect button to let Upgrade
Advisor detect and select the services installed on the specified computer. Click
Next to move on.