I have an SSIS 2005 package which is being executed using an SQL Agent Job. This package has a Web Service Task with different credentials than those being used to execute the package.
I am having the following problem when my package is executed on the Server:
"Microsoft.SqlServer.Dts.Tasks.WebServiceTask.WebserviceTaskException: System.UnauthorizedAccessException: Access to the path ..... is denied.
The package is being executed on a clustered environment. Both accounts have been created on the server so that package is able to write to TEMP files but problem still persists.
Based on this thread, you should be able to set the OutputLocation property of the webservice. This will need to be configured to point to a location the credentials of the user invoking the webservice will have access to. This might require an admin modifying ACLs on a directory path.
In a clustered environment, you should ensure the location being written to is a clustered resource. For example, you can create file share, but the file share must be a cluster resource so that it is available when the cluster fails over. If you are writing to a drive, ensure the drive is a cluster drive dependent on the proper SQL Server resource.
Related
I've inherited an SSIS package which loads CSV files into a SQL database.
The first thing the package does is call a .BAT file which maps a network drive. The .BAT file contains the username and password used to map the drive in plain text, so urgently needs to be replaced.
I've written a solution which uses New-PSDrive in a Powershell script and creates a credentials XML file with the password encrypted. If I execute the ps1 script it works Ok.
If I call the ps1 script from within SSIS and run it through VS then it also works fine.
When I call the SSIS package that calls the script task through a SQL Agent job (executed as the SQL Server Agent user account) the drive mapping doesn't seem to work, and the package complains it cannot access the file from the file share.
I presume this is no working because the SQL Server Agent user account can't run Powershell queries? The package only errors because it cannot access the share, not during the execution of the Powershell script.
So, two questions:
Is there an obvious issue with the SQL Agent deployment idea
or
Is there a different way of mapping a network drive from within SSIS without storing the password in plain text anywhere?
This is the pattern I suggest using for accessing files on a remote server:
Access the files via unc path: \\MyServer\Files
This means that the package needs to run under a context that has access to the path. There are a couple of options:
Run the package under a proxy, i.e. the account credentials that were stored in the bat file. This means that you have to also grant access to the account on the sql instance as well
Use a group managed service account (gMSA). In this case, the sql agent service account is replaced with the gMSA and the job runs under sql agent. The gMSA needs to be granted access to the remote share as well as the sql instance. This is a much more secure way of addressing the whole process because there is no password to manage (AD takes care of that) and the account cannot be used to log in anywhere. But there is set up work to do to get it created so it's not the fastest option.
I have created SSIS packages which creates new folder using file system task at output location and then creates data files in that folder using data flow task.
I have created one network drive which is mapped to azure blob. So I pass the network drive path like Z:\ to package and the folder and files are created as expected which are also reflected on the azure blob.
Now when I schedule this package through SQL agent job I get error that the cannot find part of the path Z:\folderName from file system task. So I though it is because the sql server agent service was not running through my user id . So I started sql server agent with my credentials but it still gives me same error.
Note: My Id doesnt have direct access to azure blob and the network drive is only accessible by my id.
We are currently using azure blob for dev but we may use separate server to store files due to which I cannot use flexible file system task available in SSIS azure service pack
We had reasons we could not use UNC paths (\server\share\file.txt) and struggled with mapped drives as well. The approach we ended up using was to explicitly map and unmap drives as part of our ETL Process.
Execute Process Task - Mount drive
We used a batch file to mount the drive as it made things easier on us but the command would take the form of something like
net use Z: \\server\share mypassword user#azure
Execute process task - Unmount Drive
Again, execute process task
net use /delete Z:
We ended up with a precursor step that I don't remember how we accomplished it, but we would test whether the drive had been unmounted before we attempted to mount it. I think it was File System Task to see if the drive existed and if so, then we had the Unmount task duplicated.
I was able to resolve this using credential manager. I logged in using a domain user and then added the azure path like \\server, userid and password to windows credentials . Then started the sql server agent service using the same domain user id . Set up the file path as \\server\share similar to what I have provided in windows credentials into the ssis package configurations.After doing this I was able to successfully execute the package through sql agent job.
I was able to solve this issue using script task (C# Code) to move data. I've generated a project parameter for Target ShareFolder and used it as ReadOnlyVariable for script task. The target share folder has been already mapped as a network drive on my local PC as well as on Application Server.
I am getting following error on BULK INSERT after the file location was changed to remote share. Before it used to be a shared folder in local drive and we never ran into this issue. I am running this BULK INSERT from my local PC connecting to SQL Server via SSMS.
I have made sure both SQL server and file permissions are in place.
Before when I ran this command from SSMS, it was \\SQLServer\FTP location which was a shared folder in local drive in that SQL Server but now I changed the file location to a network share \\Fileshare\FTP and have the above error but both SQL service account (domain account) and me (domain account) have elevated permission on that new location.
Any help or suggestions!!
Thanks,
I can identify three circumstances that might generate this issue:
From the SQLAuthority Blog, full detail on a related backup issue where there is a cross-domain link (in this case, from a workgroup to a full domain).
There are also two other possible answers in the question Cannot bulk load because the file could not be opened. Operating system error code 1326(Logon failure: unknown user name or bad password.) here on StackOverflow. We can discount the first one (login permissions) because you stated that you had permissions, but the other solution (I fixed it by adding the SQL Server port number to the connection string in SSIS, forcing SSIS to access SQL Server through TCP/IP instead of Named Pipes.) could apply. Try forcing a connection to the server using TCP/IP.
All of these issues appear to be related to having an attempt at cross-domain communication. If this is the issue with you, one or more of these fixes should be applicable to your issue.
-
It finally worked....
I had to configure Kerberos Authentication following the guide from this link https://thesqldude.com/2011/12/30/how-to-sql-server-bulk-insert-with-constrained-delegation-access-is-denied/.
Of course, I had to make adjustments to suit our environment and had to involve Active Directory Admin for creating SPNs and enabling DELEGATION properties.
Thanks.
When I execute my SSIS Package manually it works just fine, But when I try to execute it from SQL agent i always get an error. In my case the SSIS is called from a certain path in the server.
. The error is as follows:
Also when I See the Job Scrip I see the following under
#command N'/FILE "N:\HRSSource\SSIS-Pakete IUT-NAV-MSSQL-2 .....
Maybe the error is comming from the N'FILE?
Don't use the mapped drive use the UNC path instead, something like \servername\filepath.
For the Job to access network folders I think you need to set up a proxy with a domain account credentials and that is configured to run jobs of type SQL Server Integration Services Packages.
Look at the error message. It clearly states that the problem is that a package was not found on the path where the program searches for it. As a result, the error occurs and you see the error message. You should look at the location and see whether it exists, the user you are logged in with has the necessary rights for it and the package exists where it is searched for. If not, then according to your needs, change the necessary privileges or copy the missing package.
The job runs on the server, and I assume when you set up the job you didn't do it on the server, you did it on a remote client?
If you did set it up on the server, then most likely N is a mapped drive, which the SQL Agent service account is not aware of. So use a UNC path instead.
The SQL Agent service account (or proxy) also needs access to this UNC path
I have a SSIS package which creates a folder in an UNC share and then creates a file there (using script task).
The domain account which is used by SSIS and Agent has all the possible permissions in the DB computer and the share computer.
It always fails there.
I created a test SQL Agent job which creates a backup of the database in the same location and it fails too (Operating system error 5 - access denied).
EDIT: The above test example may be irrelevant since the backup operation is executed by SQL Server Database Engine and not the SQL Agent itself (Agent still schedules the task).
I cannot debug the script task in SSIS and therefore Im not sure what is the problem.
I have managed to fix this problem. The first problem was lack of sufficient task activation/execution permissions in the DCOM config node in Component Services. The permissions had to be set for SQL Server Integration Services.
The second problem was the fact that the UNC path looked like this:
\\192.168.250.51\C$\Folder\
I needed to create another share (visible) like that:
\\COMPUTER-NAME\Folder\
Also don't try to map any drives to the folders. It won't work.