I've been struggling with a scheduled task issue over the past few days. The task was created through Group Policy for certain users and machines. When I manually execute it from the command prompt with admin privileges, it works perfectly. Even when run without admin rights, it successfully triggers the nested PowerShell script with admin rights. However, when it's launched as a scheduled task, it fails to execute properly, particularly when it comes to uninstalling CoPilot and running the nested PowerShell script. I've set up logging for both levels, but no log is generated for the nested PowerShell execution. Here's the scheduled task configuration: It calls PowerShell from `C:windowsSystem32WindowsPowerShellv1.0powershell.exe` with arguments `-NoProfile -NoLogo -NonInteractive -ExecutionPolicy Bypass -file \\ADServer\ADfolder\RemoveCopilot.ps1 -force`.
In PowerShell, I initiate a transcript, define my credentials, and go through the packages I'm trying to remove. I noticed that when executing the scheduled task, the transcript shows `DOMAINSYSTEM` as the user, and the principal function indicates it has admin rights. Yet, when I run it from the command line, the transcript displays my user account's information.
I'm scratching my head here. Can anyone provide some insight or suggestions? Thanks!
2 Answers
Totally understand how frustrating this can be! I ran into something similar before. Just be aware that when running via `SYSTEM`, the transcript will indicate that user. If the commands in the script aren't executing at all, it could be that the PowerShell execution policy or some other restriction is preventing it. Maybe try logging additional details to see what exactly is going wrong?
Also try running the scheduled task with a different user to see if that changes anything.
It sounds like a permissions issue to me. Since the task runs as `SYSTEM`, it might not have access to the UNC path where your script is located. You should try switching to a service account that has the necessary permissions to access that path. Sharing with `SYSTEM` is a bit tricky these days, so it could be easier to copy the script to a local drive. That way, the scheduled task runs without permission hiccups.
Yeah, I agree! Moving it to a local drive is the simplest fix.
Also, make sure to test the task with the same account to verify it can access the script properly.
That’s a great idea, adding more logging could reveal hidden issues!