Re: SSIS as part of scheduled job fails
- From: "Matt Yeager" <myeager@xxxxxxxxxxxxxxxxx>
- Date: Wed, 3 May 2006 08:34:26 -0500
I posted this in another thread, but this looks like the same issue so I'm
copying the message here:
I encountered the same problem, even on the same server upon deployment.
I ended up contacting Microsoft and opening a support case. After a couple
of hours on the phone, we found that if the SSIS Package's Security setting
"ProtectionLevel" was set to EncryptAllWithUserKey or
EncryptSensativeWithUserKey that the passwords would actually be lost. This
has to do with the fact that the SQL Server Agent process on your server is
running as a different user and cannot validate the user key basically. What
I ended up having to do is switch the Security ProtectionLevel to use
EncryptAllWithPassword or EncryptSensativeWithPassword and specify a
password for the package. I then re-deployed to SQL.
How I scheduled the Job also had to change. I could no longer specify my
package as a SSIS Step in a Job. I had to make my Job execute an "Operating
System (CmdExec)". The command line was :
C:\Program Files\Microsoft SQL Server\90\DTS\Binn\DTExec.exe /DTS
"\MSDB\YOURPACKAGEHERE" /SERVER Q /DECRYPT YOURPASSWORDHERE /MAXCONCURRENT
" -1 " /CHECKPOINTING OFF /REPORTING V
It seems like very much a work-around, but that's roughly the way I was told
to keep the protected passwords. My support case person spoke with the
engineers and that was the desired result evidently. They are working on
documenting the Security Levels more though, as this seems to be coming up a
lot. I honestly wouldn't be suprised if something in Security levels changed
in SP2.
Hope this helps.
"Joe S." <joecrew@xxxxxxxxxxxxxx> wrote in message
news:45738B3D-3021-4E7C-A81F-155792D04CC5@xxxxxxxxxxxxxxxx
I have created a simple import job that first truncates three tables and
then
imports update data into those tables from an Access database. My problem
is
that the job fails on when running the SSIS import package. The import
works
when I create the package, but not from within the jop. I believe it might
be
the account the job is run under, but I cannot change that, since it
always
reverts back to running under the local system account. WHen looking at
the
job history I see that the truncate step runs under NT Authority/system
while
the SSIS package is listed as running under Athena/system (athena is the
server name). I had to correct a problem with the Reporting Service being
installed with a simular error and not being able to run until I changed
the
config file to have NT Authority/system as the user account.
.
- Prev by Date: RE: SSIS as part of scheduled job fails
- Next by Date: Re: VB Call DTS
- Previous by thread: RE: SSIS as part of scheduled job fails
- Next by thread: Re: SSIS as part of scheduled job fails
- Index(es):
Relevant Pages
|
