Link to home
Start Free TrialLog in
Avatar of agradmin
agradmin

asked on

Group Policy install of software via startup script inconsistent

We have a script set to run via Group policy to install a small software package at startup. This script has proved to be inconsistent when run in this way (failures produce error code 1603 in logs), but in all cases the install works fine when the same script is run manually following user logon.

This does not appear to be linked to location (ie link speed) and is happening at all locations (including local network). All target PC's are Windows 10.

Our theory is that this may be due to timing and that the deployment needs to be delayed during PC start, but we're open to other suggestions.


Can anyone offer insight into this and provide a possible fix?
Avatar of Vadim Rapp
Vadim Rapp
Flag of United States of America image

Set the following in Rggistry:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Type: Reg_SZ
Value: Logging
Data: voicewarmup

then have the installation fail, collect the log from the machine temp folder , and upload here.


Your script probably will have better chances if you put it in the group policy not under machine configuration / startup, but under user configuration /logon.
Avatar of agradmin
agradmin

ASKER

Thanks Vadim, we were considering switching to a logon script so it's good you concur.


Update 9/24/19

I have set as a user GPO and initial tests look OK (would have to deploy to larger sample set to confirm consistency).

The only issue I now have is that admin privileges are required to install. Any work-around for that? I'd rather not use 'run-as' but could do so on a very temporary basis just to get the app installed throughout. Users would be unaware as the app is just a plug-in and we could use a temporary account.


Any thoughts on that?
You can use user login script in a computer GPO with loopback processing.

What is the application in question? Which user runs the script when it is installed?

Is there an interactive, interaction between the user and the application when ran?

If yes, this makes the I stall interactive and explains the reason for the failure when ran under system startup.

/silent /quiet should commonly be used in a startup as well as all requisite settings passed to the executable/msi package.
Thanks for the response. The app is actually just a small exe that I believe is just a plug-in to a Microsoft Dynamics client. This should be installed on all PCs throughout the domain.

We do have the install running silent/quiet - it is working on many PCs (including those used in initial testing) via a computer policy. When running the script manually (checks for existence, then runs the exe if needed) there is no interaction (when run as admin) and the install works consistently.
usually when a software deployment fails, it notes the reason in the event log.
The only issue I now have is that admin privileges are required to install.

1. see if by any chance setup.exe unpacks and launches setup.msi. If so, steal the latter and deploy. MSI published in GP runs in elevated mode since it's assumed to be authorized by the domain admin who created the GP¹.
2. there are some tools that wrap setup.exe into an MSI. If you manage to do it, then deploy that MSI as in #1.
3. Consider using Task Scheduler instead of the startup script. I did not try it myself, but this article seems promising, and the tasks do have checkbox "run with the highest privileges".

¹) One might wonder why the same logic does not apply to the logon script.
ASKER CERTIFIED SOLUTION
Avatar of agradmin
agradmin

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks for the guidance - I'll bear all suggestions in mind when faced with similar issues in future,
As a followup, there's an article "You receive an "error 1603: A fatal error occurred during installation" error message when you try to install a Windows Installer package"

and from all signs, it's probably the last one: "The SYSTEM account does not have Full Control permissions on the folder that you are trying to install the Windows Installer package to. You notice the error message because the Windows Installer service uses the SYSTEM account to install software."