This content has been marked as final. Show 17 replies
I would just use one ePO server but it really depends on how many machines you plan on managing.
1) Just use one master and put a distributed repository at the other data center.
2) This depends on bandwidth if you have 5-10mb pipes I would recommend distributed repositories, but if you have a like 1 gig pipes you should not need any.
3) Yes you can configure a static list of which repositories they can use or have it choose by ping time, subnet, etc.
BTW i would suggest waiting till Patch 1 comes out for ePO 4.0 this month before implementing.
Just to clarify (mvasquez already posted the answer):
2. Do we actually need Distributed repository's or as these purely available for limited bandwidth networks?
-> this mainly depends on the client number and which software you will deploy
3. Can we configure roaming laptops to connect to the master repository based on the site they are at?
-> Roaming between "Master repositories" would mean roaming between two ePO servers which is currently not possible. But as mvasquez already said use a distributed repository there (not a second epo server). Be sure that all clients from that site can also communicate with your ePO server so that they get tasks and policies.
Tom\Mvasquez thanks for the swift replies.
I am closer to now having an ideas in my head about the best deisgn for our infrastructure however, I thought I would provide additional information (which I should have put in my original post) to give you guys a clearer picture.
Two Primary sites and 2 servers, one in each site and positioned in the DMZ
We have a 2GB High Speed WAN between these sites
We have a number of satellite sites with 10\15MB connections
We have 200 Client Laptops, the majority of which (95%) are at the Primary Sites
We are looking to implement, McAfee Total Protection for Enterprise - The client portions being installed include, HIPS, AV, Antispyware.
Am I right in thinking then that the 'best practise design' would therefore be to have a Master repository, ePO Server at one of these sites and a Distribution Server at the other (possibly a superagent distributed policy?)
I am still unsure about how clients would obtain DAT file updates etc? Would clients connect to the Master server when they are at that site and clients in the other site connect to the distribution repository?
I would go with one distributed repository and one master server. A superagent repository is the easiest way to configure if you have a Windows server at this site.
> I am still unsure about how clients would obtain DAT file updates etc? Would clients connect to the Master
> server when they are at that site and clients in the other site connect to the distribution repository?
This is all configurable and changeable via the McAfee Agent policies. The standard setting for the agent is to choose a repository via Ping-time which means in your case it will choose the fastest replying repository (master or dirstributed). For laptops changing between these two sites, they will also change the update repository.
But always keep in mind that all systems must have a connection to the epo server (agent communication port) to get policies and tasks. Only software updates (like DATs, products, patches etc.) will be downloaded from distributed repositories.
Thanks again. After a dissapointing start with McAFee trying to get information for the design phase of this project you are quickly redeeming that.
I am now going with the suggested design of one ePO server and one superagent repository. I have read that after you have the ePO agent on your designated repositoy server you then convert this to a superagent and it automatically creates folders etc.
Do managed clients then simply connect to this share to get updates? And if they have to connect through a FW to get to this share (Which in our case will reside on a Windows 2003 server) is it a case of opening up 445 for SMB over TCP? Is there any additional security that needs to be in place?
The SA Repository is created through setting a special McAfee agent policy for this server.
Regarding security, the clients do not need any UNC/NetBIOS ports.
For your setup you need the following firewall settings:
ePO Server -> ePO SA Repository : Agent-WakeupCall and Agent-Broadcast port (this is needed for replication)
Alle ePO Agents -> ePO Server : Agent Communication port
The ports are set when installing.
Your clients will update from your ePO SA Repository simply through the TCP/IP port you set for your Agent-WakeupCall port.
This has been a great help. I am very likley to increase my post count when we start to deploy and configure the solution:)
Just looking for clarification on this one due my below par skills on 'networking'
In my proposed design I will have one ePO master at one site and a distributed repository acting as a superagent at another. These are different physical sites and are also different subnets and both will have manged endpoints. We also have a number of other remote physical sites and subnets that will also have managed endpoints (and indeed VPN clients)
The area that concerns me is the bullet point requirement in the documentation that states 'a superagent is installed on each broadcast segment'.
Tom replied saying that..
"Your clients will update from your ePO SA Repository simply through the TCP/IP port you set for your Agent-WakeupCall port"
Does these therfore mean that clients on different network segments will be able to recieve the wake up calls? (I presume as long as the designated ports are open between routers it should work?)
Hi again :-)
a superagent is generally needed on every ip subnet if you want "global updating" to spread through all your subnets. Global updating must be activated server wide (a global update will run e.g. if a new DAT file arrives in your master repository). It is an immediate update wakeup call for all clients (before that the epo server will immediately replicate to all configured distributed reps).
After getting a global update call the client will then update from there nearest repository. So if you do not activate global updating there is no need to have a SA agent at every subnet.
If you use global updating be sure to also configure regular client update tasks as the global updating will not work for clients which are switched off when a global update is issued.