It depends on the agent version in use. MA 4.5 and earlier used a bitmask calculation to determine the difference between subnets: MA 4.6 and later use count the hops to the target. The first method didn't generate any ping traffic, but (assuming you wanted machines to find the closest repository) relied on your subnet structure matching the physical world: the second method gives more "realistic" results at the price of some extra ping traffic when the agents are calculating.
Would firewall and ICMP blocking over a WAN interfere with the Subnet "hop" count in 4.6?
Thanks for the answer. So I should only see machines with an agent 4.5 that are connecting to the wrong FTP repository.
In our environment we still have a mix of 4..5 and 4.6 agents so your explanation makes sence.
Can this please be communicated to the people writing EPO documentation and also to the EPO specialists at the calldesk.
I created yesterday a case but I got a very vage answer about something with ping very similar like the 'ping' option. I also refered to the strange explanation in de EPO documentation but also that looked like the firt time they heard about it.
Certainly many thanks for the quick respons and I will check it here.
PS maybe I should just stop creating cases and just poste it here ;-)
Absolutely, yes. I'm not sure exactly what the result would be but I suspect it would lead to the agent flagging a repository as unreachable. (This is true for both versions of the agent.)
No problem - hopefully that clarifies things
I think the reason for the confusion is that the behaviour was changed in MA 4.6, which had not been released when ePO 4.6 shipped - so the ePO documentation correctly refers to the MA 4.5 behaviour, which is the MA version that was included with ePO 4.6. (For reference, if you check out the MA 4.6 Product Guide, the various methods for choosing a repository are described in there.)
One final point though - it must be understood that neither ping time nor subnet distance are foolproof methods for choosing the "right" repository. If it is critical to you that machines only talk to a specific repository, then the only way to guarantee this is to use the user-defined list option and configure the repository list accordingly.
I requested FW traffic logging for some sites so I'll check it.
In our situation clients bypasses NAS devices with an up-time of 99.999 and if they are not responding this would have been noticed.
It certainly must have some other cause that clients are connecting to different locations.
Your explanation about the old and new agent makes sence. I'll let you know if this matches our FW logging.
The FW logging is showing machines with EPO 4.6.02292 that connect to a repository that is not the closest (number of HOPS).
Hop count to central server is 6
Hop count to decentral server is 9
EPO 4.6 agent doesn't solve my issue
What do the agent and mcscript log show when the agent is calculating the distance?
If I look at the logging I have the feeling that the election itself is an FTP connection.
This could explain why I see FTP connections to decentral sites.
2012-07-19 08:25:58 E #2720 imsite Error trace:
2012-07-19 08:25:58 E #2720 Thread [Main thread]->
2012-07-19 08:25:58 E #2720 SessMgr [initializeScript]->
2012-07-19 08:25:58 E #2720 creposi [setNextRepositoryToUse]->
2012-07-19 08:25:58 E #2720 creposi [Candidate xxxxxxx (10.xxx.xxx.xxx): testing]->
2012-07-19 08:25:58 E #2720 creposi [downloadFile,SiteStat.xml,C:\Windows\TEMP]->
2012-07-19 08:25:58 E #2720 imsite [downloadFile,SiteStat.xml,,C:\Windows\TEMP,1]->