System Center Endpoint Protection: The Facts
Recently I have visited a few customers who have asked plenty of probing questions about System Center 2012 Endpoint Protection or SCEP for short. As you may or may not know, it’s previous version Forefront Endpoint Protection 2010 has been improved and is now part of ConfigMgr 2012. SCEP gets a bad reputation and I have no idea why, this post is intended to look at SCEP and see why it has a bad name.
My thoughts on this subject started with a recent email thread internally where a customer highlighted their concerns with SCEP after they heard bad reports about the ability of SCEP to prevent infection and detection.
Their concerns came from reports on the internet, naturally my research started here. I did find one which frankly annoyed me quite a lot. It is published by McAfee who claim how much better EPO is compared to SCEP from an administration and feature point of view.
So using McAfee’s own slides, let’s begin…
Slide 6 – What first jumped out at me here is extra servers, quote 3 times as many! Where on earth is this figure coming from? You only require one server to deploy SCEP which is your primary site, if the customer is already using ConfigMgr which isn’t unlikely then this will be zero additional servers.
Even if you only used ConfigMgr for SCEP then you only need a primary site, maybe some BDPs (or just workstations as DPs in 2012) for remote distribution but these are not servers, just existing infrastructure.
Well who knows what this means? It’s a very vague statement indeed. You only need one person to manage SCEP? Use Automatic Deployment Rules to send out your definition updates and you are done. Deploy the SCEP agent by setting the policy value to true and you are done. Can’t see where this is coming from at all.
Maybe they have a point here? I don’t think so, I have never used EPO, I am told by colleagues it is fairly simple to use, but so is ConfigMgr when you have used it for much of your life. Switch these roles around, I would be lost in EPO and so would the EPO administration in ConfigMgr because they have never used it.
Even then, if you don’t know what you are doing, setting up SCEP takes a few hours maximum (less if you are experienced).
Complete rubbish in my opinion, most if not all the customers I have visited, even the smaller organisations are already licensed for SCEP anyway, again, don’t see the point here.
Reporting and Administration
“EPO membership is security orientated where as ConfigMgr is patch orientated” – Erm, say that line again please? I have no idea what the message is here.
“Distributing updates is much faster in EPO than ConfigMgr” – Yes, maybe with an out of box installation with no options configured, if you configure the software properly it will be fine.
Reporting in general, from what I have seen yes the reporting in EPO is much better and richer, this will continue to improve in SCEP though. The reporting in SCEP 2012 is already much better than we got in FEP 2010.
Over to slide nine now. Expertise required in six consoles! What! How many? A really bad case of misinformation here. You need to know how to use the ConfigMgr console only. For example, set policy, configure settings and configure updates.
This has to take the biscuit for me. “Users can tamper with and disable Forefront”. All you need to do here like any other product is configure the settings to lockdown the policy so this cannot be done.
Finally, we have a “barrage of Windows Updates, requiring too many reboots”. Looks like we are talking about patching now instead of anti-virus. Definition updates do not need a reboot to apply. Even using McAfee, Sophos or any other product, these systems still need patching. What a terrible case of misinformation yet again.
I guess in summary, my message here is, please configure SCEP properly and use it in your lab environments and make up your own mind. You pick the product which is right for you. With great features like SpyNet, SCEP is more than up to the job of protecting your environment.