Showing posts with label dtsx. Show all posts
Showing posts with label dtsx. Show all posts

Wednesday, March 21, 2012

Running SSIS package from SQL Job

I'm trying to run a SSIS package (dtsx) from inside an sql job (SQL Server agent). This works fine if the user running (run as) the step is a local admin on the server. If it's not, I get the error message "The package could not be loaded. The step failed". This happens even if the user has all possible serverroles such as "sysadmin" etc in SQL.

So, my question is, is there any way to load an SSIS package without being local admin on the machine? In case it is, what is needed?

regards Andreas

I'm not sure that this will solve the problem, but have a look at PROXY

and CREDENTIALS - I was able to invoke a sample package using them,

using a user that was only a member of the USERS local group.|||

GethWho wrote:

I'm not sure that this will solve the problem, but have a look at PROXY

and CREDENTIALS - I was able to invoke a sample package using them,

using a user that was only a member of the USERS local group.

here's a sample of what I did:

--code

--###################################################### describe

script

############################################################################

PRINT '>>> This script creates the LOGIN,

USER , CREDENTIALS and PROXY for INTEGRATION SERVICES SSIS PACKAGES

<<<'

PRINT '>>> This execution on server:

['+@.@.SERVERNAME+'] started at:

['+CONVERT(VARCHAR,CURRENT_TIMESTAMP,113)+'] <<<'

PRINT ''

PRINT '>>> Create Objects <<<'

PRINT ''

--################################################## Check and Drop

Existing

########################################################################

--################################################## CREATE Login

###################################################################################

SET NOCOUNT ON

USE [master]

IF NOT EXISTS (select 1 from sys.syslogins WHERE [Name] = 'LocalMachine\TestSSISUser')

CREATE LOGIN [LocalMachine\TESTSSISUser] FROM WINDOWS WITH DEFAULT_DATABASE = [MyDatabase]

--################################################## CREATE User and

Grant Rights on DBS

############################################################

USE [MyDatabase]

IF NOT EXISTS (select 1 from sys.sysusers WHERE [Name] = 'LocalMachine\TestSSISUser')

CREATE USER [LocalMachine\TESTSSISUser] FROM LOGIN [LocalMachine\TESTSSISUser]

EXEC SP_ADDROLEMEMBER [DB_DataReader], [LocalMachine\TESTSSISUser]

EXEC SP_ADDROLEMEMBER [DB_DataWriter], [LocalMachine\TESTSSISUser]

EXEC SP_ADDROLEMEMBER [DB_DDLAdmin], [LocalMachine\TESTSSISUser]

GRANT EXECUTE ON [sp_dts_addlogentry] to [LocalMachine\TESTSSISUser]

USE [msdb]

IF NOT EXISTS (select 1 from sys.sysusers WHERE [Name] = 'LocalMachine\TestSSISUser')

CREATE USER [LocalMachine\TESTSSISUser] FROM LOGIN [LocalMachine\TESTSSISUser]

EXEC SP_ADDROLEMEMBER [db_dtsadmin], [LocalMachine\TESTSSISUser]

EXEC SP_ADDROLEMEMBER [db_dtsltduser], [LocalMachine\TESTSSISUser]

EXEC SP_ADDROLEMEMBER [db_dtsoperator], [LocalMachine\TESTSSISUser]

EXEC SP_ADDROLEMEMBER [SQLAgentOperatorRole], [LocalMachine\TESTSSISUser]

EXEC SP_ADDROLEMEMBER [SQLAgentReaderRole], [LocalMachine\TESTSSISUser]

EXEC SP_ADDROLEMEMBER [SQLAgentUserRole], [LocalMachine\TESTSSISUser]

--################################################## CREATE Credential

##############################################################################

USE [master]

IF NOT EXISTS (select 1 from sys.credentials WHERE [Name] = 'TestProxy')

CREATE CREDENTIAL [TestProxy] WITH IDENTITY = 'LocalMachine\TestSSISUser', secret = 't3st'

--################################################## CREATE Proxy

###################################################################################

USE [msdb]

DECLARE

@.proxy_name SYSNAME,

@.subsystem_name SYSNAME,

@.UserName SYSNAME

SET @.proxy_name = 'TestSSISUser'

SET @.subsystem_name = 'CmdExec'

SET @.UserName = 'LocalMachine\TestSSISUser'

EXEC sp_enum_proxy_for_subsystem @.proxy_name=@.proxy_name, @.subsystem_name=@.subsystem_name

IF @.@.ROWCOUNT = 0

EXEC SP_ADD_PROXY


@.proxy_name=@.proxy_name, @.credential_name='TestProxy'

EXEC sp_enum_login_for_proxy @.proxy_name=@.proxy_name, @.name=@.UserName

IF @.@.ROWCOUNT = 0

EXEC SP_GRANT_LOGIN_TO_PROXY

