228 Hands-On Microsoft SQL Server 2008 Integration Services For the MSDB database of the remote SQL Server, you’ll modify the ServerName element as shown: <ServerName>RemoteSQLServerName</ServerName> And for the File System folder on a remote server, you’ll modify the StorePath element as shown: <StorePath>\\RemoteFileServerName\ShareName</StorePath> You will have to restart the SQL Server Integration Services 10.0 service for changes to take effect. After restart, when you connect to the local instance of Integration Services using SQL Server Management Studio, the MSDB folder in Stored Packages will show the packages saved to the remote SQL Server and the File System folder will show the packages saved to the file share on the remote server. Managing Packages on an Instance of an SQL Server One important point is to understand that Integration Services is not a multi-instance application like SQL Server. However, it is aware of SQL Server instances and can connect to them. For example, you might prefer to save your packages in the instance of SQL Server to which they relate instead of saving them into default instance. In that case you can modify the ServerName element as follows and connect to the MSDB database of the specified instance of SQL Server. <ServerName>ServerName\InstanceName</ServerName> You will have to restart the SQL Server Integration Services 10.0 service for changes to take effect. After restart, when you connect to Integration Services using SQL Server Management Studio, the MSDB folder in Stored Packages will show the packages saved to the specified instance. Connecting to Integration Services on a Remote Server Sometimes, you may also want to connect to Integration Services on a remote server; for instance, you may be using SQL Server Management Studio on your client machine but connecting to remote Integration Services. You can do so when you choose Integration Services in the Server Type field and the remote server name in the Server Name field in the Connect To Server dialog box, which pops up when you start SQL Server Management Studio or when you click the Connect button in the Object Explorer and choose Integration Services from the options list. Remember, Integration Services is a Windows service and uses Windows authentication; that is, it is logged on to the user’s Chapter 6: Administering Integration Services 229 account to connect to a remote server. If your account has permissions to connect to the remote Integration Services server, you will connect without any issues. However, you may receive an “Access Is denied” error if you do not have sufficient rights. To allow remote users connections, users need to have permissions on DCOM objects and the Integration Services service needs to be configured for the DCOM permissions. As you can guess, administrators will have access by default; however, if you’re using restrictive security on your server (that is, if you want to give users just enough rights to let them perform their jobs), you need to assign them appropriate permissions. First, you will need to add the required users into the Distributed COM Users group. You also need to assign users Remote Activation rights in the Launch and Activation Permissions section under the Security tab of MsDtsServer100 application properties. You can access MsDtsServer100 application under the DCOM Config node of Component Services management tool. For more details on how to configure rights for users, search for the article “Connecting to a Remote Integration Services Server” on MSDN. Managing SSIS Packages SQL Server Management Studio enables you to connect to Integration Services and manage your SSIS packages using a graphical interface. Integration Services allows you to save your packages either on the file system or in the MSDB database and can manage the storage and running of your packages from this single interface. You can import packages from any storage area and export into another. You can also run your packages from here and watch their progress while the packages are executing. Let’s do a quick Hands-On exercise to understand the storage options provided by the Integration Services service. Hands-On: Working with Integration Services Storage Folders In this exercise, you will learn about the storage areas where you can save packages and how you can change their storage type and location. Method The following will be completed: Connect to the Integration Services service and understand the storage areas C Save a package to SSIS Package Store C Add a root-level folder to Stored Packages C Import and export packages C 230 Hands-On Microsoft SQL Server 2008 Integration Services Exercise (Connect to Integration Services Service and Understand the Storage Areas) In the first part of this Hands-on, you will use SQL Server Management Studio to connect to Integration Services service and understand the folder structure it provides. 1. Run SQL Server Management Studio. Choose Integration Services in the Server Type field of the Connect To Server dialog box and type in the name of your server in the Server Name field. Then click Connect. 2. You should see the two top-level folders—Running Packages and Stored Packages. The Running Packages folder lists the currently running packages. You will be monitoring running packages from this place. Expand the Running Packages folder. You will realize that it doesn’t have any subfolder and you will not be able to create a subfolder under it. This is because the Running Packages folder is not extensible. 3. Expand the Stored Packages folder. Note that it has two subfolders—File System and MSDB. The packages saved on to the file system appear under File System folder, and the packages saved inside the SQL Server MSDB database appear under the MSDB folder. You can create subfolders under any of these folders, as this area is configurable and extensible. You will be working primarily with this area to manage the storage of your folders. 4. The File System and MSDB folders are called root-level folders. The File System folder lists the packages stored in the file system. The default location of this folder is %Program Files%\Microsoft SQL Server\100\DTS\Packages. Right-click the File System folder and choose New Folder from the context menu. Type Campaigns in the Create New Folder window and click OK to close the dialog box. You will see the Campaigns subfolder under the File System folder, you might have to refresh if this is not visible. Now explore to the %Program Files%\ Microsoft SQL Server\100\DTS\Packages folder and you will see Campaigns folder there. You can also create subfolders in the MSDB folder. Packages saved to the SQL Server MSDB database appear under the MSDB folder in Integration Services. To sum up, you can create subfolders under the File System folder and the MSDB folder to manage your packages in a hierarchical order. You can then delete or rename these subfolders; however, you cannot delete or rename the root folders. Exercise (Save a Package to an SSIS Package Store) In this part, you will explore three package storage areas the Integration Services service provides, and will save a package into SSIS Package Store area. 5. Start BIDS and open the Contacting Opportunities solution. When the solution loads, open the Mailing Opportunities.dtsx package under the SSIS Packages node to open the package in the Designer. When the package appears on screen, choose File | Save Copy Of Mailing Opportunities.dtsx As. This will open the Chapter 6: Administering Integration Services 231 Save Copy Of Package dialog box, which gives you choices of where you want to save your package. Click the down arrow in the Package location field to see the locations where you can save your packages. You have three options: SQL Server c File System c SSIS Package Store c Choosing SQL Server lets you save your packages to the sysssispackages table of the MSDB database in SQL Server. The packages saved using this option will appear under the MSDB folder when you connect to Integration Services using SSMS. The File System option allows you to save your package anywhere on the file system. You can specify a path in the Package Path field for saving the package. You will be using this option if you do not want to save your packages in the Integration Services’ defined storage area, the %Program Files%\Microsoft SQL Server\100\DTS\Packages folder. The packages saved using this option will not be available for management under SQL Server Management Studio. There are times or instances when you would like to choose this option; for instance, you may want to save your packages on a central file server instead of the local server or you may not want your packages be made available in Integration Services storage folders. The third option of SSIS Package Store allows you to save your package in the Integration Services–defined storage area on the file system or in the MSDB database. When you select this option and click the ellipsis button to specify a Package Path, you are taken to the root-level folders inside the Integration Services Stored Packages area and the File System and MSDB folders are shown to you. It’s worth noting the difference between the File System option provided to you in the Package Location field earlier and the current File System folder shown inside the SSIS Package Store. The earlier option of File System allows you to save your package anywhere on the file system and those packages will not be visible in SQL Server Management Studio, while selecting the File System folder in the SSIS Package Store option lets you save your package only under the Stored Packages root folder defined in Integration Services, which by default is %Program Files%\Microsoft SQL Server\100\DTS\Packages, and the packages saved here will be available for management in SQL Server Management Studio. The defined storage area on the file system is configurable and you can change the location of this folder; however, it is worth noting the difference between these two options so that you don’t confuse yourself while saving the packages. 6. Select SSIS Package Store in the Package location field and type in your server name or localhost in the Server field. Click the ellipsis button opposite to the Package Path field to open the SSIS Package dialog box. Expand the File System folder, select Campaigns, and then type Mailing Opportunities in the Package Name field. Click OK to return (see Figure 6-1). Note the path specified in the Package path field. Click OK again to save the package. 232 Hands-On Microsoft SQL Server 2008 Integration Services 7. Switch to SQL Server Management Studio, right-click the Campaigns folder, and choose Refresh to see the Mailing Opportunities package. Also, if you explore to the Campaigns folder under the %Program Files%\ Microsoft SQL Server\100\DTS\Packages folder, you will see the Mailing Opportunities.dtsx file saved there as well. This is the default location specified in the Integration Services configuration file, which is discussed in the next part. Exercise (Add a Root-Level Folder to Stored Packages) Now you know that the root-level folders can contain subfolders. But what if you want to store your packages at different location than the default location? Integration Services provides you with a configuration file to configure the storage locations. 8. Open the MsDtsSrvr.ini.xml file with Notepad to see the XML configuration code. This code has been listed earlier, in the section “Managing Packages with Default Settings.” Locate the XML element <StopExecutingPackagesOnShutdown> and note that you can control how Integration Services treats the running packages when the service is stopped. By default, it is set to True, which means that the running packages will be stopped when the SSIS service is stopped. By changing Figure 6-1 Saving your package to the SSIS Package Store Chapter 6: Administering Integration Services 233 True to False in this line, you can configure Integration Services to continue running packages even if the SSIS service has been stopped. 9. We will now add a root file system folder so that we can save our packages to a different area. Move to the XML element <Folder xsi: type="FileSystemFolder" > in the configuration file. Note that the storage path \Packages actually points to the %Program Files%\Microsoft SQL Server\100\DTS\Packages folder. Copy the <Folder> element—i.e., copy four lines starting from <Folder xsi:type="FileSystemFolder"> to </Folder>. Now add these lines between the </Folder> and </TopLevelFolders> elements. In the new lines, change the values of the <Name> element to My SSIS Packages and <StorePath> element to C:\SSIS\Packages. Your new lines should look like this: <Folder xsi:type="FileSystemFolder"> <Name>My SSIS Packages</Name> <StorePath>C:\SSIS\Packages</StorePath> </Folder> Save the configuration file. To see the changes, you have to restart the Integration Services service. Start the SQL Server Configuration Manager and click the SQL Server Services node in the left-hand pane. Locate the SQL Server Integration Services 10.0 service from the list, right-click, and choose Restart. Once the service stops and starts again, switch to SQL Server Management Studio and refresh Stored Packages to see the newly added root level folder, My SSIS Packages. This folder points to C:\SSIS\Packages folder on the file system. Exercise (Import and Export Packages) You can change the storage location of packages by using the import and export features of the Integration Services. This can also be done from the command prompt using the dtutil utility. In this exercise, you will import the Mailing Opportunities package to the MSDB folder and then export this package to the My SSIS Packages store you created previously. 10. Switch to SQL Server Management Studio, right-click the MSDB folder, and choose Import Package. An Import Package window will open. This window is similar to the Save Copy Of Package dialog box, except it has an extra field for specifying the package name to be imported. In the Package Location field drop-down list, choose SSIS Package Store and type localhost in the Server field. Click the ellipsis button opposite to the Package Path field. In the SSIS Package dialog box, expand the File System folder, then the Campaigns folder, and then select the Mailing Opportunities package (see Figure 6-2). Click OK to return. 11. Verify that the Package name field contains the name Mailing Opportunities. Click OK to start importing the package. Refresh the MSDB folder to see that the Mailing Opportunities package has been imported. 234 Hands-On Microsoft SQL Server 2008 Integration Services Connect to the local database server using the Connect button in the Object Explorer window. Open a new query pane and run the following query against the MSDB database: SELECT * FROM msdb.dbo.sysssispackages WHERE name like 'Mailing%' The result set will contain all the information about the Mailing Opportunities package. 12. Let’s export our package to an area on the file system, which is not defined in the SSIS Package Store. Go to Integration Services in the Object Explorer of SQL Server Management Studio, right-click the package Mailing Opportunities stored under the MSDB folder, and choose Export Package from the list of options. 13. An Export Package\MSDB\Mailing Opportunities dialog box opens. In the Package location field, choose SSIS Package Store and type localhost in the Server field. These settings enable Integration Services to read storage locations from the MsDtsSrvr.ini.xml file on the local server. 14. Click the ellipsis button next to the Package Path field to open the SSIS Package dialog box. Here you can see the My SSIS Packages folder you created earlier in Integration Services. Select My SSIS Packages and verify that the Package Name field already has Mailing Opportunities filled in. Click OK to close this dialog box. You will see the /My SSIS Packages/Mailing Opportunities value specified in the Package Path field. This is a user-friendly option that allows you to create a storage location pointer in Integration Services; all users can save packages without bothering about the actual storage location of the package. This is also quite helpful in case you want to keep your packages on a central server for archiving on your Figure 6-2 Selecting a package to import Chapter 6: Administering Integration Services 235 network storage. You also get an opportunity to define a new name to your package here, which is helpful in case you are saving with version numbers attached in the end of the package name. Click OK to export the package. Explore to the C:\SSIS\ Packages folder to verify that the package has been saved there. Leave the SQL Server Management Studio running (if you’re not ready for a break yet!), as we will return to it in the next exercise. Review In this exercise, you worked with root folders of Integration Services and managed to create a subfolder to the root folder, save a package to it, and view the options available for saving a copy of the package. You also learned about where you can monitor the running packages and where you can save them. After that, you used the configuration file for Integration Services to create an additional root folder, My SSIS Packages. The path specified for the My SSIS Packages folder was on the local server hard disk in this exercise, but it is not limited to that. You can actually use a UNC network share (such as \\<computername>\sharename) for the folder path and point your SSIS packages store to a central network share. You also saw how to use import and export features to change the storage type and location of the packages. While we are discussing the configuration file options, you might find a couple of other options useful. If you want to use an SQL Server named instance on the same server or on the remote server for storing your Integration Services packages, you can do so by specifying the instance name in the <ServerName> element of configuration file. You can specify the named instance in the format InstanceName\ServerName. Save the file, restart the Integration Services service, and you are ready to store your packages in the specified SQL Server named instance. The second option is to use an alternative configuration file. Integration Services does allow you to set up and use an alternative configuration file. By default, Integration Services refers to the MsDtsSrvr.ini.xml configuration file located at C:\Program Files\ Microsoft SQL Server\100\DTS\Binn\ MsDtsSrvr.ini.xml. This location is mentioned in the Windows registry. You can change the location of the default configuration file by modifying the value of the registry key HKEY_ LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\ SSIS\ServiceConfigFile. After making this change, all you need to do is restart the Integration Services service, which will then read the new file from the location you specified in the registry. dtutil Utility You have worked with Integration Services from within SQL Server Management Studio and have imported and exported your SSIS packages with the help of GUI tools. Having used these tools, you have realized how easy it is to manage your 236 Hands-On Microsoft SQL Server 2008 Integration Services Integration Services packages from the tools’ GUI. However, sometimes you need a command-line tool to write scripts to do the work in batches, you may want to automate tasks, or perhaps you want to schedule jobs. In this section you will learn to use dtutil, a command prompt utility provided for managing Integration Services packages. The dtutil utility can be used for the following: Verifying the existence of an SSIS package c Copying SSIS packages c Moving SSIS packages c Deleting SSIS packages c Signing SSIS packages c You can use dtutil to perform any of these operations on any type of storage—i.e., the MSDB database in SQL Server, anywhere on the file system, and the defined SSIS Package Store. Here is the base syntax: dtutil /option [value] [/option [value]] The parameters can be in any order and are not case-sensitive. Also, they are defined in terms of option and value pairs. The options must begin with a slash (/) or a minus sign (–). The dtutil uses different options for passing user credential details of the source and destination servers. For the source server, dtutil uses these options: SourceS c For the source server SourceU c For the user name at the source server SourceP c For the password of this user And for the destination server, dtutil uses the following options: DestS c For the destination server DestU c For the user name at the destination server DestP c For the password of this user You may see a pipe (|) at some places in the syntax, which is used as an OR operator to show the possible values of the arguments. Finally, it is easier to learn the dtutil commands by practicing them than by trying to memorize the syntax. So let’s get started with the Hands-On exercises. Chapter 6: Administering Integration Services 237 Hands-On: Using dtutil In this Hands-On exercise, we will use dtutil against various scenarios to understand how it works and learn the syntax along the way. Method Start SQL Server Management Studio and connect to Integration Services. Also, open Windows Explorer and the command prompt and be ready to switch windows to see the results. Exercise (Verify the Existence of an SSIS Package) You can check the existence of a package using the EXISTS option of dtutil: dtutil /EXISTS [/option [value]] 1. Verify whether the Mailing Opportunities package exists in the MSDB database of the local server instance: dtutil /EXISTS /SQL "Mailing Opportunities" As we know that the package exists in the local instance, you will see the “The specified package exists” message. The SQL option checks for packages stored in the MSDB database of the SQL Server. The other options that can be used instead of SQL are FILE and DTS. The FILE option allows the dtutil to check the existence of a package on the specified file system folder, whereas DTS checks through the defined SSIS Package Store. Note that the SQL option cannot be specified with the DTS or FILE option, as they are mutually exclusive. However, you can use the User, Password, or Server options to extend the SQL option usage. 2. Verify that the Mailing Opportunities package exists in the C:\SSIS\Packages folder of the local server: dtutil /EXISTS /FILE "C:\SSIS\Packages\Mailing Opportunities.dtsx" The FILE option checks the specified file system folder for the existence of the package. Note that FILE option cannot be specified with the DTS, SQL, User, Password, or Server options. Also, note the way you specify the name of an SSIS package—with the FILE option you have to specify the .dtsx extension with the package name, while this is not to be included for the other two SQL and DTS options. 3. Verify that the Mailing Opportunities package exists in the shared folder called Data, of the remote server named AIT: dtutil /EXISTS /FILE "\\AIT\Data\Mailing Opportunities.dtsx" . 228 Hands-On Microsoft SQL Server 2008 Integration Services For the MSDB database of the remote SQL Server, you’ll modify the ServerName element as shown: <ServerName>RemoteSQLServerName</ServerName> And. Hands-On Microsoft SQL Server 2008 Integration Services Exercise (Connect to Integration Services Service and Understand the Storage Areas) In the first part of this Hands-on, you will use SQL Server. restart the Integration Services service. Start the SQL Server Configuration Manager and click the SQL Server Services node in the left-hand pane. Locate the SQL Server Integration Services 10.0