Entries in Audit log with the action stating "ASCI - Non-matching GUID"

[JePO1]

In the ePO audit log, I can see several machines that have entries with an action of "ASCI - Non-matching GUID". What kind of actions besides a reinstall of the agent would cause this? Some of these state "Match by Computer Name" or "Matched by MAC Address". I'm assuming changes to the computer name or MAC will also cause a GUID mismatch during ASCI, but I don't see a lot of documentation on this. Is there anything that needs to be done to address these, or can these result in any issues? I already have server tasks running that remove systems with duplicate GUIDs and clear the GUID error count.

[cdinet · Accepted solution]

Non matching guid means that the guid on the client is changing.  That can happen with forceinstalls and clearing systems with duplicate guids and there was also some lower versions of agents that had issue with the system uuid changing and new guid would be generated.  We have seen forceinstalls happen where customer was unaware of a login script or sccm deployment, for example, that was pushing agent with forceinstalls.  Automatic responses or server tasks should also be checked to make sure there are no forceinstalls going on.  One thing you can check for that is to check frminst logs on the clients that are showing that.  Do you see reinstalls happening?  It will show the command line, whether it includes forceinstall or not.  Additionally, if a non-persistent vm is installed with the agent in vdi mode and the system is not shut down properly to be deprovisioned as it should, that will also create a new guid.  

[JePO1]

@cdinet Thanks for the prompt response. This was very helpful. We actually were looking into a particular machine b/c the Agent and Endpoint Security were unexpectedly installed on it. While looking into the issue I found an instance of "ASCI - Non-matching GUID" for the same machine which led me to ask the question. 

There were errors in the frminst logs indicating that a downgrade could not be performed without the /forceinstall switch. I'll have to hunt around and see if there is a deployment task or client task that may be causing this. 

[Hem]

If there is MA reinstall then when client machines communicates, it will Invoke client task if scheduled to run "Run Immediately".