I have an SSIS package that imports data from an MS Access database. I
have it running inside a job with a single step. If I manually run the
job, it will succeed only if I'm logged into the SQL Server box with my
network user account (note that I don't need to be logged into SQL
Server, just the server itself). It will fail otherwise.

I have the job set up as follows:

*Because the MS Access database is located on a remote server and
requires certain permissions to open, I created a credential based on a
my network user account, which has rights to open the MS Access file.

*I then created a proxy using this credential and associated it with
SSIS packages and CmdExec statements. The single job step is set to
run under this proxy.

*The single step is set to run my SSIS package located in a folder on
the SQL Server.

*As a test, I created a package with a single CmdExec step that copied
the remote Ms Access to a folder on the SQL Server. It runs under the
credential I created. This runs fine whether I'm logged into the box
or not. To me, this means that the credential is working.

*As a test I changed the data source in the SSIS package from the MS
Access file on the remote server to a copy of the MS Access file on the
sQL Server. This changed nothing. I still needed to be logged into
the box to get the job to run.

This is obviously a security/permissions issue, but where is the
problem? Why do I need to be logged into the box to get my package to
run? Note that the job history is no help as it only says "The package
execution failed. The step failed."

Bill E.
Hollywood, FL

This problem was solved. It was due to the package protection level
being to the default of EncryptSensitiveWithUserKey. I changed this to
EncryptSensitiveWithPassword and added a password. I then needed to
change the job step to run the package with CmdExec as in

dtexec /f "c:\ssis\package1.dtsx" /de mypassword

Now, everything runs fine.

I understand that there's a learning curve with anything new, but MS
sure did make things complicated.

Bill E.