@.login_name=@.UserName,

@.proxy_name=@.proxy_name

EXEC SP_REVOKE_PROXY_FROM_SUBSYSTEM @.proxy_name=@.proxy_name, @.subsystem_name=@.subsystem_name

EXEC SP_GRANT_PROXY_TO_SUBSYSTEM @.proxy_name=@.proxy_name, @.subsystem_name=@.subsystem_name

--###################################################### end script

##################################################################################

PRINT '>>> This execution on server:

['+@.@.SERVERNAME+'] ended at:

['+CONVERT(VARCHAR,CURRENT_TIMESTAMP,113)+'] <<<'

--code

.. it isn't perfect - I couldn't find a way to do an existance check

for the PROXY to run the SP_REVOKE_PROXY_FROM_SUBSYSTEM only if it

PROXY had been gtranted.|||

There will be a reason for the package failing to load, and this is what you need to find out. Use the CmdExec step type.

Scheduled Packages
(http://wiki.sqlis.com/default.aspx/SQLISWiki/ScheduledPackages.html)

Running SSIS package (.dtsx) from a ASP.Net web service

Where do I find about running an SSIS package (.dtsx) from a ASP.Net web service, particularly issues to do with permissions

cheers

Rob

Hi Rob,

There is books online entry that gives an example of how to do this.

http://msdn2.microsoft.com/en-us/library/ms403355.aspx

Also note the comments in the Community Content at the bottom. It has some important notes about security and thread impersonation.

~Matt

Running SSIS package (.dtsx) from a ASP.Net web service

Where do I find about running an SSIS package (.dtsx) from a ASP.Net web service, particularly issues to do with permissions

cheers

Rob

Hi Rob,

There is books online entry that gives an example of how to do this.

http://msdn2.microsoft.com/en-us/library/ms403355.aspx

Also note the comments in the Community Content at the bottom. It has some important notes about security and thread impersonation.

~Matt

sql

Running SSIS as an Agent job using a proxy

Hello,
I built a simple SSIS package using BIDS.
The package does a backup of a DB to a network share.
I imported the dtsx file into SQL Server using SQL Server WB (connected to
the SSIS server)
I created a SQL Agent job to run the SSIS package.
I have created a credential that maps to a domain account (BackupUser1). The
domain account has access to the network share: I verified it by running a
command line using the Run As and accessing the network share as that user.
Of course, I have a sql agent proxy associated to the credentials which is
assigned to run the job step that executes the SSIS package.
When the job runs it fails because of access denied to the network share.
To see what actually happened, I changed the permissions and the share (and
the NTFS permissions) to allow R/W access to 'everyone'.
I re-scheduled the job and this time it succeeds. I went over to the backup
file that was created when the SSIS package executed and discovered that the
owner (i.e. the creator) of the file is not the domain account (BackupUser1),
rather it's the data base server computer account name DBSRV$
this means that SQL Server Agent didn't impersonate the account defined by
the SQL Agent proxy.
I looked for information and wasn't able to find an answer...
A couple of things I made in the local security policy (user rights
assignment):
allowed the specified domain account the permission to log-on as a batch job
allowed the SYSTEM principal (the agent runs under LocalSystem) to replace
process level token (i.e. impersonate, at least as I understand this user
right)
Any thoughts, suggestion on why SQL Server Agent doesn’t actually use the
credentials associated with the proxy account to access the network share?
Thanks,
Asher
Hello Asher,
As for this issue, I've found your another new thread in the following
newsgroup:
Subject: Running SSIS pakcage as an agent job using a proxy
Date: Thu, 21 Sep 2006 02:58:02 -0700
Newsgroups: microsoft.public.sqlserver.server
I've posted my reply there with some suggestion. Please feel free to
followup there if you have any further finding or questions.
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.
|||Hello Asher,
As for this issue, I've found your another new thread in the following
newsgroup:
Subject: Running SSIS pakcage as an agent job using a proxy
Date: Thu, 21 Sep 2006 02:58:02 -0700
Newsgroups: microsoft.public.sqlserver.server
I've posted my reply there with some suggestion. Please feel free to
followup there if you have any further finding or questions.
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

Running SSIS as an Agent job using a proxy

Hello,
I built a simple SSIS package using BIDS.
The package does a backup of a DB to a network share.
I imported the dtsx file into SQL Server using SQL Server WB (connected to
the SSIS server)
I created a SQL Agent job to run the SSIS package.
I have created a credential that maps to a domain account (BackupUser1). The
domain account has access to the network share: I verified it by running a
command line using the Run As and accessing the network share as that user.
Of course, I have a sql agent proxy associated to the credentials which is
assigned to run the job step that executes the SSIS package.
When the job runs it fails because of access denied to the network share.
To see what actually happened, I changed the permissions and the share (and
the NTFS permissions) to allow R/W access to 'everyone'.
I re-scheduled the job and this time it succeeds. I went over to the backup
file that was created when the SSIS package executed and discovered that the
owner (i.e. the creator) of the file is not the domain account (BackupUser1),
rather it's the data base server computer account name DBSRV$
this means that SQL Server Agent didn't impersonate the account defined by
the SQL Agent proxy.
I looked for information and wasn't able to find an answer...
A couple of things I made in the local security policy (user rights
assignment):
allowed the specified domain account the permission to log-on as a batch job
allowed the SYSTEM principal (the agent runs under LocalSystem) to replace
process level token (i.e. impersonate, at least as I understand this user
right)
Any thoughts, suggestion on why SQL Server Agent doesnâ't actually use the
credentials associated with the proxy account to access the network share?
Thanks,
AsherHello Asher,
As for this issue, I've found your another new thread in the following
newsgroup:
Subject: Running SSIS pakcage as an agent job using a proxy
Date: Thu, 21 Sep 2006 02:58:02 -0700
Newsgroups: microsoft.public.sqlserver.server
I've posted my reply there with some suggestion. Please feel free to
followup there if you have any further finding or questions.
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

Running SSIS as an Agent job using a proxy

Hello,
I built a simple SSIS package using BIDS.
The package does a backup of a DB to a network share.
I imported the dtsx file into SQL Server using SQL Server WB (connected to
the SSIS server)
I created a SQL Agent job to run the SSIS package.
I have created a credential that maps to a domain account (BackupUser1). The
domain account has access to the network share: I verified it by running a
command line using the Run As and accessing the network share as that user.
Of course, I have a sql agent proxy associated to the credentials which is
assigned to run the job step that executes the SSIS package.
When the job runs it fails because of access denied to the network share.
To see what actually happened, I changed the permissions and the share (and
the NTFS permissions) to allow R/W access to 'everyone'.
I re-scheduled the job and this time it succeeds. I went over to the backup
file that was created when the SSIS package executed and discovered that the
owner (i.e. the creator) of the file is not the domain account (BackupUser1),
rather it's the data base server computer account name DBSRV$
this means that SQL Server Agent didn't impersonate the account defined by
the SQL Agent proxy.
I looked for information and wasn't able to find an answer...
A couple of things I made in the local security policy (user rights
assignment):
allowed the specified domain account the permission to log-on as a batch job
allowed the SYSTEM principal (the agent runs under LocalSystem) to replace
process level token (i.e. impersonate, at least as I understand this user
right)
Any thoughts, suggestion on why SQL Server Agent doesnâ't actually use the
credentials associated with the proxy account to access the network share?
Thanks,
AsherHello Asher,
As for this issue, I've found your another new thread in the following
newsgroup:
Subject: Running SSIS pakcage as an agent job using a proxy
Date: Thu, 21 Sep 2006 02:58:02 -0700
Newsgroups: microsoft.public.sqlserver.server
I've posted my reply there with some suggestion. Please feel free to
followup there if you have any further finding or questions.
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

Running SSIS as an Agent job using a proxy

Hello,
I built a simple SSIS package using BIDS.
The package does a backup of a DB to a network share.
I imported the dtsx file into SQL Server using SQL Server WB (connected to
the SSIS server)
I created a SQL Agent job to run the SSIS package.
I have created a credential that maps to a domain account (BackupUser1). The
domain account has access to the network share: I verified it by running a
command line using the Run As and accessing the network share as that user.
Of course, I have a sql agent proxy associated to the credentials which is
assigned to run the job step that executes the SSIS package.
When the job runs it fails because of access denied to the network share.
To see what actually happened, I changed the permissions and the share (and
the NTFS permissions) to allow R/W access to 'everyone'.
I re-scheduled the job and this time it succeeds. I went over to the backup
file that was created when the SSIS package executed and discovered that the
owner (i.e. the creator) of the file is not the domain account (BackupUser1)
,
rather it's the data base server computer account name DBSRV$
this means that SQL Server Agent didn't impersonate the account defined by
the SQL Agent proxy.
I looked for information and wasn't able to find an answer...
A couple of things I made in the local security policy (user rights
assignment):
allowed the specified domain account the permission to log-on as a batch job
allowed the SYSTEM principal (the agent runs under LocalSystem) to replace
process level token (i.e. impersonate, at least as I understand this user
right)
Any thoughts, suggestion on why SQL Server Agent doesn’t actually use the
credentials associated with the proxy account to access the network share?
Thanks,
AsherHello Asher,
As for this issue, I've found your another new thread in the following
newsgroup:
Subject: Running SSIS pakcage as an agent job using a proxy
Date: Thu, 21 Sep 2006 02:58:02 -0700
Newsgroups: microsoft.public.sqlserver.server
I've posted my reply there with some suggestion. Please feel free to
followup there if you have any further finding or questions.
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.