Andrew Brehm

“I really don’t know what you mean only admins can create scheduled tasks.”

What are you talking about? I didn ‘t say that.

“Task Manager just doesn’t support the sharing of tasks.”

I wasn’t talking about Task Manager.

“Of course, if we are talking about scheduled tasks running on servers, end users have no business here.”

It applies to both clients and servers.

I don’t support clients so I don’t know how many people want to run scheduled tasks on clients.

But I know that a lot of (server) applications use scheduled tasks on servers, and our users have created and edited scheduled tasks for a long time. Of course scheduled tasks can be “shared” if you want to call it that. We usually grant access to a group to a specific task folder and hope for the best with ACL inheritance. But as I said, it often fails and then permissions have to be fixed manually. And THIS is the step that is rather difficult.

They cannot since Server 2016. The security descriptor is contained in a value that is in a registry key that is owned by SYSTEM.

Before Server 2016 a user could simply edit the ACL of his task in Explorer.

Since Server 2016 an administrator has to annex the key and write a new security descriptor into the value in the task’s key. If that new security descriptor contains, for example, a group with appropriate permissions, all members of that group can access the task.

Unfortunatelt inheritance doesn’t always work and hence those security descriptors have to be repaired now and them.

And this is not trivial, apparently. I only know how to do it with WMI and with the C API. I was hoping there was a known better way.

And I am wondering how other sysadmins deal with this issue. Does noone else have users that use scheduled tasks? Are all users admins? How is it best done?

Users can share them, it’s just non-intuitive how to set the permissions. Using WMI or my utility I can grant access to any user to any scheduled task. Unfortunately those permissions are not inherited from task folders to tasks.

Before Server 2016 this was easily configured as NTFS permissions, including inheritance. And users are still used to that. Users did not change when MSFT changed scheduled task permissions. (In fact before Server 2016 users could easily set scheduled task permissions themselves in Explorer.)

It’s not easy moving dozens of users to a different task scheduler. They are all used to Windows Scheduled Tasks. Some use other schedulers, manu use Windows Scheduled Tasks.

Apparently MSFT simply assume that everyone is an admin. But then why do scheduled tasks have security descriptors in the first place?

I am the only one who supports users who create scheduled tasks?

To explain this better, perhaps, I created a scheduled task as user “benoit” on my laptop (I am currently travelling).

Commands here shows show the task (which runs fine) and how Get-ScheduledTask does NOT display its security descriptor and what its security descriptor is.

PS C:Program FilesABTokenTools> Get-ScheduledTask TestTask

TaskPath TaskName State
——– ——– —–
TestTask Ready

PS C:Program FilesABTokenTools> Get-ScheduledTask TestTask|Format-List

Actions : {MSFT_TaskExecAction}
Author : MYLAPTOPbenoit
Date : 2023-05-11T20:23:55.3661171
Description :
Documentation :
Principal : MSFT_TaskPrincipal2
SecurityDescriptor :
Settings : MSFT_TaskSettings3
Source :
State : Ready
TaskName : TestTask
TaskPath :
Triggers :
URI : TestTask
Version :
PSComputerName :

PS C:Program FilesABTokenTools> .ScheduledTaskAclEdit.exe TestTask
O:S-1-5-21-1997462784-3649744622-1500452921-1014D:(A;ID;0x1f019f;;;BA)(A;ID;0x1f019f;;;SY)(A;ID;FA;;;S-1-5-21-1997462784-3649744622-1500452921-1014)(A;;FR;;;S-1-5-21-1997462784-3649744622-1500452921-1014)
PS C:Program FilesABTokenTools> .LookupAccountSid.exe S-1-5-21-1997462784-3649744622-1500452921-1014
benoit
PS C:Program FilesABTokenTools>

Since “benoit” created the task, “benoit” can see/edit/delete it. But another user, possibly supporting the same application, would not be able to see it. (The only other entries in the default security descriptor are SYSTEM and Administrators.)

Configuring an ACL on the folder does apparently not work as the new task does not (or often not) inherit the ACL (presumably because of how the security descript is stored in the registry).

While Get-ScheduledTask does display an (empty) security descriptor (although a non-empty one exists and is effective), Get-ScheduledTask does not appear to be able to set a security descriptor on a task.

NB: Setting permissions these way also required access to the registry key in question, which is owned by SYSTEM and has to be annexed first, then given back. I found no easy way to do this either, which I documented in an earlier thread. Regedit.exe can do it but PowerShell cannot.

The purpose of setting permissions on scheduled tasks is to allow users to see/edit/create/delete scheduled tasks.

We have users who want to run scheduled tasks.

Problem is, they cannot see tasks created by others users, as permissions of scheduled task folders are not inherited correctly.

They also cannot see tasks they created while they installed their application, because when they created them they were members of the Administrators group and now their tasks are owned by Administrators and they cannot see them.

Our users need to be able to edit scheduled tasks created by other users and by themselves while they were members of Administrators temporarily.

Solution is to fix the permissions whenever they cannot see/edit their tasks.

