5 Replies Latest reply on Jan 4, 2011 2:13 AM by Namster

    Agent Handlers and Domain Membership

      I have a single ePO server managing agents for several organizations, each with their own Windows Domain.  My ePO server is not a member of any domain and agents get their updates exclusively via SPIPE/Agent-to-Server communication.

       

      Will there be any issue if I deploy AHs in each of the environments I manage, even though they are all different domains and the ePO server is in a workgroup?

       

      Thanks in advance!

       

      Charles

        • 1. Re: Agent Handlers and Domain Membership
          jstanley

          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.

          • 2. Re: Agent Handlers and Domain Membership

            Jeremy,

            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).

             

            Charles

            • 3. Re: Agent Handlers and Domain Membership
              jstanley

              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:

              ServerIPAddress=<IP Address>

               

              So for example if you needed to change the IP to 192.168.1.1 it would be:

              ServerIPAddress=192.168.1.1

              • 4. Re: Agent Handlers and Domain Membership

                Jeremy,

                 

                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.

                 

                Thanks Again,

                Charles

                • 5. Re: Agent Handlers and Domain Membership
                  Namster

                  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.