InstallAware

Hi,

Only just started using InstallAware and I am very impressed!

However with my first couple of projects, although they install perfectly from a command line using "program.exe /S" when attempting to install using SCCM 2007, SCCM reports the package was installed successfully, however nothing is actually installed.

What am I missing here?

I did search the forum and couldnt find any answer to this.

Dear Urban,

honestly I never used SCCM .... probably if you provide me with a sample to work on, I can try to test me too.

Regards

Well since making this post I have found this:

http://www.installaware.com/forum/viewt ... f=2&t=6658

So it really comes down to InstallAware packages unable to install under the System Account. Which makes this product useless to me, why would I want to package up installers if I cant deploy them with the leading deployment system, SCCM? I think I must be missing something though, cause if this cant be done one way or another, then how this company can be in business is beyond me.

I am going to do some testing today but will probably tell my manager that we should look into getting a refund for this inferior product.

Dear Urban,

I personally do not agree at all with your comments and indeed, I consider these offensive too.
So I ask you to be respectful to our work, also because, none of us are forcing you to use InstallAware.

Then I have replied to your question regardig SCCM "ONLY" or maybe you have not been enough clear.
You did not ever ask if you could possible to execute an Install under SYSTEM ACCOUNT.
However, you are right because you have found some incorrect answers on our forum ( ... I'm actually correcting these), but this do not give you any right to place an offensive post.

To summarize the questions that are related to the post you found:

"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.

Regarding your other cosideration;
We have a 30 day money back guarantee in addition to a free 30 day trial so you have 60 days that permit to evaluate our product extensively.
I understand your frustration, but we not tolerate abuse on our own forums, and then I ask you to be more respectful towards us in any your future post.

By the way, I am here to reply to questions and with my Possibilities in the best of my knowledge, I do all my best to give an aswer to everybody.

Regards

Ok FrancescoT, I didnt want to upset anyone and I thank you for your reply, but the fact is that I am very upset myself!

When all us go around and purchase things, in our work life and personal life, we all take some things for granted, you buy a TV in an American electronics store, you expect it to work on the American TV network, you dont ask if it does. When you buy a car in a a renowned car reseller in the UK, you expect it to meet UK standards for left side traffic, you dont ask if it does, it something you take for granted!

When I purchased InstallAware, I took it for granted that it would work with Microsoft SCCM, as this is the most common standard program for deploying packages worldwide. All application packages I have ever tried from Microsoft (Office, Visio, Silverlight etc), Adobe (Flash, Reader, Photoshop etc), Apple (Quicktime, Safari, Itunes etc), Google (Chrome, Earth etc)...the list is endless, all these work perfectly to install via SCCM under the System Account. In fact I have never found a package that would NOT install under the system account.

However, I often come across smaller applications, custom applications which simply cannot be silently installed via a software deployment solution such as SCCM, regardless of the account its installed under, the problem is normally the installer packages dont come with silent parameters or requires some customization during the installation. For me, this is where InstallAware comes in, packaging up these ups with InstallAware means I can install them silently and so I thought, deploy them with SCCM. Also sometimes using InstallAware will be quicker then testing and working out what the silent and configration parameters are, even it its possible.

So heres a few facts for you:

* as mention, all downloaded application packages straight of the developers websites/FTPs work just fine under the system account
* my InstallAware packages do not install via SCCM using the System Account, the error is: The above folder is the local client PC cache where SCCM packages are executed from, the files exit and should exist already, they dont need to be recreated, but for whatever reason, this is the root problem with InstallAware packages.

* my installAware packages install fine by manually launching them with an admin account
* in SCCM, by creating something called a Task Sequence, and a "Run command line" step in the task sequence, launching from a SCCM Application Package, I am allowed to specify an alternative account to Run the installation under, this does work...however it complicates the setup and is undesirable.

So with the fact that install the package like normal under the system account doesnt work, but under the Task Sequence works, and the other users similiar experiences as per the other topic, I contest your claim that InstallAware packages are able to install under the system account.

Dear Urban,

Although I'm no expert of SCCM, and as I've said previously, honestly I've never used ...
but I have repeated once again my tests and I can confirm the an InstallAware setup can be installed if executed as SYSTEM.

As I already told you, I used "PSEXEC" but very probably, this can be done also with: Microsoft SCCM, Landesk, GPO scripts, etc install.

These are PSEXEC cmd line options:

Copy PsExec onto your executable path. Typing "psexec" displays its usage syntax.

Usage

usage: [\\computer[,computer[,...] | @file][-u user [-p psswd]][-n s][-l][-s|-e][-i [session]][-c [-f|-v]][-d][-w directory][-<priority>][-a n,n,...>] cmd [arguments]

computer
Direct PsExec to run the application on the computer or computers specified. If you omit the computer name PsExec runs the application on the local system and if you enter a computer name of \\* then PsExec executes the commands on all computers in the current domain.

@file
PsExec will execute the command on each of the computers listed in the file.

-u
Specifies optional user name for login to remote computer.

-p
Specifies optional password for user name. If you omit this you will be prompted to enter a hidden password.

-s
Run remote process in the System account.

-e
Loads the specified account's profile.

-i
Run the program so that it interacts with the desktop of the specified session on the remote system. If no session is specified the process runs in the console session.

-l
Run process as limited user (strips the Administrators group and allows only privileges assigned to the Users group). On Windows Vista the process runs with Low Integrity.

-c
Copy the specified program to the remote system for execution. If you omit this option then the application must be in the system's path on the remote system.

-n
Specifies timeout in seconds connecting to remote computers.

-f
Force the copy of the specified program if it already exists on the remote system.

-v
Copy the specified file only if it has a higher version number or is newer on than the one on the remote system.

-d
Don't wait for application to terminate. Only use this option for non-interactive applications.

-w
Set the working directory of the process (relative to the remote computer).

-x
Display the UI on the Winlogon desktop.

-priority
Specifies -low, -belownormal, -abovenormal, -high or -realtime to run the process at a different priority.

-a
Separate processors on which the application can run with commas where 1 is the lowest numbered CPU. For example, to run the application on CPU 2 and CPU 4, enter: "-a 2,4"

arguments
Arguments to pass (note that file paths must be absolute paths on the target system)

I have used my test setup package in the following ways:

> psexec -i -s c:\test\SysTest.exe (run as System account)
> psexec -i -s c:\test\SysTest.exe /s (run as System account in silent mode)

For your personal test, attached with this topic you will find my ready to use test "SysTestexe" along with PSEXEC tool.
Use the above command line and you of course will see that the package it is executed as SYSTEM as you expect.

In the meantime ... I will verify as soon as I can find a bit of time, with SCCM too.

PSTools can be found here:
http://technet.microsoft.com/en-us/sysi ... s/bb897553

Regards

I thought I'd add to this as I'm having similar trouble with a vendor package http://www.installaware.com/forum/viewt ... f=2&t=8581. Further investigation of the installation log shows some bleeding of contexts, as it is making some references to the logged on users directories even though it is running as System.

I've run my installer using PSEXEC -I -S and it still fails. Although interestingly PSEXEC runs under Network Service where as SCCM runs under Local Service (at least in my case).

I'm not sure what I make of the results yet but I'll mull it over at the weekend. My gut tells me that it is the way the vendor has scripted the install unfortunately.

I'm investigating on SCCM ... and I will tell you.

Regards

Hi Urban

I've managed to get mine installed through SCCM after a few days of playing. Are you still having problems?

Dear CHARL13,

I am very happy that you has been able to do the same with SCCM
I am also happy because you confirm what I previously said.

Any particular advice that would you want to share with other users?

Regards

This may be package specific and so not work for everyone but it might help:

Firstly launch <Package>.exe /s /l=C:\InstallLocal.txt from a command prompt as a locally logged on admin user.

Configure the SCCM command line to launch <Package>.exe /s /l=C:\InstallSCCM.txt.

Allow the package to deploy and study both C:\InstallLocal.txt and C:\InstallSCCM.txt. Look at the Variables block near the top of the file and look for any variables that are incorrect. You know that InstallLocal.txt worked correctly so you want to make sure that InstallSCCM.txt almost mirrors it. In my case, the desktop directory, shortcuts directories and quick launch directories were all configured for the logged on user rather than All Users.

If any variables are incorrect, ammend the SCCM command line to push the correct values, for example <Package>.exe /s /l=C:\InstallSCCM.txt DESKTOPDIR="C:\Documents and Settings\All Users\Desktop\". Be carefull with trailing backslashes and ensure they match the original.

Check the InstallSCCM.txt file again and ensure that all of the variables are correct, and that the changes are reflect in the Properties block. I had 1 incorrect property that I couldn't get rid which meant the desktop shortcut was being left behind on uninstall. I had to use a batchfile to delete it post install.

Search for "Command Line" in install.txt to get the actual command line being passed to the MSI. I found that it was pushing the property SRCDIR into the MSI, which on studying the MSI Script, was a requirement for all other actions. The absence of which meant the install actions were skipped and althought he install said it had completed, actually did very little.

Although this worked, it is a work around. The question remains as to why the logged on users directories are being detected, when the software was launched in a System context bubble. Is it an InstallAware oddity or is it the way the the 3rd party vendor has scripted the MSI?

Dear CHARL13,

Of course, if the installation logic of your 3rd party vendor executes actions for a particular folder, it will remains even if install it is launched as System.

Honestly, I don't think it is an InstallAware ... oddity ... to verify it just execute a test as I done previously.

Example,

If with MSI code you point to Desktop folder as SYSTEM, this won't work ... instead doing the same for all USERS or for a specific existing user will work.

Regards

Hi guys,

Charl13, thats good work, however as far as workarounds go, I find it easier to use my workaround with Task Sequence command lines under an admin user.

I do think you were onto something though with this:

Although interestingly PSEXEC runs under Network Service where as SCCM runs under Local Service (at least in my case).

Thats obviously a big difference between PSEXEC and SCCM and can explain why InstallAware packages install under PSEXEC and not SCCM by default and without using workarounds such as mine and yours.

Francesco: isnt DESKTOPDIR a InstallAware Target Folder? is the problem that we need to make our InstallAware packages Windows XP or Window 7 specific, or perhaps 32bit or 64bit specific?

Dear Urban,

Yes it is an IA predefined and I used DESKTOPDIR variable as example.

What I was trying to say is that, according to the specific needs of a project, it is good idea to check what are the possible issues that may be affected by installing as SYSTEM. In other words, if the logic of the installation performs specific operations as for current user (... as when installing per user), when executed as SYSTEM, probably it will fail. This however is not due by a malfunction of InstallAware but instead, on how the logic has been designed.

To my knowledge in most cases this is mainly the cause the of possible errors.

Regards