Windows 10: Issue faced when PowerShell script executed through SQL Server Agent Job

Verma Rachna · May 4, 2020

I have a PowerShell script that searches for an excel file at a particular location, if found copies it as a CSV file to another location.

This CSV is used as a source in ADF - Copy Activity.

This script is not interacting with any database, nor performing any db tasks - just reading an excel and converting it to CSV at particular location.

It is working fine as intended, when executed through PowerShell ISE, but when I scheduled it as a SQL server agent job it is not doing anything. The job successfully as per the message in Job History, but it does not do anything. The message says :

=====================================================================================

Message

The job succeeded. The Job was invoked by User PMCI\VermaRachna. The last step to run was step 1 Load_Radiotherapy_Machine_Utilization_File_Org_Src.

Message

Executed as user: PMCI\SVC_DASH_SQLDevAGT. The step did not generate any output. Process Exit Code 0. The step succeeded.

=====================================================================================

I have scheduled the Job with type as "Powershell" and the script code is pasted in Command area of the Job Step.

Since I am not getting any error message how do I know what is the issue due to which script is not doing anything when run through SQL Server agent job. Can some one help with this please. I can share the script code if required.

:)

Sherry Scheffe · May 4, 2020

SSIS with Oracle connection doen't work in SQL job agent

I use Oracle connection in SSIS. There are two ways to access Oracle data in SSIS package, one is MSORA Connector (Microsoft Connector for Oracle by Attunity), another is ODBC connection.

I can use both ways when execute in visual studio. But it can’t be done in SQL server as step
in job agent.

Do you know what's the matter cause this issue? Thanks!

Brink · May 4, 2020

SQL Server Guidance against speculative execution vulnerabilities

SQL Server Guidance to protect against speculative execution side-channel vulnerabilities

Summary

Microsoft is aware of a new publicly disclosed class of vulnerabilities referred to as “speculative execution side-channel attacks” that affect many modern processors and operating systems including Intel, AMD, and ARM. Note: this issue will affect other systems such as Android, Chrome, iOS, MacOS, so we advise customers to seek out guidance from those vendors.

Microsoft has released several updates to help mitigate these vulnerabilities. We have also taken action to secure our cloud services. See the following sections for more details.

Microsoft has not received any information to indicate that these vulnerabilities have been used to attack customers at this time. Microsoft continues working closely with industry partners including chip makers, hardware OEMs, and app vendors to protect customers. To get all available protections, hardware/firmware and software updates are required. This includes microcode from device OEMs and in some cases updates to AV software as well.

More information about the vulnerabilities can be found here: Microsoft Security Advisory ADV180002.

Supported SQL Server versions impacted

The following versions are impacted when running on x86 and x64 processor systems: SQL Server 2008, SQL Server 2008R2, SQL Server 2012, SQL Server 2014, SQL Server 2016, SQL Server 2017. IA64 (SQL Server 2008) is not believed to be impacted.

Recommendations

The following table outlines what customers should do, depending on the environment SQL Server is running in and what functionality is being used. Microsoft recommends customers deploy fixes using normal procedures to validate new binaries before deploying to production environments.

[table][tr][td]Scenario Number[/td] [td]Scenario Description[/td] [td]Priority Recommendation(s)[/td] [/tr] [tr][td]1[/td] [td]SQL Server is run on bare metal (no virtual machines) AND no other untrusted application logic (application tier) is run on the same machine AND no untrusted SQL Server extensibility interfaces are being used (see below for list)[/td] [td]No immediate need to patch. Please deploy updated OS and SQL patches after normal pre-production validation testing. Do not enable the registry settings in Windows to enable the microcode changes.[/td] [/tr] [tr][td]2[/td] [td]SQL Server is run in a virtual machine in a public hosting environment[/td] [td]For Azure: No VM image update necessary (see KB 4073235 for details). For other public hosts: refer to their guidance.[/td] [/tr] [tr][td]3[/td] [td]SQL Server is run in a virtual machine in a private hosting environment[/td] [td]Apply patch to Host OS or isolate SQL Server on dedicated physical hardware. Please refer to Windows OS guidance on whether microcode changes should be enabled.[/td] [/tr] [tr][td]4[/td] [td]SQL Server is run in a physical or virtual machine and is not isolated from other application logic running on the same machine or is using extensibility interfaces in SQL Server with untrusted code[/td] [td]

Apply OS patches as described in Scenario 3

Apply SQL Server patches, when available

If running with untrusted code on the same machine, please enable the microcode changes as described in the Windows OS guidance.

OR

Restrict use of extensibility interfaces to block untrusted code from executing on the machine (see below)

[/td] [/tr] [tr][td]5[/td] [td]Customers running SQL Server 2017 on Linux OSes (independent of whether extensibility interfaces are being used)[/td] [td]

Apply Linux OS patches

Apply Linux SQL Server patches

Consult with your Linux OS vendor about whether and how to enable the firmware changes

[/td] [/tr] [/table]

Performance Advisory:

Microsoft continues to do performance evaluation on the patched binaries. However, at the time of publication, Microsoft has not yet validated SQL Server performance with all microcode patches, nor has it validated performance in all Linux environments. Customers are advised to evaluate the performance of their specific application when applying patches. Please validate the performance impact of enabling microcode changes before deploying into a production environment. Microsoft will update this section with more information when it is available.

