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