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. . 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. . 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,. 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.