PS can't do file management when running as SYSTEM

Question

A PowerShell script renames a log folder to function as an archive, creates a new log folder, copies the ACL from the old folder to the new one, then deletes the oldest archives if there are more archives than desired. Snippet follows--

If ( $NumberOfLogsToKeep -gt 0) {  
    # archive recent logs  
    $dateStamp = get-date -uformat "%Y-%m-%d@%H-%M-%S"  
    $archiveFolder = "$LogFolder-$dateStamp"  
    Rename-Item $LogFolder $archiveFolder  
    New-Item $LogFolder -ItemType Directory  
    Get-ACL $archiveFolder | Set-ACL $LogFolder  
  
    # prune stale log folders  
    If ( Test-Path "$PSScriptRoot\Logs-*" ) {  
        $archiveFolders = Get-ChildItem -Path "$PSScriptRoot\Logs-*" -Directory | Sort-Object -Descending  
        $i = 0  
        $archiveFolders | ForEach-Object {  
            $i = $i + 1  
            If ( $i -gt $NumberOfLogsToKeep ) {  
                Remove-Item $_ -Recurse  
            }  
        }  
    }  
}  

$NumberOfLogsToKeep and $LogFolder (a share hosted on a remote server) are specified in a "preferences" section at the top of the script.

On a WS2019 domain and WS2019 server, works perfectly when run as a Scheduled Task using Domain Admin creds. Does not work at all when run as a Scheduled Task using NT AUTHORITY\SYSTEM creds. The log folder is not renamed; don't know if the rest of the code would run correctly because it has nothing to do if the log folder is not renamed. SYSTEM has full control on the folder, subfolders, and files.

But on a different, WS2012R2 domain, on a WS2012R2 server, runs perfectly as a Scheduled Task as NT AUTHORITY\SYSTEM.

Is this a change in WS2019 PowerShell? For security?

TIA

Answer 1

$NumberOfLogsToKeep and $LogFolder (a share hosted on a remote server)

When you run a process on Server1 as SYSTEM, and reference \Server2\ShareName, in a domain environment, then the account that Server2 sees is the AD computer account for Server1.

The account is YourDomainName\Server1$ it is not "SYSTEM".

The difference is likely something in either the share permissions or NTFS folder permissions where "everyone" or "authenticated users" have access. Check the security eventlog on Server2 and look for logon events from Server1$.

Answer 2

I'm not aware of any changes but, from a security point of view, I would have to ask the question why you would ever need to run a script like that as SYSTEM anyway. SYSTEM is designed for the OS to use, not any program you would ever write. Even services don't run under this account unless they absolutely need to (which is rare these days).

At a minimum I would run as a regular user. If it is file permissions issue then grant the user the necessary permissions on the folder structure(s). In the absolute worst case then run as an admin. SYSTEM would be overkill unless you're trying to rename OS logs that only SYSTEM has access to.

I would run the script as SYSTEM outside of a scheduled task and see what errors, if any, you're getting. This would help narrow down the problem. Scheduled tasks hide too much information when you're trying to debug an issue like this. I'd also recommend that you add verbose logging to trace what is going on and enable verbose output so you can see the messages.

Answer 3

Without any error checking in the script you're reduced to grasping at straws when it comes to figuring out what to change.

Add a Start-Transcript at the start of the script and a Stop-Transcript at the end of it.

If I had to guess at what the problem might be, I'd start with the permissions on the files/directories you're manipulating.