Internet Explorer 10 IEAK capturing Security Settings

Question

I am trying to package a custom installation for Internet Explorer 10 using IEAK.  I am having some trouble with the Import Security Settings portion of the tool.
It is failing to import the security settings.  It says it has imported them, but upon installation the security settings have not been included in the IE 10 installation. 
Looking at the "INS" folder that is built and the custsec.inf file create there, I can see that only two security settings have been captured -- "1401" and "2500" and none of the other 50 or so security settings are collected
for any zone.
In addition, I have trusted sites set to not require HTTPS, but that selection is not captured into the custom IEAK generated browser installer.
Does anyone have any tips on how to successfully deploy a customized version of IE 10?  I am even more reliant now on IEAK since IEM mode was removed from Group Policy, so I reall need to figure out why it doesn't function correctly.

Answer 1

More...
When ActiveSetup is run on a 64bit OS, first all the 32bit ActiveSetup keys are run first, and the 64bit ActiveSetup keys are run second.
The problem is that IEAK is adding the CUSTOM ActiveSetup to the 32bit key, and the ie4uinit.exe is added to the 64bit key.  While the IEAK has an ">" listed in the GUID (to signal for it to run last) it runs "last" in the 32bit
ActiveSetup commands.  The 64bit ones (which the ie4uinit.exe is part of) all run after the 32bit stuff....
So it appears that IEAK is not designed to build an IE 10 installation that will run correctly on 64bit OSes.  The IEAK CUSTOM settings will always apply prior to the ie4uinit running.  I suppose this can be changed by further manipulating the
registry after IEAK customized IE 10 is installed and making sure the >{GUID} entry is moved to the 64bit registry.
I suppose another way to look at it is ie4uinit is not correctly noticing that that the user settings are already present in the user's registry and is wallpapering over them with the incorrect settings.  Either way, the end result is that the incorrect
settings are being configured for the user on first logon.
I find it difficult to believe that Microsoft IE team has messed this up and that no one has discovered it before.  (I'm not being sarcastic) That makes me question what I am doing that is incorrect because I can't  believe that a problem like
that would exist in a product as major as IE - and that no one has run into it and blogged about it.  I must have
something incorrect, but I really can't figure out what it is.  Why is IEAK's IE 10 writing that CUSTOM ActiveSetup into the 32bit registry on a 64bit machine?  Maybe it will work to just move the CUSTOM key from 32bit to 64bit at the end
of the installation.
Looking closer, the IE installer writes to both the 64bit and 32bit ActiveSetup areas in the registry.  The problem is that the 64bit one never runs because the 32bit one has run already and ActiveSetup runs only once.  So the IEAK CUSTOM
runs once out of activesetup in the 32bit registry.  Then the IE4Uinit runs once from the ActiveSetup 64bit registry area, then the IEAK CUSTOM ActiveSetup is evaluated (it has the same GUID as the 32bit one) ActiveSetup decides that GUID has already
run and doesn;t run a second time. 
I have been able to solve my problem simply by deleting the IEAK CUSTOM entry in ActiveSetup under the 32bit registry area  I just look at each subkey of HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Active Setup\Installed Components
Looking at the string values of StubPath in all the subkeys I find one with the value "RunDLL32 IEDKCS32.DLL,BrandIE4 CUSTOM" and I delete the parent key from ActiveSetup.  (don't delete the one in HKLM\Software\Microsoft\ActiveSetup)
This makes it so that IEDKCS32 always runs after the ie4uinit thing, and that makes everything work as planned.  I have no idea why I have to do this.  Hopefully someone else will find this saga useful in their own situation.