How to succesfully run a batch file in an SQL Agent job? - sql-server-2008

Dear Stackoverflow users,
I have a SQL Agent Job which generates a specific report in PDF-file and then copies the PDF to a network directory and then deletes the PDF file in the source directory.
The SQL Jobs consists of 2 steps:
1. Generate the report
2. Copy the report to the network location.
For step 2 I made a bat-file which handles the copying and removal of the pdf file.
The bat-file is as follows:
set source_dir=C:\Reports\Energie\Uur
set dest_dir=\\KWS2-WEB-SERVER\Share\Reports\Uur
C:\Windows\System32\Robocopy.exe %source_dir% %dest_dir% /MOV /Z
However, when I run my the Job, it hangs on the second step. The status just stays on "Executing".
This is the line which I stated in the step (location of the bat-file to execute):
cmd.exe /c "C:\Reports\rapport_uur_copy.bat"
My job-settings are as follows:
Step 1
Type: Operating system (CmdExec)
On Success: Go to the next step
On Failure: Quit the job reporting failure
Step 2
Type: Operating system (CmdExec)
On Success: Quit the job reporting success
On Failure: Quit the job reporting failure
Some facts:
I have read/write permissions on the network directory
I run the steps as the Administrator-account (the logged in user, default)
Step 1 succeeds
I run Windows Server 2008 R2 Standard
I have SQL Server 2008 R2
When I run the script from the cmd manually, it works (under Administrator account).
Thanks in advance!

when a batch script needs to use drives not local, eg shares it always needs special rights, means you need to use an account to run the script which is allowed to log on as batch task in secpol - (click start type secpol.msc and start it - Select "Local Policies" in MSC snap in - Select "User Rights Assignment" - Right click on "Log on as batch job" and select Properties - Click "Add User or Group", and include the relevant user.)
too in normal batch it is not possible to use \\drives, they have to get mapped as drives with a char e.g. V:\drive and this mapping got to be made by the batch itself with the user account used running the batch i experienced this in a script of mine.

Related

Scheduled MS Access macro to run query and export to CSV

I'm trying to get a windows Scheduled Task to open up MS Access DB (.mdb) which has an AutoExec macro that runs some queries and then exports it to a .csv replacing the .csv file that is already there.
From the command prompt I can run:
"C:\Program Files (x86)\Microsoft Office\root\Office16\MSACCESS.EXE" "/Path to my Access DB"
and everything works perfectly. Access opens up, runs the query, and replaces the .csv with new data from the query.
When I try to do this with a Scheduled Task access just deletes the .csv file without ever replacing it and returns the error "the operator or administrator has refused the request".
Any ideas? I was looking for a quick way to get the data but I feel like I might be better off just writing some python to connect to Access.
I was able to return to this problem this week and finally found the solution.
The problem came down to the scheduled task. It was a local machine permissions issue and running the task with the correct domain that solved it.
First to fix the local machine permission I had to make sure that the user running the task had "Log on as a batch job" permissions.
Found at Control Panel -> Admin Tools -> Local Security Policy\Local Policies\User Rights Assignments -> "Log on as a batch job"
Second, because I was on a domain the schedule task had to be explicitly created by the domain user. I had to manually find the user on the domain during the creation of the task and remove the user that was auto populated by the task scheduled creation wizard.

SSIS breaks when attempting to execute psftp.exe gives result 1

I have psftp.exe installed on my server, and am using it to obtain files via sftp to be ingested into my sql server. I am using psftp.exe from the putty site to obtain it:
GET ZIP FILES:Error: In Executing "C:\Program Files\PuTTY\psftp.exe"
"XXXXXX#sftp1.XXXX.com -pw XXXXX -be -batch -b "D:\Code\XXXXX\XXXXXX.bat"" at
"D:\Data\ZIPFOLDER", The process exit code was "1" while the expected was "0".
The this works while in SSDT with no problems...however, when called by SQLSERVERAGENT on SQL SERVER, it fails.
to attempt to repair the issue, I have given NT SERVER\SQLSERVERAGENT full permissions on C:\Program Files\Putty\ and my Data drive D: where all of my code and data storage rests.
My problem is that while I think exit code 1 means a SFTP error (is it?) how do I troubleshoot?
Thanks.
UPDATE #1
as per instructions given by sandeep rawat, I added a windows user with administrative privileges and full control over the code and data sections of the server.
In addition, I created credentials associated with this use, and assigned a proxy user to those credentials.
Lastly, I reset the runas section in SQL SERVER AGENT's primary job to that proxy user.
Plus the setting in Internet Options.
I am still getting the same response.
THanks.
This type of issue generally happens when sql AGENT try to launch the DOS window which is the reason for the package to hang. and fails.
1 Change Window style property to hidden in process tab
2 Give the cmdExec permission to your SQL Agent account.
https://www.mssqltips.com/sqlservertip/2163/running-a-ssis-package-from-sql-server-agent-using-a-proxy-account/
3 Add the local drive to your trusted Intranet Sites by opening Internet Explorer and go to Internet Options > Security > Click Local Intranet > Sites and add your drive location as shown below

Flat File Source Failing When Deployed and Executed

I am trying to create a simple SSIS package that can be deployed to a VM on another domain (same computer) that has SSIS on it. The package that I have created will transfer data if I simply run the data flow from SSDT on the source computer, but when I try to deploy and execute it, it appears to have 2 errors. The first being that it cannot open the datafile "C:\SSIS\Product Data.txt". The second being that the Flat Files Source 1 failed the pre-execute phase. I think that the second error is caused from the first. Does anyone know how to create a package that can transfer data to another computer without the flat file source?
Thanks in advance!
C:\SSIS.... will refer to the local C drive of the computer that is executing the package. So if you have it on the VM it would be at the \VM\C$. Typically it means 1 of 2 things.
1) The file path is not correct and you are not referencing where the file actually is.
2) the user you are executing the package as does not have permission to that file.
So where is the file is it on the C drive of the machine you are executing the SSIS package on? The answer to that wasn't clear in your question.
Second how is the file being executed? manual execution such as DTS_Exec? SQL Agent? T-SQL? If manual then the user logged in executing the task must have permission, if SQL Agent then the sql agent service account and possible the sql server service account have to have permission to the file, and T-sql sql server service account needs to have permission.
When it is local file path then a local user or domain user will work for the service accounts. If network path then the local user used for service account won't work and you will need to setup a way to run as a different credential.

Running an SSIS Package as a SQL Server Agent Job doesn't copy files?

I have an SSIS package I can import into Integration Services on my server and run with no problems. All it does is copy files from a directory on the network to the server it is running on.
When I execute the SQL Agent Job it says the job ran successfully but no files are copied. I verify there are files in the source location and the destination path exists. I am also using absolute paths (no mapped drives).
Why doesn't it copy any files when I run it as a SQL Agent Job?
FYI - the source directory is actually on a UNIX box and to map a drive to that location you have to enter a user/password combination.
I have a feeling that the SQL Agent Job runs as NT SERVICE\SQLSERVERAGENT, which is not the user that has permission to the UNIX box. Is there a way to run the SQL job as a specific user?
Thanks in advance.
You need to create a Credential, a SQL Agent Proxy, and then assign the proxy account to the SQL Agent job step. Proxy accounts are specific to each subsystem (e.g Powershell, CmdExec, SSIS, etc.)
-- creating credential
USE [master]
GO
CREATE CREDENTIAL [Superuser] WITH IDENTITY = N'DOMAIN\account', SECRET = N'mypassword'
GO
-- creating proxy for CmdExec subsystem, adding principal
USE [msdb]
GO
EXEC msdb.dbo.sp_add_proxy #proxy_name=N'My custom proxy',#credential_name=N'Superuser',
#enabled=1
GO
EXEC msdb.dbo.sp_grant_proxy_to_subsystem #proxy_name=N'My custom proxy', #subsystem_id=3
GO
EXEC msdb.dbo.sp_grant_login_to_proxy #proxy_name=N'My custom proxy', #fixed_server_role=N'sysadmin'
GO
-- assigning job step to run as a given proxy user
USE [msdb]
GO
EXEC msdb.dbo.sp_update_jobstep #job_id=N'0df2dac2-4754-46cd-b0bf-05ef65e1f87e', #step_id=1 , #subsystem=N'CmdExec',
#proxy_name=N'My custom proxy'
GO

Analysis Services Processing Task Fails When Run By SQL Server Agent

I have an SSIS package which contains an Analysis Services Processing Task.
This package is kicked off by a SQL Server Job in SQL Server 2008 R2.
If I run this job myself or process the cube manually everything is fine.
However if I schedule the job and let the SQL server agent run it then the Analysis Services Processing task fails stating Errors in the OLAP storage engine and that an error occurred while processing the one of the measure groups.
Has anyone else every seen anything like this?
The SQL Server Agent service account may not have sufficient permissions. You can validate this by doing any of the following:
Add the service account to the Administrators group on the analysis services server to validate this issue. Let the job run as scheduled.
Create a proxy that runs under your credentials and set the job to execute under the proxy. Let the job run as scheduled.
Change the SQL Server Agent to use your credentials. Let the job run as scheduled.
If the job completes successfully after making any of the above changes, then you have a permission issue that you need to resolve.
So after months of looking at this I finally realised the answer; of course it's a simple one.
The SSIS job I had created was processing the Cube only, while every time I processed manually in management studio I was processing the whole SSAS database.
I've now changed the SSIS package to process the whole database and everything seems to be working correctly.
when This Error Generate :
reporting services catalog database file existence failed sql server 2008 r2
================================================================================
This issue occurs because the databases for the SQL Server 2008 Reporting Services instance that you want to install already exist on the computer with following path.
C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA
Manually Remove .MDF and .LDF files of Report from above path and Re-run Setup.
In my case I found the solution in other way. First of all I login into analysus services using SQL management studio.Second of all I searched into databases folder the name of my project, after I open that and double clic in Roles folder, clic in new role, in this window I selected Membership in the left pane, clic in add button and search the NT AUTHORITY\Service, clic in Ok button and finally restart Sql analysis services. I tried to run my job and It works.