/build/static/layout/Breadcrumb_cap_w.png

App won't finish installing until admin is logged in locally

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

Answers (3)

Posted by: anonymous_9363 12 years ago
Red Belt
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.
Posted by: milhaus 12 years ago
Yellow Belt
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.
Posted by: pjgeutjens 12 years ago
Red Belt
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
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