Hands-On Microsoft SQL Server 2008 Integration Services part 29 ppsx

258 Hands-On Microsoft SQL Server 2008 Integration Services
2. Expand the SQL Server Agent node in Object Explorer and right-click Jobs;
then choose New Job from the context menu to open the New Job dialog box.
3. Type Running Mailing Opportunities in the Name field. Ensure that the
Enabled check box is ticked before moving on to the Steps page.
4. Go to the Steps page and click New to create a new step for this job. In the Step
Name field of the New Job Step window, type Executing Mailing Opportunities
Step.
5. In the Type field, click the down arrow to display the list of job types and choose
SQL Server Integration Services Package. As you choose this option, the window
changes to include the options for running an Integration Services package.
6. In the Run As field, leave SQL Agent Service Account selected.
7. In the General tab, set the Package Source field to SSIS Package Store, type
localhost in the Server field, and leave Use Windows Authentication selected
in the Log On To The Server area. Click the ellipsis button next to the Package
field to choose the Mailing Opportunities package under the MSDB storage
folder. Click OK. Note the package path shown in Figure 6-6.
8. Click the Advanced page in the New Job Step window to see the available
options. You can specify what should happen on the success or failure of a step.
The default for success of a step is to go to the next step, and the default for
the failure of a step is to quit the job and report failure. You can also specify the
number of retry attempts and the time to wait between retries here, as well as
record output in an output file or table. Click OK to close this dialog box. You
should see the package listed in the Job Step List area. Notice the arrow buttons
on the lower-left side of this page; you can use these to move your job steps up
and down and hence change the order in which they are executed.
Exercise (Create a Schedule to Execute the Package)
In this section, you will be creating and adding a schedule to the job.
9. Move to the Schedules page. You can now create a new schedule for this job by
clicking the New button or choose a schedule from the list of already defined
schedules by clicking the Pick button. Once you create a schedule for a job, it

is listed in the Available Schedules list, where you can pick a schedule for other
jobs you define, saving you the time required to redefine similar schedules again.
As you have not created any schedule until now, you will create a new schedule
here. Click New to open a New Job Schedule window. In the Name field, type
Schedule for Mailing Opportunities package. Leave the Recurring setting in the
Schedule type field and leave the Enabled option checked.
10. In the Frequency area’s Occurs field, choose Daily and leave the Recurs Every
field set to 1 day.
Chapter 6: Administering Integration Services 259
11. In the Daily Frequency area, select a time equal to the time when you want to
execute the package. For the sake of quick testing, set the time about 10 minutes
from now.
12. In the Duration area, you can specify when to start and when to stop executing
the scheduled packages. Leave default values selected.
13. A summary of the schedule is shown in the Description box in plain English for
your review (see Figure 6-7). Click OK.
14. In the next two pages of Alerts and Notifications, you can create alerts, define
responses to those alerts, and send the notifications via e-mail, page, or Net Send
or write to a Windows Application event log. Refer to Microsoft SQL Server
2008 Books Online for more details on these topics.
Figure 6-6 Configuring a step for an SQL Server Agent job
260 Hands-On Microsoft SQL Server 2008 Integration Services
15. The Targets page lets you define which server to target with this job. SQL Server
2008 includes a feature called multiserver administration to manage multiple
servers by designating them a master server and target servers. The master server
distributes jobs to the target servers and receives events from them to keep the
status information. Target servers periodically connect to master servers to get the
new schedules for the jobs allocated, download new jobs, or update the master
server with the latest status about the jobs being run. You can create a master
server or target server from multiserver administration by right-clicking SQL

