Windows 10: Why does my created task RUN when manually called for but when automated it says, "request...

I have created a task on my Windows 10 PC which is up to date as of 11/24/2021It's for running FreeFileSync every 30 minutes. It will run successfully when run from FreeFileSync and also when RUN manually from Task Scheduler but does not run when the next time the task scheduler calls for automated, and and at that time reports . . .[operator or administrator has refused the request 0x800710E0]I am signed in always as administrator and I didn't refuse the request.Is there any help here I would be appreciative for sure!jep

:)

 

Window's Task Scheduler Not Running

Hi,

To assist you better, kindly provide us more details by answering the following questions:

• Have you tried recreating the task? If so, are you getting the same issue?
• Have you tried creating a new task?

Meanwhile, we suggest that you ensure that the Task Scheduler is running. You can verify if the service is running by following these steps:

• Press Windows key + R on your keyboard.
• Type services.msc and hit Enter.
• Under Services (Local), make sure that the Task Scheduler service's status is
  Started or Enabled.

Should you need further assistance, feel free to get back to us.

 

App Runs Properly but Win10Pro Task Scheduler Cannot Run It

We have a requirement for extremely accurate computer clock time and use a small app that that, when launched, checks with a pool of time servers and syncs our computer clock. We want to schedule this app to run every couple of hours.

The app runs properly when I launch it manually. I created a task in Task Scheduler to do this automatically every two hours and, when I manually run the task within Task Scheduler, it also runs properly. However, it will not run on on its own on a schedule.
Task Scheduler fails to launch it.

On a different computer, another app is able to launch it when that app is launched but, again, Task Scheduler fails to launch it on a schedule.

The task is configured in Task Scheduler as follows:

GENERAL

• When running the task, use the following user account: it's my own account, and I am an Administrator on the computer
• Run only when user is logged on
• Run with highest privileges
• Configure for Windows 10

TRIGGERS

• Trigger: At task creation/modification
• Repeat every 2 hours for a duration of indefinitely
• Enabled

ACTIONS

• Start a program "path...\SysTimeUpdate.exe" min ('min' being an argument)

CONDITIONS

• none - no conditions

SETTINGS

• Allow task to be run on demand
• Run task as soon as possible after a schedules start is missed
• Stop the task if it runs longer than 1 hour
• If the running task does not end when requested, force it to stop
• If the task is already running, then the following rule applies - Stop the existing instance

Someone suggested that my Administrator account may not have full privileges, and it may be a permissions issue but, if so, why can I launch it manually and why can another app launch it when that app is launched but Task Scheduler cannot? This very very
baffling, and any assistance would be very much appreciated. Thank you.

 

Scheduled tasks run with elevated privileges can't access stored Windows credentials

It seems that after Creators update scheduled tasks run with elevated privileges ('run with highest privileges' option) can't access stored Windows credentials. Is that a bug or an intentional change and is there a recommended workaround?

Here's one way to reproduce the behaviour:

• Start Credential Manger and add some Windows share credentials.
• In a console window type 'cmdkey /list', which should list the added credentials
• Create a task in a task manager:
  • Trigger: on user logon
  • Action: run cmd.exe
  • Tick the 'run with highest privileges' option
• Reboot the machine and log in
• In the console window (let's call it 'console 1') opened from the scheduled task type 'cmdkey /list'. This most likely won't display the credentials added in step 1 and properly listed in step 2. ->
  This looks like a bug
• Now, without closing 'console 1' open another console window as an administrator (let's call it 'console 2') and type 'cmdkey /list'. This will properly list credentials added in step 1.
• Switch to 'console 1' and type 'cmdkey /list' again. This time the credentials are listed properly, unlike in step 5. It looks like an access to Windows credentials was somehow 'unlocked' by step 6.