<tt><font size=2><br>
> I agree that folder redirection makes it quite hard to track what
is really<br>
> happening on the system. However I am running Windows x64 since <br>
> years (since my<br>
> first Windows Vista installation) and never had such issues yet.<br>
> <br>
> In addition I was under the impression that %TEMP% expands to %<br>
> SystemRoot%\temp<br>
> (c:\windows\temp) for the system account. At least I've never seen
<br>
> it expanding<br>
> to systemprofile\AppData\Temp which looks anyway wrong, if at all
it should<br>
> expand to "systemprofile\AppData\Local\Temp" but this would
also lead to the<br>
> problems you describe. But I am quite sure %TEMP% of the system <br>
> profile expands<br>
> to "windows\Temp".</font></tt>
<br>
<br><tt><font size=2>Did you test this on 7? As far as i know, this did
change on 7 - (And you're right, it is \local\Temp, but the base path is
still unfortunately %WINDIR%\system32\systemprofile)</font></tt>
<br>
<br><tt><font size=2><br>
> <br>
> Even installers writing temporary data to %AppData% should work because
the<br>
> installer/archive will be a 32-bit self-extracting archive writing
to the<br>
> redirected SysWOW64 folder. Then it invokes msiexec.exe, in any casethe
32-bit<br>
> process cannot open the 64-bit binary from the (real) system32\ folder
and<br>
> executes SysWOW64\msiexec.exe which is a 32-bit application as well.</font></tt>
<br>
<br><tt><font size=2>This is true in theory - and the msiexec.exe called
by the install.exe actually is 32bit, but all msiexec.exe does is call
the Windows Installer Service via some internal Interface - and that one
is 64bit. </font></tt>
<br><tt><font size=2><br>
> <br>
> In any case I don't like boxed installers too much. So I used to extract<br>
> Installers which extract MSI files in advance and then work with <br>
> pure MSI files.</font></tt>
<br>
<br><tt><font size=2>Which is fine when all the .exe does is unpacking
and running the MSI. In the case of X-Manager I spent nearly 2 days and
finally giving up. This Installer is installscript-driven and convincing
the MSI to run without installscript produces a broken install.</font></tt>
<br><tt><font size=2>I'm ok with the "boxed" versions if they
give all the options I need and work reliably. Saves me from much work
disecting every version upgrade. Java's Installer is okay-ish, except for
the 64bit issue.</font></tt>
<br><tt><font size=2><br>
> In your case you might run your Installshield installer on a test
system, then<br>
> during the installation do not close the installation window and grab
the MSI<br>
> files from %TEMP%.<br>
</font></tt>
<br><tt><font size=2>Tried and did for many packages - but some are left,
those pesky ones that need InstallScript for the install to go right.</font></tt>
<br>
<br><tt><font size=2>But I see light - I looked through some Docs and it
seems that (by default) the builtin "Administrator" local user
on Windows 7 is running elevated by default. That would mean no UAC-Prompts
for this user - so it'd work for silent installs. It just needs to be activated
(and passworded). I'll try this and report back to the list :)</font></tt>
<br>
<br><tt><font size=2>Best Regards</font></tt>
<br><tt><font size=2>        Heiko Helmle</font></tt>