We had a case with many computers in an environment reporting Software Update installation but very low compliance for the February / March updates.
From a few screenshots provided by the customer it looked like the machine install succeeded, yet the inventory rule did not pick up these details. So we had a remote session to take a close look at it.
The agent logs showed the update as ready, not installed and the update cycle went on without any issues. We tried to restart the Altiris Agent (to kick off the InventoryRule process) with my favorite command line ("sc stop aexnsclient"). This did not work, with a file not found error. So I went to the "windows\system32" folder to run the service controller directly there.
The agent was thus restarted and the Inventory Rules came up showing all newly installed updates (all returned a success code of 0) as 'IsInstalled = false'.
We turned the InventoryRule Agent and Altiris Agent logging to verbose, and we could from the log viewer (we connected from the server to the workstation c$ share) the inventory rule information coming up and failing.
Seeing the rule details I noted that many of the path checks used environment variables, namely '%windir%'. A quick check in the cmd environment showed a very odd situation: the path variable was not set, but nor were any of the system variables such a %windidr%.
We added the %windir% path to the "Computer properties > Advanced >Environment Variables > System variables" and after a restart of the Altiris Agent about half of the updates on the last cycle came up as installed.
Conclusion: some weird stuff can happen on computers, detected in some ways by the end point management agent, even if the issue in itself had nothing to do with our product or agent.