SSIS Package Execution Error
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.
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.
ASKER
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\pat
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.
I changed the script to use \\ServerName\ShareName\pat
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.
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.
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.
ASKER
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?
Another job that doesn't access the other server runs fine using my credentials.
How do you setup proxy accounts?
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.
You may also want to look in the Windows event logs to see if there is any additional information.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
fixed
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?