[UPDATE 7/23/2014] I've create a wiki page at http://social.technet.microsoft.com/wiki/contents/articles/25585.emet-gpo-gpp-using-task-scheduler-to-import-emet-settings.aspx that condenses these steps and adds a few new items and is open to collaborative editing as well so you may want to view that as well [/UPDATE??]
If you have deployed EMET in an enterprise setting you have probably realized there are basically 2 different ways to push a configuration to the clients. One is to the use the .admx/.adml files that are under the deployment folder when you install EMET and the other method is to export a configuration from a client and import it on another client via usage of the emet_conf –export / –import command line tool.
I prefer the xml file configuration method for a number of reasons which is why this post, some of those reasons include:
Realistically there are a number of ways you can do this via GPO/GPP:
I’m basically going to pick doing the last one on the list as I can make this trigger more frequently than the first 2. As with a previous post I also want to trigger based on Group Policy Refresh event id’s.
First I need to configure an EMET client how I want it to be configured. If you need extra pin rules, need to remove mitigations, turn on system wide settings, disable system wide settings, etc now is the time to do it. Once you have the client configured as you want export the configuration: you can either do this through the GUI with the Export button at the top left
or you can use the command line and emet_conf –export (make sure you have an elevated cmd prompt any time using emet_conf)
Either way you now have a config xml file that you can import to other clients. Create a new GPO and make a note of the GPO’s GUID as we are going to use that GPO’s folder in SYSVOL to store our configuration file.
Next step we drop this config file into the root of this GPO that we have created. (I know some GPO purists are thinking you shouldn’t do this but hey it is a config file and GPO’s are meant for configs right?? + if this gpo ever gets deleted that means we cleanly got rid of this as opposed to throwing it in the netlogon/scripts folder where it would likely sit forever)
So new GPO is created and the config file is copied into the GPO’s folder in my domain. At this point we need to create the task scheduler item again.. I am not going to recreate the whole blog post on that but rather point you to the previous post at http://blogs.technet.com/b/kfalde/archive/2014/03/13/automatically-refreshing-emet-gpo-s.aspx covering it. The one exception is to the arguments that we are going to run with the scheduled task. Instead of running emet_conf –refresh we are going to run emet_conf –import \\…sysvol..\..gponame..\supercoolconfig.xml as seen in the screenshots below.
I put a couple to try to show the beginning and end of the argument statement which is actually
Don’t put spaces in your XML config file name as that would probably break it / require quotes.
Once you have all this completed and applied to some test clients run gpupdate /force a couple of times and verify that you see the EMET Event ID 21’s in your application event log which indicates that the task scheduler item is working. You can also check your task scheduler locally on the system as well to verify that the task was created and has ran successfully.
As always let me know if you have any questions in the comments and I’ll do my best to get an answer for you.
Saw some issues where Pinning is disabled by default during a silent msi install of EMET. In order to ensure that Pinning is enabled add another “Action” to your scheduled task to run emet_conf again however the argument should be “--system Pinning=Enabled”
Applying an xml configuration file does not an overwrite operation but rather an additive operation i.e. if an application has been added via the GUI and the xml file does not have that application as one that is protected then the application stays in place. It is not removed. If you want to ensure that only the contents of the xml file are the actively configured settings then add another “Action” item as the first in the “Actions” order list to run emet_conf with the argument “--delete_all” this will ensure that all current local configuration is removed and only the imported xml configuration is in place.