1 of 1 people found this helpful
such as how did you deploy the agents if ePO doesn't have access to the remote workstations, and the remote workstations don't have access to the ePO server?
the agent handler will house the agent install package, and from the handler the package gets sent to the local systems for install.
when you do the agent deployment, there is an option to choose which handler to deploy from(assuming the dmz handler is all setup and working).
1 of 1 people found this helpful
I maybe able to help you on this one..
Before you begin you should be using the MA 4.5 agent, as it has the ability to use more than ONE SPIPE server (epo server / agent handlers). Using the older 4.X agents is a lot more difficult to explain and use as it only allows one SPIPE ID.
First off make sure that the AH (Agent Handler) has Bi-directional communication to the "Console-to-Application server communication port", and Bi-Directional Communication to the SQL server Port. You should be able to create specific Firewall rules to only allow these ports to and from the ePO server.
Second, once you install the Agent Handler, and it registers it self under the Agent Handler Addin of the ePO Console, you will need to Enable Authorization of the Handler. (open the epo console | Menu | configuration | Agent Handlers | Inactive Handlers | enable)
Third, Now that your Agent handler is up and running you need to point machines to the use that Agent Handler. In the epo console | Menu | configuration | Agent Handlers | Handler Assignment Rules | New Assignment | Create Assignment Name | Add Tree Locations - Set the IP range of the DMZ and/OR Set the group of machines that you are using in the DMZ (assuming you have setup this Group) | Handler Priority - Only set the one Handler List. | Save
Fourth, Deploy the Mcafee Agent to these machines. (there are several ways to do this, login script, sms, etc.)
If you are using the MA 4.5 agent, and are installing Clean (for the first time, or no previous agent) the sitelist will have both the epo server and the Agent Handler in the sitelist.xml. This is good, as if they return from the dmz they still work.
NOTE: if you are upgrading the 3.x or 4.0.x agents to 4.5, it WILL NOT put both the EPO Server and AH in the sitelist.xml. This is because the upgrade script doesn't replace the sitelist (we have an internal bug on this, and hope to get it fixed in a future patch release of the agent). So if you are wanting to upgrade the agent, I recommend a FORCEINSTALL switch be used, or a Removal of the old agent first and then a clean install of the MA 4.5 agent.
Let me add ...
When you install the agent handler, we use the credentials you give us in the installer to connect to the app server via the console port (8443 by default). This gives us a secure connection over which we request generation and download an AH specific certificate. Future communication between the AH and the app server uses the client auth port (8444 by default). So make sure that the client auth port is enabled as well. I believe after the install is completed, there is no need to keep the console port open.
Also, the AH will automatically proxy agent requests for software from the "real" master repository located on the primary server, so if there's ever a chance of agents falling back to the master repository, you'll need to have port 80 open too (or whatever you've configured that port to be).
Hope that helps.
Is there a reason why:
"irst off make sure that the AH (Agent Handler) has Bi-directional communication to the "Console-to-Application server communication port", and Bi-Directional Communication to the SQL server Port."
Surely the SQL channel is an uneccessary security risk, and the comms should instead be piped through the Console-to-Applicaiton server port (and encrypted) or go through some other encrypted channel.
Or am I misunderstanding things?
Running the comms via the ePO server would reintroduce the bottleneck that the agent handlers are designed to alleviate
ePO can use SSL comms to the SQL server - this is configured on the DB connection page (the core/config page.)
The SQL server can't originate the db connections, unfortunately. And the primary goal of multiple AHs is for scalability. An ancillary benefit now that you can have multiples of them is that you can stick one of them out in the DMZ, but it does need to be able to communicate with the sql server and the app server.
We've just set up an agent handler in a DMZ. Connections between AH and EPO are working, and direct communication from DMZ agents to the EPO server is not allowed.
We are experiencing an "interesting" situation, where:
- Agents are deployed to DMZ machines by script (i.e. framepkg.exe /install=agent etc...). Both agent handler and EPO server are in the sitelist.
- Agents contact the agent handler.
- A new sitelist is downloaded, that contains only the EPO server.
- The agent is effectively lost.
Any ideas? The order of the assignment rules are:
1. \My org\SITE\ <----- EPO server
2. \My org\SITE\DMZ <------ Agent handler
3. \My org\ <------ Use all agent handlers
The machine is in the DMZ group.
The rules are prioritized, and the first rule that matches (\org\site) is winning, giving you only the epo server.
Move rule #2 above #1 and it should work.
Hi Ryan, I've been upgrading all my 3.6.0 agents to agent 4.5 to connect to a new ePO 4.5 server using command > framepkg.exe /install=agent /s. When I look at the Sitelist.xml file on a few workstations I do see my Agent Handlers listed (they are listed as SpipeSite Type:master same as the epo server). You mentioned that there is a bug with the 4.5 agent when upgrading but from want I see my agent handlers are listed. Should I be concerned that I might have a large number of upgraded clients that are not using my Agent Handler servers? When is the 4.5 patch 1 scheduled for release? Will it fix all existing issues and put the agent handlers in the sitelist.xml file when I deploy agent Patch1?
I also see a lot of error 57's in the agent logs on Windows 2008 servers, hopefully the patch will be fixing this error as well. Thanks in advance, look forward to your reply.