After my post last week on things a System Administrator can do to protect against zero days in your browser, operating systems and applications, one of the biggies for Windows is to deploy EMET - Microsoft's Enhanced Mitigation Experience Toolkit.  EMET implements advanced security controls that are not native to the operating system.  Using EMET, you can take advantage of security features from Windows 8, even if you are running Windows 7 or even to some extent on XPSP3.  Or you can beef up what's in Windows 8 with features that aren't anywhere but in EMET yet.

I've been running EMET for some time on my "production" laptop, and haven't had it cause an issue - ever.  However, I don't run any "corporate applications", and lots of the dedicated security tools I use are either in VMs or are deployed on different machines.  In a corporate environment, I'd still suggest that EMET is a great way to go, but you'll want to test this tool on a small but representative user group, then deply in stages.  If you've got a reasonably complex environment with apps that have been around since the 90's, then you are like most shops, and you can expect EMET to break things here or there - you'll really want to test this thoroughly before you roll it out en masse.

But there's the rub - how do you deploy EMET to a 20. 200, 2,000 or 20,000 desk environment, without going to every desk?  

And once it's there, how do you manage settings?

A really simple deploy can be done from the login script.  Something like works in lots of cases:

if exist "C:\Program Files (x86)\EMET 4.1\EMET_GUI.exe" goto EMETISOK
msiexec /i "\\uncpath\EMET Setup.msi" /qn /norestart
:EMETISOK

This assumes you're allowing users to install applications (which I'm hoping you don't do!)

At the other end of the spectrum, Microsoft documents rolling EMET out using SCCM in the EMET User's Guide.

However, if you want something between these two extremes - something more reliable than the login script, but you don't have SCCM in your environment, Carlos Perez has a great "How to deploy EMET using WSUS" doc, found here:
http://www.darkoperator.com/blog/2013/8/28/deploying-emet-40-in-small-to-medium-environments-using-wsus.html

OK, now it's installed, how do you manage all the dials and knobs that make up the dozens of options within EMET? 

You can go a long way down this road with Group Policy.  There are two files you need - EMET.adml and EMET.admx, located in the EMET directory: Deployment\Group Policy Files.  On the host you'll be building your Group Policies (usually on one or more of your Domain Controllers) copy EMET.adml to \Windows\PolicyDefinitions\en-US.  Copy EMET.admx to \Windows\PolicyDefinitions.  Once this is done, you'll have access to many of the EMET settings in Group Policy.

Computer Settings:

And User Settings:

You can also manage EMET from the CLI - you can export your EMET settings to an XML file once it's tuned (Microsoft includes 3 XML files with the tool), and you can import settings stored in  XML from the CLI.  If you have a group of stations or users with settings that are complex enough that Group Policy won't do the trick for you, you can can work out procedures using XML files for these users, either using a login script or a centralized script that might use psexec from Microsoft's sysinternals.

This is a really high level description of how you'd deploy EMET in a typical Windows shop.  Where I've done this, it really has been this simple - this is one of those tools that just works.  But if you've found a "gotcha", or a slick way of getting someting done in EMET, please add to the conversation in our comment form.

===============
Rob VandenBrink
Metafore