Solved Make Scheduled Task Accessible to Non-Admins

hdmi · Jul 18, 2025

johnaw said:
@hdmi Thanks for all your efforts! But very complicated and long.

"It takes a little bit of suffering to be beautiful" is what Italians say.

You only need to run it one time, as it only creates the new task in Task Scheduler. So, the whole idea is to just keep the task in there after that. The command to run this task is simple and short, and should work even if you're logged in with a standard user account instead of an account that belongs to the Administrators group. It's this:
schtasks /run /tn Reset-Audio

@garlin had it right the first time, the task should ideally be run as SYSTEM, as this makes it easier to avoid pitfalls like the Access is denied error that you were experiencing. Setting the requested privilege to Highest causes it to request the highest. It doesn't mean that the highest will actually be granted.

For this specific intent/purpose (i.e. running pnputil), choosing SYSTEM avoids the need to expose Credentials, and it simplifies the logic as a bonus. There exist a lot of situations where choosing SYSTEM could cause serious problems (and could even be a security risk), but this isn't one of them.

Granting Authenticated Users permission to trigger the task by modifying the task's security descriptor is what avoids the Access is denied error without having to do anything else.

This also is why the command to run the task is just schtasks /run /tn Reset-Audio.

Just in case you still don't understand why Task Scheduler is the way to go, it's because otherwise you will be greeted with the annoying UAC prompt each time before your command resets the audio device. (Disabling UAC is most definitely NOT recommended excepting only maybe if you really, REALLY know what you're doing, so...)

johnaw · Jul 18, 2025

hdmi said:
"It takes a little bit of suffering to be beautiful" is what Italians say.

I noticed you use ` -ForegroundColor Yellow`. Is that needed for this to run properly?

hdmi · Jul 18, 2025

johnaw said:
I noticed you use ` -ForegroundColor Yellow`. Is that needed for this to run properly?

Of course not.

johnaw · Jul 18, 2025

hdmi said:
Of course not.

Are there other non-critical parts of the script? I'm not going for Italian beauty, just American functionality

hdmi · Jul 18, 2025

johnaw said:
Are there other non-critical parts of the script? I'm not going for Italian beauty, just American functionality

Not really. You could always decide to make it shorter, but doing so would only make it harder to read for anyone who doesn't eat PowerShell for breakfast. You certainly wouldn't gain any disk space from making it shorter, and also you wouldn't notice a big enough difference in speed to be able to justify the effort and time spent on it. Remember that you only need to run it one time so, why bother?

johnaw · Jul 18, 2025

hdmi said:
Not really. You could always decide to make it shorter, but doing so would only make it harder to read

"shorter" you mean remove white space but keep all the same code? I want to reduce the amount of code, not the amount of white space.

johnaw · Jul 18, 2025

this is all I need. if I can minimize or eliminate password requests in a non-admin account I'm good

Powershell:

> $deviceID = "INTELAUDIO\FUNC_01&VEN_10EC&DEV_0295&SUBSYS_1028099F&REV_1000\5&1B578A47&0&0001"
> Disable-PnpDevice -InstanceId $deviceID -Confirm:$false
> Enable-PnpDevice -InstanceId $deviceID -Confirm:$false

hdmi · Jul 18, 2025

johnaw said:
if I can minimize or eliminate password requests in a non-admin account I'm good

This is exactly what the task in Task Scheduler lets you achieve, as you can simply run it without ever getting prompted in any way. So, after you run the batch script, this is all you'll ever need: schtasks /run /tn Reset-Audio

Here is a shorter version of my batch script:

Batch:

<# ::
@echo off
"%windir%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -ExecutionPolicy Bypass -Command ^$p = '%~dpnx0'; Invoke-Expression ((Get-Content '%~dpnx0') -join [Environment]::NewLine); Ele
goto :eof
#>
$c = "`$p = '$($p)'; Write-Host 'Processing: ' -NoNewline; Write-Host `$p; Invoke-Expression ((Get-Content `$p) -join [Environment]::NewLine); if (`$p -ne '') { Main }"
function Adm { return ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) }
function Ele {
  $x = 'Start-Process "$env:windir\System32\WindowsPowerShell\v1.0\powershell.exe" "-NoProfile -ExecutionPolicy Bypass -Command `"$c`""'
  if (-not (Adm)) { $x = $x + " -Verb RunAs" }
  Invoke-Expression ($x)
}
function Main {
  $p
  if (Adm) {
    $n = "Reset-Audio"
    $i = '"INTELAUDIO\FUNC_01&VEN_10EC&DEV_0295&SUBSYS_1028099F&REV_1000\5&1B578A47&0&0001"'
    Register-ScheduledTask -TaskName $n `
                           -Action @((New-ScheduledTaskAction -Execute "pnputil.exe" -Argument "/disable-device $i"), (New-ScheduledTaskAction -Execute "pnputil.exe" -Argument "/enable-device $i")) `
                           -Trigger (New-ScheduledTaskTrigger -Once -At (Get-Date)) `
                           -Principal (New-ScheduledTaskPrincipal -UserId SYSTEM -LogonType ServiceAccount -RunLevel Highest) `
                           -Settings (New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable) `
                           -Force
    $s = New-Object -ComObject Schedule.Service
    $s.Connect()
    $t = $s.GetFolder("\").GetTask($n)
    $d = $t.GetSecurityDescriptor(0xF)
    if ($d -notmatch 'A;;GRGX;;;AU') {
      $d += '(A;;GRGX;;;AU)'
      $t.SetSecurityDescriptor($d, 0)
    }
  } else { Write-Host "Couldn't elevate the script." }
  pause
}

EDIT: Removed -ForegroundColor Yellow from $c.

johnaw · Jul 19, 2025

hdmi said:
This is exactly what the task in Task Scheduler lets you achieve, as you can simply run it without ever getting prompted in any way. So, after you run the batch script, this is all you'll ever need: schtasks /run /tn Reset-Audio

Your task is visible to, and runnable by, the logged-in non-admin user.

I'm trying to duplicate your code through the Scheduler GUI. But although i apply all the same settings when i create the task, i can't see or run my code from a non-admin login.

>schtasks /run /tn "Reset-Audio"
SUCCESS: Attempted to run the scheduled task "Reset-Audio".
- works

>schtasks /run /tn "Disable-Audio"
ERROR: Access is denied.
- fails

I exported your task and mine and ran a diff. I don't see any relevant difference, except yours contains two commands where mine contains just one.

Reset-Audio - Diffchecker

<?xml version="1.0" encoding="UTF-16"?> <Task version="1.3" xmlns="http://schemas.microsoft.com/wind - Text Comparison

www.diffchecker.com

So there is something in your code, which isn't visible in Scheduler, which makes your task accessible from non-admin users. I suspect this might be the line which makes the task accessible to non-admin users.
`$t.SetSecurityDescriptor($d, 0)`
I don't know what it's doing, but i think it's setting file/folder permissions on the task in `C:\Windows\System32\Tasks`, and/or it's applying an Access Mask in the registry:

Windows: Permit a limited user to run a schedule task defined by an Administrator

Hi, This post is developed by the trial and error principle ;-) . Here you can find some background. On Windows a User with just "normal" user rights cannot see and execute Tasks created from User with Administrator permissions. There are dozed of sites that describes that the permissions of...

michlstechblog.info

Other notes:
- I don't see `-join [Environment]` in the doc, not sure what that is. Is that a PS concatenation operator?
- I think your fx `Adm` returns a boolean indicating if the user executing the script has admin rights.
- Your fx `Ele` executes command $c, but i don't understand what $c is doing.
- Your `Register-ScheduledTask` creates the new task, actions, settings, and principal (SYSTEM).

I found both tasks in `C:\Windows\System32\Tasks`, and i noticed your task has permissions for Authenticated Users; mine does not. I added Authenticated Users to my task and rebooted, but i still cannot see or execute my task from the non-admin logged-in account. I checked Effective Access for the logged in non-admin, and it appears to be identical.

Btw, I noticed that your task can still be run on demand after i deleted the trigger, so it seems your trigger was unnecessary. I removed the trigger code from your task, and then from your task-creation script, and the task still behaves as expected.

Also attached are exports from the registry cache for each task.

johnaw · Jul 19, 2025

hdmi said:
This is exactly what the task in Task Scheduler lets you achieve, as you can simply run it without ever getting prompted in any way. So, after you run the batch script, this is all you'll ever need: schtasks /run /tn Reset-Audio

Yep, after more reading, i have little doubt you're modifying the ACL for the task.

How to modify permissions for scheduled tasks in Windows 10?

I have a scheduled task that I want to be able to run/trigger as a normal user that has no administrative privileges on the local computer. The task itself was created with the account NT AUTHORITY\

superuser.com

"Granting access to Authenticated Users for READ and EXECUTE is as simple as connecting to the Task Scheduler API and adding (A;;GRGX;;;AU) to the Security Descriptor"

Task Permissions | OSDeploy by Recast

www.osdeploy.com

In their example, i'd like to understand why the task path is `$TaskPath = '\Corporate\PowerShell'`. It seems they are setting that path in Register-ScheduledTask. Normally, aren't all tasks in `C:\Windows\System32\Tasks`? For personal, local use, i'd leave out $TaskPath and assume default location.

Also, i just confirmed that running as SYSTEM isn't required. It can be run by the Admin account who created it. You can accept the default when you create the task.

However, it must be set to "Run whether user is logged on or not", to enable a non-admin logged-in user to run it when the Admin account is not logged in.

I assume this if statement is just checking to see if the task has already been modified this way
if ($GetSecurityDescriptor -notmatch 'A;;0x1200a9;;;AU')

I see no reason the script to give access to users can't be a .bat which accepts the task-name as an input parameter. And, no need to create the task with code -- the Scheduler GUI works fine. Therefore, i can create any task in Admin Scheduler, and then run this .bat to give all users access to it.

To me, that's the lowest effort, most understandable way to achieve this.

Manually create task in Scheduler. Set "Run whether user is logged on or not". Don't require "highest privileges" No triggers. Does not have to be run by SYSTEM, can be run by the Admin account.
Execute this script (with some minor tweaks) to give access to all users:

Code:

$Scheduler = New-Object -ComObject "Schedule.Service"
$Scheduler.Connect()
$GetTask = $Scheduler.GetFolder($TaskPath).GetTask($TaskName)
$GetSecurityDescriptor = $GetTask.GetSecurityDescriptor(0xF)
if ($GetSecurityDescriptor -notmatch 'A;;0x1200a9;;;AU') {
    $GetSecurityDescriptor = $GetSecurityDescriptor + '(A;;GRGX;;;AU)'
    $GetTask.SetSecurityDescriptor($GetSecurityDescriptor, 0)
}

Ben Myers · Jul 19, 2025

My understanding of Task Scheduler is that the task has to be set to run with highest privileges and also has to be set to run whether the user is logged in or not. You will have to supply the username and password when creating the task.

Ben

johnaw · Jul 19, 2025

Ben Myers said:
My understanding of Task Scheduler is that the task has to be set to run with highest privileges and also has to be set to run whether the user is logged in or not. You will have to supply the username and password when creating the task.

Ben

My understanding is that to give all users access to a task, it must be set to run as SYSTEM in Scheduler, and not as any specific user.

Also, i can confirm that a non-admin user can view and execute this particular task (disabling and enabling a device driver), with ACL configured as described by @hdmi, does not require "Run with highest privileges". So that's another item which could be removed from @hdmi 's code.

Ben Myers · Jul 19, 2025

I don't think that tasks created by the system allow user interaction. You might try creating the task using your admin account and allowing other users to access it.

Ben

johnaw · Jul 19, 2025

Ben Myers said:
I don't think that tasks created by the system allow user interaction.

The task isn't "created by" SYSTEM. It's created by an admin account. It's set to run as SYSTEM in Scheduler.

However, i just confirmed that this isn't required. It does not have to be run by SYSTEM, can be run by the Admin account. You can accept the default when you create the task.

However, it must be set to "Run whether user is logged on or not", to enable a non-admin logged-in user to run it.

Ben Myers said:
You might try allowing other users to access it.

How? I think we have solved this as explained in replies above. But i would love to hear your suggestion.

johnaw · Jul 19, 2025

There's an alternative solution, if you don't want to mod the ACL:
- Create a task with an event trigger. Choose an event that non-admin users are authorized to do.
- A user can fire the task indirectly, by executing that event.

https://superuser.com/a/1854555

How to empower restricted users to execute defined administrative tasks | Experts Exchange

Learn more about How to empower restricted users to execute defined administrative tasks from the expert community at Experts Exchange

www.experts-exchange.com

johnaw · Jul 20, 2025

hdmi said:
"It takes a little bit of suffering to be beautiful" is what Italians say.

Why doesn't this work? My task still won't run for user:

mod-acl.bat

Code:

    $s = New-Object -ComObject Schedule.Service
    $s.Connect()
    $t = $s.GetFolder("\").GetTask("Disable-Audio")
    $d = $t.GetSecurityDescriptor(0xF)
    if ($d -notmatch 'A;;GRGX;;;AU') {
      $d += '(A;;GRGX;;;AU)'
      $t.SetSecurityDescriptor($d, 0)

Ben Myers · Jul 20, 2025

You seem to be running a batch file full of powershell commands.

Ben

johnaw · Jul 20, 2025

johnaw said:
Why doesn't this work? My task still won't run for user?

Solved. It was a little thing known as a bug. Corrected code below. Works.

Powershell:

$TaskName = "Enable-Audio"
$Scheduler = New-Object -ComObject "Schedule.Service"
$Scheduler.Connect()
$Task = $Scheduler.GetFolder("\").GetTask($TaskName)
$SecurityDescriptor = $Task.GetSecurityDescriptor(0xF)
if ($SecurityDescriptor -notmatch 'A;;0x1200a9;;;AU') {
    $NewSecurityDescriptor = $SecurityDescriptor + '(A;;GRGX;;;AU)'
    $Task.SetSecurityDescriptor($NewSecurityDescriptor, 0)
}

hdmi · Jul 20, 2025

Yeah, you are correct about the fact that the line with -Trigger can simply be removed from my script. Good catch! Also, of course it is possible to create the task manually, but running the script is significantly faster, and lets you avoid the hassle of going through each step manually when there's no need to do it manually. It's called Automation. Again, you only need to set up the scheduled task in Task Scheduler one time, which is what the script also lets you achieve (conveniently, by merely double-clicking on it, taking a deep breath, watching it confirm that it successfully created the new task, and then closing the PowerShell window).

The security descriptor of a registered task is in a binary blob in the registry under:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\<TaskName>
The 0xF value specified in the GetSecurityDescriptor() method call is a bitmask that combines all four of these:

OWNER_SECURITY_INFORMATION	0x1	Retrieve/set the owner SID
GROUP_SECURITY_INFORMATION	0x2	Retrieve/set the group SID
DACL_SECURITY_INFORMATION	0x4	Retrieve/set the DACL
SACL_SECURITY_INFORMATION	0x8	Retrieve/set the SACL

The SDDL ACE string (A;;GRGX;;;AU) grants grants read and execute permissions to all authenticated users.

A	Access Allowed ACE type
;;	No ACE flags (e.g., inheritance)
GRGX	Generic Read (GR) and Generic Execute (GX) permissions
;;;	No object GUIDs specified
AU	Applies to Authenticated Users group

if ($GetSecurityDescriptor -notmatch 'A;;0x1200a9;;;AU') does indeed check if the security descripter has already previously been adjusted.

[Environment]::NewLine produces a Carriage Return character followed by New Line character, it is equivalent to "`r`n" but lets you conveniently avoid having to deal with escape characters when using PowerShell in this particular context. The Adm function does indeed check if the script is running with administrator privileges (i.e., if it is running elevated), The $c variable is the PowerShell command that is run in the Ele function to self-elevate, as Register-ScheduledTask will fail to create the new task if Register-ScheduledTask runs without administrator privileges.

About letting the task run as SYSTEM instead of letting it run as an administrator. You said to keep the script as short as possible, and, SYSTEM is only 6 characters in length.

Seriously, though... there's absolutely no need to change this. But yeah, SYSTEM already has higher privileges than any user that is a member of the Administrators group anyway in the first place. So, there's that and the fact that the user account that belongs to the Administrators group could potentially be replaced with a different user account [that also belongs to the Administrators group] at some point in the future (e.g. after the account profile gets corrupted somehow) in which case you'd have to remember to adjust the task accordingly, and then, also potentially, you might have to futz around with the password again (until finally, at very long last, you come to realize that choosing SYSTEM not only is adequate, but the actual bees knees for this specific purpose.

Finally, although nothing is wrong with the alternative solution you outlined in post #35. Modifying the task's security descriptor is more elegent (and shorter, which, IIRC, 150 percent matches what you asked...). There are no potential undesired side effects to either one of both these two different solutions, at least not that I am aware of. If you're worried about how Task Scheduler relates to security vulnerabilities, IMO your time could be a lot better spent reading this one right here:

Task Scheduler– New Vulnerabilities for schtasks.exe

UAC bypass, metadata poisoning, and log overflow vulnerabilities in Windows Task Scheduler reveal new tactics for defense evasion and privilege escalation

cymulate.com

hdmi · Jul 20, 2025

Here's my updated script:

Batch:

<# ::
@echo off
"%windir%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -ExecutionPolicy Bypass -Command ^$p = '%~dpnx0'; Invoke-Expression ((Get-Content '%~dpnx0') -join [Environment]::NewLine); Ele
goto :eof
#>
$c = "`$p = '$($p)'; Write-Host 'Processing: ' -NoNewline; Write-Host `$p; Invoke-Expression ((Get-Content `$p) -join [Environment]::NewLine); if (`$p -ne '') { Main }"
function Adm { return ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) }
function Ele {
  $x = 'Start-Process "$env:windir\System32\WindowsPowerShell\v1.0\powershell.exe" "-NoProfile -ExecutionPolicy Bypass -Command `"$c`""'
  if (-not (Adm)) { $x = $x + " -Verb RunAs" }
  Invoke-Expression ($x)
}
function Main {
  $p
  if (Adm) {
    $n = "Reset-Audio"
    $i = '"INTELAUDIO\FUNC_01&VEN_10EC&DEV_0295&SUBSYS_1028099F&REV_1000\5&1B578A47&0&0001"'
    Register-ScheduledTask -TaskName $n `
                           -Action @((New-ScheduledTaskAction -Execute "pnputil.exe" -Argument "/disable-device $i"), (New-ScheduledTaskAction -Execute "pnputil.exe" -Argument "/enable-device $i")) `
                           -Principal (New-ScheduledTaskPrincipal -UserId SYSTEM -LogonType ServiceAccount) `
                           -Settings (New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable) `
                           -Force
    $s = New-Object -ComObject Schedule.Service
    $s.Connect()
    $t = $s.GetFolder("\").GetTask($n)
    $d = $t.GetSecurityDescriptor(0xF)
    if ($d -notmatch 'A;;GRGX;;;AU') {
      $d += '(A;;GRGX;;;AU)'
      $t.SetSecurityDescriptor($d, 0)
    }
  } else { Write-Host "Couldn't elevate the script." }
  pause
}

Solved Make Scheduled Task Accessible to Non-Admins

Jack of all trades – master of none

My Computers My Computers

At a glance

At a glance

Member

My Computer My Computer

At a glance

Jack of all trades – master of none

My Computers My Computers

At a glance

At a glance

Member

My Computer My Computer

At a glance

Jack of all trades – master of none

My Computers My Computers

At a glance

At a glance

Member

My Computer My Computer

At a glance

Member

My Computer My Computer

At a glance

Jack of all trades – master of none

My Computers My Computers

At a glance

At a glance

Member

Attachments

My Computer My Computer

At a glance

Member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Member

My Computer My Computer

At a glance

Member

My Computer My Computer

At a glance

Member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Member

My Computer My Computer

At a glance

Jack of all trades – master of none

My Computers My Computers

At a glance

At a glance

Jack of all trades – master of none

My Computers My Computers

At a glance

At a glance

My Computers

My Computer

My Computers

My Computer

My Computers

My Computer

My Computer

My Computers

My Computer

My Computer

My Computers

My Computer

My Computers

My Computer

My Computer

My Computer

My Computers

My Computer

My Computers

My Computers