Running a Cmd.exe inside an ETL Process Task and it's failing with Exit code 1.
If I run the command as the same user I'm running the SQL Agent job as outside of the ETL it's running fine and giving Exit code 0.
I've seen some DCOM errors in Event Viewer and Ive taken steps to give permissions to the user I'm running the ETL through the SQL Agent Job for. However it's still failing.
Are there other things I should check about running a CMD command across servers as a specific user?
Just to say this was a permission issue ultimately for it to write a file inside the Default folder. It wasn't manifesting as such until I dumped out the Log a little more. I had to make the user I was running the agent job to be a part of the Administrators group on the SSIS server to allow the process to work.
Related
I have an SSIS package that runs a backup in a T-SQL task and then uploads the file to google drive from an execute process task. The package runs perfectly from the catalog. When I try to run it from sql-agent job, the backup runs ok but the upload to google drive does not. There are no error messages in the job history or in the package history.
The sql agent job is set to run from a proxy account with the necessary credentials.
The issue turned out to be that the command file was trying to find another file it needed to run execute the code, but since the windows user changed it was looking in a different users folder. We solved it by passing the filepath as a param so it doesn't default to the user accounts folder its executed from.
I have written a small Rust script for an import job. I added the script execution into the SSIS package through the Execute process task and set the correct working directory. Using the debugger, the script works without a problem, as it does when executed normally, e.g. through cmd or PowerShell.
When I start the job in SSMS as an Agent Job, the package fails with
The process exit code was "-1073741515" while the expected was "0".
What I tried
Replacing the script with a very basic Rust script that just writes one single line to a file in the working directory to exclude the possibility that the script somehow panics, but still nothing.
The script is compiled with the i686-pc-windows-msvc toolchain. With 64bit the script does not work at all on the server.
Permissions look okay for the executing and the working directory. Full control for both folders.
Since execution works on the server I think this should most likely be a permissions issue but I can't for the life of me not figure out what is wrong.
Okay the problem was indeed with the default SQL Server Service Agent-account that ran the job. If I run the job with a Proxy-account it runs fine.
I'll have to look into the configuration of the Service Agent but until then, Proxy account it is.
I have a SSRS solution that contains 20 reports all of which utilise a shared data source called "DataWarehouse". This datasource has been configured to use Windows Authentication. These reports have been deployed to a server.
I have a requirement where I need to be able to automatically run these reports once a data warehouse has completed loading overnight. Sometimes the warehouse load might take 5 hrs, sometimes it might take 10 and so I don't want schedule these reports at a particular time using reporting services, I want the warehouse load to determine when its done and trigger the reports.
Now, I have a mechanism to do this:
I have written a c# console application that accepts a report name and a file path which runs the report and saves it do wherever it needs to.
I have an SSIS package that executes the console application from (i). I use an SSIS package because the DBA where I work will not enable xp_cmdshell.
I have an agent job that runs the SSIS package when the warehouse load completes.
Now if I run the SSIS package on my local machine (as me) the package executes successfully and the report is generated and saved. When I deploy the SSIS package to the server and try and run it through the agent job it fails with the following error:
System.Web.Services.Protocols.SoapException: The permissions granted to user 'NT SERVICE\SQLSERVERAGENT' are insufficient for performing this operation. ---> Microsoft.ReportingServices.Diagnostics.Utilities.AccessDeniedException: The permissions granted to user 'NT SERVICE\SQLSERVERAGENT' are insufficient for performing this operation.
at Microsoft.ReportingServices.Library.ReportExecution2005Impl.LoadReport (String Report, String HistoryID, ExecutionInfo2& executionInfo)
at Microsoft.ReportingServices.WebServer.ReportExecutionService.LoadReport (String Report, String HistoryID, ExecutionInfo& executionInfo)
My initial guess was that this means the SSIS job gets executed as 'NT SERVICE\SQLSERVERAGENT' and this user does not have access to run reports on the report server. So I jumped on to the report server and tried adding NT SERVICE\SQLSERVERAGENT as a user who could run reports but I was still getting errors. Can anybody help me figure how I can get this working?
Thanks
This will help you execute the SSIS package in the command prompt, and you can run the package on the server in scheduled tasks from the batch file (you may need special permissions to run a batch file in scheduled tasks). What you will want to do is create a windows batch file to allow you to automatically run the SSIS package via Command Prompt and you will need to use Dtexec. Here is what your batch file will look like:
#ECHO OFF
Some comment about what the package is doing
Dtexec /f "C:\some\file\path\YourPackage.dtsx
Then once you save the notepad as a windows batch file you will be able to open the batch file and it will run your package in the Command Prompt. I hope this helps
I edited the console application to connect to the SSRS server as a specific user. I've added what I did below incase its useful to somebody else.
To do this I created a file called account.config which just contained the username on the first line and password on the secondline:
MyUser
MyPassword
Then in my console application I have the following code:
// Read in the config file and add the lines to a list
List<string> accountDetails = File.ReadAllLines(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "account.config")).ToList();
ReportExecutionService myReportExecutionService = new ReportExecutionService();
// Add the credentials
// accountDetails[0] is the username, accountDetails[1] is the password
myReportExecutionService.Credentials = new NetworkCredential(accountDetails[0], accountDetails[1]);
I have three SSIS packages to sync data from SharePoint to SQL Server, I have put them in task schedule to run daily, but one or two of them failure sometimes.
The error message from task schedule is
action "C:\Program Files\Microsoft SQL Server\110\DTS\Binn\DTExec.exe" with return code 2147942401"
And my task is running using a service account:
"C:\Program Files\Microsoft SQL Server\110\DTS\Binn\DTExec.exe" /F E:\SSIS\Package.dtsx /Conf E:\SSIS\config.dtsConfig
If I uncheck the Run whether user logged on or not, then all goes fine.
It seems the package can't connect to the SQL Server that I config in config.dstConfig when failure. The failure also cause my db account been lock out.
But why only one or two package failure, not all?
And why everything goes fine if I run manually?
Any help is appreciated.
After much work, I found out the schedule task fail because the SSIS package validation failed before run. It's not a permission issue. But still no idea why only fail in task scheduler.
You can do this workaround, it think it will solve your issue:
Instead of putting the full file path in the program/script textbox, use the Start in (Optional) field to put the folder that the dtExec file is actually in - Like so:
Check 'Run with highest privileges' Checkbox.
References
https://blogfodder.co.uk/posts/win-2008-task-scheduler-with-return-code-1-0x1/
I have a vb script which moves files from one server to another and it works successfully when run manually but when a job is created in SQL Agent to automate the process it doesn't perform the task. SQL Agent doesn't fail it simply does not perform the move.
I granted local admin rights to the account performing the task and still nothing. I copied the files manually to the local SQL Server but I still get the same outcome when attempting to run the job in SQL Agent.
I also tried using FQDN but it still doesn't perform the process. Any suggestions? Please help and thanks in advance.
if you have 32 bit try:
C:\Windows\system32\config\systemprofile\Desktop
For the package to work. If you do not have Destop folder, create one and it should work.
Try to check: C:\Windows\SysWOW64\config\systemprofile\Desktop folder for the package to work.