39 replies to this topic

[PsiMoon314]

Hi,

I am very surprised and disappointed that nothing appears to have been done to resolve these IE7 installation issues within AP!

There is clearly enough information here in this thread to describe the problem and even a posting I made some time ago with a work-around to resolve this problem.

When is this issue going to be fixed?

Kind Regards

Simon

Edited by PsiMoon314, 11 May 2008 - 02:03 PM.

[PsiMoon314]

Hi,

Bump .. just wondering if anyone will look into this issue and fix it?

Every time I update AP I need to reedit the .APM file so IE7 will install correctly.

Kind Regards

Simon

[Cristiano]

> have not looked into why the DetectionRegisty section might be causing an issue with AP installing IE7
there's at least 2 versions of msie7: one with that wga validation and another one without it. if you don't have that registry detection, you may see this module also "not installed" when is, due an change at the .cat file. removing that md5 may do the same trick, but i didn't check it.

> just wondering if anyone will look into this issue and fix it?
well, i have this module:

Quote

[AutoPatcher 5.6 Module]

[General]
Title=Windows Internet Explorer 7.0 para Windows XP
Description=Windows Internet Explorer 7.0 para Windows XP
Author=Microsoft
ModuleAuthor=ModuleEditor2
WebPage=http://www.microsoft.com/brasil/windows/ie/default.mspx
ReleaseDate=20071025

[Behavior]
ParentID=WINDOWS_COMPONENTS_PARENT
UniqueID=IE7_XP_X86_PTB
Critical=False
AutoExpand=True
Depends=
TimeToInstall=180
TimeToRemove=180
RequiresReboot=True

[DetectionRegistry]
RegistryPath=HKLM\SOFTWARE\Microsoft\Internet Explorer
KeyName=Version
KeyValue=7.0.5730.10

RegistryPath=HKLM\SOFTWARE\Microsoft\Internet Explorer
KeyName=Version
KeyValue=7.0.5730.11

RegistryPath=HKLM\SOFTWARE\Microsoft\Internet Explorer
KeyName=Version
KeyValue=7.0.5730.12

RegistryPath=HKLM\SOFTWARE\Microsoft\Internet Explorer
KeyName=Version
KeyValue=7.0.5730.13

[DetectionFile]
FilePath=windows:\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
FileName=ie7.cat
FileVersion=ANY
FileMD5=d31f1e6a5e09d5b9c12fe850c930f875

[OperatingSystem]
WindowsVersion=XP_SP2_X86,XP_SP3_X86,XP_MCE2005_X86
SystemLanguage=1046

[SystemComponents]
InternetExplorer=ANY
WindowsMediaPlayer=ANY
DotNetFramework=ANY
WindowsInstaller=ANY
MSNMessenger=ANY

[OfficeComponents]
Word=ANY
Excel=ANY
PowerPoint=ANY
Outlook=ANY
Publisher=ANY
Visio=ANY
Project=ANY
OneNote=ANY
FrontPage=ANY
InfoPath=ANY
Access=ANY

[Installation]
"Module:\IE7-WindowsXP-x86-ptb.exe" /quiet /update-no /norestart

[Removal]
"windows:\ie7\Spuninst\spuninst.exe" /quiet /norestart

if i'm not mistaken, it's the same than ENU version and ie7 always install fine. so, really, i don't know what may be wrong to not install in other languages, since the command line is the same for all and it works in here. it isn't related to nlite or something?

[]s

edit: i forgot one thing... can someone that is having this issue of ie7 module showing also "not installed" take a look at:
HKLM\SOFTWARE\Microsoft\Internet Explorer

and please report what version is showed in there, before edit modules or force ie7 to be installed? this is important, because you may have an version that isn't those listed to be detected

thanks in advanced

[PsiMoon314]

Hi,

I have the latest build of the IE7 installer direct from MS.

I generally install IE7 on a clean PC (just installed the OS) so I cannot see that there should be any issues with pre-installed software.

If I install manually or edit the IE7 installation module then I can get it to install from AP correctly.

Logically this would seem to indicate an issue with the module (and/or the installation order within AP).

Kind Regards

Simon

[Cristiano]

> I have the latest build of the IE7 installer direct from MS
me too

> I generally install IE7 on a clean PC (just installed the OS)
in booth situations and plus: anything can be installed first, since the machine can already be updated or any sort of software can already be installed

> If I install manually or edit the IE7 installation module then I can get it to install from AP correctly
i do nothing. take a look:
br:
"Module:\IE7-WindowsXP-x86-ptb.exe" /quiet /update-no /norestart
en:
"Module:\IE7-WindowsXP-x86-enu.exe" /quiet /update-no /norestart

except by the name of the installer, same thing. since booth are the same, i can't see any issue regarding this

about reg detections and en detections, booth are the same thing.

about the .cat file, i do this:
[DetectionFile]
FilePath=windows:\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
FileName=ie7.cat
FileVersion=ANY
FileMD5=d31f1e6a5e09d5b9c12fe850c930f875

eric does this:
[DetectionFile]
FilePath=windows:\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
FileName=ie7.cat
FileVersion=ANY
FileMD5=

