?
Solved

SSIS Package Execution Error

Posted on 2014-01-12
8
Medium Priority
?
435 Views
Last Modified: 2016-02-10
I have a SSIS package that copies a file from one server to another.  The source server is on a workgroup, and the target server is on a domain (if it matters).    The package executes normally in debug mode, but after I deploy the package to sql server, it fails when trying to access the file on the source server.  I assume this is due to a different execution context when running on the server.

I have a mapped drive to the source server, which I am using as the source for the copy function.  The directory where the file exists has read/write for everybody.  I don't understand why access to this file is being blocked.

Since the user that runs the process (SQL Agent) doesn't exist on workgroup source server, I can't add it to security.

Sql Server 2012 R2.
0
Comment
Question by:No1Coder
  • 4
  • 4
8 Comments
 
LVL 18

Expert Comment

by:Matthew Kelly
ID: 39774912
What is the error that gets added to the SQL Agent history for the error? Also just to check, have you verified you can access the server drives when you are logged into the SQL server? I am assuming based on your question you are running debug on your machine and then deploying it to a different machine (the sql server)?

For example, if your script is using lettered drives instead of full path the letter drive may not exist. Follow on questions would be, is the SQL Agent running as a custom user or as NETWORK SERVICE?
0
 

Author Comment

by:No1Coder
ID: 39774942
I am using a lettered drive.  When debugging, I am running on the same server (where SQL Server runs).  

I changed the script to use \\ServerName\ShareName\path\file instead of lettered drive.

This works in debug mode, but fails in production mode.  Gets error "User Name or Password is incorrect".  The share in question has Everybody - full control.

I am not sure it this rund under sql server agen, or Integration Services.  For integration services, the user is NT Service\MsDtsServer110.
0
 
LVL 18

Expert Comment

by:Matthew Kelly
ID: 39775012
If the SSIS package is running as a job in a scheduled Agent job step it runs as the agent user. Local accounts won't be able to access cross domain resources and it appears your account has access (i.e. why it works in debug).

So try changing the Agent to run as your account and test to see if the deployed package works (or what error it gives then). If that works, create a new domain account and use it as the agent service account. At that point there are other security items you will want to do (such as set the account in domain policy for service logon only), but at this point try your account for testing.

Integration services also has the ability to use "Proxy Accounts" if you needed to only do it for this single job, but usually just running every job as a particular service account is fine for most servers.
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 

Author Comment

by:No1Coder
ID: 39775073
I used SQL Configuration tool to change both SQL Server agent and SQL Server integration Services to use my domain account.  The agent restarted.  When I run it, gets same error "User name or password error".

Another job that doesn't access the other server runs fine using my credentials.

How do you setup proxy accounts?
0
 
LVL 18

Expert Comment

by:Matthew Kelly
ID: 39775131
Although, the proxy just allows you to set different credentials for just a job step; so changing it to your credentials should do the same thing basically. Note they also needed to make sure the user existed on the workgroup server with the same name/password combination, but that doesn't explain why it works in debug for you...

You may also want to look in the Windows event logs to see if there is any additional information.
0
 

Accepted Solution

by:
No1Coder earned 0 total points
ID: 39777555
I got this to work by creating a local account of the source (non-domain) server with credentials that match the domain credentials that the agent is running on.
0
 

Author Closing Comment

by:No1Coder
ID: 39790470
fixed
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Why is this different from all of the other step by step guides?  Because I make a living as a DBA and not as a writer and I lived through this experience. Defining the name: When I talk to people they say different names on this subject stuff l…
This month, Experts Exchange sat down with resident SQL expert, Jim Horn, for an in-depth look into the makings of a successful career in SQL.
Viewers will learn how to use the SELECT statement in SQL and will be exposed to the many uses the SELECT statement has.
Stellar Phoenix SQL Database Repair software easily fixes the suspect mode issue of SQL Server database. It is a simple process to bring the database from suspect mode to normal mode. Check out the video and fix the SQL database suspect mode problem.

615 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question