here comes the scenario: there is more than one site with thousands of end-points, historically those sites rely on different AD back-ends having different management and administration. Site covers one or more states and links between sites (about 100mbps, shaping possible) are shared between number of applications. Centralized ePO is used in one and ePO is also chosen for other sites. Number of McAfee security agents are deployed.
What could be the deployment for consolidated ePO infrastructure? It there any good practice/advice/white-paper for multi-site deployments?
As to shown analysis separate sub-trees within ePO system tree with own set of policies and proper authority delegation can be used to describe sites and allow their co-existance within one ePO.
But what about performance/scalability? Availability?
Should remote agent handlers be used for the non-ePO sites? What are then network bandwidth requirements per thousand end-points?
Or "policy sharing" and "roll-up reporting" is the way to go? Anyone to share experience with those two last?
Also any experience of having centralized ePO in geographically dispersed environment is warmly welcome
on 1/5/10 3:11:41 PM CSTon 1/5/10 3:34:34 PM CST
A lot of good advice is found in the "Walkthrough" guide for your version of EPO, which is available in the documentation section of downloads, or the Mysupport portal.
EPO scales very well to massive sites. The bandwidth for reporting etc is very small - where you do have big bandwidth usage is updates of clients, replication of repositories and software deployment.
Agent handlers will not address bandwidth concerns (because the event data still has to be sent back to the SQL server by the agent handler) rather they are designed to off load some of the burden from the EPO server in respect to handling agent-to-server communication requests. Also they can be used to manage agents on a completely separate network that cannot communicate to the ePO server directly (i.e. you may put an agent handler in your DMZ for home users). A good rule of thumb would be if you have more than 80,000 nodes you will need one or more agent handlers. This also depends on what point products you are managing so if you are managing VSE, HIPS, DLP and MNAC for example then you may need additional agent handlers at about 40,000 nodes.
For availablility ePO does support a clustered install.
For bandwidth concerns you should setup distributed repositories at all of your remote sites. This allow your clients at remote sites to update DATS / Products / Patches from a repository on their LAN rather than going all the way back to the ePO master repository.
I've attached a copy of the ePO 4.5 Hardware Bandwidth guide for your reference.
Did I catch you correctly that in your second scenario (40k nodes running VSE/HIPS/DLP/MNAC) it should be enough to have
-one central ePO system with proper hardware sizing
-repositories in each LAN
And one additional question - can I have 20000 clients over one single WAN with the assumption that I have repository in every LAN in that remote WAN site? (we are planning to use DFSR for distributing data between repositories)
on 1/6/10 1:05:11 PM CSTon 1/6/10 1:06:34 PM CST
Well you should take those numbers with a grain of salt they are grossly simplified. It depends heavily on factors such as exactly what kind of hardware the ePO server is installed on, whether or not the ePO DB is local or remote, what your network bandwidth is like, etc. More specific information is provided in the hardware bandwidth sizing guide I linked. Those figures are more to give you a general idea of when you may need additional agent handlers.
That said for just about any deployment size (even if you are only managing a couple of hundred clients) a distributed repository at remote sites is recommended. The only reason NOT to do this would be if the remote site had like 10-20 computers. In that scenario the bandwidth used to replicate to the distributed repository would be more than the bandwidth the distributed repository is saving you if that makes sense.