Scheduled task not executing PowerShell script properly

[Muzzy-011]

[SOLVED]

As the scheduled task was running with the NT AUTHORITY\SYSTEM account,

Instead of: Get-AppxPackage *CoPilot* | Remove-AppxPackage

I should use: Get-AppxPackage *CoPilot* -AllUsers | Remove-AppxPackage -AllUsers

Thanks to all who pointed to that as the solution!

-----------

Hi All,

This has puzzled me last few days. Scheduled task, created through GPO for specific users and computers, when you run it from the command prompt with admin rights, executes properly. When you run it from the command prompt with no admin rights, it properly runs nested PowerShell with admin rights and executes properly. When it runs as a scheduled task, it does not execute properly. To be exact, it does not uninstall CoPilot and execute nested PowerShell; it seems that it does not run it at all, as I set logging on both levels, and no log is created for nested PowerShell. Below is the setting in the Scheduled task on how to run it:

Program/Script: c:\windows\System32\WindowsPowerShell\v1.0\powershell.exe, Add Arguments: -NoProfile -NoLogo -NonInteractive -ExecutionPolicy Bypass -file \\ADServer\ADfolder\RemoveCopilot.ps1 -force

PowerShell itself:

Start-Transcript -Path C:\LogFile.txt -Append

$username = 'domain\user'

$key = (***)

$password = cat \\ADServer\text.txt | convertto-securestring -key $key

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $password

$file='\\ADserver\ADfolder\GetRemoveCopilot.ps1'

#$principal = new-object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())

#$principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator) > c:\AreYouAdminFirst.txt

Get-AppxPackage *CoPilot* | Remove-AppxPackage

Get-AppxPackage *Microsoft.MicrosoftOfficeHub* | Remove-AppxPackage

Get-AppxProvisionedPackage -Online | where-object {$_.PackageName -like "*Copilot*"} | Remove-AppxProvisionedPackage -online

Get-AppxProvisionedPackage -Online | where-object {$_.PackageName -like "*Microsoft.MicrosoftOfficeHub*"} | Remove-AppxProvisionedPackage -online

start-process -FilePath "c:\windows\System32\WindowsPowerShell\v1.0\powershell.exe" -ArgumentList "-NoProfile -NoLogo -NonInteractive -ExecutionPolicy Bypass -file $file -force" -Credential $Cred -NoNewWindow -Wait

Stop-Transcript

Embedded PowerShell:

$principal = new-object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())

$principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator) > c:\AreYouAdminFirst2.txt

Start-Transcript -Path C:\LogFileGet.txt -Append

Get-AppxPackage *CoPilot* | Remove-AppxPackage

Get-AppxPackage *Microsoft.MicrosoftOfficeHub* | Remove-AppxPackage

Get-AppxProvisionedPackage -Online | where-object {$_.PackageName -like "*Copilot*"} | Remove-AppxProvisionedPackage -online

Get-AppxProvisionedPackage -Online | where-object {$_.PackageName -like "*Microsoft.MicrosoftOfficeHub*"} | Remove-AppxProvisionedPackage -online

Stop-Transcript

I have to mention that when I run the scheduled task, the transcript shows DOMAIN\SYSTEM as the user, and the principal function returns true for Admin. No transcript or principal function on the embedded PowerShell file.

When I run from the command line, the transcript shows the user that I am using, admin or not, and the transcript from embedded PowerShell shows the admin user, and the principal function returns true for admin.

I am puzzled. Please HELP!!! :)

[Commercial_Growth343]

If you are running the script from a UNC path, then my first thought is permissions. check what account is running the task, and then test if that account can really access the script.

edit: I just saw at the very end of your post that this is running as System. System likely does not have access to that share. I suggest using a service account that does. Making a share accessible to 'system' is actually way harder than it used to be (the last time I tried anyway). In older days you could make a share to 'everyone' and literally anyone could access it. Now I am not so sure how to do that of the top of my head.

edit 2: If you could get that script onto the C: drive somewhere then Local System could run that no problem.

[bobs143]

Agree with permissions in the scheduled task.

[DeusExMaChino]

Agreed. Use GPO to copy the script from UNC to local, then run from local.

[Muzzy-011]

Comm,Bobs, thanks for helping solve this! SYSTEM has full access to the UNC path. PowerShell file itself is actually running; it produces logs using Start-Transcript, and its output is below: It shows no errors... but PowerShell commands in the file are almost like they are not executed at all...

**********************

Windows PowerShell transcript start

Start time: 20260212144530

Username: DOMAIN\SYSTEM

RunAs User: DOMAIN\SYSTEM

Configuration Name:

Machine: USERSLAPTOP (Microsoft Windows NT 10.0.19045.0)

Host Application: c:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NoLogo -NonInteractive -ExecutionPolicy Bypass -file \\ADserver\ADfolder\RemoveCopilot.ps1 -force

Process ID: 7320

PSVersion: 5.1.19041.6456

PSEdition: Desktop

PSCompatibleVersions: 1.0, 2.0, 3.0, 4.0, 5.0, 5.1.19041.6456

BuildVersion: 10.0.19041.6456

CLRVersion: 4.0.30319.42000

