This issue I think potentially can have several root causes: communication failure to ePO server from the client altogether or duplicate client entries (and you look at the wrong entry in the ePO tree while your servers generated their own new entries and they are appeared somewhere else in the tree due to IP or tag based sorting).
Troubleshooting the communication failure is easy, please look for the Agent local log whether it shows signs of the same. Also you could "wake up" the servers (from the entries that you think are theirs) from the ePO server and check the results in server.log (whether you get any reply or ePO can reach them at all).
You could then check the duplicates in the tree whether your servers have more than one entries and if those entries do have proper contact times (Last Update info).
1 of 1 people found this helpful
Use the option in ePO to "Move GUID to duplicate list and Delete System". Next time it checks in, it will have to regenerate its GUID. This should should resolve the problem.
Update yuor Agent extension.
Thank you all ...
@ Peter Simmons After we used this option " Move GUID to duplicate list and Delete System " . The epo console ll automatically list the machine in the console or we have to do something like reinstalling the client in the server ?
Try deleting the object out of the ePO console. Then while logged into the remote client, do a cmdagent. It will contact the ePO server, ePO will think it is a new machine and recreate the object. If you manually assigned tags, tasks, or policies you will need to reattach. I have found that this works about 20-30% of the time. It is about the 3rd or 4th thing I try after some of the stuff above.
It seems that some objects just get corrupted.
sorry to reply uninvoked. Please allow a few comments.
Generally it is most useful to get acquainted with the ePO server and client logs that are your friends in resolving problems. They are worded logically and can be interpreted easily. A duplicate system can be due to a number of ways, trying to resolve things to fix that is a result of such log lookup (beside KB search) and sharing the information.
For example if you set the server task to put the duplicate systems on a blacklist (which is actually a database table) and delete the system, you could as well open server.log in parallel and look for the actual name of the client and see what reaction ePO server did to that connection request when it performed that blacklisting action.
Also, for other reasons of connection failure it is most useful to open the agent logs on the server and take a look (for example after you woke up the ominous entry from ePO server) to see if the agent are contacted by the server at all. Or do a cmdagent.exe /p on the server and monitor the agent log what ePO server it tries to connect and whether it succeeds.
These are not hard things and will help you get out of the dark as far as resolving connection problems are concerned.
It is OK to try things recommended and they may work but then you never get so deep understanding of the system you are supposed to take care of, as you could have.