I posted a similar question before, but I have now came back to the point where I need to deal with this and after some tuning I have managed to get rid of all the errors, except one warning that basically tells me that the path provided to the package not finding any files in the directory (which is false). This almost makes me want to believe this is again a permissions issue. As when I run the package locally it all works fine. Here is the warning:
Same message appears when I right click SSIS package under the catalogue and directly try to execute the job.
I made sure that the caller has full permissions to the folder in question
SQL Server Agent Job calls the job like so
With a single step in it to execute the SSIS package from the catalogue:
The history of the executions is all successful and the history of SQL Agent job is all green
One of the suggestions I got was to open SQL Server Configuration manager but I don't appear to have access to that. I am new to this whole process so I am not sure if authentication has something to do with it or the sa account's permissions.
Note: I am working on this on a remote dev server and not directly on my pc.
Any help would be greatly appreciated.
Since you're running the package as the Agent Service Account:
The permissions need to be applied to the SQL Server Agent Service Account or its per-service SID.
You can see the service account with PowerShell like this:
PS C:\Users\david> (Get-WmiObject win32_service | where Name -eq "SQLSERVERAGENT").StartName
NT Service\SQLSERVERAGENT
Turns out the database instance was on a whole different server that I wasn't even given access to. That server obviously didn't have the path specified in the SSIS package, so what I had to do is create a folder for files in the correct server, reroute my files there, and change the SSIS package path after obtaining the access to the server where DB instance lives. Me being new to all this, it was absolute frustration especially since our team is small and I am new in it I can't just ask someone questions about this all the time. Hopefully this will save someone a lot of time.
I've been stuck on this for sometime now. I have an SSIS package thats supposed to read a file and populate a database. I need to run it from a SQL Server Agent Job and the source files to read are located on a folder in another server that I have shared with this server.
The shared path to the folder looks like like this: \\server\D\folder\folder
However when I run agent job through a service account it tells me File name property is not valid. Filename is a device or contains invalid characters
The SQL Server Agent uses a service account to run this job. It runs just fine if the source path is located somewhere on the machine where the database instance lives, however I can't get it to run from a shared folder. If I run it myself by right clicking on the SSIS catalog I can run it just fine. I am aware that it is most likely a credentials issue, but all of these servers and accounts were not set up by me. Can someone help me explain how I should go about adding appropriate permissions to the said SA account so it can read the files successfully? Some examples/references would be greatly appreciated!
Things I've tried: Going to the folder security tab and adding all permissions to everyone on both the server where the folder originally is from and the server that the folder is being shared from. I can confirm everyone has the permissions with the windows PowerShell Get-Acl command.
Switching owner of the job task in SQL Server Agent to my account (I don't think its supposed to work ever to begin with) - this makes Agent complain about being "Unable to determine if user has server acces" with SA account it does have server access, it just can't read the folder.
I saw a post where someone suggests to change the SQL Agent Job advanced step option to "execute as user" and change the user with appropriate credentials, but I don't even see that option in my MSSQL.
I have stumbled upon this thread here , it was never really solved it seems but it looks like the 3 steps given should help me:
Assume that we need to write \serv\share\dir1..\dirN\targetDir\somefile.txt using SSIS throught SQL Agent Job and nonadmin proxy account MyDomain\TestAccount
MyDomain\TestAccount need read/write access to share \serv\share
MyDomain\TestAccount needed at least FILE_READ_DATA permission for all folders (share,dir1,..dirN)
MyDomain\TestAccount needed the CHANGE rights + FILE_DELETE_CHILD permission for folder targetDir
However, me being new to this, I have no idea how to properly check whether or not all these 3 conditions are true and if they are even completely relevant to the problem
EDIT:
There is a project-level variable in SSIS that determines where to read from (in this case set to \\server\d\folder\folder)
This variable is passed into forEach file enumerator in a for loop.
There is also a fileName variable used to check if file name was already loaded in the db as I store them in the table. The variable goes like this:
DECLARE #FileName VARCHAR(50) SET #FileName='' IF EXISTS (SELECT 1 FROM FileLoadStatus WHERE fileName = #FileName) BEGIN SELECT 1 AS FileExistsFlg END ELSE BEGIN SELECT 0 as FileExistsFlg END
If variables are at fault, I still don't know why it works if I execute it manually through catalog myself, but SQL Server Agent is unable to execute it through an SA account
EDIT 2: Exact errors say the following:
EDIT 3: Now that I have set a windows system task to execute the SSIS package instead of a SQL Server Agent Job it just tells me that the "for each file enumerator is empty" basically meaning it can't find any files in the destination to read, even though files are there
it might be a late respond, for all who come to check for an answer to this issue:
the main thing is to be sure that the SQL agent has the authority to read from the shared folder:
1- hold down the Windows key and press R on your keyboard to open the Run command in windows.
2- type services.
3- search for SQL Server Agent.
4- as in the screenshot shows on the logon option you will find which user the agent is using, be sure that this user has the authority to read from the shared folder.
or change the user to another one with the right credentials.
5- you can check the users of the shared folder by right clicking on it and choosing properties --> security. From this window you can change the credentials of the users.
I've seen this question asked several times but never with a satisfacory answer. I have read through all the posts I can related to this and tried as much as I possibly can.
I have an SSIS package that loops thru a network folder of Excel files, I won't explain what it does inseide the loop container as that is not relevant.
I refernce the folder via a UNC \servername\folder
The package works fine from within Visual Studio.
I deployed the package to the Integration Services Catalogs on the
server
After I deploy, I connect to the server from my local pc via SSMS and then I execute it from SSMS via "Integration Services Catalogs"... Execute - This fails.
However If I remote desktop onto the SQL Server box, then start SSMS, connect to the SQL Server using my own credentials and execute the package using exactly the same method as above it works fine.
When I look in the logs of the failed attempts I see a warning that "The For Each File enumerator is empty". I'm not sure if this is telling the full story as, if I rename the network folder, I get the same message, (I expected to see an error that the folder was not found) - this may or may not be relevant.
I've sketched up a quick overview of what works and what doesn't
NOTE The "script execution" method is just a t-sql script for running these packages. This is the method I will use eventually but at the moment I'm focusing on the simple right-click execute method as this essentially does the same thing.
Since I did this I have tried a few more things...
I've tried accessing the folder as a UNC, a mapped drive and also UNC using IP address instead of server name.
I recreated the issue on our development server so I could change
service accounts etc.
I tried the default accounts on both SSIS and SQL Agent services.
I tried changing these to domain accounts and network service accounts.
I get the package to log the folder name which is and expression - this always looks correct. I do the same with the user name which always shows me as the exection user.
I can change most things as I can test on the development server with the excpetion of testing with a domain admin account so any suggestions would be greatly appreciated.
I'm maintaining a project using Microsoft SQL Server 2016 (SP1) (according to this script) which heavily depends on recurring jobs (mirroring certain external db's and so on).
Especially the mirroring jobs are essentially based on SSIS packages which define a datasource, then execute a hardcoded SQL query and afterwards store the results in the specified destination.
Unfortunately the source databases where moved to a different domain and thus aren't accessible via the previous url.
My issue right now is that I simply have to change the source destination url but I'm not able to do that. There are plenty of ways to 'modify' SSIS packages but none of them seem to work with me.
What I managed (and seems the most promising) to do is to open the 'Integration Services...' part of my db, export the jobs to my desktop, modify them with Notepad and reimport them. And they seem to work if I execute them separately. But as soon as I try to execute the packages via SQL Server Agent it fails screaming:
Description: Failed to decrypt protected XML node "DTS:Password" with error 0x8009000B "Key not valid for use in specified state."
Does somebody know whats going on here and how I'm able to solve this? No password or username changed, only the connection string.
Is it even possible to manage a package like that?
Thank you for your help!
After further investigation I detected that even a newly created job didn't run properly. It was kind of strange that a package would run without any issues while directly executed but not via the SQL Server Agent, so I assumed it may be a rights issue and it was!
Somehow the Server Agent wasn't allowed to decrypt (although I never changed the executing user of a step) the password anymore.
I was able to work around my issue by simply creating each SSIS package again (some click hell but ok) but this time I secured 'sensitive data' with a password instead of the users key.
Afterwards I had to change each job step with a reference to to the damaged ssis packages and obviously type in the new passwords.
Seems to work again.
Thanks anyway
For some weird reason I'm having problems executing a bulk insert.
BULK INSERT customer_stg
FROM 'C:\Users\Michael\workspace\pydb\data\andrew.out.txt'
WITH
(
FIRSTROW=0,
FIELDTERMINATOR='\t',
ROWTERMINATOR='\n'
)
I'm confident after reading this that I've setup my user role correctly, as it states...
Members of the bulkadmin fixed server role can run the BULK INSERT statement.
I have set the Login Properties for the Windows Authentication correctly (as seen below).. to grant server-wide permissions on bulkadmin
(source: iforce.co.nz)
And the command EXEC sp_helpsrvrolemember 'bulkadmin' tells me that the information above was successful, and the current user Michael-PC\Michael has bulkadmin permissions.
(source: iforce.co.nz)
But even though I've set everything up correctly as far as I know, I'm still getting the error. executing the bulk insert directly from SQL Server Management Studio.
Msg 4861, Level 16, State 1, Line 2
Cannot bulk load because the file "C:\Users\Michael\workspace\pydb\data\andrew.out.txt" could not be opened. Operating system error code 5(Access is denied.).
which doesn't make sense because apparently bulkadmins can run the statement, am I meant to reconfigure how the bulkadmin works? (I'm so lost). Any ideas on how to fix it?
This error appears when you are using SQL Server Authentication and SQL Server is not allowed to access the bulk load folder.
So giving SQL server access to the folder will solve the issue.
Here is how to:
Go to the folder right click ->properties->Security tab->Edit->Add(on the new window) ->Advanced -> Find Now. Under the users list in the search results, find something like SQLServerMSSQLUser$UserName$SQLExpress and click ok, to all the dialogs opened.
I don't think reinstalling SQL Server is going to fix this, it's just going to kill some time.
Confirm that your user account has read privileges to the folder in question.
Use a tool like Process Monitor to see what user is actually trying to access the file.
My guess is that it is not Michael-PC\Michael that is trying to access the file, but rather the SQL Server service account. If this is the case, then you have at least three options (but probably others):
a. Set the SQL Server service to run as you.
b. Grant the SQL Server service account explicit access to that folder.
c. Put the files somewhere more logical where SQL Server has access, or can be made to have access (e.g. C:\bulk\).
I suggest these things assuming that this is a contained, local workstation. There are definitely more serious security concerns around local filesystem access from SQL Server when we're talking about a production machine, of course this can still be largely mitigated by using c. above - and only giving the service account access to the folders you want it to be able to touch.
I had the same problem SSIS 2012 and the solution was to use Windows Authentication. I was using SQL authentication with the sa user.
Go to start run=>services.msc=>SQL SERVER(MSSQLSERVER) stop the service
Right click on SQL SERVER(MSSQLSERVER)=> properties=>LogOn Tab=>Local System Account=>OK
Restart the SQL server Management Studio.
Try giving the folder(s) containing the CSV and Format File read permissions for ‘MSSQLSERVER’ user (or whatever user the SQL Server service is set to Log On As in Windows Services)
This is what worked for me:
Log on SSIS with Windows authentication.
1. Open services and find MSSQL NT Service account name and copy it:
2. Open folder from which SQL server should read from. Security - Group or user names tab - Add and paste there copied account:**
You will probably get "Multiple names found error", just select MSSQL user:
Your BULK INSERT query should run fine now.
If problem persists try adding SQL Server Agent account to folder permissions in same way.
Make sure you restart MSSQL server in services after you are done.
This is quite simple the way I resolved this problem:
open SQL Server
right click on database (you want to be backup)
select properties
select permissions
select your database role (local or cloud)
in the you bottom you will see explicit permissions table
find " backup database " permission and click Grant permission .
your problem is resolved .
sometimes this can be a bogus error message, tried opening the file with the same account that it is running the process. I had the same issue in my environment and when I did open the file (with the same credentials running the process), it said that it must be associated with a known program, after I did that I was able to open it and run the process without any errors.
Make sure the file you're using ('C:\Users\Michael\workspace\pydb\data\andrew.out.txt') is on the SQL server machine and not the client machine running MSSMS.
1) Open SQL
2) In Task Manager, you can check which account is running the SQL - it is probably not Michael-PC\Michael as Jan wrote.
The account that runs SQL need access to the shared folder.
I have come to similar question when I execute the bulk insert in SSMS it's working but it failed and returned with "Operation system failure code 5" when converting the task into SQL Server Agent.
After browsing lots of solutions posted previously, this way solved my problem by granting the NT SERVER/SQLSERVERAGENT with the 'full control" access right to the source folder.
Hope it would bring some light to these people who are still struggling with the error message.
In our case it ended up being a Kerberos issue. I followed the steps in this article to resolve the issue: https://techcommunity.microsoft.com/t5/SQL-Server-Support/Bulk-Insert-and-Kerberos/ba-p/317304.
It came down to configuring delegation on the machine account of the SQL Server where the BULK INSERT statement is running. The machine account needs to be able to delegate via the "cifs" service to the file server where the files are located. If you are using constrained delegation make sure to specify "Use any authenication protocol".
If DFS is involved you can execute the following Powershell command to get the name of the file server:
Get-DfsnFolderTarget -Path "\\dfsnamespace\share"