The error codes for Task Scheduler are listed as hexadecimal at msdn, and your code 2147942401 converts to hex as 0x80070001 (which is not listed there), but this superuser describes it as an "Illegal Function". He fixed his problem by using "the simplest task scheduler settings and now it works". I note that he only runs his task when the user is logged in, so he doesn't need "Log on as a batch job".
If you want to run the batch job when you're not logged in, you need a special privilege called "Log on as a batch job". Note that there is also a "DENY log on as a batch job" privilege, which you wouldn't want.
Your task calls a network resource. These powershell scripters recommend bringing those resources to your local machine to eliminate any chance of network/connectivity/permissions issues ... but that may not always be appropriate or practical.
This error code can also result from a bug/mistake in the actual Powershell script or Batch (.bat) file, even if all task scheduler settings, permissions, etc. are correct; in my case I was referencing a directory that doesn't exist.
Throwing another common cause of the error action "powershell.exe" with return code 2147942401 here. If your action arguments are not correct you will also get this error message.Check that the action argument parameters and parameter values are spaced correctly.
For me, the task would sometimes work and sometimes wouldn't. According to the Scheduled Task History, when failing, it would appear as if it's been running for about 40 seconds, doing nothing, and completing action "C:\windows\SYSTEM32\cmd.exe" with return code 2147942401.
In this case, there was no point messing with the Group Policy settings because sometimes it would work. But not everytime. Which means it's a timing problem, not a Policy problem.
I did also consider butchering my batch file and getting rid of the standard output redirection, thus abandonning the logging capability (and becoming blind). Or simply running an actual "*.exe" process, instead of using a batch file at all. This could potentially have been a solution.
Ultimately, I remembered that services can be delayed: "Automatic" vs. "Automatic (Delayed Start)". So I imitated this by added a delay on the scheduled task, in the Tasks Scheduler. For "At startup" scheduled tasks, it's the trigger that have individual properties of its own, and that's where the delay can be configured:
I believe my scheduled task was sometimes being started a few milliseconds too early and some OS service or functionality was not yet available or allowed. Simply adding a small delay on the trigger fixed the problem.
I had the same error from Task Scheduler but it happened to me when my ps script had incorrect digital signature.I was using ExecutionPolicy with 'AllSigned' and my ps script was digitally signed but meantime I changed something inside the script and the script has to be signed again after such action.
How can I turn off this notification? I understand that Windows 10 Version 21H2 or higher needs to be installed. However, I have zero intention of updating my Windows OS at this point in time.
Could you please allow this status to be disabled in the "Application Status" under Advance setup.
Thank you.
Hello,
Thanks for your reply.
But there are millions of users who are still on Windows 10. And some of use may not be on 21H2.
I also understand that ESET won't be able to update to newer versions after Dec 2023 and the notification cannot be disabled in home products at the moment.
Could you please release an update where the users can at least hide the notification? It is annoying at the moment.
Thank you.
In home products it won't be possible. With Microsoft ending support for Windows 10 21H1 and older, you won't receive any security updates which will make your Windows more vulnerable as time goes. It is crucial to keep the operating system as well as applications up to date all the time.
Yes, I understand with all the ending support. But each users are on a different timeline. I also understand the users won't be receiving any security updates. But the is the user's choice.
But you need to provide the users to suppress the notification. Suppressing the notification has nothing to do with security update. When the user suppress the notification, he/she is doing intentionally knowing the consequence.
Hence, please allow this option. Thank you.
If currently the users are able to suppress the notification the notification for Windows Update, ESET developers can definitely allow the users to suppress the notification the notification for "Missing Support for Azure Code Signing"
Not everyone/organisation is on the same timeline as Microsoft proposes. We have number of PCs that are running earlier builds of Windows 10 LTSC. Even though, each client is managed individually and locally. Hence, we are not using Endpoint version of ESET. We have company wide policy to disabled Windows Update for various/several reasons (specific production workflows and custom applications).
You are going to provide Endpoint users the option to suppress the notification. Hence, I humbly request ESET developers to provide users the option to suppress the notification for your regular version of ESET.
Thank you.
@Peter Randziak @Marcos
We are not "Home" Users. Isn't it oxymoronic? On your very website for business users, you also recommending "Home" products for business users who wants to lets users manages their endpoints/client PCs individually. The word "administrator" has a broad term for different organisation.
Even for small business who are letting users manages their endpoints individually, there is an IT administrator. Hence the lines are blurred.
It is administrator's and business owners choice when to upgrade their Apps and OS. There are various mission critical factors. We are not on the same timeline as everyone. I strongly believe there tons of business who are in the same position.
Those who disable it, knows fully the consequence. Please and simply allow disabling of status - Missing Support for Azure Code Signing. It is not rocket science.
Thank you!
The /INTEGRITYCHECK linker option provides Windows kernel digital signature verification for user mode Portable Executables (PE) files. This linker option is required for anti-malware and anti-cheat scenarios to register components with the Windows Security Center.
No one is forcing anyone to upgrade their Win OS version. That said, it is imperative to apply the appropriate KB update depending on Win version. If you don't, you will find Microsoft Defender real-time protection running side-by-side with Eset's.
The effect of not installing the KB adding ACS support will be that after Dec 2023 ESET will not be able to update to newer versions and users won't be able to install our products again unless ACS support is added to the OS.
Just give the users the choice to disable the status. You can also prompt a explicit dialogue box letting users of the consequence.
Since it would be after Dec 2023, you should release an update to the app to let suppress the notification.
Thank you.
Please. Please. Please allow users to freeze updates of modules, but not the anti-virus signatures during general updates. I am like many others who have chosen not to update to later versions of Windows 10 as I have taken a very long and extensive effort to get what software I use to work correctly with the earlier Windows 10 version I use, hence I have not nor want to continuously update. When version 16.2.13.0 of EIS updated over my working verson 16.0.26.0 of EIS, I received the message about Azure support, but also the firewall was disabled as a result of the product version update. There seemed to be no way around this. I could not restart the firewall. So the result was even less security.
We don't force you to update Windows, it's your decision when you will do so even that keeping the OS up to date is crucial for maintaining the system protected against newly emerging exploits. In order for your ESET program to update after Dec 2023, it is enough to install just ACS support as per -gb/topic/kb5022661-windows-support-for-the-azure-code-signing-program-4b505a31-fa1e-4ea6-85dd-6630229e8ef4. That said, you don't have to update whole Windows to a newer version to get ACS support.