so, the only one difference that i can see is that the en version doesn't have an md5 for the .cat file and i have. every single time that i run my version, it always detect fine. but since eric don't put any md5, if the file is found, any file with that name shall work

> Logically this would seem to indicate an issue with the module (and/or the installation order within AP)
i don't think so. i just install oem versions of win xp, untouched. with the machines that i just update and wasn't installed by me, i can't be sure about nothing and yet, it worked. so, logically, and assuming that in deed there's an issue regarding some installs of this module and since no one else, in any other language has complained about, this issue shall be restricted to en versions. assuming this and assuming that all translations run the exact same thing, this issue can be restricted to issues regarding the en version of msie7 or some issue regarding the version of windows installed. even matching the module that you posted, you just removed the reg detections and change an /quiet to /passive. really, the only one difference changing from /quiet to /passive is that in /quiet you don't see it installing and in /quiet you see an progress bar. so, assuming that this have nothing to do with the issue, i only can assume that, by some reason, that .cat file isn't in the right place and some of this reg entries already are in there, but ie7 isn't working or isn't installed. can you check this?

thanks

[PsiMoon314]

Hi,

Just for clarification and to bump this message yet again so someone will finally look into this issue.

IE7 does not install on a clean Windows XP Home SP3 installation, unless the modifications to the IE7 module file I posted earlier are made.

I am using the latest download of the IE7 installer obtained directly from the MS website.

Regards

Simon

[Cristiano]

> IE7 does not install on a clean Windows XP Home SP3 installation
i did it yesterday with the module that i've posted above. it works. and yes, was an windows xp home sp3 slipstreamed (the original one was an untouched media of the same version, but sp2). by the way: i did it just twice, one for an xp home sp3 oem and other one for xp pro sp3 oem, booth slipstreamed with sp3, nothing more, nothing less

> I am using the latest download of the IE7 installer obtained directly from the MS website
me too. i'm choosing the version that i link into autopathcer script

[]s

[Erik Ramey]

Hey there PsyMoon314. Sorry about not responding, I've missed this thread entirely.

Later on today, I'll go ahead and update this module to include the release date and the passive install which is a good idea. As for the registry detections, there isn't any need to remove these since they don't interfere with installations. They are only used when the module is loaded by AP which calls a scan to the registry to see if the key exists.

[James]

Can I please make a plea to the "I can't install IE7" group in this thread to take look at IE7's own install logs and let us know what reason the log files give for the failed install? Please?

Notes:
1) IE7 writes ie7.log and ie7_main.log in the windows folder;
2) IE7 writes a third log if you UNinstall it;
3) Microsoft currently list about 16 (sixteen) reasons why IE7 won't install, ranging from the obvious to the obscure - none of these involve AP;
4) That doesn't include the Webroot problem, nor the gmail problem.
5) The one constant in this thread "war" is that Microsoft have NOT changed the install package since August 2007. "I am using the latest version" is therefore not much (if any) help. I know the download page says "7/3/2008" (American date format) but IE7-WindowsXP-x86-enu is still dated Tue, 14 Aug 2007 01:59:11 GMT on Microsoft's servers.

--

[PsiMoon314]

Hi Erik,

Erik Ramey, on Jul 22 2008, 06:24 PM, said:

Hey there PsyMoon314. Sorry about not responding, I've missed this thread entirely.

Later on today, I'll go ahead and update this module to include the release date and the passive install which is a good idea. As for the registry detections, there isn't any need to remove these since they don't interfere with installations. They are only used when the module is loaded by AP which calls a scan to the registry to see if the key exists.

Thanks for looking into this issue. I will update my AP installation in a few days and then see if these changes work on the systems I have here.

What do the RegistryDetect options with the .APM file do? Are they for installation detection?

Kind Regards

Simon

[PsiMoon314]

Hi James,

Thanks for the information in your post, it may prove useful.

