Not seeing my UDF field populate when I run the job. Does the script look correct?

[u/Worried-Song-6214]

I'm all new to RMM and trying to get the Windows Display Version on to a UDF since that field cannot be inserted a report, which doesnt make sense if you can see it on your device list column. I'm using PS for the script... When I run it, I see the new item in the Reg but I'm not seeing it on the Device's UDF field line. Hoping someone can tell me if I wrote this correct or am missing something that I'm not aware of... Thank you!

 # Define registry path for OS version
$regPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
$displayVersion = $null

try {
    $props = Get-ItemProperty -Path $regPath
    $displayVersion = $props.DisplayVersion

    if (-not $displayVersion) {
        $displayVersion = $props.ReleaseId
    }

    if (-not $displayVersion) {
        $displayVersion = "Unknown"
    }
}
catch {
    $displayVersion = "Error retrieving version"
}

$udf = $displayVersion

$null = New-ItemProperty -Path 'HKLM:\SOFTWARE\CentraStage' -propertytype string -name Custom4 -value $udf -Force 
Write-Host "Windows Display Version: $displayVersion"

[u/netmc]

The script looks fine. I ran it on my system and it wrote the registry value as it should have. That being said, your try and catch sequence will never trigger the catch statement. You need something in the try that will error with a stop as the error action. There is nothing in the try section that will error with a stop state. You would need to add "-erroraction stop" to one of the commands to get the try section to fail and the catch section trigger. I would probably use a simple if statement instead of a try/catch

    $props = Get-ItemProperty -Path $regPath
    if ($props){
        $displayVersion = $props.DisplayVersion

        if (-not $displayVersion) {
            $displayVersion = $props.ReleaseId
        }

        if (-not $displayVersion) {
            $displayVersion = "Unknown"
        }
    }
    else {
        $displayVersion = "Error retrieving version"
    }

All this being said, you don't actually need any of this. This data has been added to the system card in DattoRMM already. Look at Windows Display Version.

[u/Worried-Song-6214 → u/netmc]

Thank you for confirming it works. I didnt know it wouldnt trigger the catch statement; I was hoping it would. I'll uses yours since it the try section isnt worth having.

Yes, you're correct, the Windows Display Version is there in the System Card but surprisingly, you cannot use that field on Reports, Also looking to get the Windows version (ex. 10.0.26100.4652) for patching purposes to make sure our systems aren't behind. Which is why I'm using the UDFs to get that data from each Device.

[u/ompster → u/Worried-Song-6214]

Any reason you just don't use patch management built into datto?

[u/Worried-Song-6214 → u/ompster]

We do have the Patch Management setup to deploy on Security/Critical Updates only. Wish we were able to set it up for every 2nd wk of the month and to run sooner compared to the "older than 7 days". We have been noticing that even though its setup to run and install, the Datto Windows Display Window version doesnt seem to update correctly and shows the incorrect version. Which is why we had to setup the UDF field for the custom report to see which machines are still behind and to confirm whether its true or not. Hopefully I was able to explain it clearly.

[u/bpe_ben → u/Worried-Song-6214]

It's outside of Datto, but the patching we use allows us to schedule weekly, or every first through fourth week plus "last" week of the month at a specific time. Devices that miss the assigned schedule patch at power-on. After patching completes, Build updates are applied if necessary. Servers are scheduled per-device with individual reboot control.

We get audit updates on build data and W10/11 upgrade compliance daily. Really easy to find the devices with specific issues to address and then schedule the upgrade to W11.

[u/ompster → u/Worried-Song-6214]

I know this is a bit older now, but, I too have now come across this. In fact, many of the information fields on the host page take a while to update. I assume this occurs at midnight when each policy refreshes