UAC is not a good solution for the problem of created tasks being owned by Administrators because users would likely create tasks from an elevated prompt anyway. (Or their application installer, running elevated, would do it.)

Personally, I don’t know why so many users want to run scheduled tasks and why so many applications use Windows scheduled tasks (instead of their own task schedulers, like UC4). But I am not the one who decides what the right tool is for the users’ requirements. I am just looking for the right tool to change scheduled task permissions so that users can see/edit/create/delete scheduled tasks.

So far I have found two ways: using Win32_SecurityDescriptorHelper and HKLM: and using my utility program quickly wrote to avoid having to use WMI.

(My utility program: https://github.com/ajbrehm/ABTokenTools/blob/master/ScheduledTaskAclEdit/ScheduledTaskAclEdit.c)

As I understand that is the account the scheduled task will run under. It has nothing to do with who can see/edit/delete the task.

The task will simply not be visible to a user who has no access to it, hence I need to be able to set permissions on the task, not an account to run it under.

(The user in question can likely not use an “elevated prompt”, as he is not an administrator. Most of our users are not administrators, obviously. I don’t think the difference between “elevated” and non-elevated applies to restricted users.)

That does not work. It sets permissions on the XML files where the tasks are stored not on the tasks themselves.

The task permissions themselves are stored as byte arrays in registry values at “HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionScheduleTaskCacheTree”.

Before Windows Server 2016 setting file permissions was sufficient (and inheritance worked). Since Windows Server 2016 this doesn’t work any more, hence the question.

I asked a Microsoft technician who was sent to my company to answer technical questions but he had no idea really what scheduled tasks are or why and if you would set permissions on them. (Maybe at MSFT everyone is an administrator and the issue never comes up.)

How does everybody handle this? PowerShell and WMI? Administrator rights for everyone? No scheduled tasks for anyone?

(I didn’t know Get-Acl ever worked with anything that isn’t a psdrive.)

Thanks.

Ironically, this is more complex than using SDDL and Win32_SecurityDescriptorHelper and almost as complex as my C program. 🙂

Nevertheless, it doesn’t seem to work for me.

Get-Acl -Path “MicrosoftWindowsTaskScheduler$TaskName”

I created a task “TestTask” (it runs cmd.exe with arguments /c cls) in the scheduled tasks root.

And while I can see it:

PS C:> Get-ScheduledTask TestTask

TaskPath TaskName State
——– ——– —–
TestTask Ready

I cannot Get-Acl it using your command:

PS C:> get-acl -path “MicrosoftWindowsTaskSchedulerTestTask”

Get-Acl: Cannot find path ‘MicrosoftWindowsTaskSchedulerTestTask’ because it does not exist.

What am I doing wrong? Is the path supposed to be on a certain provider and/or drive like HKLM:?

Does it work for you? Can you paste an example?

Hm… ok, that was weird.

1. The OSK on the client works on one server in the BIOS setup program. I.e. return and up/down keys work in the menu. (I don’t know why.)

2. The OSK on the client does NOT work on the Windows Server Core login screen. (I don’t know why. Especially since it works in 1.)

3. However, an American “” worked now. Perhaps this was fixed in one of the updates of the last few months.

Perhaps MSFT found out (I told them and they seemed to ignore the issue) and fixed it.

Or this was a fluke or someone reconfigured the keyboard layout of the server. Have to find out.

Ok, that was a confusing reply.

1. Yes, there is a Swiss keyboard. I live in Switzerland. I know. I actually speak German and French. But I use a qwerty keyboard. I know there are servers that use a Swiss keyboar layout.

2. You can doubt it, but I actually experienced it. ALT+ASCII doesn’t work on Server Core. I don’t think it matters that it is “not related to the GUI”.

3. No, Num Lock was not a factor.

4. There is no On-Screen Keyboard on a Server Core server. That actually IS related to the GUI.

I think switching keyboards around based on the “nationality” of the server currently using is stupid.

Besides, it’s not an option for our team in Singapore who have no access to Swiss keyboards but do (apparently) have a need to send a keyboard code produces by one to Swiss servers.

I could solve the problem by having a US, a German, a French and a Swiss keyboard ready at my desk. Or perhaps there is a superkeyboard available somewhere that can send all sorts of international codes?

If I could connect via PowerShell remoting, I wouldn’t need to use the ILO.

The company would also object to me changing the system’s general keyboard layout for the login screen (which is the default keyboard layout for all users).

“So if you have physical access, you can logon and then change the keyboard layout.”

If I had physical access, I also wouldn’t need to to use the ILO. However, I now assume I would have the same issue logging on. If logging in requires me to type a Swiss
“” and my keyboard doesn’t have that key, I won’t be able to logon. So I think the issue is really with Windows Server and not with ILO.

Windows Server Desktop allows changing the keyboard layout on the login screen, Windows Server Core does not. I really don’t know how MSFT imagined this should work.

(I think perhaps they imagine a world where different keyboard layouts don’t exist, just like they imagine a world in which every server everywhere is always connected to the Internet and hence PowerShell modules don’t have to come with help files because they can be downloaded at will, in MSFT-land.)