Group Policy schedule task not appearing on Windows 10 pro machine

Hi Guys,
I'm trying to create an scheduled task using a GPO.

user configuration
  control panel settings
   scheduled tasks
I'm selecting (scheduled task at least windows 7)

Now for test I'm just trying to open notepad (c:\windows\notepad.exe).

Then I go to the PC and run
gpupdate /force

Then I run
gpresult /R

And I get the new GPO in the list of applied policies.

But guess what?
Nothing happens when the time to execute the scheduled task comes.

How can I see if the task is being scheduled?
How can I see if the task is being executed?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

cargexAuthor Commented:
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.
cargexAuthor Commented:
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.
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

A little 101? What is not clear? is MS' 101.
cargexAuthor Commented:
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.
cargexAuthor Commented:
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:

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?

MS changed something: we can no longer save credentials to tasks because it would be insecure. This functionality was patched away. But: you would not need to deploy a task with dom-admin credentials anyway. Domadmins are for domain administration, they should not be used on the clients.

Use the system account instead, it has all privileges at the clients. Username is system.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
cargexAuthor Commented:
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  
 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.
cargexAuthor Commented:
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?
cargexAuthor Commented:
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?

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.
cargexAuthor Commented:
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!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.