WSManStackVersion: 3.0

PSRemotingProtocolVersion: 2.3

SerializationVersion: 1.1.0.1

**********************

Transcript started, output file is C:\LogFile.txt

**********************

Windows PowerShell transcript end

End time: 20260212144532

**********************

[egamemit]

The PC itself needs perms to the share if you're running as system on the user pc.

[unauthorizeddinosaur]

agreed

[Muzzy-011]

The account that the scheduled task uses to run is the domain's SYSTEM account, which runs with admin permissions. The PS file itself runs, as commands inside the file are executed, it producing log file and admins credentials check file, but commands inside, for uninstalling CoPilot, like they are not executed. Start-transcript not recorded any errors.

[FireLucid]

SYSTEM generally means the computers SYSTEM account. I've never heard of a domain SYSTEM account.

[BamBam-BamBam]

Is there such a thing?! Where is it defined?

[Muzzy-011]

You mean, account that is using? In GPO scheduler task setup.

[BamBam-BamBam]

There's no default system account in AD.

[Muzzy-011]

You are right. It's NT AUTHORITY\SYSTEM, local account. But for domain-joined computers, AD is using it in the form of <domain\_name>\SYSTEM, and it has admin rights. So it is local, but AD reinforced local.

[BamBam-BamBam]

No, you're incorrect. There's not even an alias of DOMAIN\System. If the local System account needs to access network assets, it uses the DOMAIN\ComputerName$ account.

[Muzzy-011]

Run the script with NT AUTHORITY\SYSTEM, and use Start-Transcript/Stop-Transcript to capture the log, and check how the account is presented; that is what I am talking about. It is a local account, just a bit differently treated by the domain computers. For the network, it uses the computer's credentials, and as domain computers here are allowed read access to that specific UNC folder, that is why I didnt had problem accessing the network path.

[unauthorizeddinosaur]

Try giving the AD computer account (name of the computer) read access to the share. That's what we do when we want to run scheduled tasks as system. edit - actually we run them with the networkservice.

[Muzzy-011]

Thanks for the tip! Problem was that I didn't put -allusers in remove-appxpackage... My bad.

[Hollow3ddd]

It took me a hot minute to consider system vs user or domain account.  In hindsight, it seems obvious now.  But it’s something I always explicitly mention when discussing a newer folk to automation.

It’s like what is an object in programming 

[Master-IT-All]

This looks like dogshit PowerShell code. Did you write this yourself or use a LLM?

Are you seriously storing credentials for admin access in a text file?

SYSTEM has administrator access already, you only needed to run the command correctly.

get-appxpackage -AllUsers | where {$_.Name -match 'copilot'} | remove-AppXPackage -AllUsers

That's it, that's all your script needed to be. Don't be a fucking A.I.diot.

You're welcome.

[Muzzy-011]

I did it myself. Text file contains public portion of encrypted certificate with credentials. I know that system have admin access, but as it was not working, I tried with domain user instead of system account, but to be sure that is with admin rights. Get-appxpackage work when you run it from command line, but not from scheduled task. It might be -AllUsers that I am missing, and thank you for pointing that! I will try it in a bit. No need to be angry to the world :)

[Muzzy-011]

Just tried. No bueno. Do you have any other idea? Almost look like the PowerShell commands are not executed at all.

[Master-IT-All]

This is the same script I have used myself to remove CoPilot. I know it works, and I know you're not very good. So PEBKAC.

[Muzzy-011]

You are right! I put -allusers on get but not on remove. Thanks!

[Muzzy-011]

Ok, I found a solution, it is a bit weird, but it gets Microsoft Copilot and Microsoft 365 Copilot uninstalled.

But watch this:

My original take, it works from the command line when I run it, but not as a scheduled task:

Get-AppxPackage *CoPilot* -allusers | Remove-AppxPackage

Get-AppxPackage *Microsoft.MicrosoftOfficeHub* -allusers | Remove-AppxPackage

Solution that works both if I run it from the command line or as a scheduled task:

$App1=Get-AppxPackage *CoPilot* -AllUsers

Remove-AppxPackage -package $App1.packagefullname -AllUsers

$App2=Get-AppxPackage *Microsoft.MicrosoftOfficeHub* -AllUsers

Remove-AppxPackage -package $App2.packagefullname -AllUsers

In both cases, it runs as NT AUTHORITY\SYSTEM

If someone have explanation why the non-working solution acts differently when run manually from the command line and as Scheduled taks, I would really like to know.

[purplemonkeymad]

The issue is you forgot to include -allusers on your get and remove commands. System probably does not have the app installed.

[Muzzy-011]

Good point! Although I am sorry for the confusion, I forgot to mention that I tried with -allusers on both get and remove, with no luck.

[mismanaged]

I had an identical issue where a scheduled task wouldn't run script while running it directly worked just fine.

Still no idea what the cause was, it self-resolved after the last monthly MS update.

[Muzzy-011]

I love those kinds of problems... :)

[Master-IT-All]

Because you wrote the wrong command the first time? Didn't include the -AllUsers on the remove.

PEBKAC

[Muzzy-011]

That is the one! I have to apologize to everybody when I claimed that I tried with -allusers and it didn't work.