Server Agent in the SQL Server Management Studio. If no target servers are
listed, the only option is to run the job from the local server. For more details on
multiserver administration and how to make a master server or a target server,
refer to Microsoft SQL Server 2008 Books Online.
Figure 6-7 Creating a schedule for a job
Chapter 6: Administering Integration Services 261
16. Click OK to create the job. You will see this job listed in the Jobs node under
SQL Server Agent. Have a cup of coffee, and by the time you return to your
computer, you will see the test mails in your inbox.
Exercise (Using an SQL Server Agent
Proxy Account to Run the Job)
In the previous part of the exercise, you’ve added the job step using an SQL Server
Agent Service Account. In real life not many DBAs would like to run the jobs under
such a privileged account. SQL Server 2008 does provide an alternate way to run the
jobs under a less privileged account. To understand how the SQL Server Agent lets you
do this, you should know a couple of things.
Firstly, note that several security enhancements have been made in SQL Server 2005
onward that affect the way jobs run in the SQL Server Agent. In the versions before
SQL Server 2005, the SQL Server Agent service account had to be a member of the
local Administrators group when executing the xp_cmdshell extended stored procedure,
ActiveX scripting, or CmdExec jobs owned by users who were not members of the
SysAdmin fixed server roles. This is not required in SQL Server 2005 and above, as it has
a hierarchy of fixed database roles (in the MSDB database) to control access to the SQL
Server Agent. A user must be a member of any of the three fixed database roles in order
to use the SQL Server Agent. These roles, SQLAgentUserRole, SQLAgentReaderRole,
and SQLAgentOperatorRole, are stored in the MSDB database.
Second, when you define a job step for an SQL Server Agent job, you choose a
Type for the job as you did in Step 5. This job step is actually called an SQL Server
Agent subsystem and is a security object that represents a set of functionality available
to special accounts called the SQL Server Agent Proxy. The Sysadmin fixed server

role can create multiple proxy accounts and assign each account to a separate step of
an SQL Server Agent job. This means that you can create security contexts using
SQL Server Agent proxy accounts limited to their own subsystems and hence to a job
step only. You can have a proxy for multiple subsystems to keep things simple, but if
you have a requirement to secure each and every job step, you can do so. Ideally, you
will not run the SQL Server Agent service under a Microsoft Windows account that
has administrative privileges but will create dedicated proxy accounts with necessary
permissions required to run the job steps for the required subsystems and will use these
proxy accounts to configure the job steps. Enough theory, it’s time to do the hands dirty.
17. Create two windows accounts as follows that we will use in Chapter 7 as well.
Choose Start, right-click Computer, and choose Manage from the context menu.
In the Server Manager window, expand Configuration and then the Local Users
and Groups folder, right-click the Users folder, and choose New User from the
262 Hands-On Microsoft SQL Server 2008 Integration Services
context menu. This will open a New User window where you can create a user.
Fill in the following details to create a user account:
User name ISUser01
Password ISUp@ss01
Clear the User Must Change Password At Next Logon option check box before
clicking the Create button.
Create another user with the following details:
User name ISUser02
Password ISUp@ss02
Close the New User and Server Manager windows.
18. Next create logins for both users in SQL Server Management Studio.
Assign db_datareader role to ISUser01on the Campaign database. To do this, go
to User Mapping page, select the Campaign database in the Users Mapped To
This Login section, and select db_datareader in the Database Role Membership
section. Click OK to create this login.
Assign SQLAgentOperatorRole to ISUser02on the MSDB database. To do this,

go to User Mapping page, select msdb as the database in the Users Mapped To
This Login section, and select SQLAgentOperatorRole in the Database Role
Membership section as shown in Figure 6-8. Click OK to create this login.
19. In this step we will create an SQL Server Agent proxy account and will link this
account to ISUser01. To link these accounts, we will need to use a credential.
So, let’s first create a credential for ISUser01. In Management Studio, expand
the Security node, right-click on the Credentials node and select New Credential
from the context menu. Type ISUser01 in the Credential Name field. Select
the Windows user account ISUser01 in the Identity field by clicking the ellipsis
button. Finally fill in the password fields for the ISUser01 account and click OK.
Now expand SQL Server Agent and right-click the Proxies node. Select New
Proxy from the context menu. Type ISUser01 in the Proxy Name field and
select ISUser01 in the Credential Name field by clicking the ellipsis button. Now
select SQL Server Integration Services Package in the Active To The Following
Subsystems section (Figure 6-9). Click OK to create the proxy account.
20. Until now you’ve created accounts—ISUser01 with sufficient permissions to
execute the package and ISUser02 with rights to start the job. Let’s now modify
the job to use the proxy created earlier. Open the Running Mailing Opportunities
Job properties from the Jobs node. Go to the Steps page and click Edit to edit the
step. In the Run As field, select ISUser01 proxy from the drop-down list. Click
OK twice to close the Job Properties window.
Chapter 6: Administering Integration Services 263
21. Now, Logon with ISUser02 account. Open SQL Server Management Studio and
expand the Jobs node under SQL Server Agent. Right-click the Running Mailing
Opportunities job and choose Start Job At Step from the context menu. You will
see the job executed successfully. So, in the preceding step you’ve run a job using
an account ISUser02 that had no permissions on Campaign database and with
the proxy account ISUser01 that had just sufficient permissions to execute the job
successfully.
Figure 6-8 Assigning an SQL Server Agent operator role