However characterising this thread as a war (even if that's in quotes) is not really fair or frankly accurate.

I and others have simply been trying to work out what is going on and why the problem has persisted for so long.

Regards

Simon

[James]

@ PsiMoon314
Simon, I'm sorry if my use of the word "war" (including quotes) has offended you - that was certainly not my intention. The fact remains, however, that this thread is quite easily divided into posters in the "I can't install IE7" group and posters in the "I can install IE7" group. After 30 posts and four months since your own first post, we do indeed seem no nearer resolving this, so I can fully understand your frustration. Until such time as the "I can install IE7" group can both understand and reproduce the problem, progress will continue to be slow.

My plea for information from ie7.log and ie7_main.log is to help make progress. We need also to eliminate side issues. For example, WGA is no longer relevant to an IE7 install. We also need to establish what else people are doing during the install process. Thirdly, we need to establish when (and how many times) people are rebooting.

MSFT advice to network administrators (IE7Deploy.doc) lists no less than 3 (three) required reboots. One of these is obviously to reconfigure for remote automatic logon, but that leaves two. Hence, I suspect, this is the source of the often repeated question throughout the various forums of "Have you rebooted twice?" That, however, is not the complete solution (far from it, in fact).

The suggestion that AP have the ability to install IE7 on an exclusive basis (with a forced reboot, I should add) is certainly valid, but until it can do that we need to line up the workarounds.

To answer your question to Erik, [DetectionRegistry] (and [DetectionFile]) are (to put it simply) the sections that turn the update "blue".


--

[James]

@ Erik
Is there any particular reason why this:

[Behavior]
...
Depends=WGA_XP_X86_ENU

is still in IE7_xp_x86_enu.apm?

Also, I do not understand why both you and Cristiano include:

RegistryPath=HKLM\SOFTWARE\Microsoft\Internet Explorer
KeyName=Version
KeyValue=7.0.5730.10

and:

RegistryPath=HKLM\SOFTWARE\Microsoft\Internet Explorer
KeyName=Version
KeyValue=7.0.5730.12

in the [DetectionRegistry] section, since the only publicly released versions of IE7 are 7.00.5730.1100 (=7.0.5730.11) and 7.00.5730.1300 (=7.0.5730.13). Is it different in languages other thah English?

--


EDIT: corrected typo

Edited by James, 26 July 2008 - 10:29 AM.

[Cristiano]

@James

Quote

since the only publicly released versions of IE7

because ap had the first release of IE7 and, if you keep only the detection for that first version, everyone that had the second version (without wga) may see that first version also not installed. was me that saw that issue and reported. after confirmed, erik put those 2 extra detections because at that time, we wasn't sure about how many versions of msie7 ms released and, just to be sure that this issue was fixed, we added those 2 extra detections. at least, those 2 extra detections doesn't harm.

> is still in IE7_xp_x86_enu.apm?
this was in that due an decision of blaze. i never agreed about do something that you may very well call of spyware be an requeriment to install another valid thing. if the user wishes, he always can check wga to install and we shall not force him to do something that even ms force you to do. it's an user choice install wga and we should keep that. but answering your question about, yes, today, that requeriment is still in IE7_xp_x86_enu.apm module:

[Behavior]
ParentID=WINDOWS_COMPONENTS_PARENT
UniqueID=IE7_XP_X86_ENU
Critical=False
Recommended=True
AutoExpand=False
Depends=WGA_XP_X86_ENU
TimeToInstall=240
TimeToRemove=240
RequiresReboot=True

since even ms doesn't asks for wga to install wga today, i don't see why keep that. so, by me, that shall be removed at once

by the way: i never add that and that module always worked fine in original versions of Windows XP

[]s

[Erik Ramey]

Cristiano, you are the man and thanks for typing the explaination for me =) <the last two weekends I've actually had a life for once. Additionally I leared that it's fun too>

I aggree that we should remove the WGA tags. I'll update the modules tomorrow.

[James]

@ Cristiano + Erik
Thanks, that's as I expected, but it's always best to ask the author. As you'll see, I am just trying to clear up the non-issues.

Eriik -- I know how busy you are -- you won't catch me round here weekends either (except early on some Saturdays) !

--

[Erik Ramey]

IE7 for XP was just updated. The WGA tag has been removed.

[PsiMoon314]

Hi Erik,

Thanks for the updates to this module. I will be testing this in the next few days as new PC's and work comes through.

A side issue to this is something I have just noticed, which could be a feature or a bug with AP, depending on your point of view

I set the read-only flag on my IE module files within my working copy of AP and the APUP module updater will then not update that module. Cool as a feature when you need APUP not to "break" your own module customisations.

There doesn't seem to be anything in the APUP UI or the log file which indicates that APUP respects the read-only flag however it does seem to.

If you accidentally or unintentionally do this (such as copying the AP files from a CD to Hard Drive) then APUP probably won't update correctly.

Is this a "feature" by accident or by design, and should APUP be warning that module files are read-only and that they will not be updated?

Kind Regards

Simon

[PsiMoon314]

Hi James,

James, on Jul 26 2008, 11:08 AM, said:

@ PsiMoon314
Simon, I'm sorry if my use of the word "war" (including quotes) has offended you - that was certainly not my intention. The fact remains, however, that this thread is quite easily divided into posters in the "I can't install IE7" group and posters in the "I can install IE7" group. After 30 posts and four months since your own first post, we do indeed seem no nearer resolving this, so I can fully understand your frustration. Until such time as the "I can install IE7" group can both understand and reproduce the problem, progress will continue to be slow.

My apologies also I my comments came off as too strong, that was not my intention. Chalk this up to experience

I think the issue with the installation via AP might be the WGA dependency in the module .APM which has now been fixed by Erik.

WGA is not required (now) for IE7 installation so if AP was requiring this then this might explain a lot of the installation issues folks were seeing.

Installing IE7 earlier on in the AP process might also help and I await feedback on this from other AP users with interest.

Kind Regards

Simon

[James]

Well, sorry to be the bearer of bad news, but I think there's rather more than WGA as the problem. I wanted it out of the way, because otherwise we would need to know what install of Windows is involved (OEM-SLP and VLK don't need activation, all others do). That's why I would like to see what is in ie7.log and ie7_main.log when an install fails.

These log files, incidentally, are not always easy to interpret!

--