So I just deplyed a small upgrade to some machines but the application doesn't finish installing until anyone with admin rights logs on the local machine.

The new program version does not appear in Add/Remove for a few minutes after logging in.

The deployment was a command script that simply uninstalled by product code, and installs from a network location.

Running the script while logged in to the machine works fine.

The network access account permissions have been checked.

The system logs are clean.

I made sure the package was running with Administrator rights, whether or not a user was logged on.

Can anyone think of a reason as to why a program would not be able to install under these cicumstances?

Thanks
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Community Chosen Answer

1
The network access account permissions have been checked.Do you mean that you have added the machine accounts to the list of permissioned accounts? Because by default, the local System account (which will be being used by your deployment system) has no access to network resources.
Answered 12/23/2011 by: VBScab
Red Belt

Please log in to comment
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
since you're talking about uninstalling old versions by ProductCode I'm going to assume we're talking about an MSI here.
Just turn on systemwide logging for Windows Installer and have a look through the logs to identify the exact action that's causing the problem.

PJ
Answered 12/23/2011 by: pjgeutjens
Red Belt

Please log in to comment
1
I inherited this system, but the way the local machine accesses the network is twofold. The account serving as the Network Access and also the Client Install account is part of a security group that is included in the local Administrator group in the images and has domain permissions to access network resources. This account has been working for my organization for a long time.

Recently, another account has been created that is a global security group including rights to all computers and needed network resources, and has also been added as a Network Access account in SCCM.

I take issue with having two accounts intended to accomplish the same task being added to SCCM, but this is what was decided. Any thoughts on multiple accounts? I would love to have a reason to straighten things out, but I haven't been able to find solid documentation about why it shouldn't be done.

Since posting, I have learned that there are several different lockdown policies affecting the machines in question, which have been added over time at the behest of our security team. Removing those lockdown policies allows the program to install.

In effect, it looks like something in those lockdown policies is blocking the Admin rights SCCM uses to install programs. This has not been a problem in the past. BUT I have noticed other deployment problems where SCCM fails with a bad environment message. The bad environment error does not repeat if say, the small script I am pushing is added to a share on the SCCM server. It doesn't even need to be a application package.

There is a silver bullet in here somewhere, but finding it is starting to look like an easter egg hunt.

ORIGINAL: VBScab

The network access account permissions have been checked.Do you mean that you have added the machine accounts to the list of permissioned accounts? Because by default, the local System account (which will be being used by your deployment system) has no access to network resources.
Answered 12/23/2011 by: milhaus
Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity