Group Policy schedule task not appearing on Windows 10 pro machine

I found the following error in the client computer event viewer:

"Group Policy object did not apply because it failed with error code 0x80070005 Access is denied."

Setup the task in the computer config section instead and link the GPO to your test computer object's OU.

Hi McNife,
Just for the test i created both 1 in compures and 1 in users to see which one work.

I have found some comments regarding the security options and the user used to create the scheduled task. Can you please give me a little 101 on how to manage that?

So far im creating my GPOs with the domain admin user.

A little 101? What is not clear?
https://technet.microsoft.com/en-us/library/cc725745.aspx is MS' 101.

Possible pitfalls?

Please remember that my original question is regarding the following error:

 "Group Policy object did not apply because it failed with error code 0x80070005 Access is denied."

So there is something definitely wrong with the security options, but like you said it seems very straight forward, so I was hoping somebody has run into this issue before.

For instance, when I go to the PC and use the task scheduler the security options let me choose literally any user even a local admin to that machine, but using the GPO only domain users are available.

Also I'm using the domain Administrator to open the Group Policy Management and then I create the GPO, as a matter of fact that's who comes up as the "author" of the GPO.

Could this be what is causing the "Access Denied" error?

No possible pitfalls. I have no idea what account you configured for the task that you deployed to your user object. I only deploy tasks to computer objects.
Please describe what account you used as executing account for the task.

This is my GPO configuration:

computer configuration > preferences > control panel settings > scheduled tasks

Action: Update
Author: DOMAIN\Administrator

Security Options:
When running the task, use the following user account:
DOMAIN\pcadmin

Run whether user is logged on or not

There is a grayed out option here that says: "Do not store password"
I'm thinking this could be the culprit but it is grayed out.

pcadmin is a domain user that I have added to all computers Administrators local group.

That's it, what do you think?

How?
Should I login to the domain controller with the "pcadmin" user?

The option where is says "Author" is just there, it doesn't let me change it.
Unless I login to the Domain Controller as "pcadmin" and run the Group Policy Management.

Here is how it looks:

Name  Computers Test  
 Author  DOMAIN\Administrator  
 Description    
 Run only when user is logged on  InteractiveToken  
 UserId  DOMAIN\pcadmin  
 Run with highest privileges  LeastPrivilege  
 Hidden  No  
 Configure for  1.2  
 Enabled  Yes

The author does not matter. You may create the task as domain admin. But the account that should run the task should be system.

I think we are getting somewhere.
I have focus my tests on the account that runs the task.

So far this is what I have:
If when I create the GPO I select the test user in the test pc that is logged in right now it works.

But I can't do that, obviously each user is different so it will work for the test, but not for everybody else.

If I select the DOMAIN\pcadmin user that I want to use. This is a domain user that I have added to all the client computers "Administrators group", then it is back to the error in question.

Are my findings correct?

McKnife,
A related question.
I need to run a maintenance task that requires admin rights in the background at night, so I'm thinking well let's store the password of the Administrator user in the task and let it run whether the user is logged on or not.

From the stand point of security how bad is this?

If it is too bad, then what is the alternative?

Thanks.

Let me put some things straight:

tasks that run under different accounts run invisible. So you might think "hey it does not run", while task manager would show that notepad or whatever you start for a test does indeed run invisible in the background. So: tasks are not good for starting things interactively unless you want to run as logged on user.

Then: we cannot store passwords in tasks. As I told you before: this functionality has been patched away because it was incredibly insecure. For tasks that you use for maintenance, use the system account, it doesn't need a password.

Mr. McKnife,
Thank you very much, I've read your answers in other posts and I respect your comments very much.

For those of you reading this post with a similar issue, please read through all the comments as they contain a series of clarifications that help me make this work.

You are welcome!