hosts disappear from EPO

[afrolkin]

Hello, Issue in problem summary - after connection some of hosts disappears or not appears after fist connect in EPO. ePO Build: ePolicy Orchestrator 5.10.0 (Build 2408) Update Installed: Update 4 (2.0.0.448) MER from agent at attach. After checking and connecting computer to network host appears and no further problem. first connect was via ethernet cable (not VPN). After connecting this PC type (notebooks) added in special group, in which autoremoving old host is disabled. In logs host connected to EPO: 2019-09-28 18:46:56.103 masvc(4788.5824) ahclient.Info: Network library rc = <1008>, Agent handler reports response code <200>.

[LKS]

Hi afrolkin,

You mean to say once you install Agent then it connects to EPO without any issue and showing as Managed in EPO system tree and then disappeared. You can see in Audit Log to see why the machine got disappeared. Also check if the disappeared machine MAC address has duplicated to any other client machine.

When an agent communicates with the ePO server, the server first checks whether the agent's GUID exists in the database:

• If the agent's GUID exists, ePO already knows this system and does not need to add it to the database again.
• If the agent's GUID does not exist, this computer is either new, or the GUID has been changed. For example, it changed during a complete reinstallation of the agent.

To differentiate between these cases when the GUID is unknown, the server performs another step and checks whether the MAC address is already known. If it is, the ePO server assumes that the computer's GUID changed, and associates the new GUID with the database entry that contains the matching MAC address. But, this causes problems when multiple computers legitimately have the same MAC address, for example, in a Network Load Balancing scenario, or with teamed NICs.

In this situation, the first node to communicate will be added to the database correctly. But, when the second node communicates, its properties will replace those of the first node because it has a new GUID, but the same MAC address. When the first node communicates again, its properties will replace those of the second node, and so on. The end result is that only one node displays in ePO at any one time.

Secondly i do not understand this part "After connecting this PC type (notebooks) added in special group, in which autoremoving old host is disabled."

Was my reply helpful?

If you find this post useful, please give it a Kudos! Also, please don't forget to select "Accept as a Solution" if this reply resolves your query!

[afrolkin]

Thank You LKS.
>>i do not understand this part "After connecting this PC type (notebooks) added in special group
I have task to removing inactive systems, but only not added in notebooks group - I wanted to say that disappeared systems doesn't removed automatically.
I found in Audit Log ASCI events - Inappropriate GUIDs and name of system, which disappeared. But only this event. There is no event of removing system with this GUID.
In the system tree there is no System with this GUID.

[cdinet]

If they are disappearing after connecting via vpn, then check kb52949.  ePO 5.10 has a section in server settings to remediate those systems rather than modifying the database directly.

[afrolkin]

No, as I wrote at topic description, first connect was via default ethernet link

[cdinet]

I understand the initial connection, but my question is, when they disappear, are they connecting via vpn?  You can also watch the server log closely on the epo server or agent handler that one of the disappearing systems is talking to for any changes.  You might see that in the server log.  

Also - I found in Audit Log ASCI events - Inappropriate GUIDs and name of system

What specifically did you see regarding inappropriate guid?  What is the exact message (leaving out system name)?

[afrolkin]

>>are they connecting via vpn?
No, they are installed and not used.
>>What specifically did you see regarding inappropriate guid?
I translated event via google because it is on Russian
Compliance according to "MAC address only", GUID: "CCC891B4-E22E-11E9-3800-000000000000", name: "notebookname", MAC address: "3C18A011A505", domain: "companydomain", platform: "Windows 10:10: 0: 0, "1" is permitted
Original event:
Соответствие по "MAC address only", GUID: "CCC891B4-E22E-11E9-3800-000000000000", имя: "notebookname", MAC-адрес: "3C18A011A505", домен: "companydomain", платформа: "Windows 10:10:0:0", разрешается "1"

Also, in parameters "Matching Detected Systems" and "Matching Managed Systems" selected both MAC and Hostname checkboxes.

[cdinet]

If you delete the system and let it check back in, does it get removed again?  If so, put the server in loglevel 8 logging and log size 100 so we can capture that in the server logs.  KB56207

You should see the system checking in and when it gets removed from epo, you might see something possibly changed on the system to cause it. 

Check also the server task log to see if there is possibly anything contributing to the issue.  

[rgc]

Additional to Caryn,

Get some data for the same system, when the issue persist and details as below.

Go to system tree click on MY ORG - This group and all sub groups and add AgentGUID & MAC columns and export the data through .XLS/CSV format for all clients and get it

Go to audit log and search with the problem system and under Preset: Set NO filter and search and get the complete results from the day one what are the activities for this problem system.

These two with client MER will be helpful to understand the source of the problem.

Either it could be a server task running for inactive / duplicate systems to delete hourly which leading to get deleted and not removing the Agent and adding back through ASCI

OR

May be machine with same MAC from more than two systems, which is overwriting one to another, by every ASCI  [default -60min], which leading to show one entry out of two clients in ePO could be one more cause

If you have AD sync configured and enabled the delete option with Leave systems in sync group enabled.... and if the system moved from one to another OU in AD, this will impact to get system removed here and got added by next ASCI and reported under Lost & found group.


SO, we need to find what would be causing this issue briefly through the data collected as suggested.

[cdinet]

Just be sure to not post that data to this public forum, as it would contain sensitive company information.  Please open a ticket so we can help investigate this with that data.