Group Policy Software Installation (GPSI) is an effective (and free) way to manage software deployment. After years of use, I have found these five common issues. Let’s walk through the top five issues and the solutions to a fix them! We will figure out why group policy software installation not working!
Problem 1: Does the GPO apply?
If the software isn’t installing on the computer, the first place to start is at the scope tab of your GPO. Basically, if the GPO can’t apply to the computer (or user) – the application won’t install. You can ensure the GPO is applying by running a GPResult on that computer and ensuring that the GPO applied and that the application appears under Software Installation.
If the software doesn’t appear, take a look at The Top 10 Ways to Troubleshoot Group Policy. One special note about software deployment. If you deploy the software to the user side (assigned or published), the GPO must be linked to an OU containing users (or you have to enable loopback).
Also remember that GPSI applies in the foreground. Installation can only happen on a reboot or logon (and only if the GPO was downloaded beforehand). In a default environment, it is easiest just to reboot twice. If you want to turn this into a single reboot, you can enable “Always Wait on the Network at Computer Startup or Logon”. Be aware that this will slow down startups/logons.
Problem 2: Does the software install quietly?
For an MSI to deploy through GPSI, it must be able to install silently. To test this, you only need MSIEXEC! To test quietly, here is your syntax:
msiexec /I “PATHTOYOURMSI” /QB /T “PATHTOMST”
and here is a practical example:
After the installation progress bar has completed (and MSIEXEC.exe has terminated in the Task Manager), you should be able to launch your application through any created shortcuts. If the application errors out during install, you most likely need to specify additional options in your MST file. An example of this would be Adobe Photoshop Elements. If you do not include the serial number in the install, it can’t be deployed through GPSI.
Problem 3: Where is the MSI?
As a best practice, do not store your MSIs in Sysvol. While it may look like a great way to create redundancy, it is going to be a management nightmare. Instead, set up a dedicated file server (or better yet – use DFS!) and organize your MSI structure. For our environment, we organize the MSIs by manufacturer – then product – then version. This vertical hierarchy allows us to easily find (or update) any piece of software.
The second point to consider is how you load the MSI into Group Policy. Whenever possible, use a DFS Namespace (first choice) or a UNC path (second choice) over an IP. IPs can change (though you should be using a reservation).
Problem 4: Can X access the MSI?
So even though your software is compatible, your users/computers that need to install this software might not be able to reach it. Take a look at the share and file/folder permissions where the MSI is located. If you are deploying to a computer, that computer needs Read/Execute. The same thing applies to a user. In our environment, we actually grant authenticated users read/execute to the share and root folder. This ensures that every deployed MSI always have the correct permissions.
Problem 5: Where are the logs?
If you’ve made it this far, you likely have an installation issue. This can be caused by a misconfigured machine, an old piece of software breaking the upgrade, or a missing component. Lucky for us, GPSI does a decent job logging these kind of issues. Open up event viewer on the troublesome machine and selection the system log. Filter the log to show any issues by Application Management Group Policy (the source) and to only show Warnings and Errors.
As you can see from the error above, GPSI couldn’t install this software until another logon has occurred. If you receive any strange MSI errors – just do a quick search on Experts-Exchange or AppDeploy for that error (ex: 1204) plus MSI. Because these error codes are consistent across nearly all MSIs, you don’t really need to search for your specific product.
One caught me out the other day that I’d never seen before, app looked like it was installing but never completed – turns out the installer language was German but all machines were English – enable Ignore Language and then deployed OK.
That is a first for me as well! Thanks for the tip!
David did you get this sorted? We were experiencing a similar problem. Software had been deploying using GPOs successfully then started failing. In the end it was IPv6 causing chaos. IPv4 network with IPv6 enabled. Fixed this by disabling IPv6 on all Desktops and static devices and GPOs now work. Random!
That is super random Sue! Just for kicks, have you seen any DNS errors or replication errors with your domain controllers?
Hi Joseph
Random GPSI issue not covered here (and I wonder if you might point me in the right direction?)
New Win8.1 machines installed to a lab, end of last year. Old GPSI package deployed to generations of computers over 8 years, never with problems. A number of new machines installed the software at build time, but some didn’t. Trying to solve this problem now.
Event logs from last year during the build showed:
– The assignment of application blah from policy blah failed. The error was : %%1274
– The removal of the assignment of application blah from policy blah failed. The error was : %%2
I fixed this at the time by tinkering with startup network timings:
– GPO Computer Settings > Specify startup policy processing wait time
– Eventually fixed properly by tagging ports on a switch as these ports were not configured properly and weren’t bringing the connection up fast enough when machine started up
ANYWAY. Zoom forward to March 2015 and I’m trying to fix the machines that never received the software. I’ve re-downloaded the whole policy using gpupdate /force. I get “Changes to software installation settings were applied successfully” in system log and no other errors. Running GPRESULT /H with elevated command prompt allows me to verify that the computer is indeed receiving the setting to install the package. Checked permissions, even though I know they wouldn’t have changed in 8 years as I’m the only one who manages the network – no issues there.
I’d like to avoid de-joining and re-joining affected machines to the domain, any ideas where to start?
By the way, I’ve already attempted to enable userenvDebugLevel logging, as well as appmgmtDebugLevel logging, neither of which appear to work in Win 8.1 (MS article confirms latter definitely doesn’t work!)
Mat – you have done almost everything that I would do before opening a case with MS. The last thing that I would do is see if the application registered itself with group policy. If it did, I would delete the application key. You can use MSI Manager (available on this page: https://deployhappiness.com/resources/tool-downloads/) to do this.
Either way – let me know what you find out!
I’ve pulling my hair on this one. There are event IDs 101, 103, 108 and 1112 showing up every 5 minutes even though MSI are successfully installed on a client test machine. I have made necessary changes in GPO attached below and rebooted DC but no joy – still cluttering my event System log stating that it failed to install which is not true. A shared drive can be accessed by anonymous/guest users from domain and non-domain machines on the same LAN. No issues with AD, DNS, DHCP etc.
* Computer Configuration
* Policies
* Administrative Templates
* System
* Logon
ENABLE: Always wait for the network at computer startup logon
* Group Policy
ENABLE: Specify startup policy processing wait time (temporarily set to 120 will change to 30 later)
Errors:
101
The assignment of application 7-Zip 9.20 (x64 edition) from policy DOMAIN base packages installation failed. The error was : %%1274
103
The assignment of application 7-Zip 9.20 (x64 edition) from policy DOMAIN base packages installation failed. The error was : %%1274
108
Failed to apply changes to software installation settings. The installation of software deployed through Group Policy for this user has been delayed until the next logon because the changes must be applied before the user logon. The error was : %%1274
1112
Failed to apply changes to software installation settings. The installation of software deployed through Group Policy for this user has been delayed until the next logon because the changes must be applied before the user logon. The error was : %%1274
Download MSIManager from this page: https://deployhappiness.com/resources/tool-downloads/
Run it and browse to a computer having this issue – remove 7.zip from the list. Restart and see if the issue goes away.
BTW the good example of how to deploy MSI via GPO I found here:
http://messenger.softros.com/help/domain-install.html
step-by-step instructions with screen shots
Thanks Taho! Those are nice and simple directions – good to see it using Windows 8 screeshots!