Audit Issues: Device Not Auditing

1. Understand how Audits work. It collects its info from WMI on the device and sends it to the platform, while also saving a copy of what it found in auditsnapshot.xml in ProgramData
2. Check log.txt - FIRST, BEFORE THE HEALTCHECK! Find the audit activity using the keyword "audit" and if you can't find it, request a new audit it and note the time, so you can go to that part of the log. Audit errors are often pretty explicit and helpful if it fails
   1. If you see a log error like the below, it likely means the info collected from the registry related to installed software had characters that are not part of the standard unicode character set, so the XML document couldn't be created 
      |ERROR|18|AuditHandler: Audit failed|{ "exception": {"Message":"There was an error generating the XML document.",
      1. If this is the case, now we can run the healthcheck to use the section that checks for invalid unicode to identify where the foreign characters are coming from. We can then share the characters found and their locations with the partner to see how they want to address it. If they don't need the program that has foreign characters in the registry, they can uninstall it or change the registry to remove the foreign characters (they should proceed with caution if opting to change the registry)
         1. Note "TurboMeeting" is a common offender when it comes to invalid characters in their registry entries that break audit
      2. Once the foreign characters are no longer in the registry, the device should be able to audit properly.
   2. If you see an error like the following, it points to a different issue, where info couldn't be collected from WMI
      4.4.10062.10062|2025-08-27T00:01:32.482-04|ERROR|13|Audit: Failed to get LastBootUpTime from "Win32_OperatingSystem" WMI class|{ "exception": {"ErrorCode":"NotFound", "Message":"Not found ",
      1. Usually the problem here is that the WMI on the device isn't working properly and not presenting the info we're trying to collect.
      2. This article lists out commands you can use to directly check WMI and confirm if the info is being presented or not, but if it is different info failing to present, you can just use google/chat GPT to see what commands can be used to pull WMI info for the given info set
         https://internal-kb.datto.com/rmm/Content/rmm/KB370000002131.html?Highlight=audit%20batch%20powershell
      3. If we do pin down the audit failure cause as related to broken WMI, this would be environmental and we can start encouraging them to solve this locally on their end
      4. That said, you/they can also use the healthcheck WMI check option to run a WMI repair. If you respond yes to "attempt to repair WMI", it may solve the issue, but if individual commands show WMI is still unable to present desired info, it becomes environmental and their responsibility to troubleshoot
      5. These commands also can repair WMI and are worth a shot if you have the partner do this or ask for permission to run them with the partner:
         cd %windir%\system32\wbem

for /f %s in ('dir /b *.mof') do mofcomp %s

3. If you don't see an audit error in the log, but never see it complete and send to the platform (auditsnapshot.xml might also not be created), what could be happening is there is more data to collect via WMI or registry than expected, and the collect process stalls or never completes
   1. In this case, you'll want to get log.txt into debug mode, which will list out all the different types of data it will collect. The last one you see is typically the one that has a lot of data, so this can be helpful in determining what data is large that it's stuck on
   2. Additionally, a WMI repair or commands above may again be helpful here as it may clean up the data we're struggling to receive.
   3. It may also be worth checking device resources if the audit process seems to max out CPU or RAM at time of audit.
4. It's also possible the info can be collected and parsed to xml successfully, but the platform fails to publish it. This is rare, but in this scenario we would see the audit appear to be sent successfully in the log, and auditsnapshot.xml was generated successfully with a recent date modified in ProgramData. If this seems to be the case, you can check Kibana using the device ID around the time of when the audit was sent to see if the platform got the message or not
   1. If all looks okay, but the info isn't posting, what could be happening is the info received has longer info fields than the platform is expecting. Two times I've seen this happen is when a device had an uncommonly high amount of mac addresses found (more than the platform could handle), and another time when one of the collected software that was found in the registry had a whole paragraph of junk in the "display version" field, which was well longer than the number string we expected. In both cases, a problem case needed to be made in order to handle the unexpectedly long data more gracefully. Send to L2 for additional review if this appears to be the case