I think that the audit information is corrupted or missing. What can I do?

On the affected endpoint, perform the following steps:

Part 1: Initial troubleshooting

  1. Follow the steps outlined in the Agent Health Check tool topic to deploy the Agent Health Check tool, and review the results.
  2. Ensure that the version of the Microsoft .NET Framework installed on the endpoint is up to date and functional. Repair the installation if necessary. Refer to .NET repair Tool.
  3. Uninstall and reinstall the Datto RMM Agent. To learn more about this process, refer to Installing or uninstalling the Windows Agent, Installing or uninstalling the macOS Agent, and Installing or uninstalling the Linux Agent.
  4. Check the health of the endpoint's WMI Repository, and repair it if it is corrupted. See the Part 2: Discover if the WMI Repository is corrupted section of this article for more information.

Part 2: Discover if the WMI Repository is corrupted

The Datto RMM Agent imports information about an endpoint by querying the host device's Windows Management Instrumentation (WMI). Occasionally, the WMI can become corrupted and unreadable. This affects the audit information that the Datto RMM Agent can gather and send to the platform.

There are many ways to check for WMI corruption. This process focuses on evaluating parts of the WMI that the Agent uses to retrieve audit information.

To check if the WMI Repository is corrupted, run the below script in an administrator PowerShell session or as the script of a component:

"ComputerSystem","Baseboard","Bios" | % {
try {
gwmi win32_$_ -ea 1
} catch {
write-host "! WMI ERROR When polling Win32_$_."
write-host " Error details:"
$error | select *
}
}

Normal output will show a list of information about the device. If any of the following error messages are returned, then the WMI of your device is faulted, preventing the Datto RMM Agent from reading it's data: 

  • The interface is unknown
  • Invalid class
  • Invalid namespace \root\cimv2
  • Invalid namespace \root\default
  • Provider load failure
  • Specified cast is not valid
  • The specified module could not be found
  • Value does not fall within the expected range
  • The executable program that this service is configured to run in does not implement the service
  • The service did not respond to the start or control request in a timely fashion
  • Class not registered

If you see any of the above-listed error messages, proceed to the Attempt to fix the WMI Repository section of this article.

Part 3: Attempt to fix the WMI Repository

NOTE  While this article uses script commands, we do not recommend writing any of the contents below as components as some commands are interactive and rely on user input.

Method 1: Verify and restore the repository

Perform the following steps from an elevated command prompt to verify and restore the WMI:

  1. From the Windows Command Prompt, enter the following:
winmgmt /verifyrepository
  1. If you see any output other than WMI repository is consistent, run the following command to merge the readable content of the inconsistent repository into the rebuilt repository:
winmgmt /salvagerepository

NOTE  If the output is WMI repository is consistent but wmic and/or Get-CimInstance commands still return errors, continue on to use method 2 or method 3 to attempt a resolution.

Method 2: Re-register all DLL files and recompile .MOF files

  1. Run the following script to re-register all DLL files and recompile .MOF files in the C:\Windows\System32\Wbem folder on the endpoint.

    2. You can save this script as a .BAT file and run it locally on the endpoint, from an elevated Windows Command Prompt session, or from the Desktop as an Administrator. You can also run it from the remote Agent shell or deploy it via a component.

    @ECHO OFF
    sc config winmgmt start= auto
    reg add HKLM\SOFTWARE\Microsoft\Ole /v EnableDCOM /t REG_SZ /d "Y" /f
    reg add HKLM\SOFTWARE\Microsoft\Ole /v LegacyAuthenticationLevel /t REG_DWORD /d "2" /f
    reg add HKLM\SOFTWARE\Microsoft\Ole /v LegacyImpersonationLevel /t REG_DWORD /d "3" /f
    reg delete HKLM\SOFTWARE\Microsoft\Ole /v DefaultLaunchPermission /f
    reg delete HKLM\SOFTWARE\Microsoft\Ole /v MachineAccessRestriction /f
    reg delete HKLM\SOFTWARE\Microsoft\Ole /v MachineLaunchRestriction /f
    NET STOP SharedAccess
    NET STOP winmgmt
    CD %WINDIR%\System32\Wbem\Repository
    DEL /F /Q /S %WINDIR%\System32\Wbem\Repository\*.*
    CD %WINDIR%\system32\wbem
    REGSVR32 /s %WINDIR%\system32\scecli.dll
    REGSVR32 /s %WINDIR%\system32\userenv.dll
    MOFCOMP cimwin32.mof
    MOFCOMP cimwin32.mfl
    MOFCOMP rsop.mof
    MOFCOMP rsop.mfl
    FOR /f %%s IN ('DIR /b /s *.dll') DO REGSVR32 /s %%s
    FOR /f %%s IN ('DIR /b *.mof') DO MOFCOMP %%s
    FOR /f %%s IN ('DIR /b *.mfl') DO MOFCOMP %%s
    MOFCOMP exwmi.mof
    MOFCOMP -n:root\cimv2\applications\exchange wbemcons.mof
    MOFCOMP -n:root\cimv2\applications\exchange smtpcons.mof
    MOFCOMP exmgmt.mof
    rundll32 wbemupgd, UpgradeRepository
    NET STOP Cryptsvc
    DEL /F /Q /S %WINDIR%\System32\catroot2\*.*
    DEL /F /Q C:\WINDOWS\security\logs\*.log
    NET START Cryptsvc
    cd c:\windows\system32
    lodctr /R
    cd c:\windows\sysWOW64
    lodctr /R
    WINMGMT.EXE /RESYNCPERF
    msiexec /unregister
    msiexec /regserver
    REGSVR32 /s msi.dll
    NET START winmgmt
    NET START SharedAccess
  2. After running he script, restart the endpoint.
  3. Run an audit on the endpoint. To ensure a full audit, make sure that you do not select any other devices. Refer to Request Audit in Devices and Request Audit in Device summary.

Method 3: Rebuild the WMI Repository

If all other troubleshooting described in this article has failed to resolve the issue, you can perform the following procedure to rebuild your WMI repository.

Proceed with caution and at your own risk. Before attempting this process, review the following warning from Microsoft:

IMPORTANT  If you suspect WMI or repository corruption, rebuilding the repository is the last thing you should do. Deleting and rebuilding the repository can cause damage to the system or to installed applications. Other steps should be taken first to eliminate other possibilities or to confirm you have repository corruption. An extremely large repository also creates problems and can sometimes be interpreted as a corrupt repository, which is not always the case. If issues are due to a large repository, rebuilding it is currently the only method available to reduce its size.

If this process fails to re-add any .MOF files, some installed programs on your endpoint may stop working and require reinstallation. Consider your options carefully before continuing.

To rebuild your WMI, run the following commands from an elevated command prompt on the affected endpoint:

Net stop Winmgmt
Winmgmt.exe /standalonehost
Winmgmt.exe /resetrepository
Net start Winmgmt