I have a SCOM task running a powershell script that lists the largest folders on a disk.
Most of the time it runs great but sometimes I get an error:
The SCOM task failed with error code -2130771868
I believe this has to do with the Task time-outs.
I clocked it on a server having an issue.
Running the SCOM task it takes about 90 sec before I get the error.
Running the same script directly on the server takes about 200 sec and then a result is produced.
The timeout value for the task is set to 300 sec
So somehow the task ignores the Timeoutvalue? Or something else is wrong 
Any ideas?
For debugging PowerShell I absolutely love transcript logging.
Typically I include an overridable property or look for a Registry key on the host, if true it does logging and sends it to a defined folder ($Env:Temp if I’m being lazy). I’ll also then set $VerbosePreference to ‘continue’ and scatter Write-Verbose about the script to let me know what is going on. If you’re getting errors you’ll capture them, if you crash out you get a rough idea what completed successfully, so on.
If you capture an error then you’ve got an answer. If not then yeah maybe you’re onto something with the timeout. Maybe you can pass the timeout into the script purely to spit out the value using Write-Verbose?
Enabled logging and I found out that the script just seems to stop running after a bunch of access denied errors.
(The error occurs on C: drives but works on all other drives, at least those I have tested)
The last line is the end of the logfile. It just cuts off.
Here is the script (without logging)
param(
[string]$DeviceID
)
$DeviceID = $DeviceID +’’
$allFolders = Get-ChildItem -Literalpath $DeviceID -Directory -Force
#Create array to store folder objects found with size info.
[System.Collections.ArrayList]$folderList = @()
#Go through each folder in the base path.
ForEach ($folder in $allFolders) {
#Clear out the variables used in the loop.
$fullPath = $null
$folderObject = $null
$folderSize = $null
$folderSizeInMB = $null
$folderSizeInGB = $null
$folderBaseName = $null
#Store the full path to the folder and its name in separate variables
$fullPath = $folder.FullName
$folderBaseName = $folder.BaseName
$folderLastWrite = $folder.LastWriteTime
#Get timeago
$timeago = ((Get-Date) - $folderLastWrite)
$timeagomin = [math]::Round($timeago.Minutes)
#Write-Verbose "Working with [$fullPath]..."
#Get folder info / sizes
$folderSize = Get-Childitem -Path $fullPath -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum -ErrorAction SilentlyContinue
#We use the string format operator here to show only 2 decimals, and do some PS Math.
$folderSizeInMB = "{0:N0}" -f ($folderSize.Sum / 1MB)
$folderSizeInGB = "{0:N2}" -f ($folderSize.Sum / 1GB)
#Here we create a custom object that we'll add to the array
$folderObject = [PSCustomObject]@{
Path = $fullPath
#FolderName = $folderBaseName
'Size(Bytes)' = $folderSize.Sum
#'Size(MB)' = $folderSizeInMB
'Size(GB)' = $folderSizeInGB
#LastwriteTime = $folderLastWrite
TimeAgoMinutes = $timeagomin
}
#Add the object to the array
$folderList.Add($folderObject) | Out-Null
}
#Return the object array with the objects selected in the order specified.
$folderList | sort-object ‘Size(Bytes)’ -Descending | select -First 20 | ConvertTo-Json
I know that Get-ChildItem with the -force parameter can pick up some wierd things. Might be that that particular user has something funky in their profile or something like that.
For immediate first steps I’d probably change the line (I haven’t counted the line numbers but I assume that this is where the error is)
$folderSize = Get-Childitem -Path $fullPath -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum -ErrorAction SilentlyContinue
Split it out into chunks each with try catches.
Try Get-ChildItem
$Length = Foreach item in Folders
Try get length
You then have options for error handling. For example something like:
Catch { If ($_.CategoryInfo.Category -eq 'PermissionDenied') { Write-Warning "Some sort of permissions error happened at $($_.CategoryInfo.TargetName)" Write-Verbose (Get-ACL $_.CategoryInfo.TargetName | Out-String) } Else { Throw $_ } }
Difficult to tell because of the formatting but my guess is that the Measure-Object is trying to do maths on a null and bombing out because of the access denied. So catching the access denied to keep the nulls out of your array or adding a loop instead of using the pipeline on the returned items so that you can do some validation is where I suspect you’ll need to go (and/or deal with those permissions issues).
Solved it with some error handling inspired by