You can certainly deploy agent handlers in each domain but I'm not sure it would resolve any issues for you. If bandwidth is the concern then distributed repositories would be the solution as agent handlers will not really save you any bandwidth (the agent handler receives the properties package from the clients but it still has to forward that information back to the EPO SQL DB).
Here are the two primary reasons to use an agent handler:
1- You are managing a very large number of clients with EPO (exact number depends on what products you are managing and how powerful your epo server is but lets say over 80,000)
2- You have clients on external networks that cannot connect directly to the EPO server (maybe home machines that you want to manage with EPO so you put an agent handler in your DMZ)
If you don't meet one of the above criteria I would not setup any agent handlers.
First, thanks for your excellent support in the past.
Second, the remote networks we manage Agents on are not routable from the ePO server, thus our Agent Handlers are dual-homed: 1 interface is reachable by ePO, 1 interface is reachable by clients.
Today, we are taking advantage of the configuration options in the "Handler List" screen, where the "Published" information reflects what our remote Agents need to see in the SiteList.xml (the Handler Assignment Rules tying a particular handler to particular subnets) and the "Handler IP" being the IP ePO needs to see to send SPIPE info to the apache service on the AH. It really is the real IP/published IP Agent Handler settings in ePO that allow us to do this, which is why using Repositories is not possible. I know this was intended to use for Agents that are managed through a NAT, though it is working for us today.
Additionally, since we manage Agents in multiple forests, having Agent Handlers that are domain members allows us to push Agents to hosts without the need of system management software (SCCM, Radia, BigFix, etc).
The published IP address is only for use by agents. So if you need to supply an IP Address for agents to connect to that is not the actuall IP address of the agent handler (maybe a public facing router with a port forward rule for example) that is what you would use for the "Published IP Address". If however you need to specify an IP address for EPO to use to connect to the agent handler then you need to edit the server.ini file on the agent handler and add the following line:
So for example if you needed to change the IP to 192.168.1.1 it would be:
That is exactly what we did. Modifying the server.ini on the Agent Handler caused EPORegisteredApacheServers to update with the IP from the interface you want to have ePO
connect to. This allowed the ePO server to send the mastercatalogchanged and flushcache SPIPE messages to the proper IP on the Agent Handler. Without this, the ePO server was trying to send SPIPE messages to an IP on our dedicated Backup Network, which of course is a network dedicated to backup and restore traffic and therefore ePO has no route to it.
Well, hopefully I'm not waay off base but.
Let's start simple first.
Dual homed ePO server, public nic and private nic, no AH. ASCI will try IP, netbios, FQDN.. in some order you'll find in a KB. If the clients on the private network can't reach the ePO server on the naturalyl published IP address as indicated in the server.ini, the clients will eventually get to the ePO server and get it's updates.
Now with that working these private clients should still get the sitelist.xml and direction to traverse to a certain AH. Put the AH on the private network and the clients will first goto ePO and then to their designated AH. The clients will need to get this instruction from ePO first, so a connection to ePO might be required.
As for getting the clients there, on the private network, either DNS or host file point the private clients to the private NIC of the ePO server.
ePO and AH can work without domain membership, domain independant. BUT, if the AH and ePO aren't part of the same domain, sometimes changing it's password is difficult. So perhaps, don't expire the password for the AH to ePO connection.