Silent update failed when running from SYSTEM account.

[JeffryPaul]

Does Installaware 12 resolve this problem?

[giaviv]

Again, this is not a bug but rather an expected behavior, therefore it hasn't changed in IA 12.

[Joc02]

Hi,

I'm in the same situation, and I search solution for get round the behaviour.
So, all people that search to install in "SYSTEM MODE", how did you do to solve your problem ? Are you abort the installation by the SYSTEM account ?

Thank for your help.

[Urban]

Are you telling me, you built a packaging product which doesn't allow for applications to be installed under the System account?

Thats like building a car that is 150 feet wide, sure, its nice a big and packed with features, but its also 100% COMPLETELY useless, because it wont be allowed to operate on any roads!

Why in the world would I want a packaging application that isnt compatible with the most common deployment product on the market, Microsoft System Center Configuration Manager (SCCM)?

My users arent administrators on their PC, thats the whole point of a packaging product such as this, to be able to deploy applications to users company wide from a central point.

If InstallAware had an option to specify an account to Run As under, this would all be somewhat workable, but the only thing I can think of now is create task sequences for all my applications in SCCM which will allow me to specify a run as account there, but thats just overcomplicating something that should be easy!

[FrancescoT]

Dear Users,

I have found some incorrect answers on our forum ... I'm actually correcting all these.

To summarize the questions:

"Note that by design InstallAware doesn't guarantee supporting updates from the SYSTEM account so this might not work." - false

"This is as designed, and is caused by the lack of a lot of environment variables when running in a SYSTEM environment." - false

We recently did this testing and were able to do.
In our test we used "psexec " utility from from sysinternals that permits to run a package as the SYSTEM account.
Some others InstallAware users have used it and found useful. I really think that will work using tools other than PSEXEC.

Regards

[JeffryPaul]

Dear Users,

I have found some incorrect answers on our forum ... I'm actually correcting all these.

To summarize the questions:

"Note that by design InstallAware doesn't guarantee supporting updates from the SYSTEM account so this might not work." - false

"This is as designed, and is caused by the lack of a lot of environment variables when running in a SYSTEM environment." - false

We recently did this testing and were able to do.
In our test we used "psexec " utility from from sysinternals that permits to run a package as the SYSTEM account.
Some others InstallAware users have used it and found useful. I really think that will work using tools other than PSEXEC.

Regards

PSEXEC is not a valid test, as ONLY the called EXE is actually run as SYSTEM. If any EXEs are spawned from the initial EXE, they are run as the current user.
A better test of an installer is to run "setup.exe /s" using a scheduled task that runs as System.

[FrancescoT]

I will try it ... if you already done it please tell how is gone.

Regards

[JeffryPaul]

Here is what happens when running setup using a SYSTEM account:

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.

[FrancescoT]

Could you try using my attached setup exe?

Let me know.

Regards

[JeffryPaul]

OMG! IT WORKS!

The following tests were performed on Windows 7:
1. Ran SysTest.exe installer provided by Installaware (which installs WinDiff) using a scheduled task running as SYSTEM. Success!
2. Ran one of my own Installaware setups (using the native engine) created in July 2011(not sure if that was IA11 or IA12) using a scheduled task running as SYSTEM. Success!
3. Ran an updated Installaware setup (definitely IA12) using a scheduled task running as SYSTEM. Success!
4. Used my home-grown Installaware update service (which runs as SYSTEM) to install my latest Installaware setup. Success!

Due to the MSI Installer headaches, I switched to the Installaware native engine. I wonder if that change made the difference.

Thanks, Installaware, for revisiting this issue.

[FrancescoT]

Many many thanks JeffryPaul!

[alibaba]

A customer has this problem with my InstallAware-Setup. He is deploying through Matrix42 Empirum that is using the SYSTEM-account. He is getting the error:

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

I don't want to use the native engine, so is it somehow possyible with InstallAware NX to solve this problem?!

[FrancescoT]

Dear Alibaba,

I never used Matrix42 Empirum and if it works as any other tool, it should install the package under System Account as well.

As you can see by the previous posts, this has been verified by other users and not by me only.

Please, could you try to verify how does using the test setup package I provided with this topic?

Let me know.

Regards

[alibaba]

AFAIK this test-setup is using the native engine it does not answer my question:

I don't want to use the native engine, so is it somehow possyible with InstallAware NX to solve this problem?!

I can only tell you that my installation that has this problem is installing well when it is running with administrator account within Matrix Empirum.

Is this test-setup using the native engine?

[FrancescoT]

Dear Alibaba,

the setup test uses standard MSI engine features.

Regards