264 Hands-On Microsoft SQL Server 2008 Integration Services
Exercise (View the Job History)
Let’s now study how you can obtain the status of a job:
You can configure a notification to be sent to you via e-mail while configuring the
c
job in the Notifications tab.
You can choose to write to the Windows Application event log in the
c
Notifications tab while configuring the job.
You can select to see the Job History from the Report drop-down list box in the
c
Summary sheet of Jobs in SQL Server Management Studio.
Figure 6-9 Creating a Proxy for SQL Server Integration Services Package subsystem
Chapter 6: Administering Integration Services 265
To see the detailed job history, you can right-click the job and choose View c
History. When you choose the View History option, you will see the history as
shown in the Log File Viewer window (see Figure 6-10).
Review
In this exercise, you learned how to automate execution of an SSIS package using the
SQL Server Agent. You learned how to create a new job, add steps to the job, specify a
schedule for the job, and view job history. You have also seen some of the key features
that make creation of jobs in the SQL Server Agent much safer and easier to run, such as:
Figure 6-10 Job History in Log File Viewer window
266 Hands-On Microsoft SQL Server 2008 Integration Services
e user account under which the job executes doesn’t need to be sysadmin c
anymore; you can use a proxy account to run the packages.
e steps of a job have a type that is, the agent subsystem—SQL Server
c
Integration Services Package—which allows you to configure all the options
required to run a SSIS package in this category.

Executing SSIS Packages Programmatically
SSIS packages can also be run programmatically using the SSIS Object Model. You
can build a custom application such as a Windows Forms application, an ASP.NET
Web form, or a Web service that allows users to run SSIS packages on local or remote
servers. SSIS exposes a rich object model that allows you to not only manage and run
SSIS packages but to build custom objects and packages to extend SSIS functionality.
More details on programming facilities in SSIS are covered in Chapter 11. Taking you
through the custom application development for this exercise is out of scope of this
book; however, the steps that you will take while building a custom application to run
SSIS packages are listed here.
1. First of all, you will add a reference to the Microsoft.SqlServer.ManagedDTS
assembly in your project, as it provides access to the managed run-time engine.
2. Import the Microsoft.SqlServer.Dts.Runtime namespace in your application,
as it will allow you to use classes and interfaces to load and run packages. The
Microsoft.SqlServer.Dts.Runtime namespace is commonly used in custom
applications, as it contains the classes and interfaces to create packages, custom
tasks, and other package control flow elements.
3. The Application class provides a mechanism to discover and access package
objects. You will use the Application class to discover and instantiate the package
object.
4. If you want to run the package on a local server, you will load the package first
before executing it. You can load a package using different methods based on the
storage type.
LoadPackage
c Loads a package stored in the file system
LoadFromSqlServer c Loads a package stored in the SQL Server
LoadFromDtsServer c Loads a package stored in the SSIS Package Store
Chapter 6: Administering Integration Services 267
For running a package on a remote server, you can use the LaunchPackage web
service method that loads the package using one of these methods based on the

source or storage type. You can also choose to run a package on the remote server
using the sp_start_job system stored procedure inside your application, in which
case, you don’t have to follow any of the preceding steps, but simply add a reference
to the System.Data assembly and build your application as you would to execute
a stored procedure on a remote server.
5. Irrespective of the fact that you can build an application to run SSIS packages
locally or on a remote server, SSIS packages execute on the server where the SSIS
service is installed. So, if you are executing packages locally, the SSIS service has
to be installed on the local server and if you are executing packages on the remote
server, the SSIS service has to be installed on the remote server.
6. Finally, you use the Execute() method to execute the package.
Summary
SQL Server 2008 comes with several tools that enable you to manage Integration
Services and Integration Services packages effectively and easily. You started this
chapter learning to manage storage locations for storing Integration Services packages.
You’ve used SQL Server Management Studio and dtutil to manage Integration Services
packages and storage areas. You also learned how to import and export an Integration
Services package from one storage location to the other. In the process, you created a
new storage location on the file system for these packages. Last, but most important,
you learned about various tools to run an Integration Services package that include the
use of the Execute Package Utility and the DTExec command-line utility. In the end
you automated running of a package by creating a job and its schedule using the SQL
Server Agent. In the next chapter we will discuss securing Integration Services packages
and use of fixed database-level roles to control access to SSIS packages.