10 replies to this topic

[liorby]

Hi,

We emcounter some problem  with  setup.exe .

We have a basic msi project that create a setup.exe file.

one of our users changed the USERPRFILE environment varaible to point to C:\Windows\System32\config\systemprofile

.

when he try to run the setup it failed and it seems like it does find the extracted files.

 

 

I've attached the log file.

Did anyone had this problem? is ther a solution for it?

 

thanks in advance

Lior

[Stefan Krueger]

It looks like attaching the log didn't work. Can you please try again and tell me if there were any errors uploading the log?

 

I guess this is a permission problem. Does the user have write access to that system profile folder? (and why is he doing this in the first place?)

[liorby]

Thank you for the quick response.

 

I've attached the log file.

I'm not why they are changing the USERPROFILE  folder but it is an important customer.

I've checked the permission of the folder and Administrators group and the System user have  write acsess.

The Administrator user is not in the list.

 

thanks, in advance

 

Lior

Attached Files

•  msi_log.txt   3.32KB   174 downloads

[Stefan Krueger]

The log indicates that the file C:\Windows\System32\config\systemprofile\AppData\Local\Downloaded Installations\{A7D28918-3E02-4B69-9841-50CEF71009ED}\MLNX_VPI.msi could not be found. So I guess it fails to extract the msi file, most likely becuase of  a permission problem. You can run ProcessMonitor from SysInternals to verify this. I don't know which operating system you or your customer are using, so it might also be related to user account control (UAC).

 

To avoid the problem, in InstallShield go to Media > Releases, select your release, go to the setup.exe tab and either switch "Cache MSI locally" to no (not recommended, because the msi file may be needed later for maintenance operations) or change the Cache Path to a location where the user has write access (the defult is [LocalAppDataFolder]Downloaded Installations).

[liorby]

thank you  for your replay.

I'm using windows server 2008 64 bit.

when i'm log in as administrator I succeed to create a folder in C:\Windows\System32\config\systemprofile\AppData\Local .

Does the permission of the setup.exe are different than the permission of the user?

[Stefan Krueger]

This could still be some UAC isssue, or maybe 32/64 bit. In any case, ProcessMonitor should tell you.

[liorby]

thank you for your help.

i just found that  the package was extracted to syswow64  andnot to the sysstem32 folder.

I'm not sure why it happened because the userprofile point to system32\config\systemprofile and it seems that the setup try to run the package from the system32 folder but it actually in the syswow64\config\systemprofile folder.

 

any idea what could be the problem?

 

thakns in advance

Lior

[Stefan Krueger]

System32 is the system folder for 64 bit programs. 32-bit programs get redirected to SysWOW64. Is your setup a 32-bit or a 64-bit msi package? I'm not sure if InstallShield uses a 64 bit setup.exe when you build a 64 bit setup.

See also: http://msmvps.com/bl...pplication.aspx

[liorby]

My package is 64 bit package but i think that installshield build the exe as 32 bit and that why it redirect from system32 to sysWOW64

[Stefan Krueger]

Yes, In think the setup.exe of a Basic MSI project is always 32 bit. Maybe you can use some other extractor which supports 64 bit. Or you could try wrapping your msi file in a Suite/Enhanced UI project, as this can have a 64 bit setup exe (if I'm not mistaken).

[DBE]

Hello together,

 

yesterday I had the same issue and I found the reason and a solution for this:

 

Reason

The problem is due to 64-bit folder redirection. When extracting the msi file from the exe it is cached to the system account's LocalAppDataFolder which is redirected to a 32-bit version because it's under C:\Windows\System32; but then we tell Windows Installer to install it and it looks in the non-redirected 64-bit location instead.

 

Solution/WorkAround

Create a linked folder between the two directions:

//optionally you have to create a folder in the system32 directoy before

mklink /J "C:\Windows\System32\config\systemprofile\AppData\LocalLow\Downloaded Installations" "C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow\Downloaded Installations"

 

 

Have a nice day :-)