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.
Wednesday, March 21, 2012
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment