installation of package failing due to system account

Hi All
I am a bit puzzled but hopefully someone can help me understand why certain packages are failing to install on Windows 7.    According to our packagers they have come ?across some roadblocks installing applications that will no install under the system account.  ConfigMgr gives the option to specify a user account under which is used to install vs the logged in users or system account.  Since they locked down Win 7 (and not sure what is locked), they cannot specify to install as the logged in users as it will result in a falure dur to the lack of admin rights.  The app will not installas the system account either because a lot of the default environments variables sucks as %userprofile% and the rest of hte Win7 system paths.  So as a workaround they want to use a generic admin account.  I am not sure if this will solve the problem they are experiencing if the local system account cannot even install the app.  Has anyone came across this before?  
 
The package they are testing with has the Run Mode under the Environment tab set on the Program to "Run with administrative rights" and the box checked to "Allow users to interact with this program" which mean it is running with the Local System Accounts credentials.

That wont work neither  a generic account its essentially doing the same thing as system. If they need to configure user settings they should look at  software to see if it can be installed per system vs per user or try usign the ActiveSetup registry key to where it will run what is needed per user.

Thanks, I will have them check that.  I am having them test the install by opening a command window under local system context to get more details on the error.  The only error they get is from the install logs with a -3.  That doesn't mean anything to me.  They did indicate they tested it by running the exe directly from the cache when an admin was logged in and it ran perfectly fine.

Just so that I’m on the same page…. Your packages are using PsExec (on Windows 7 this must be launched as an elevated user; see Jarvis blog for more detail http://verbalprocessor.com/2007/12/05/running-a-cmd-prompt-as-local-system/ ) and opening a command prompt using the following command:
 
Psexec –s –i cmd
 
Then they are preforming their test?
 
What software are they using to package this application? Is this an MSI? Have they looked at active setup?

-3 ?? I am assuming its an installshield install? Running from cache should work but it will setup the user stuff for that admin account right??

@Garth
The way they typically have been packaging apps is using a custom wrapper (exe) they created so the user gets prompted about what is going to occur.  In that custom wrapper it also calls an ini file that runs the various installs.  In this case it does 3 things.
 
First installs SAP
"msiexec.exe" /i "%apppath%SAP_BO_Planning_Consolidation_7.50.10.msi" TRANSFORMS=SAP_BO_Planning_Consolidation_7.50.10.mst /qb! /L*V C:\Control\Logs\SAP_BO_Planning_Consolidation_7.50.10.log ISSETUPDRIVEN=1 ADDLOCAL=ALL
 
Second installs Office 2010 Primary Interop Assemlies
"MsiExec.exe" /i "%apppath%o2010pia.msi" /qb! /l*v "c:\control\logs\o2010pia_MSI.log"
 
and third installs a SAP patch
"%apppath%BPCCLIENT10P_1-10009079.EXE" /s
 
The packager indicated he can run the custom wrapper (exe) directly from the cache on the win 7 machine using his admin credentials and it runs just fine however when he creates an advertisement that calls the program setup to run with administrator rights it fails.  They also tested creating another program running under the pacakger's credentials and setting up an advertisement and that worked fine.
 
I am trying to figure out why the local system account is not behaving as it should which is why I wanted to test the app by having them open up a command prompt under local system and running that exe so see what happens.
 

Hi Kathy,
 
There are a ton of reasons why it will not work, such as:

• There is a network connection to a particular drive
• There is a registry key that should exist
• The package must be run in interactive mode
• GPO conflicts
• Security policy conflicts
• Etc…

 
What is still unclear to me is, Have your packaging team, tested their package using the local system account (aka the psexec trick)
 
Using the trick, will help them narrow down things.