Silent update failed when running from SYSTEM account.

[yjdev]

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.

[giaviv]

Hey,

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

[yjdev]

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.

[yjdev]

giaviv,

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

[giaviv]

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?

[yjdev]

Hi giaviv,

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

[mmorcill]

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

[giaviv]

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.

[mmorcill]

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

[giaviv]

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.

[JeffryPaul]

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.

[giaviv]

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.

[JeffryPaul]

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.

[giaviv]

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.

[bmenot]

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.