Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, March 27, 2018 11:29 AM | 1 vote
Hello everyone,
I'm having a strange problem with the Windows 10 task scheduler. Following setup:
- Windows 10 pro workstation (fully updated) in a Windows 2012 domain environment
- domain administrator is logged in 24/7
If I first create a task which should run interactively under the domain administrators account everything is fine. As soon as I change eg. the trigger of the task, the task won't run the next time it should. I only get a 332 event from the task scheduler which states the task could not be executed because the user [LocalPcName]/Administrator was not logged in. While this is technically correct (I'm logged in as [Domain]/Administrator) the task should not be executed under the local administrators account in the first place.
If I edit the task and explicitly set the account to [Domain]/Administrator and then save everything is OK again.
So: Whenever I save a scheduled task (after the initial creation) without explicitly stating [Domain]/Administrator as the user account, the user account gets changed to the local administrator. I also see this, when I export the tasks before and after saving a trigger change: The User-IDs in the XML-file are different and they match the local and domain administrators respectively.
I already saw this question (https://social.technet.microsoft.com/Forums/windows/en-US/00159bd3-a496-440b-8a75-23c23c1d9c10/) and I am pretty sure the suggested workaround would work, but for me there is no way to rename the administrator accounts.
So: Am I doing something wrong or is this really a bug in the task scheduler UI?
Thanks in advance!
All replies (4)
Wednesday, March 28, 2018 1:58 AM
>>but for me there is no way to rename the administrator accounts.
If you are not an system admin, my solution still cannot be used, after all, edit group policy needs admin permission.
Computer Configuration--> Windows Settings --> Security Settings --> Local Policies --> User Rights Assignment --> Log on as a batch job
Disable this GPO, force gpupdate.
Besides, I find out a similar case, there is also a good workaround.
Regards
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Tuesday, April 3, 2018 9:07 AM
We have not heard from you in a couple of days. Please post back at your convenience if we can assist further.
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Tuesday, April 3, 2018 12:56 PM
First: Thanks for your reply and sorry for my late reply.
The problem with renaming the accounts (as suggested in my link) is not that I am not a system admin but I think that it is a bad idea to rename the local administrator-account or the [Domainname]\Administrator-Account.
So regarding your first idea (grant the permission to log on as batch job): This permission is already granted to the local "Administrators"-Group which every involved user-account is a member of. So this does not help me.
Regarding the workaround: Sure, this works (and this is how we currently handle this). But this really can only be a workaround, because it involves extra steps which have to be remembered. And I am not the only one changing this task.
So: There currently is no way to *really* solve this issue? Are there any plans to fix this in future versions?
Thanks in advance!
Tuesday, July 9, 2019 7:18 AM
Now the whole world knows the name of your root domain administrator's account.
Only a handful of people know ours.