Hey Jack! 
Thank you for pointing this out, I’m going to take this back internally and get some feedback on where this problem may be coming from. 

You may be hearing from a member of our customer support team and/or our agent team to get more details.
My take is those endpoints may have a corrupt repository

I suggest using these commands in a worklet to kick-start the WMI service by rebuilding the repository.
Which may allow the automox agent to re-populate the data correctly. 

 

net stop winmgmt

winmgmt /salvagerepository

net start winmgmt

Tried those steps remotely and wasn’t able to get it to work. Might have to see about remote control so I can run the commands locally and give that a go. Thanks for the suggestion!

Follow-up. The strategy when this happens includes backing up WMI and rebuilding WMI with a batch script, then restoring from a backup. Each use case was slightly different and this was done manually on each device. In some cases, the WMI backup steps were skipped completely. In other cases backing up the MOFs and restoring those kept some unique applications working as intended. 

Here is the WMI.bat script

@echo on

if not exist "c:\temp" md "c:\temp"
cd /d c:\temp

if not exist %windir%\system32\wbem goto TryInstall

cd /d %windir%\system32\wbem
net stop winmgmt /y
winmgmt /kill

if exist Rep_bak rd Rep_bak /s /q
rename Repository Rep_bak

for %%i in (*.dll) do RegSvr32 -s %%i
for %%i in (*.exe) do call :FixSrv %%i
for %%i in (*.mof,*.mfl) do Mofcomp %%i

net start winmgmt

goto End

:FixSrv
if /I (%1) == (wbemcntl.exe) goto SkipSrv
if /I (%1) == (wbemtest.exe) goto SkipSrv
if /I (%1) == (mofcomp.exe) goto SkipSrv
if /I (%1) == (WMIC.exe) goto SKipSrv
if /I (%1) == (WinMgmt.exe) goto SKipSrv
%1 /Regserver

:SkipSrv
goto End

:TryInstall
if not exist wmicore.exe goto End
wmicore /s
net start winmgmt

:End

Automox Support, @Bryan.York, helped with a solid process to backup WMI and any MOF exports necessary to ensure a smooth transition.

Backup WMI Repository:

1. Open an elevated PowerShell window. (Run as Administrator)
2. Run wbemtest.
3. Click "Connect," enter root in the "Namespace" field, and click "Connect" again.
4. Click "Backup/Restore."
5. In the "Repository backup" section, click "Backup" and specify a backup location.
6. This action creates a backup of the WMI repository, including MOF class definitions and relationships.
7. In order to Restore that backup:
8. In the "Repository backup" section, click "Restore" and browse to the location of your WMI repository backup. Select the backup file and click "Open" to initiate the restoration process.
9. Follow the prompts to complete the restoration.

 
Export MOF Definitions:

1. Open an elevated PowerShell window. (Run as Administrator)
2. Run the command: mofcomp C:\Path\To\Your\MOF\File.mof (changing the filepath and name to something of your choosing) to compile and register MOF definitions with WMI.
3. In order to Import those definitions
4. You should be able to simply re-run the previous mofcomp command. When you run that command with a filepath to a MOF file that is not present it will create one, when you run the command and there is already a MOF file at that location, it should import it rather than overwrite it.

 
By following these steps, you should be able to safeguard your WMI configurations and MOF definitions, reducing the risk of application disruptions and enabling a swift recovery in case of issues. I do not, however, know if this would carry over those corruptions after the rebuild so the method would need to be tested as well. Do let me know if that process works.