Available Builds:

At the time of publication, the following patched SQL Server builds are available for download:
Servicing Release

SQL Server 2017 CU3

SQL Server 2017 GDR

SQL Server 2016 SP1 CU7

SQL Server 2016 SP1 GDR

This document will be updated when additional patched builds are available.

For Windows OS Builds, please refer to the following guidance for the latest on available Windows builds:

Windows Guidance for Consumers

For Linux builds, please contact the Linux vendor to find the latest patched builds for your specific Linux distribution.

Untrusted SQL Server extensibility mechanisms

SQL CLR assemblies

R and Python packages running through the external scripts mechanism or run from the standalone R/Machine Learning studio on the same physical machine as SQL Server

SQL Agent extensibility points running on the same physical machine as SQL Server (ActiveX scripts)

Non-Microsoft OLE DB providers used in Linked Servers

Non-Microsoft Extended Stored Procedures

Mitigations to take if using untrusted code in SQL Server:

[table][tr][td]Scenario/Use Case[/td] [td]Mitigations/Suggested Steps[/td] [/tr] [tr][td]Running SQL Server with CLR enabled (sp_configure ‘clr enabled’, 1)[/td] [td]

If possible, disable CLR if it is not needed in your application to reduce the risk of any untrusted code being loaded into SQL Server

(SQL Server 2017+) If CLR is still needed in your application, enable only specific assemblies to be loaded using the “CLR Strict Security” feature (https://docs.microsoft.com/en-us/sql...trict-security) using sys.sp_add_trusted_assembly (https://docs.microsoft.com/en-us/sql...y-transact-sql)

Consider whether CLR code can be migrated to T-SQL equivalent code

Review security permissions to lock down scenarios where CLR-based operations can be used. Limit CREATE ASSEMBLY, EXTERNAL ACCESS ASSEMBLY, and UNSAFE ASSEMBLY permission to the minimum set of users/code paths to disallow loading new assemblies in an existing, deployed application

[/td] [/tr] [tr][td]Running R/Python external scripts from within SQL Server (sp_configure 'external scripts enabled', 1)[/td] [td]

If possible, disable the external scripts capability if not needed in your application to reduce attack surface area.

(SQL Server 2017+) If possible, migrate external scripts doing scoring to use the native scoring feature instead (https://docs.microsoft.com/en-us/sql...native-scoring)

Review security permissions to lock down scenarios where external scripts can be used. Limit EXECUTE ANY EXTERNAL SCRIPT permission to the minimum set of users/code paths to disallow arbitrary scripts from being executed

[/td] [/tr] [tr][td]Using Linked Servers (sp_addlinkedserver)[/td] [td]

Please review installed OLEDB providers and consider removing any untrusted OLEDB providers from the machine. (Please make sure that you do not remove OLEDB providers if they are used outside of SQL Server on the machine). An example on how to enumerate existing OLEDB providers is here: https://msdn.microsoft.com/en-us/lib...numerator.aspx

Please review and remove any unneeded linked servers from SQL Server (sp_dropserver) to reduce the possibility of any untrusted code being executed within the sqlservr.exe process

Review security permissions to lock down ALTER ANY LINKED SERVER permission to the minimum number of users.

Review Linked Server Login/Credential mappings (sp_addlinkedsvrlogin/sp_droplinkedsvrlogin) to limit who can execute operations over linked servers to the minimum set of users/scenarios.

[/td] [/tr] [tr][td]Using Extended Stored Procedures (sp_addextendedproc)[/td] [td]As Extended Stored Procedures are deprecated, please remove all uses of these and do not use them in production systems.[/td] [/tr] [/table]
Click to expand...

Source: https://support.microsoft.com/en-us/...for-sql-server

Gerard Qui · May 4, 2020

Sql server agent 2012

Hi,

Usually, SQL Server Agent 2012 might stop after an upgrade. This issue is better suited for the IT Pro audience on TechNet Networking forum. We recommend posting your concern on this
link for further assistance about SQL Server Agent 2012.

Feel free to post back if you have other concern.

Windows 10: Issue faced when PowerShell script executed through SQL Server Agent Job

Issue faced when PowerShell script executed through SQL Server Agent Job

Issue faced when PowerShell script executed through SQL Server Agent Job

Issue faced when PowerShell script executed through SQL Server Agent Job

Issue faced when PowerShell script executed through SQL Server Agent Job - Similar Threads - Issue faced PowerShell

SQL Server agent is not starting.

SQL Server agent is not starting.

Executable Powershell script that will assist me in removing the Microsoft Monitoring Agent...

Executable Powershell script that will assist me in removing the Microsoft Monitoring Agent...

I am facing issue with executing SSIS_ SQL agent jobs

I am facing issue with executing SSIS_ SQL agent jobs

Powershell Script .ps1 file Does Not Work When Executed Through Task Scheduler

Powershell Script .ps1 file Does Not Work When Executed Through Task Scheduler

Powershell 2 scripts Execution

Users found this page by searching for:

powershell executed successfully excel to csv but failed in sql server agent

run powershell in sql agen job