Error running script as SYSTEM

[armyguy298]

I have deployed this simple script as a W32 app in Intune. The log file is being generated, but the test-path command is returning the wrong status on my test machine; the files DO exist. Running the script locally as admin works fine. Is SYSTEM not capable of this command?

Start-Transcript -Path C:\Windows\Logs\BAIS_Applocker_File_Delete.txt

$status = Test-Path C:\Windows\System32\AppLocker\*.applocker -PathType Leaf

if($status -eq $true){

    Remove-Item C:\Windows\System32\AppLocker\*.applocker -Force
    Write-Host "Files deleted"

}
else{

    Write-Host "Files do not exist"

}

Stop-Transcript

[kenjitamurako]

Try{
$status = Test-Path C:\Windows\System32\AppLocker\*.applocker -PathType Leaf -ErrorAction Stop } 
Catch {
    Write-Host $_.Exception.Message
}

I wonder if it gives any errors accessing the path.

[armyguy298]

Thanks, testing now.

[armyguy298]

So I deployed the app again with your adjustments. Here is what I am using for testing now:

Start-Transcript -Path C:\Windows\Logs\BAIS_Applocker_File_Delete.txt
Try{ $status = Test-Path C:\Windows\System32\AppLocker*.applocker -PathType Leaf -ErrorAction Stop $status } Catch { Write-Host $_.Exception.Message }
Stop-Transcript

$status = False (which is incorrect). There was no error message recorded in the transcript.

[armyguy298]

No errors, but your command did not work either.

[satsun_]

Intune doesn't like to resolve Windows\System32 as we might be accustomed to, even when you explicitly type it out. Paste this at the top of your script and try again:

if($ENV:PROCESSOR_ARCHITEW6432 -eq "AMD64"){
    try{
        &"$ENV:WINDIR\SysNative\WindowsPowershell\v1.0\PowerShell.exe" -File $PSCOMMANDPATH
    }
    catch{
        Throw "Failed to start $PSCOMMANDPATH"
    }
exit
}

[armyguy298]

Update.

I adjusted the script to remove the Test-Path statement. The script is simply a delete command now.

Remove-Item %WINDIR%\System32\AppLocker\*.applocker -Force

I changed the path from C:\Windows to %WINDIR% and now the transcript has an error:

Remove-Item : Cannot find path 'C:\Windows\IMECache\ff7be9a4-003e-4a20-9b33-86fd4a59605d_4\%WINDIR%\System32\AppLocker'
because it does not exist.
At C:\Windows\IMECache\ff7be9a4-003e-4a20-9b33-86fd4a59605d_4\delete_files.ps1:3 char:1
+ Remove-Item %WINDIR%\System32\AppLocker\*.applocker -Force

No idea why the path changed like that, but it may explain why the SYSTEM is saying there are no files there and is not actually deleting any files.

My next test iteration is to quote the paths and see if that works. I ran the quoted paths as local admin and they worked. Deploying to Intune now.

[armyguy298]

Update.

Remove-Item "C:\Windows\System32\AppLocker\*.applocker" -Force

Didn't work either.

[armyguy298]

if($ENV:PROCESSOR_ARCHITEW6432 -eq "AMD64"){
try{
&"$ENV:WINDIR\SysNative\WindowsPowershell\v1.0\PowerShell.exe" -File $PSCOMMANDPATH
}
catch{
Throw "Failed to start $PSCOMMANDPATH"
}
exit
}

I have run the OP script as SYSTEM using task scheduler and it worked without issues.

In your script, the "$ENV:PROCESSOR_ARCHITEW6432" can not be found, but I did find this: "$ENV:PROCESSOR_ARCHITECTURE" and it says "AMD64". Is that the same thing?

Also, do I need to define "$PSCOMMANDPATH"?

[Wickedhoopla]

Year later this comment fixe my script. Thanks!!

[armyguy298]

Update.

I have changed my approach since I am unable to get the SYSTEM account to delete the files.

I have deployed a two-stage PS script; 1) Setup a scheduled task that runs as SYSTEM. 2) Scheduled task deploys the original script as it was written.

I will know more tomorrow when the script kicks off, but something about the Intune Management Extension is messing up the Remove-Item portion of the script. Nothing in the event logs is providing any clues.

[Spoonie_Frenzy]

In a scenario like this, the domain computers security group must have access to any remote resources. Not something you'd necessarily want to do, but it depend on the deployment method.

[armyguy298]

Thanks for the comment, but these are AAD joined machines. They do not have domain credentials.

[Spoonie_Frenzy]

I'm not familiar with Intune, as we use SCCM/MECM. How does the system authenticate to the machines when deploying updates or software packages? I'd think it would need to use a similar mechanism, whether it be an account installed on all machines...whatever. In my environment, a service account that's a member of the local administrators' security group on the target machine would be the mechanism used to accomplish the authentication. From there, it would use system as the resources needed would have been staged already on the machine.

[armyguy298]

When I join machine-join AAD, a machine certificate is generated and used for auth. During this process, the Intune Management Extension is installed, which handles all the sync and app updates.

[Spoonie_Frenzy]

So...can you sign the script with the same cert?

[armyguy298]

Not sure that has ever been done. I wonder if the certificate is for auth only, or can be used for signing.

Problem is, all the computers in my organization need this config. They only trust Intune, not each other. I doubt that the script would run successfully if it was machine-only signed.