InstallAware

Hey guys,

I wonder if anyone can help. I am trying to run a silent update as well from a Windows Service.

When I tried it in the command prompt, it worked with using /update /s switch. However when I tried inside Windows Service using .Net Process I get this error in Event Viewer:

Error 1312. Cannot create the directory 'C:\Windows\TEMP\miaCBA5.tmp\xxx.exe'. A file with this name already exists. Please rename or remove the file and click retry, or click Cancel to exit.

This error only occurs when I am trying to run it from Windows Service. When I try to run from a command prompt it does not give this error. I notice that the user is SYSTEM when this error occurs. When I try running it in command prompt the user is normal user. Also, the temporary directory that stores the installation files is 'C:\Users\userXXX\AppData\Local\Temp\mia18\' rather than 'C:\Windows\TEMP\mia...\'.

Why is it giving this error when running under SYSTEM? I tried deleting all files and folders in C:\Windows\Temp\ before running the silent update and the same error happened as well.

Hey,

Did you consider running from the Windows Service as a user?
How exactly are you running the update from the service?

Hi giaviv,

I run the update just like I would run it from a command prompt. I worked out the uninstallString path from the registry and then run the command "setup.exe /update /s". Except when I run it from Windows Service that command is run under SYSTEM account. When I run it manually on a command prompt that command is run under the current user.

I think it's hard to run the update as a user in windows service. What if there are no users currently logged on? Also, how am I going to determine the username and password? All the clients that are using the setup will have different user accounts.

I guess my real question is, why is it not working under SYSTEM account? SYSTEM account should be the most powerful user account. Also, what does the error mean? I empty the Temp folder before updating but it is still saying that it already exists. Somehow the setup is creating the files twice?

Please help ... Thanks.

giaviv,

Do you have any ideas why it is causing error? Thanks.

Hi,

I have contacted you via email a few days ago - did you not get it? Could you please send your email address to support at installaware.com?

Hi giaviv,

Sorry, I was not checking my inbox. I have sent you my reply. Thanks!

Hello,

I am having a similar issue where a client is deploying our install using Matrix42 Epirum which is using a system account as well . The error is the same as above so I'm wondering is there any chance of getting the solution sent to me? The enviroment is Windows 7 (x86 and x64) and this is holding up their rollout of our product.

Thanks in advance!

Michael

Hey Michael,

The OP and I are trying to find a solution for this.
Note that by design InstallAware doesn't guarantee supporting updates from the SYSTEM account so this might not work.

You will be kept posted.

Thanks for the quick reply. Any chance version 11 addresses this one? We're just about to pull the trigger on the order for v11.

Thanks!

Michael

Hi Michael,

Altough this feature was not addressed in IA 11, we are working on finding a workaround for this. I'll keep you posted.

giaviv wrote:Note that by design InstallAware doesn't guarantee supporting updates from the SYSTEM account so this might not work.

I have upgraded to IA11 and created a small, native setup. The setup runs fine both silently and interactively while running under a user account's credentials. However, when running as SYSTEM, the setup seems to hang after the decompressing step. The first line of the setup script never executes. This is a serious flaw.

Please allow me to beta test any solution you develop, as I have an important and urgent need to push out a sofware update to my customers.

Dear JeffryPaul,

Updates are not supported on SYSTEM accounts. This is as designed, and is caused by the lack of a lot of environment variables when running in a SYSTEM environment.

We are not certain if and when this will be possible, but for now, please run updates as a regular user.

I am attempting to distribute a complete setup package, not an update. I am not using the installaware update logic either.
My installer script was written specifically for SYSTEM, and it makes reference only to those environment variables I need to access: Temp, Windows, System32, Program Files, Common Files, Common Start Menu.

Why should the Installaware runtime engine attempt to lookup or determine user settings if the installer script doesn't specifically reference them?

As a temporary fix, I recommend including a new compiler variable, such as SystemAccount=True/False, which modifies the installer engine runtime engine to bypass those sections of code that attempt to determine/define user-specific variables.

As I mentioned previously, I'll be happy to beta test whatever solution you can provide.

Hi,

I apologize - I got confused. I meant to say that installations in general are not supported with the SYSTEM account.

We apologize for the inconvenience.

giaviv wrote:Hi,

I apologize - I got confused. I meant to say that installations in general are not supported with the SYSTEM account.

We apologize for the inconvenience.

If that is the case, then InstallAware does not produce enterprise-ready setups. SCCM, LANDesk, etc. typically deploy under SYSTEM, so this is a major issue for any Enterprise customers purchasing your software you've packaged with it.

Here's what I found helped when working with a vendor package with this problem.

--Open the MSI File in Direct Edit mode
--Locate the Directory Table entry that is getting set to the name of the *.exe file. It'll get resolved in CostFinalize.
--Remove its entry(s) from the CreateFolder table
--Create a SetDirectory custom action (type 35) and set the Directory Table entry to the Start Menu group you're trying to create for the program.
--Save the MSI and test it under SYSTEM with Setup.exe /s and see how it goes for you.



*Also, for Posterity, there are indeed plenty of Environment Variables set for the SYSTEM account. I think you're referring to ShGetFolderPath() returning different values than expected, which is likely the root of this issue.