• “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
    PS C:Program FilesABTokenTools> .LookupAccountSid.exe S-1-5-21-1997462784-3649744622-1500452921-1014
    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.)


  • How does everyone here deal with software vendors who claim that their particular service was “designed” (whatever that means) to “run as an admin”, i.e. requires the service’s account to be a member of the Administrators group?

    The fact that several users would have that account’s password (if it is a user account) and that several users that have temporary admin rights to a server where the service is running will also know the account’s password, makes for an audit nightmare. (Who has permanent admin rights to those servers? Wait, lots of people. Don’t know how many at the moment…)

    Usually those services do not require every privilege and permission the Administrators group owns. Few services need to create local users, even fewer need to format disks or create volumes. So how do you deal with this?


  • 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?

  • I am currently configuring permissions on Scheduled Tasks using a self-written C program that converts SDDL into a security descriptor and writes that into the “SD” value of the registry key associated with the Scheduled Task.

    More complicatedly this can be done, of course, using PowerShell’s Set-ItemProperty cmdlet and WMI’s Win32_SecurityDescriptorHelper class.

    Both ways cannot set inheritance correctly (since, presumably, binary blob security descriptors do not support inheritance).

    Is there a better (and ideally supported) way to set permissions on Scheduled Tasks?

    schtasks.exe supports showing a security descriptor (schtasks/showsid /tn MyScheduledTask) but cannot, apparently, set it.

    We have lots of users who require settings up Scheduled Tasks.

    How do others support those situations.

    (Giving everyone Administrator privileges is obviously not an option.)

  • 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.


  • Update: The described functionality is now part of ACLEdit.exe, same repo.

  • 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.)


  • I just encountered an annoying issue.

    When trying to log onto Windows Server Core via ILO using a local account, it is impossible to type a backslash if the server’s keyboard layout is too foreign.

    In my case it’s a Swiss keyboard layout. Swiss keyboards apparently have a key between z and left-shift that (in combination with alt-gr, another special key on the Swiss keyboard) types . My American keyboard doesn’t have that key.

    I tried:

    1. Changing the keyboard layout in the console. This fails because ILO does not, apparently, send shift-alt through to the server.

    2. Typing left-alt and 9 and 2 on the numberpad to get ASCII . This fails because Server Core apprently doesn’t support this handy input method. (It acts as if I pressed return.)

    3. Using / instead of .

    4. Using @servername instead of servername. (Obviously this didn’t work.)

    5. Using ILO hotkeys, which apparently cannot send foreign keycodes either. becomes $ (because a Swiss keyboard has $ where an American has ).

    6. Calling a colleague with a Swiss keyboard. That worked, but is not practical at all hours.

    How did HPE think this should work? What am I overlooking?

  • For what it’s worth, I tried it without C# or PowerShell.

    Using SetNamedSecurityInfo() it appears to be possible to set a new DAC on an object owned by me without either Set Value or Write DACL set (and obviously without being an administrator).

    Originally Benoit has full control on his key:

    I then got SDDLs for Full Control and two versions for without Set Value and without Write DAC

    And finally I wrote that SDDL over the existing DACL

    It appears that .NET ignores the fact that the owner can modify the DACL without any specific permissions set.

    Now, I tried the same thing with opening registry keys and writing security descriptors to them (without using SetNamedSecurityInfo()) and then I found the same behaviour as with .NET: I could only change a DACL if I had Set Value. Perhaps .NET (and thus both C# and PowerShell) set registry permissions using RegSetKeySecurity() rather than SetNamedSecurityInfo().

    I didn’t try if Write DAC becomes relevant if I am not the owner of the key, I assume it does.

    Hope this helps someone else who has this problem in a script.

    The (not very good and entirely non-error-checking) code can be found here: https://github.com/ajbrehm/ABTokenTools

  • I am not talking about admins, but about an ACL. There is no “Set Value” privilege, it’s a permission in the ACL. In order for my user to have that permission, it has to be set by someone who has that permission. The owner of the key should be able to set that permission and, with regedit, can.

    But that doesn’t help with a script, for example.

    My question is not about UAC or about admins, it’s only about a problem with .NET where an ACL is obviously interpreted differently as by Win32 (which is why regedit works).

    A user who owns a key should be able to modify the key’s ACL. With C# and PowerShell he cannot, and I was wondering about that.

    I will try another way now and see if it’s purely a .NET issue.

  • Load More
© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account