Configuring EMET via GPO/GPP w/o using the ADMX files

[UPDATE 7/23/2014] I've create a wiki page at 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:

  • XML allows you to create and configure Certificate Pin Rules (GPO’s do not)
  • When using GPO’s the local EMET GUI does not properly reflect the configuration that is active but instead reflects the local configuration which is overridden by the GPO configuration.  To truly see the active configuration you have to run emet_conf –list and review the GPO section of the output.
  • Because of the previous point there is not a quick method to create a local exception on a client, i.e. a certain operation in a plugin in outlook is crashing with emet and a helpdesk tech needs to override is not possible as the GPO configured mitigations will always be the ones in effect.
  • Since I already need to run an emet_conf –refresh for GPO’s and use task scheduler/GPP anyway why not just use the more full featured and friendly xml config via the same mechanisms (GPP/TaskScheduler)

Realistically there are a number of ways you can do this via GPO/GPP:

  • User Logon script that copies/imports the configuration file from SYSVOL or some other file share (difficult as needs to be elevated)
  • Computer Startup script that copies/imports the configuration from SYSVOL or some other file share (works computer needs right to share and only runs on startup)
  • GPP / Task Scheduler Item that imports the file from SYSVOL or some other share on either a scheduled/triggered basis

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 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

--import \\\sysvol\\Policies\{2368E536-C9BA-41E6-A1D8-8AA1C7854275}\supercoolconfig.xml

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.

Edit 1:

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.



Comments (7)
  1. Kurt Falde says:

    @John yeah I definitely agree didn’t think about this until later when a customer was saying something about their x86 win7 systems and this and realized oops this wont work so well or you’ll need separate task scheduler items/targeting or maybe you could
    just stick with one and customize your install of EMET so it always installs into c:program files regardless of OS type as I believe you could probably do that with the msiexec cmd line options for installing it in an enterprise deployment. Either way I want
    to take this instruction set and make it a wiki article instead and I’ll just point a link from here to there that way the wiki article can be modified as needed.. i.e. there are some other things that should be added like system wide mitigations are not set
    via xml currently so you need an extra emet_conf line for them etc.

  2. Kurt Falde says:

    Thanks W. Spu completely did not realize this.

  3. Kurt Falde says:

    on the client you can always run emet_conf –list to see what settings are currently applied. To view the XML file you would need to go to your network share and look at the content. You could use task scheduler locally to see the job however that just
    tells you an xml file name.. same thing with running gpresult it just shows you the file name not necessarily the contents of the xml file.

  4. paul says:

    Briljant Kurt. Together with your other post regarding the scheduled tasks this works great. Thanks

  5. John says:

    Kurt, some discussion of "Program Files" vs. "Program Files (86)" is probably in order since many of us will still manage mixed 32/64 bit environments. (And some of us forget this for hours while troubleshooting.)

  6. W. Spu says:

    There is a undocumented installation option CONFIG_OPTIONS through which you can do a silent msi install of EMET with the recommended settings (with pinning enabled). See the comment posted by Microsoft in the feedback

  7. PhoniX says:

    Hi thank you for the superb guide.
    Where can i find out what .XML profile is active at a moment?
    I’m speaking about stand alone and not GPO one machine just finding out what XML configuration is active CMD command or similar ?

    Thanks 🙂

Comments are closed.

Skip to main content