locked
How to upgrade/migrate policy from EMET 3.0 to 4.1 RRS feed

All replies

  • 1st: Backup your GPOs e.g. with the GPMC.msc

    You can make a new gpo for emet 4 and use WMI and Security group filtering for a rolling upgrade.

    You can also upgrade within the same gpo but gpo setting compatibility problems may occour.

    Don't forget to do emet_conf --refresh on the target machines after gpo changes.

    Tuesday, December 10, 2013 12:28 PM
  • Thanks!  That is what I am trying to avoid.. Compatibility problems.  Our current EMET 3.0 is working just fine and I was thinking if there's a side by side solution to test 4.1 without affecting  the 3.0 users at all. 

    In other words...Can EMET 4.1 GPO coexists with 3.0? I guess no, huh? Because when I add 4.1, it detects that EMET GPO exists already.  I want to know how others are safely migrating? Side by side solution would be great.

    Thanks!

    Tuesday, December 10, 2013 5:33 PM
  • I'm in the same boat; EMET v3.0 to v4.1

    I'm using a central store, but I can't have both ADMX files in the central store.  I believe I can replace the EMET.admx file from the v3.0 install with the one from the v4.1 install even if the options are dissimilar since I won't be editing the settings in the old v3.0 GPO.  Is that true? 

    Also, the "emet_conf -- refresh" command... This was not required for EMET v3.0.  Why is it for v4.1?  Is it only for immediate settings refresh?  Can I just reboot and have the settings be applied by GPO, or will machines permenantly ignore GPO settings until I run a script on them?  Do I need to run this after every boot in case some changes are made to the EMET sttings?  How long does it take?  Is there user feedback?

    Thanks.

    Thursday, January 16, 2014 8:38 PM
  • Looking at the EMET 3.0 manual, I guess the "emet_conf -- refresh" command was supposed to be issued (silly me!), but we never did and it appears that the settings are effective.  So, I'm still wondering, Does this command really have to be issued?  How come it doesn't need to be given when EMET is pushed out by SCCM?

    I've pushed out EMET 4.1 (via GPO) with the "Internet Explorer" protection profile to some test machines that previously had EMET 3.0 with the "Popular Software" protection profile.  I see the EMET program/client is updated, but when I run "emet_conf -- list", I see a big list of applications that look to me like the ones from the EMET 3.0 profile.  Running "emet_conf -- refresh" makes no difference.

    How do I remove the EMET 3.0 settings and take up the EMET 4.1 settings? 

    Thanks.

    Monday, January 27, 2014 9:55 PM
  • Answered here

    To start configuring from scratch you can issue the commands:

    .\EMET_Conf.exe --delete_all
    .\EMET_Conf.exe --refresh
    And from The v4.1 User Guide:

    ...
    3.2 Group Policy
    ...
    Once EMET Group Policies are enabled, they will be written out to the registry at HKLM \SOFTWARE\Policies\Microsoft\EMET. To make them effective in EMET, the following command must be executed:
    EMET_Conf --refresh
    Please note that when Group Policy is applied, there is often a short delay before Group Policy are written into the registry.
    This command can be run separately, for instance at system startup, at logon time, or with a scheduled task.
    To view the Group Policy controlled EMET settings, run the following command using the EMET Command Line Tool.
    EMET_Conf --list
    It is important to note that the settings configured via Group Policy take precedence over the settings configured locally using the EMET GUI or the EMET Command Line Tool. Also, Group Policy controlled settings can only be modified or deleted via Group Policy.
    ...

    Tuesday, January 28, 2014 9:55 AM
  • Thank you for the response, but I'm not sure it gets me any further. 

    I've read the User Guide, but it doesn't make sense to me why deployment through SCCM does not require the "emet_conf --refresh" command while deployment through GPO does.  Both of them just install the .msi and apply a set of registry entries.  Why would the programmers have it write to the registry but then ignore those settings?  What other program does that?  Now, if the manual said to either run that command or reboot, it would make sense. 

    I must also emphasise that we are not issuing the "emet_conf --refresh" command  when v3.0 is being deployed here.  It's not in any GPO, and we have new systems picking up EMET 3.0 all the time.  Running the "emet_conf --list" command on them returns exactly the protection profile we have requested -- emet_conf --refresh NOT required.

    Note that the last line of what you quoted indicates that the "emet_conf --delete_all" line you also mention will not work for the GPO settings that were applied when EMET v3.0 was deployed.

    The immediate problem/question right now is how do I remove the EMET 3.0 settings that were pushed via GPO?  EMET 4.1 is deployed along with the ADMX for v4.1, but the protection profile reflected in the machines that have picked the new version up are the settings that were for v3.0.  They don't seem to be picking up the v4.1 settings and they aren't recognized by the v4.1 ADMX:

    The bigger-picture problem is that the documentation on deployment appears to be incorrect (or poorly phrased) and there is no documentation on how to upgrade via GPO.  It would be mighty nice if someone "official" (maybe from the EMET development/testing team) were helping here!


    • Edited by cascomp Tuesday, January 28, 2014 4:33 PM word precision
    Tuesday, January 28, 2014 1:47 PM
  • I would also be interested to find this out because it looks like there's no way to do parallel run of EMET 3 and EMET 4 without giving up or removing the 3.0 GPO and fully implementing 4.1.  It appears to me that this can't be done side by side but let met know.
    Tuesday, January 28, 2014 4:30 PM
  • It is not enough to write the registry keys because EMET makes use of the Application Compatibility Framework. The databases in %SystemRoot%\AppPatch\Custom\" have to be updated. You might check that and monitor for example with procmon if and how this is done without --refresh.

    How EMET works: http://0xdabbad00.com/2010/09/12/how-emet-works/

    Again: You might use GPO WMI filtering to apply the appropriate EMET configurations to the right systems: http://technet.microsoft.com/en-us/library/cc779036%28v=ws.10%29.aspx

    when I look at the example and the output of "wmic product" it should be:

    Select * from Win32_Product where name = "EMET 3.0"

    or

    Select * from Win32_Product where name = "EMET 4.1"

    When I look at other installed software Microsoft seems to have forgotten the "Microsoft " Prefix in the EMET product name there.

    Wednesday, January 29, 2014 12:45 PM
  • Thanks for the suggestions.

    Frankly, I'm too busy to care about how EMET works (e.g. gets its settings without a --refresh call).  It is obviously doing so.  I'm more concerned how to get it working and removing the old settings.  The --refresh and --delete_all calls shouldn't "fix" the GPO-based configurations (based on documentation) and does not based on experience. 

    The problem in trying to have both versions is there can be only one ADMX file for EMET in the central store.  Even if the name of the file itself is changed, the GPME pops up an error that there are two templates for the same thing and only allows one of them to work. 

    Wednesday, January 29, 2014 7:24 PM
  • This should work but is not supported:

    Copy the adml and admx files to EMETSuffix.* and change the follwing lines:

    in the EMETSuffix.admx line 4 and 16:

       <target prefix="EMETSuffix" namespace="Microsoft.Policies.EMETSuffix" />
        <category name="EMETSuffix" displayName="$(string.EMET)" explainText="$(string.EMET_HELP)">

    in the EMETSuffix.adml line 7:

          <string id="EMET">EMETSuffix</string>

    You might change "Suffix" as you want.

    Thursday, January 30, 2014 8:57 AM
  • Very interesting!

    This did allow both "EMET.admx" and "EMET4.1.admx" to co-exist in the central store.  I'm not sure it is allowing me to use the "emet4.1.admx" template.

    I cannot distinguish between v3 and v4.1 settings in the GPMC. 

    In the GPME, I can only see a single "EMET" entry under "Administrative Templates\Windows Components".  Looking at the settings themselves, and the protection profiles that match what is returned with an "emet_conf --list" command are properly identified as enabled.  The text for them is that of the v3 adml.

    Are there additional changes that can be made to the .adm* files to make them distinguishable in the GPMC/GPME?  Does anyone know of a source for information on customizing/creating admx files?

     

    Thursday, January 30, 2014 10:12 PM
  • Hi,

    Question, do these commands can be also put into a start up script or does it have to start with c:\program files\EMET 4.1 path? Because I noticed that if I type in this command inside Windows, I cannot issue it without going through that program files path so I wonder if the startup script will work by simply issuing:

    .\EMET_Conf.exe --delete_all

    .\EMET_Conf.exe --refresh

    If not, could you please help me figure out what exactly my start up script looks like with this commands?  Thanks!

    Tuesday, March 4, 2014 6:56 PM